AI in Australian Financial Services

CPS 230 Went Live on 1 July 2025. Your AI Vendor Is Now a Material Service Provider.

Most Australian financial services businesses, brokers, wealth managers, insurers, super funds, fintechs, neobanks, have a draft AI roadmap somewhere. Very few have mapped that roadmap to APRA's Prudential Standard CPS 230, which became fully operational on 1 July 2025 and which explicitly treats third-party AI and machine learning vendors as material service providers.

CPS 230 is only one of four regulatory regimes you need to plan for. ASIC has signalled AI governance as a 2025-26 strategic priority and continues to apply the Corporations Act s912A "do all things necessary" obligation to AI-driven advice and decisions. The OAIC enforces the Privacy Act 1988 and the Notifiable Data Breach scheme, which bite hard the moment an AI system processes personal information at scale. AUSTRAC expects AML/CTF programs to identify, manage and mitigate the new risks AI introduces into transaction monitoring and customer due diligence.

If you have read the earlier articles in this series (why not to DIY without understanding the operating reality, the production reality, the staffing gap, the vendor selection questions and the ACCC consumer law exposure), the thesis here will sound familiar: AI in financial services is not a technology program. It is a prudential program. The CIO does not own it alone. The Chief Risk Officer, Head of Compliance, AML Compliance Officer and the board all have skin in the game.

This article maps the four regulatory regimes, walks through the four AI failure modes that map directly to enforcement, and gives finserv leaders a control stack and readiness checklist you can put in front of your audit committee this quarter.

Part 1: The Four Regulators That Look at Your AI

Four regulators have a view on AI in Australian financial services, and they cover different ground. The mistake most firms make is treating "AI compliance" as a single problem. It is four overlapping problems.

APRA: Prudential Soundness and Operational Resilience

APRA regulates ADIs, general insurers, life insurers, private health insurers and superannuation trustees. APRA's relevant instruments for AI are:

• CPS 230 Operational Risk Management (effective 1 July 2025). Requires the board to maintain effective management of operational risk, including risk arising from third-party service providers. AI and ML vendors that support critical operations are material service providers. The standard requires a register, due diligence, ongoing monitoring and exit plans.
• CPS 234 Information Security. Requires the board to maintain an information security capability commensurate with the size and complexity of the entity and the threats it faces. AI systems handling regulated data sit inside this perimeter.
• CPG 235 Managing Data Risk. APRA's practice guide on data governance, lineage and quality. AI training and inference workloads inherit this expectation.

ASIC: Conduct, Consumer Protection and Licensing

ASIC regulates Australian Financial Services (AFS) licensees, credit licensees and listed entities. ASIC does not have an "AI Act," but several existing instruments bite hard:

• Corporations Act s912A: an AFS licensee must "do all things necessary to ensure that the financial services covered by the licence are provided efficiently, honestly and fairly." This is technology-neutral and applies to AI-driven advice, AI-powered chatbots and AI-assisted underwriting.
• Regulatory Guide 271 Internal dispute resolution: response timeframes (most complaints, 30 days) and minimum content requirements apply whether the decision was made by a human or an AI.
• Regulatory Guide 78 Breach reporting: significant breaches under s912D must be reported within 30 calendar days of becoming aware. AI failures that cause customer harm can be reportable.

OAIC: Privacy and Notifiable Data Breaches

The Office of the Australian Information Commissioner administers the Privacy Act 1988, the 13 Australian Privacy Principles and the Notifiable Data Breach scheme. AI systems that process personal information must meet APP 1 (open and transparent management), APP 3 (collection limitation), APP 5 (notification), APP 6 (use and disclosure), APP 11 (security) and APP 12 (access). For more detail, see our data sovereignty guide and our piece on how the wrong AI tools leak business data into LLM training.

AUSTRAC: AML/CTF Programs

