AI in financial services after the Bank of England paper, and the audit that survives PRA scrutiny

The Bank of England's discussion paper on artificial intelligence and machine learning, the PRA's supervisory statement on model risk management (SS1/23), and the FCA's discussion paper on AI in financial services together describe a coherent regulatory expectation. The expectation is that a firm using AI in a regulated context can supply the regulator with a verifiable record of any decision the AI took, the data the decision was conditioned on, the model version that produced it, and the governance gate it passed.

The expectation is not new. The way the industry currently meets it, where it meets it at all, is not structurally durable.

This article sets out the gap, the structural test for closing it, and the substrate that does.

The three lines and the missing record

PRA SS1/23 codifies the three-lines-of-defence model for AI: the business owns the decisions, the model risk function owns the controls, and internal audit owns the assurance. Each line needs evidence to do its job. The evidence has to be reproducible, attributable, and durable.

A typical AI deployment at a UK bank in 2026 ships its audit trail through one of three patterns. The model is hosted by a third-party provider and the audit log is held inside the provider's tenancy. The model is self-hosted but the logging tier uses a shared cloud database with operator-write access from the provider's support team. The model is air-gapped but the audit log is unsigned, retained on the same host as the model, and exported to evidence on request.

None of the three answers the regulator's structural question. The PRA cannot verify a record the firm cannot independently authenticate. The FCA cannot reconstruct a customer-impact decision the firm cannot reconstruct itself. Internal audit cannot sign off on a control whose evidence base lives in a perimeter the firm does not control.

The structural test

The regulator-side audit expectation has the following components.

The audit record has to be sealed under a key whose private half is held in hardware the firm controls, not in a provider tenancy. The record has to include the input, the model snapshot reference, the retrieval set, the governance gate state, the decision, and the time, against a clock the firm trusts. The signature scheme has to be one that retains its evidential weight across the regulator's record-retention horizon. The verification has to be possible without the involvement of the original vendor, who may not exist in the same form by the time of the regulator review.

The structural answer is operator-side, post-quantum signed, hardware-bound audit.

The Mickai substrate, mapped to the three lines

The Mickai Sovereign Intelligence Operating System gives the bank an engineering primitive for each of the three lines.

The first line gets, for every AI-assisted decision, a structured action record. The Router brain decomposes the request. The Retrieval brain returns the relevant prior decisions and the policy context. The domain specialist (ZEUS for legal and governance work, KARP for data and analytics, JAXON for software work in the bank's own systems, GABRIEL for client communications) produces the candidate output. The Audit Ledger seals the action under FIPS 204 ML-DSA-65 with the bank's hardware-bound key. The decision is signed at the moment of generation, against the bank's key, in a record the bank holds.

The second line, model risk management, gets a signed evaluation record for every model version deployed. The pre-deployment evaluation, the continual monitoring runs, the calibration drift checks, and the policy compliance evaluations are themselves signed actions in the Audit Ledger. The model risk function can re-run an evaluation against the signed snapshot and verify the result. SS1/23 is met with engineering evidence, not with a self-attested statement.

The third line, internal audit, gets a verification path that does not depend on the model vendor. The Audit Ledger is browser-resident verifiable WebAssembly. Internal audit recovers a sample of records, verifies the signatures against the bank's published key, reconstructs the input set from the retrieval logs, and writes the assurance opinion. The opinion is itself a signed action.

Operational resilience and the PRA SS2/21 expectation

The PRA's operational resilience statement, SS2/21, requires firms to identify important business services, set impact tolerances, and demonstrate that the service stays within tolerance under severe but plausible disruption. The Bank of England's discussion paper notes that an AI-assisted business service inherits the operational risk of the AI dependency.

Mickai is designed to run with the cable pulled. Inference, retrieval, audit, and policy evaluation all execute on the operator's hardware. The seventy-two-hour disconnection test is a primitive of the substrate. A bank running a customer-facing AI on Mickai can demonstrate impact-tolerance compliance under foreign-vendor outage, foreign-jurisdiction sanction, or undersea cable disruption, because the dependency on the foreign vendor does not exist in the critical path.

What the regulator actually sees

The PRA inspector, the FCA supervisor, or the bank's own group internal audit receives, on a single recovery, a record that contains the customer or counterparty identifier, the decision, the model snapshot the decision was made against, the retrieval set the decision was conditioned on, the policy state at the moment, the hardware identity of the executing host, the bank key under which the record was sealed, the time, and the inverse action available if the decision is later retracted.

The verification step uses the bank's published key. The vendor of the underlying model is not a trust party in the verification step. SS1/23 model risk, SS2/21 operational resilience, the FCA's consumer-duty AI expectations, and the Bank of England's AI discussion paper expectations are met by engineering primitives, not by attestation.

What the next AI procurement at a UK bank should specify

The acceptance criteria are clean. The audit ledger writes under the bank's hardware-bound key. The signing scheme is FIPS 204 ML-DSA-65 from contract commencement. The verification path is browser-resident WebAssembly against the bank's published key. The model risk function can re-run the evaluation against the signed snapshot. The runtime perimeter on the AI process is enforced at the syscall layer in a separate trust domain. The disconnection test forms part of the acceptance criteria.

The Mickai Sovereign Intelligence Operating System is built to that specification. The 101 filed UK patent applications cover each primitive. The PRA, the FCA, and the Bank of England can verify the resulting record under the bank's own key. That is what regulator-grade AI in UK financial services looks like.