CPS 230 and AI Vendor Dependency Mapping for Financial Services

APRA's CPS 230 Operational Risk Management standard came into effect on 1 July 2025, and it changes how banks, insurers, and superannuation trustees are expected to think about third-party risk. For firms that have started layering AI models and AI vendors into critical processes — fraud detection, claims triage, customer service, underwriting support — CPS 230 raises a question many technology teams haven't yet answered properly: do you actually know which AI dependencies sit behind your critical operations, and what happens if one of them fails?

What is APRA CPS 230?

CPS 230 is APRA's prudential standard on operational risk management, effective from 1 July 2025, replacing the previous outsourcing standard (CPS 231) and elements of the risk management standard (CPS 220). It applies to authorised deposit-taking institutions, general and life insurers, private health insurers, and superannuation trustees. The standard requires regulated entities to identify their critical operations, set tolerance levels for disruption, and maintain a register of material service provider arrangements — including the risks those providers introduce.

Why does CPS 230 matter for AI vendor relationships?

CPS 230 was written broadly enough to capture any service provider supporting a critical operation, and that includes AI and machine learning vendors — model API providers, managed ML platforms, and specialist AI vendors embedded in a workflow. If an AI service sits in the path of a critical operation, it is a material dependency under the spirit of the standard, whether or not your existing outsourcing register was built with AI in mind.

This matters because most AI adoption inside financial services has happened faster than governance processes have kept up. A model provider chosen by an engineering team for a pilot can end up embedded in a production workflow within months, often without going through the same vendor risk assessment a traditional core-banking or policy administration vendor would face.

What counts as a "critical operation" involving AI?

A critical operation, in APRA's framing, is a business function that if disrupted beyond the entity's tolerance would materially affect depositors, policyholders, members, or the entity's safety and soundness. Where AI is used to support decisions in these functions — not just as a peripheral tool — the underlying model and vendor arrangement needs to be assessed as part of that operation's dependency chain, not treated as a separate IT concern.

The practical difficulty is that AI dependencies are often less visible than traditional outsourcing. A single customer-facing process might rely on a cloud AI platform, a third-party foundation model accessed via API, and one or two smaller specialist vendors for fine-tuning or evaluation — each with its own subcontractor relationships that are rarely documented anywhere.

How should firms map AI vendor and model dependencies?

Dependency mapping for AI should extend the same discipline financial services firms already apply to core outsourcing: identify every AI vendor and model touching a critical operation, document what each does, and trace what those vendors themselves depend on. This means going one layer deeper than a standard vendor register — asking not just "who is our AI vendor" but "what does our AI vendor depend on to keep operating."

A reasonable starting structure includes: the operation or process the AI component supports; the vendor and specific model or service in use; whether the vendor operates the model directly or resells a foundation model from a further upstream provider; data flows in and out of the model; and the vendor's own business continuity and subcontractor arrangements. This is close to the kind of foundational work covered under data infrastructure planning, since much of the mapping depends on knowing where data actually moves, not just where a contract says it should.

What is concentration risk in AI vendor dependencies?

Concentration risk, in this context, is the risk that multiple critical operations depend on the same underlying AI vendor or model provider, so a single outage or vendor failure creates a compounding rather than isolated impact. Because a small number of foundation model providers underpin a large share of commercial AI tooling, many organisations have more concentration risk than their vendor register suggests — several "different" AI vendors may all sit on the same upstream model.

Consideration	Traditional outsourced service provider	AI vendor / model dependency
Visibility of subcontractors	Usually documented in contract	Often undisclosed or several layers removed
Substitutability	Generally well understood, tested via exit plans	Frequently untested — model behaviour differs vendor to vendor
Failure mode	Outage, breach, insolvency	Above plus silent model drift, degraded output quality, API deprecation
Concentration exposure	Assessed per contract	Can span many "different" vendors sharing one upstream model
Tolerance testing maturity	Established practice under prior outsourcing standards	Early stage for most regulated entities

How does this connect to broader operational resilience planning?

AI vendor dependency mapping is not a standalone compliance exercise — it should sit inside the same operational resilience planning that already covers business continuity, disaster recovery, and outsourcing risk. Firms that treat AI vendor risk as a separate, IT-owned conversation tend to miss the connections between AI dependencies and the critical operations they actually support.

It's worth noting that Australia's broader AI governance landscape — including the DISR Guidance for AI Adoption and the now-superseded Voluntary AI Safety Standard — sits alongside, not instead of, prudential obligations like CPS 230. Those frameworks are useful for general AI risk practice, but they are not a substitute for the specific critical-operations and material-service-provider requirements APRA-regulated entities need to satisfy.

Where do firms typically get stuck?

Most firms get stuck not because the concept is unclear, but because the underlying technical picture is incomplete — nobody has a reliable, current inventory of which models and vendors sit behind which processes. This is often a symptom of how AI capability was introduced: through fast pilots, individual teams, or point solutions, rather than through a coordinated AI product strategy that considers governance and vendor risk from the outset.

There's also a genuine commercial dimension here. A vendor relationship where your team simply calls an external API gives you limited visibility and limited ability to substitute if that vendor changes terms or degrades service. An engagement model that transfers real understanding of the model, its data flows, and its failure modes back to your own team — rather than leaving you dependent on a black box — makes the CPS 230 exit-planning and substitutability conversation far more tractable. This is one of the reasons dependency mapping and AI engineering work should be done together rather than treated as separate streams.

Getting started

A practical first step is a focused review: list the critical operations already defined under your operational resilience framework, then trace which AI vendors and models sit behind each one, including their known subcontractors. This alone usually surfaces gaps — models in production without a documented tolerance level, or vendor relationships that were never assessed against the same criteria as a traditional outsourcing arrangement.

For more on related themes, see our insights on operational modernisation and AI governance.

If you're working through what CPS 230 means for your AI vendor footprint, we can help — starting with a structured review of your critical operations and the AI dependencies sitting behind them.