APP 1.7 Automated Decisions in Fraud and KYC Controls

Regulatory Strategy · October 2026 · Australia

From 10 December 2026, Australian privacy policies must disclose significant automated decisions. A governance model for fraud, KYC, screening and scam controls.

Automated decision-making in fraud controls becomes a privacy disclosure question in Australia from 10 December 2026. From that date, an organisation that uses a computer program to make, or substantially help make, decisions that could significantly affect a person’s rights or interests must say so in its privacy policy.

The Office of the Australian Information Commissioner (OAIC) released its final guidance on 30 September 2026, updating its APP 1 Guidelines and publishing a fact sheet and flowchart for the new Australian Privacy Principles (APPs) 1.7 to 1.9.

For fraud, financial crime and identity teams, writing the privacy policy paragraph is the easy part. The harder question is which of the many automated controls in the customer lifecycle fall within scope, who owns each one, and how the disclosure stays accurate as models and rules change. That question cuts across fraud scoring, customer due diligence (CDD), identity verification, payment authentication and scam interdiction, and it rarely sits with a single team.

This article sets out what the obligation requires and proposes a governance model risk leaders can use to answer it once, across domains. It is general information, not legal advice.

Automated decision-making fraud controls visual mapping fraud and identity controls to the automated decisions they make, with a four-layer governance model for APP 1.7 disclosure

Fraud, identity, screening, payment authentication and scam controls can each make or shape decisions about a customer. A single register keeps their disclosure consistent.

Program involved

A computer program makes the decision, or does something substantially and directly related to making it.

Significant effect

The decision could reasonably be expected to significantly affect an individual’s rights or interests.

Personal information

Personal information about the individual is used in the program’s operation.

Disclose

Where all three are met, the privacy policy must describe the decisions and information used.

Quick answer

From 10 December 2026, Australian organisations must disclose in their privacy policy when a computer program makes, or substantially and directly helps make, decisions that could significantly affect individuals. Many fraud, identity, screening, payment authentication and scam controls can meet that test, even where an analyst makes the final call or a vendor supplies the model. A single cross-domain register of automated decisions, tied to change control, keeps the disclosure accurate.

What the new APP 1 obligation requires

APP 1.7 applies when three conditions are all met:

the entity has arranged for a computer program to make a decision, or to do something substantially and directly related to making it
the decision could reasonably be expected to significantly affect an individual’s rights or interests
personal information about the individual is used in the program’s operation

Where they are met, APP 1.8 requires the privacy policy to describe the kinds of personal information used, the kinds of decisions made solely by the program, and the kinds of decisions where the program does something substantially and directly related to the decision. APP 1.9 confirms that refusing or failing to make a decision counts, and that the obligation applies whether the outcome is beneficial or adverse.

Three features matter most for fraud and identity controls.

Human review does not take a control out of scope

The Explanatory Memorandum describes “substantially” as the program being a key factor in facilitating the human’s decision, and “directly” as having a direct connection with making it. A fraud score that analysts almost always follow is likely to meet that description even though a person makes the final call.

The scope is wider than AI

The OAIC’s final guidance confirms the requirements reach well beyond AI-driven decisions and may capture ordinary software, decision-support tools and embedded technologies. Rules engines and threshold logic are not exempt because they are simple.

Third-party systems still count

The obligation attaches to the entity that arranged for the program to be used. If a vendor’s model makes or shapes the decision, the organisation deploying it still needs to understand and disclose it, and contracts should state clearly who is making the decision.

Which automated decision-making fraud controls are exposed

Few organisations will struggle to identify a credit-decisioning model as in scope. Fraud and financial crime controls are less obvious because they are framed internally as protections rather than as decisions about a customer. From the customer’s side, many of them refuse, delay or restrict something.

The table maps common controls to the decision each one makes or shapes. Whether a particular control meets the “significantly affect” condition depends on its real effect, so the right-hand column is a question to test, not a conclusion.

Control	Decision it makes or shapes	Question to test
Identity verification at onboarding	Accept, refer or decline an application	Does a failed check stop the person opening an account or receiving a service?
PEP and sanctions screening	Hold onboarding or a payment pending match review	How long can a hold last, and what does the customer lose while it does?
Fraud scoring on payments	Allow, step up, hold or decline a transaction	Is the outcome a short delay, or a refused payment the customer cannot easily retry?
Risk-based payment authentication	Approve without friction, or challenge and sometimes decline	Is a challenge an inconvenience, or does a failed challenge block the purchase?
Scam interdiction	Pause, delay or stop an outgoing transfer	Does the pause affect a time-critical payment such as a property settlement?
Transaction monitoring and customer risk rating	Raise alerts that may lead to restriction or exit	Does the output materially drive account restriction or closure?

