AI in Australian financial services is regulated through four existing regimes: APRA prudential standards such as CPS 230 and CPS 234, ASIC conduct and licensing obligations, the Privacy Act administered by the OAIC, and AUSTRAC's AML/CTF rules. There is no single AI law. Compliance means mapping each AI use case to these regimes and applying operational risk controls to it.
Key takeaways
- APRA's CPS 230 took effect on 1 July 2025. AI vendors that support critical operations can qualify as material service providers.
- ASIC applies the technology-neutral s912A "efficiently, honestly and fairly" obligation to AI-driven advice, chatbots and underwriting.
- Four AI failure modes map directly to enforcement: bias, unlicensed personal advice, model drift and chatbot misrepresentation.
- Controls for AI are mature operational risk controls applied to a new kind of asset.
- Name a lead regulator for every AI use case so accountability does not fall between teams.
Which regulators oversee AI in Australian financial services?
Brokers, wealth managers, insurers, super funds, lenders and fintechs mostly have an AI roadmap. Fewer have mapped it to their regulators. "AI compliance" is four overlapping problems, owned jointly by the CIO, chief risk officer, head of compliance, AML compliance officer and board.
APRA: prudential soundness and operational resilience
APRA regulates ADIs, general and life insurers, private health insurers and superannuation trustees. Relevant instruments:
- CPS 230 Operational Risk Management (effective 1 July 2025): board oversight of operational risk, critical operations, tolerance levels and material service providers, with a register, due diligence, monitoring and exit plans.
- CPS 234 Information Security: an information security capability matched to the entity's size and threats. AI systems handling regulated data sit inside it.
- CPG 235 Managing Data Risk: guidance on data governance, lineage and quality that AI workloads inherit.
ASIC: conduct, consumer protection and licensing
ASIC regulates AFS licensees, credit licensees and listed entities. There is no AI Act, but existing obligations apply:
- Corporations Act s912A: licensees must do all things necessary to ensure financial services are provided efficiently, honestly and fairly. It applies to AI-driven advice, chatbots and underwriting.
- RG 271 Internal dispute resolution: timeframes (30 days for most complaints) and content requirements apply whether a person or AI made the decision.
- RG 78 Breach reporting: reportable situations under s912D must be reported within 30 days. AI failures that harm customers can be reportable.
OAIC: privacy and notifiable data breaches
The OAIC administers the Privacy Act 1988, the 13 Australian Privacy Principles and the Notifiable Data Breaches scheme. AI processing personal information must meet APP 1 (open management), APP 3 (collection), APP 5 (notification), APP 6 (use and disclosure), APP 11 (security) and APP 12 (access). From 10 December 2026, privacy policies must also explain certain automated decisions. See our data sovereignty guide and how the wrong AI tools leak business data.
AUSTRAC: AML/CTF programs
AUSTRAC regulates reporting entities including ADIs, remittance providers and many fintechs. AML/CTF programs must be based on a documented risk assessment, and the 2024 amendments restructured program obligations from 31 March 2026. When AI is used in transaction monitoring, sanctions screening or customer due diligence, it is part of the program and the risk assessment must cover it.
| Who they regulate | Primary AI exposure | Impact | |
|---|---|---|---|
| APRA | ADIs, insurers, super trustees | Material service providers and critical operations (CPS 230), information security (CPS 234), data risk (CPG 235) | Prudential |
| ASIC | AFS and credit licensees, listed entities | s912A, RG 271 IDR, RG 78 breach reporting | Conduct |
| OAIC | All APP entities | Privacy Act, 13 APPs, NDB scheme, automated decision transparency | Privacy |
| AUSTRAC | AML/CTF reporting entities | Risk-based program covering AI in monitoring and CDD | Financial crime |
How does APRA CPS 230 apply to AI?
CPS 230 is the largest shift for APRA-regulated entities deploying AI. Three obligations bite directly.
Critical operations. The board must identify operations whose disruption would materially affect customers, the entity or the financial system. An AI model in underwriting, claims, advice, fraud detection or transaction monitoring is likely inside a critical operation.
Tolerance levels. For each critical operation, the board sets the maximum disruption it will tolerate. Model drift, inaccurate customer-facing answers or a degraded vendor API must be assessed against those tolerances.
Material service providers. A provider the entity relies on for a critical operation, or that exposes it to material operational risk, is a material service provider. Cloud AI APIs, AI platforms and specialist analytics vendors will often meet that test. CPS 230 requires a register, due diligence, written agreements with minimum content, monitoring and an exit strategy.
Business continuity testing should include scenarios where the AI vendor is unavailable, degraded or compromised. A manual fallback counts only once you have tested it.
What AI failure modes trigger regulatory consequences?
Most AI compliance failures in financial services fall into four categories.
| Failure mode | Regulatory trigger and control | Impact | |
|---|---|---|---|
| Bias in lending or underwriting | Disparate impact on protected attributes, such as postcode proxying for ethnicity | ASIC s912A 'fair' obligation; federal anti-discrimination Acts; Australian Consumer Law | Pre-deployment bias testing, documented fairness definition, ongoing monitoring |
| AI straying into personal advice | A general chatbot nudges a customer toward a specific product | Corporations Act Chapter 7 personal advice definition; s912A | Scope boundaries, guardrails blocking personal-advice patterns, a person reviews tailored recommendations |
| Model drift in fraud or AML detection | A model trained on older patterns degrades against new fraud types | CPS 234; AUSTRAC risk-based obligations; possible reporting gaps | Continuous performance monitoring, drift thresholds, retraining cadence, vendor update SLAs |
| Chatbot misrepresentation | AI tells a customer something wrong about a product, fee or right | Australian Consumer Law ss18 and 29; AFCA; Moffatt v Air Canada 2024 BCCRT 149 | Answers grounded in an approved knowledge base, logged conversations, AFCA-ready complaint pathway |
Moffatt v Air Canada (2024 BCCRT 149), a Canadian tribunal decision, is widely cited for the principle that a business is bound by what its chatbot tells customers. Australian courts have not ruled on a directly analogous case, but the ACL, s912A and AFCA's remit point the same way. See our ACCC consumer law and AI article.
Where does liability go when customer-facing AI fails?
The same incident can travel several paths at once.
- Customer interactionAI provides advice, a decision or a representation
- Adverse outcomeWrong product, denied service, misstated term, biased decision, data exposed
- TriageComplaint, breach reporting trigger or NDB assessment
- AFCA / ASIC / OAICAFCA complaint, RG 78 report or notifiable data breach
- RemediationCompensation, regulator engagement, board incident review, control uplift
Three points firms underestimate:
- AFCA caps add up. One AI-driven systemic error across thousands of customers turns individual compensation limits into a large aggregate exposure.
- RG 78 runs a 30-day clock from when the licensee becomes aware, interpreted broadly. Monitoring must detect problems early enough to investigate and report.
- The NDB scheme runs its own clock. Suspected eligible breaches must be assessed within 30 days, and notified as soon as practicable once confirmed.
What controls does AI in financial services need?
Map mature operational risk controls across the AI lifecycle.
- Pre-deploymentRisk and impact assessmentPrivacy impact assessment, model risk assessment, fitness-for-purpose review, bias testing on protected attributes.
- Vendor selectionMaterial service provider due diligenceRegister entry, written agreement with CPS 230 minimum content, documented exit strategy.
- Go-liveAccountable sign-offBoard sign-off against tolerance levels for critical operations; mapping to an accountable person under FAR where it applies.
- Live operationsContinuous monitoringPerformance and drift dashboards, bias monitoring, vendor SLA tracking, logs that reconstruct any individual decision.
- Incident responseDetection and timingAlerts inside the RG 78 window, NDB assessment workflow, remediation pathway, complete complaint files.
- Annual cycleIndependent reviewInternal audit of AI controls, independent validation for high-risk models, continuity testing including vendor outages.
The engineering layer underneath is covered in AI agent governance, data access and human override.
Which regulatory regime should you prioritise for AI?
This triage is a starting cut, not legal advice.
Which is your dominant exposure?
- APRA-authorised entity with AI inside a critical operationAPRA-led: CPS 230 register, tolerance levels, continuity testing, board reporting
- AFS or credit licensee with AI affecting consumer decisions or adviceASIC-led: s912A mapping, RG 271 pathway, RG 78 breach detection
- AI processing personal information at scale, including through a third-party modelOAIC-led: privacy impact assessment, APP 1 transparency, NDB workflow, residency review
- AI in transaction monitoring, sanctions screening or due diligenceAUSTRAC-led: program update and risk assessment of the AI controls
Most firms land in two or three rows. The order matters less than naming a lead regulator per use case.
What should be on a financial services AI readiness checklist?
Before any AI goes live, compliance, risk and technology leaders should be able to answer yes to each:
- Is the use case in our AI inventory with named business and technical owners?
- Is it risk-classified, triggering the right level of sign-off?
- If a vendor supports it, is the vendor on our material service provider register with a compliant agreement and exit plan?
- Is a privacy impact assessment complete where personal information is processed?
- Has the model been bias-tested, with an approved fairness definition?
- Are performance and drift monitored, with thresholds that trigger investigation inside the RG 78 window?
- Are decisions and conversations logged so they can be replayed for a complaint, audit or AFCA matter?
- Is the manual fallback in the continuity plan and tested in the last 12 months?
- Does the customer experience meet APP 1 transparency, and does IDR cover AI-driven decisions?
- For APRA-regulated entities, is the use case mapped to critical operation tolerance levels?
- For AML/CTF use cases, is the AI covered by the program and risk assessment?
- Is there a named accountable person with the authority and information to oversee it?
If the regulator asked tomorrow for evidence of how you manage AI risk, could you send your existing operational risk pack with the AI rows highlighted? That is where CPS 230 expects you to be.
How Solve8 can help
Our consultants and engineers help financial services organisations map AI use cases to their regulators, build material service provider evidence and put monitoring and logging in place, through our AI strategy and managed AI services. AI runs on your infrastructure in Australia, and a person approves before anything reaches a customer. Talk to us about your AI portfolio.
Sources: APRA CPS 230, CPS 234 and CPG 235; ASIC RG 271 and RG 78; Corporations Act 2001 ss912A and 912D; Privacy Act 1988 and the NDB scheme; AFCA Rules; AUSTRAC AML/CTF program guidance; Moffatt v Air Canada 2024 BCCRT 149. General information, not legal or compliance advice.