AUSTRAC regulates AML/CTF reporting entities, which includes ADIs, remittance providers, designated services providers and a growing slice of fintech. The AML/CTF Act and Rules require a documented Part A program based on a risk assessment. When AI is used in transaction monitoring, sanctions screening or customer due diligence, it becomes part of that program and the risk-based assessment must explicitly cover it.

Part 2: The CPS 230 Lens (New Since 1 July 2025)

CPS 230 is the single biggest shift for finserv firms deploying AI. The standard consolidates and replaces older operational risk standards and introduces three obligations that bite directly on AI:

Critical operations. The board must identify the operations that, if disrupted, would have a material adverse impact on customers, the entity or the financial system. If an AI model sits in the middle of underwriting, claims, advice generation, fraud detection or transaction monitoring, it is almost certainly inside a critical operation.

Tolerance levels. For each critical operation the board must set tolerance levels for the maximum disruption it is prepared to tolerate. AI/ML failures, model drift, hallucinations in customer-facing flows, or a degraded vendor API, must be assessed against these tolerances.

Material service providers. A material service provider is one on which the entity relies to undertake a critical operation or that exposes the entity to material operational risk. Cloud-hosted LLM APIs, AI/ML platform vendors and specialist analytics vendors will almost always meet this test for a finserv user. CPS 230 requires a register, due diligence, written agreements with specified minimum content, ongoing monitoring and a documented exit strategy.

Business continuity testing must include scenarios where the AI vendor is unavailable, has degraded performance, or has been compromised. "We will switch to manual" is not a tested plan until you have actually tested it.

Part 3: The Four AI Failure Modes That Map Directly to Regulatory Consequences

Most AI compliance failures in financial services fall into four categories. Each maps to a specific regulatory instrument and a specific control.

The Moffatt v Air Canada decision (2024 BCCRT 149) is the most-cited precedent globally for the principle that a business is bound by representations its AI agent makes to a customer. Australian courts have not yet ruled on a directly analogous case, but the ACL, ASIC's s912A obligation and AFCA's mandate all point the same way: the AI's representation is the licensee's representation. We explored the ACL angle in detail in our ACCC consumer guarantees article.

Part 4: The Liability Flow

When something goes wrong with a customer-facing AI in financial services, the liability flow usually runs in one of three directions. The same incident can run in all three simultaneously.

A few practical points firms consistently underestimate:

• AFCA monetary limits matter. AFCA's compensation caps are set in the AFCA Rules and reviewed periodically. A single AI-driven systemic error across thousands of customers is the scenario that turns a small compensation cap into a large aggregate exposure.
• RG 78 has a 30-calendar-day clock. Significant breaches must be reported within 30 calendar days of when the licensee becomes aware. "Aware" is interpreted broadly. Your monitoring needs to detect the problem early enough that you still have time to investigate and report.
• NDB has a different 30-day clock. Where a data breach affecting personal information meets the "likely to result in serious harm" test, the OAIC and affected individuals must be notified as soon as practicable after the entity becomes aware (and after a 30-day assessment window). AI systems that process personal information at scale concentrate this risk.

Part 5: The Control Stack

The good news: the controls you need for AI in financial services are mature operational risk controls applied to a new asset class. Map them across the lifecycle.

For the underlying technical governance, our piece on AI agent governance, data access, privacy and human override covers the engineering layer in more depth. The control stack above sits on top of that engineering.

Part 6: Which Regulatory Regime Should You Plan For First?

No firm can uplift everything at once. The decision tree below is the rough triage we use when working with finserv leadership teams on AI strategy. It is not a substitute for legal advice, but it is a useful starting cut.

Most firms land in two or three quadrants at once. The order matters less than naming a lead regulator per use case so accountability does not fall between stools.

Part 7: The Readiness Checklist

Before any AI goes live in a financial services context, your compliance, risk and technology leaders should be able to answer yes to each of the following. If they cannot, you have a remediation backlog rather than a go-live.

