CPS 230 compliance for financial services software: a founder's practical guide

This is general, practical context for founders and product teams — not legal advice. If CPS 230 applies to your business, get a proper compliance and legal review alongside the technical work.

What CPS 230 actually is

CPS 230 is APRA's prudential standard on operational risk management, covering APRA-regulated entities — banks, insurers, super funds — across three areas: managing operational risk generally, keeping critical operations running through disruption, and managing the risk that comes from relying on third parties. It replaced a handful of older, narrower standards with one unified expectation: know your operational risks, be able to keep critical services running, and know exactly what you're relying on to do it.

Why it matters even if you're not APRA-regulated

The part founders in advice, lending and wealth-tech most often miss: CPS 230 doesn't stop at the regulated entity. If your software is a "material service provider" to a bank, insurer, super fund or licensed adviser group, that entity now has an obligation to assess and monitor you as part of their own compliance. In practice that means being asked for things a lot of early-stage software teams have never had to produce: a documented incident response process, evidence of tested business continuity, clarity on what your product depends on to keep running, and a real answer to "what happens if this goes down."

Losing a sales cycle to "we can't pass this vendor's operational risk review" is a much more common way CPS 230 costs a startup money than any direct regulatory action ever will be.

What "operationally resilient" software actually looks like

• Documented dependencies. Knowing — and being able to show — exactly what your product relies on: cloud provider, data processor, model provider, payment rail, and what happens to your service if each one is unavailable.
• Real monitoring and alerting, not "we'll notice if a customer complains." Critical operations need to be observable, with someone actually watching.
• A tested incident response process — not a document that says one exists, but one the team has actually walked through.
• An operational console that gives your regulated customers visibility into how their critical service is actually performing, rather than a black box they have to take on faith.
• Change management — updates and deployments that go through a controlled process, not an ad hoc push to production.

Common gaps in advice, lending and wealth-tech builds

A lot of financial-services software gets built by teams who are excellent at the domain — advice, lending, portfolio modelling — and newer to the operational discipline a regulated buyer will now expect. The most common gaps: no documented incident process, no clear answer for what happens if a key third-party API goes down, monitoring that only covers uptime and not data integrity, and a deployment process with no audit trail of what changed and when.

None of these are hard to fix. They're expensive to fix retroactively, under time pressure, during a due-diligence process — and comparatively cheap to build in from the start.

A practical checklist

• Can you list every critical third-party dependency your product relies on, in one document?
• Do you have a written, tested incident response process — not just a plan that exists on paper?
• Can a regulated customer see, in real time, how your service is performing against agreed expectations?
• Is every production change traceable — who made it, when, and why?
• If your primary cloud region went down for six hours, do you know exactly what happens next?

If you can't confidently answer most of these yet, that's normal for an early-stage product — it's exactly the gap between "works" and "ready for a regulated customer's vendor review."