Two patterns that stand out

Looking across the table, two patterns explain why disclosures written team by team tend to fail.

One customer, many controls The same customer can pass through five or six of these controls in one journey, each owned by a different team.

Overlapping personal information Most controls draw on identity attributes, device and location data, transaction history and behavioural signals. Disclosures written separately by each team will either repeat each other or contradict each other.

A cross-domain governance model for automated decisions

A practical answer is a single register of automated decisions spanning fraud, financial crime, identity and payments, with privacy as reviewer rather than sole owner. A workable model has four layers.

Inventory each decision, not each system

Record the decision a control makes or shapes rather than the platform it runs on. One transaction monitoring system can support several decisions, such as alert generation, customer risk re-rating and account restriction, and each may need its own assessment. For every decision, capture the business owner, the systems and vendors involved, the personal information used and the possible outcomes, including refusal.

Assess significance and human involvement consistently

Apply one test across all domains for whether a decision could significantly affect rights or interests, and one test for whether the program’s contribution is substantial and direct. Record the reasoning. A fraud team and a KYC team should not reach opposite conclusions about controls that work in the same way.

Map in-scope decisions to disclosure language

Group in-scope decisions into the kinds of decisions and kinds of personal information the privacy policy will describe. A shared register prevents duplicated or conflicting wording. Disclosure operates at the level of kinds, and commercial-in-confidence information about the systems is excluded, which leaves room to be transparent without describing detection logic.

Tie the register to change control

The disclosure has to remain accurate after 10 December. Add an automated-decision check to the change process for models, rules, thresholds and vendors. A fraud model that starts declining payments it previously referred, or an identity vendor that introduces biometric matching, may change what the policy needs to say.

Check disclosures against tipping-off obligations

Financial crime teams should check privacy policy wording with whoever advises on tipping-off obligations under the AML/CTF Act, so a privacy disclosure never signals what prompts a suspicious matter report.

Where accountability should sit

Because these decisions cross domains, accountability usually works best at two levels, with privacy and legal providing review.

Decision owner

Each decision has a business owner in the team that runs the control.

Register owner

A single executive, often the Chief Risk Officer or a delegate, owns the register and settles disagreements about scope.

Privacy and legal review

Privacy and legal review the assessments and own the final policy text.

The same structure answers a question boards are likely to ask after December: how many decisions about customers are now made or shaped by software, and who signs off when that changes?

What to do before 10 December

Inventory fraud, identity, screening, payment authentication and scam controls, starting with those that can refuse or stop something.
Apply the OAIC’s three-condition test consistently and record the reasoning for each decision.
Identify vendor-provided models and confirm contractually who makes each decision.
Draft grouped disclosure language with privacy, legal and financial crime input.
Add an automated-decision check to model, rule and vendor change processes.
Report the register and its ownership to the risk committee.

How Nexiant supports automated decision governance

Nexiant brings together specialist capabilities across AML screening, identity verification, transaction monitoring and payment authentication through MemberCheck, NameScan, FraudShield and GPayments. Organisations running these controls can use the model above to decide which automated decisions need disclosure, and to keep that disclosure accurate as their controls change.

Frequently Asked Questions

When does the automated decision transparency obligation start?

It commences on 10 December 2026. The OAIC released its final guidance on 30 September 2026, including updated APP 1 Guidelines, a fact sheet and a flowchart.

Which automated decision-making fraud controls are likely to be in scope?

Any control that makes, or does something substantially and directly related to making, a decision that could significantly affect a person, using their personal information. Identity verification at onboarding, screening holds, fraud scoring on payments, risk-based payment authentication, scam interdiction and transaction monitoring that leads to restriction or exit should all be tested against that condition.

Does a fraud alert reviewed by an analyst still need to be disclosed?

It may. The obligation covers programs that do something substantially and directly related to a decision, not only fully automated decisions. If the score is a key factor in the analyst’s decision, human review is unlikely to take it out of scope.

Do we have to explain how our fraud or screening models work?

No. The privacy policy must describe the kinds of personal information used and the kinds of decisions involved, not the detection logic. Commercial-in-confidence information about the systems is excluded. Check the wording against AML/CTF tipping-off obligations.

Do vendor-provided identity and screening tools count?

Yes. The obligation sits with the entity that arranged for the program to be used, so a vendor’s model that makes or shapes a decision still needs to be assessed and, where in scope, disclosed.

Map the automated decisions across your controls

Speak with a Nexiant expert about how your fraud, identity and financial crime controls fit together, and where automated decisions sit across them.

Speak to our fraud and identity team

This article was accurate at the time of publication in October 2026 and is intended for general informational purposes only. It does not constitute legal, regulatory or compliance advice. Organisations should seek qualified professional guidance in relation to their specific obligations.