CPS 230 for AI. The operational playbook APRA expects you to have.
CPS 230 commenced on 1 July 2025. The standard does not mention artificial intelligence, but it regulates every material AI decision your organisation makes.
The first annual material service provider register was due to APRA by 1 October 2025. Since 1 July 2026 the contract requirements have reached pre-existing arrangements as well. APRA's prudential reviews are already running, starting with significant financial institutions and then moving to non-SFIs.
This post converts the standard into artefacts a CRO can act on: a register that classifies foundation-model vendors, tolerance levels that hold up on probabilistic systems, an exit strategy that acknowledges foundation-model lock-in, and a board pack your regulator will recognise.
What CPS 230 requires.
CPS 230 consolidates five earlier standards (CPS 231, CPS 232, SPS 231, SPS 232, and HPS 231) and applies to every APRA-regulated entity: ADIs, general and life insurers, private health insurers, RSE licensees, and authorised NOHCs.
- 01
Operational risk management.
Across every process that delivers a critical operation, the board is accountable and senior management is responsible for implementation.
- 02
Business continuity.
Documented tolerance levels and tested severe-but-plausible scenarios. Failure modes mapped to escalation paths.
- 03
Service provider management.
A maintained material service provider register and credible exit strategies. CPG 230, APRA's supervisory guidance, is the document APRA staff read before a prudential review.
Artificial intelligence is not a critical operation.
Listing "artificial intelligence" on a register is a category error, because AI is an input, not an operation. The critical operation is the decision it supports: a fraud alert, a credit decision, a claims triage, a member-advice interaction.
| Example | Critical? | Why |
|---|---|---|
| Credit-decisioning model in retail lending | Yes | The decision affects customer access to finance |
| General member chatbot with always-human escalation | Maybe | Depends on whether silent misrouting breaches tolerance |
| Internal GenAI summariser of adviser notes | No | Output stays internal and feeds no regulated decision |
The first job of a CPS 230 AI programme is to make this judgement consistently. The second is to document it, because the opening question in any prudential review is "show me the reasoning."
Classifying AI vendors on the MSP register.
APRA defines a material service provider as one the entity relies on for a critical operation, or one that exposes the entity to material operational risk. Third, related, and connected parties all count. The first annual register submission was due on 1 October 2025.
PolyGovern's third-party AI risk practice classifies vendors against the test below. A modern AI deployment runs through four tiers of provider.
| Tier | Provider | Materiality trigger |
|---|---|---|
| 01 | SaaS the entity contracts with (fraud vendor, wealth platform, claims automation) | Material whenever the SaaS supports a critical operation |
| 02 | Cloud provider hosting the SaaS (AWS, Azure, GCP) | Material where the cloud provider carries availability of the critical operation |
| 03 | Foundation-model API (OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Google Vertex) | Material where model output meaningfully shapes the decision |
| 04 | Training-data vendors, model hosts, fine-tuning providers | Material where fourth-party failure reaches the critical operation |
CPG 230 is explicit that fourth parties should sit on the register when they are material. That covers the cases where a licensed SaaS silently routes prompts or embeddings to a foundation-model provider the bank never contracted with. Regulated customers of that SaaS carry a documented exposure they did not sign up for, and the register must reflect it.
Five questions for every AI vendor.
Two "yes" answers mean the provider belongs on the register.
- 01Does the AI output support or constitute a decision on a critical operation?
- 02Is the AI output visible to a customer, a member, or a regulator?
- 03Can the entity substitute the AI provider within the business-continuity tolerance without degrading the critical operation?
- 04Does the AI provider process customer personal information, transaction data, or regulated records?
- 05Is the entity exposed to enforcement, customer harm, or financial impact if the provider fails for 24 hours?
The checklist below expands each question with evidence requirements, scoring guidance, and a sample register row.
On the NTSP consultation.
APRA's consultation on non-traditional service providers did not carve AI out, so every AI vendor touching a critical operation remains in scope.
Tolerance levels for probabilistic systems.
CPS 230 requires tolerance levels across three classical dimensions: maximum tolerable period of disruption, maximum tolerable data loss, and minimum service levels. These assume binary failure: a system is up or down, and data is retained or lost. Large language models do not fail that way.
Four AI failure modes classical tolerance does not model.
- 01
Output drift.
A provider-side model upgrade shifts output distribution. Nothing looks broken. Pass-rate on the entity's golden evaluation set falls by 4% and no one notices for six weeks.
- 02
Indirect prompt injection.
A retrieved document carries embedded instructions that redirect the model. The operation completes successfully. The wrong person receives the output.
- 03
Hallucinated factual output.
The model asserts non-existent content confidently. Courts have sanctioned filings with fabricated AI citations.
- 04
Runaway agentic loops.
Agent recursion triggers token or rate-limit events that hit the operation's availability. A classical service-level dashboard does not show them.
The five-dimension tolerance set.
For every AI-enabled critical operation, document:
| Dimension | Type | Measured against |
|---|---|---|
| Maximum tolerable period of disruption | Classical | Provider outage, model deprecation, forced migration |
| Maximum tolerable data loss | Classical | Prompt history, fine-tune state, embeddings |
| Minimum service levels | Classical | Throughput, latency, availability |
| Maximum tolerable output drift | AI-specific | Pass-rate on the entity's golden evaluation set |
| Maximum tolerable hallucination rate | AI-specific | LLM-as-a-judge evaluation plus sampled human review |
Classical tolerances catch deterministic failure. The AI-specific two catch silent drift and hallucinated output, which is how LLMs fail in practice. PolyGovern's risk-framework practice sets these tolerances against an entity's existing operational-risk taxonomy.
Exit strategy when your dependency is a foundation model.
Classical SaaS exit plans assume three things that foundation-model dependencies break.
- 01
Fine-tune lock-in.
A fine-tuned model does not port to a different provider's base. Re-tuning is fresh engineering work, and it brings its own behaviour regressions.
- 02
Embedding lock-in.
Vector indexes built against one embedding model are non-transferable. Re-embedding a corpus of millions of documents takes a scheduled programme of its own.
- 03
Prompt and evaluation lock-in.
Prompts and evaluation suites calibrated against one model need recalibration against a replacement. A prompt that reliably produces structured JSON from one model will over- or under-constrain another.
What a defensible exit strategy looks like.
Dual-model architecture from day one.
Two providers able to serve the operation with minor prompt and adapter changes. The second kept warm through weekly regression runs or a small percentage of live traffic.
Vector stores decoupled from the embedding provider.
Access control, chunking, and retrieval logic in the entity's own code, so the provider holds none of it.
AI escrow.
The AI analogue of software escrow. Fine-tune weights, prompt libraries, and evaluation harnesses deposited with a third party under release triggers tied to the CPS 230 materiality thresholds.
Tolerances calibrated to deprecation events.
Major providers have deprecated production checkpoints at short notice.
A documented minimum viable replacement.
The pared-down capability the entity will operate under for the duration of a replacement programme. It is the bridge state the entity runs on until the replacement is complete.
An exit strategy needs engineering behind it. A document with no architectural mitigation will not survive a real model deprecation.
Where AI sits in APRA's broader framework.
CPS 230 is one of four intersecting instruments. An entity that implements CPS 230 alone has a compliant operational-risk frame with an incomplete AI control set.
CPS 234
Information Security.
The information-security counterpart. APRA's CPS 234 warning to RSE licensees previews the CPS 230 supervisory posture.
FAR
Financial Accountability Regime.
FAR makes end-to-end management of a significant business activity personally attributable. AI-enabled critical operations are significant business activities. An accountable person must be named for each. Personal penalties reach $1.565 million per contravention.
ASIC REP 798
Conduct-side companion.
ASIC looked at 23 AFS and credit licensees and 624 AI use cases. Only 12 of those licensees had AI policies that addressed fairness, discrimination and bias risks, and only 43% had policies requiring AI disclosure to consumers. For dual-regulated entities, REP 798 is the conduct-side companion to CPS 230.
ISO 42001 + VAISS
AI-specific control set.
Where CPS 230 is silent on AI-specific controls, ISO/IEC 42001 and the Voluntary AI Safety Standard fill the gap. PolyGovern's ISO 42001 certification practice layers both on top of an existing CPS 230 programme.
The board report CPS 230 asks for.
The quarterly pack needs these six elements.
- 01
MSP register.
With AI classification flagged, row count, change month-over-month, and any additions or removals that crossed the materiality threshold.
- 02
Critical operations enabled by AI.
With performance against each tolerance dimension and pass-fail on golden evaluation sets.
- 03
Output drift and hallucination metrics.
With monthly trend against the tolerances. A breach is escalated the day it is found, and never sits in the pack as a line item.
- 04
AI incident log.
Covering disruption events, prompt-injection events, and model-deprecation events, with resolution status and lessons applied elsewhere.
- 05
Exit-strategy testing results.
For each material foundation-model dependency, including the minimum viable replacement walk-through.
- 06
Material supervisory correspondence.
Any APRA letter referencing CPS 230 or CPS 234 for an AI operation, and any heightened-supervision flag.
FAR statements that name AI.
An accountable-person statement for an AI-enabled critical operation names four things:
- The accountable person: the CRO, the CIO or a named business-line executive. A CDO or Chief AI Officer rarely holds this accountability.
- The critical operation in CPS 230 language, aligned to the register.
- The material service providers in the AI chain, referenced by register entry.
- The escalation paths for tolerance breaches.
Statements that describe AI as "a distributed capability across the organisation" are not FAR-compliant. A single person owns each AI-enabled critical operation. PolyGovern's board-level AI governance practice drafts the statements with the named accountable persons.
The first prudential review.
APRA's reviews start with SFIs and then move to non-SFIs. The CPS 234 cadence translates forward: letters first, formal directions next, enforceable undertakings where issues remain unresolved.
APRA expects AI to work as a co-pilot and never as the autopilot.
What to have ready.
Entities that can produce this evidence within a week pass. The rest get a letter.
What to do now.
Six actions, sequenced. Each maps to a specific gap a prudential review will find first.
- 01
Re-test the MSP register.
Run every AI-vendor entry through the five-question test. The entries written before 1 October 2025 pre-date the first review cycle.
- 02
Write tolerance levels on the five-dimension set.
Output drift and hallucination rate are new. The team will not have baselines. Establish them on production traffic this quarter so the next board pack has real numbers.
- 03
Engineer the exit strategy.
Dual-provider architecture, AI escrow, minimum viable replacement. Raise any of the three lock-ins without mitigation to the risk committee.
- 04
Check every vendor contract against the 1 July 2026 requirements.
Sub-processor disclosure is the most common gap. The 24-hour incident notification window is the second.
- 05
Rewrite the FAR statements.
The statements filed before the AI programme existed are incomplete by construction.
- 06
Rebuild the board AI report on the six-element structure.
The next pack the risk committee sees should be the first one APRA would recognise in a review.
Two CROs read CPS 230. One passes the AI review.
The one who reads it as an operational-risk standard passes a generic review and fails the AI questions. The one who reads it with the AI overlay (four-tier MSP mapping, the five-dimension tolerance set, an engineered exit strategy, the six-element board pack, FAR statements that name AI operations) passes both.
Free download · PDF · 10 pages
MSP classification checklist for AI vendors.
The five-question test with scoring, evidence requirements, a board sign-off block, and review-trigger cadence. Versioned for quarterly review.
Thirty-minute call
CPS 230 AI readiness review.
A senior consultant walks through your current register against the five-question test, with no deck.