APRA CPS 230 · operational resilience

When the regulator asks you to prove the decision, the AI can’t be the one that made it.

The AI reads the evidence and extracts the facts. A deterministic engine makes every compliance decision, the same way every time, so you can replay it exactly when APRA asks.

uploaded evidenceregisters · testspolicies · risksAI · READS ONLYextracts the factsfrom the documentsnever decides anythingfactsDETERMINISTIC ENGINEevery decision, by ruleversioned · explicit · not inferredsame evidence → same verdictrun after run, identicalthree lines of defence — each validated by a personL1operationsruns the controlL2compliancevalidates the evidenceL3internal auditstands behind itREPLAYABLE AUDIT TRAILevery decision, with the exact inputs and the rule version it ran — so when APRA asks, you replay it exactlythe AI read · the rules decided · the people validated · and all of it can be proven again
APRA CPS 230regulated finance
Assurance platformthree lines of defence
In active developmentengine proven on synthetic data

The situation

An Australian financial institution needed to keep up with CPS 230, which is the operational resilience standard APRA now holds every bank, insurer and super fund to.

The short version of what the standard asks for is this. You have a set of critical controls, and you have to be able to show, at any moment, that they are actually working. And it is not enough for one team to say so. Three separate lines have to be satisfied independently. The operations people who run the controls, the compliance people who monitor them, and internal audit, who has to be able to stand behind the whole thing. Each of them tests, reviews and signs off on their own.

Done by hand, that is hundreds of hours a quarter of spreadsheets, email chains, and audit packs assembled the week before a deadline. So the pull towards automation is obvious, and so is the pull towards throwing a large language model at it, because a lot of the work looks like reading documents and summarising them.

And that is exactly where it gets dangerous.

The hard part

The thing that makes this different from most “AI reads your documents” problems is what happens afterwards.

In a lot of domains, if the AI gets something a bit wrong, you notice, you correct it, and you move on. Here, the output of the system is a compliance decision. Whether a control is adequately evidenced. Whether a line of defence can rely on the work of the line below it. Whether something needs to be escalated to the board as a risk. Those decisions end up in front of a regulator.

And a regulator does not just ask “what did the system decide.” They ask “show me how it decided, show me the evidence it used, and show me that if you ran it again on the same evidence, it would decide the same thing.” That last part is the one that quietly rules out a whole category of approaches. If the thing that made the decision was a language model, you cannot honestly promise that. Run it twice and you might get two different answers, two different explanations, two different confidence levels. That is fine for a chatbot. It is not fine when you are being asked to prove a decision was sound and repeatable.

the line the model never crossesAI · what it does· reads uploaded documents· extracts structured facts· registers, tests, risks, policiesreading. nothing more.DETERMINISTIC ENGINE · what decides· is the evidence adequate· what tasks each line needs· does a reliance decision hold· what must escalate to the boardevery compliance call, by rule
The AI is fenced to one side of a hard line. It reads the documents and extracts the facts. Every actual compliance decision is made by the deterministic engine on the other side.

So the hard part was not “can we use AI to read the evidence.” Of course we can, and it is genuinely useful for that. The hard part was drawing a very firm line between the reading and the deciding, and making absolutely sure the model never crossed it.

What we did

We split the system in two, and we were strict about it.

The AI’s job is to read. It takes the documents an institution uploads, the control registers, the test results, the risk registers, the policies, and it extracts the structured facts out of them. That is real work and the model is good at it. But that is the entire extent of what it is allowed to do. It reads, it extracts, and it hands the facts on.

Every actual decision is made by a deterministic engine sitting downstream of the model. Whether the evidence for a control clears the quality bar. What tasks that generates for each of the three lines. Whether a reliance decision holds. Whether something has to be escalated. All of that is computed by explicit, versioned rules, not inferred by a model. The same facts always produce the same decision, with the same explanation, every single time. And every decision is written to an insert-only trail with the inputs it used, the version of the rules it ran, and the outcome, so that when someone asks you to prove it, you can replay it exactly.

the same evidence, run three timesevidence packone institutionrun 1EQS 42 / 100hash 3f9a…c1run 2EQS 42 / 100hash 3f9a…c1run 3EQS 42 / 100hash 3f9a…c1IDENTICAL, EVERY RUNthis is what you replay for APRAa model on its own cannot promise this. the same prompt can give three different answers.
Run the same evidence through the engine as many times as you like and it produces the same verdict, identically, every time. That is the property a regulator is really asking for.

We tested this on a full synthetic institution, a fictional bank with a complete set of evidence, and the property held. The engine produced the same verdicts run after run, with matching results each time, from the same evidence. That is the thing you want to be able to say to a regulator, and it is the thing a model on its own can never quite say.

There is one part of this that people get wrong in the other direction, and we were deliberate about avoiding it. It would have been easy to let the deterministic engine quietly auto-pass everything that cleared the threshold and only bother a human with the failures. We did not do that. The engine computes the quality score first, and then the item is put in front of the responsible person to validate, even when it is comfortably above the line, and it is flagged when it falls below. The point of the second line of defence is that a human actually looked, not that the software waved most things through and escalated the rest.

the tempting shortcut we did not takeauto-pass everything above the threshold · only show a human the failuresthen the second line of defence is just software waving things throughwhat we did insteadengine computes the scoreEQS, deterministically, firsta person validates iteven when it is above the linethe human judgment the standard asks foris actually performed, not assumed.
The engine does the arithmetic first, then a person validates the item, even when it cleared the threshold. The human judgment the standard asks for is actually performed, not assumed.

And because this is multi-tenant, one more rule runs underneath all of it. Every task, every control, every decision is strictly isolated to its own institution. One tenant’s evidence and decisions can never bleed into another’s. In this domain that is not a nice-to-have, it is the difference between a system a regulated institution can actually use and one it cannot.

The outcome

The platform is in active development, and the core of it, the deterministic decision engine, is built and proven. On a full synthetic institution’s worth of evidence, it generates the compliance decisions across all three lines of defence, produces the same verdicts repeatably from the same evidence, and writes every one of them to a replayable audit trail.

What the institution gets is a system where AI takes the enormous manual reading burden off the compliance team, without ever becoming the thing that decides whether they are compliant. The model reads. The rules decide. The people validate. And when APRA asks you to prove any of it, you can.

If you are facing the same thing

If you are putting AI into a regulated decision, the question that matters most is not how good the model is. It is whether you can draw a clean line between the part of the system that reads and the part that decides, and keep the model on the reading side of it.

Because the moment a regulator, an auditor, or a court asks you to prove a decision was sound and repeatable, “the AI worked it out” is not an answer you want to be giving. “The AI read the evidence, a versioned set of rules made the decision, and here is the exact replay” is. We have now drawn that line inside a financial-services assurance platform, a HIPAA billing system, and a GxP quality system. The domains are completely different. The discipline is the same one every time.

Putting AI into a decision that has to hold up under scrutiny?

That is the conversation worth having. If you are building AI into something a regulator, an auditor, or a court could ask you to prove, we have done this before, and we can talk through where the line between reading and deciding needs to be.

Start a conversation →