1. Is this AI use case listed in our AI inventory with a named business owner and technical owner?
2. Has the use case been risk-classified, and does the classification trigger the right level of board or executive sign-off?
3. If a third-party AI/ML vendor supports this use case, is the vendor on our CPS 230 material service provider register with a compliant written agreement and a documented exit strategy?
4. Has a Privacy Impact Assessment been completed and signed off where personal information is processed?
5. Has the model been bias-tested on protected attributes, and is the fairness definition documented and approved?
6. Are model performance and drift monitored continuously, with thresholds that trigger investigation inside the RG 78 30-day window?
7. Are individual decisions and customer-facing conversations logged in a form that can be replayed for a complaint, an audit or an AFCA matter?
8. Is the use case covered in our Business Continuity Plan, with the manual fallback tested in the last 12 months?
9. Does the customer-facing experience meet APP 1 transparency expectations, and does our IDR process under RG 271 explicitly cover AI-driven decisions?
10. If this is an APRA-regulated entity, has the use case been mapped to tolerance levels for the critical operation it supports?
11. If this is an AML/CTF use case, has it been incorporated into the Part A program and risk-based assessment?
12. Is there a named accountable person (under FAR/BEAR or your internal accountability framework) who has both the authority and the information to oversee this AI in production?

One question settles it. If the regulator wrote to you tomorrow asking for evidence of how you manage AI risk in your business, would you send your existing operational risk pack with the AI rows highlighted, or would you have to build something from scratch? The first is where CPS 230 expects you to be. The second is where most firms still are.

Where Solve8 Helps

Australian financial services businesses rarely have BHP-scale governance budgets, yet they carry BHP-scale obligations the moment an AI sits inside a critical operation. Our work with regulated industry clients is informed by enterprise-scale governance projects across mining, energy and infrastructure, including our Tier 1 Infrastructure carbon reporting case study, and by purpose-built products like Carbonly.ai and RootCauseAI that demonstrate how regulated, auditable AI is built in practice.

Our AI Strategy service and Managed AI Services are designed to help firms map the four regulatory regimes onto their actual AI use cases, build the CPS 230 register, and instrument the controls that survive a regulator's first request.

If you would like to walk through the readiness checklist with us against your actual AI portfolio, book a confidential 30-minute consultation: calendly.com/solve8.

Related Reading:

• AI Agents and Australian Businesses: Why You Should Not Build Your Own Without Understanding This - The strategic context for the build-versus-buy decision that sits underneath every CPS 230 register entry.
• After You Build: The Hidden Operating Reality of DIY AI Agents for Australian Businesses - What CPS 230 monitoring and incident response actually looks like day to day.
• The Hidden Hiring Bill: Five Specialist Roles Your DIY AI Agent Actually Needs - The staffing gap behind every "we will manage it in-house" decision.
• 10 Questions to Ask Before Choosing an AI Vendor in Australia - The vendor due diligence questions that double as CPS 230 material service provider evidence.
• ACCC Consumer Law and AI for Australian Businesses - The consumer law layer that sits underneath the ASIC s912A obligation.
• AI Agent Governance, Data Access, Privacy and Human Override - The engineering controls that sit underneath this prudential control stack.

Sources:

Regulatory framework references: APRA CPS 230 Operational Risk Management (effective 1 July 2025); APRA CPS 234 Information Security; APRA CPG 235 Managing Data Risk; ASIC Regulatory Guide 271 Internal dispute resolution; ASIC Regulatory Guide 78 Breach reporting under s912D Corporations Act 2001; Privacy Act 1988 and the Notifiable Data Breach scheme; AFCA Rules; DISR Voluntary AI Safety Standard (2024); AUSTRAC AML/CTF program guidance. Liability precedent: Moffatt v Air Canada 2024 BCCRT 149. This article is general information, not legal or compliance advice; obtain advice specific to your entity and use case.