How can a financial-crime team use AI without sending a single transaction to a third party?

A financial-crime team can use AI without sending a single transaction to a third party by running the model where the data already lives, inside the institution's own boundary, rather than shipping records out to a hosted service. At Mickai we build a Sovereign Intelligence Operating System, a SIOS, that runs offline on operator-owned hardware behind a zero-egress inbound perimeter, so alert scoring, entity resolution and case narratives are produced locally and no transaction record ever leaves the building. This works because inference happens next to the ledger, not in someone else's data centre. The confidentiality guarantee for the AI becomes the same one that already protects core banking.

The question matters because the 2026 market splits cleanly in two. Public cloud AI services require sending prompts, and therefore data, across a network boundary to infrastructure a regulated institution does not control. For sanctions screening, suspicious-activity investigation and know-your-customer review, that boundary crossing is the exposure, not a convenience. DORA has been in force since January 2025, NIS2 now reaches essential and important entities, and the US CLOUD Act means data held by a US provider can be compelled regardless of where the server physically sits. Teams want the analytical lift of a large model without inheriting the reach of a shared one.

How does zero-egress transaction scoring actually work?

The model is deployed inside the institution's perimeter on hardware the institution owns. Transactions, customer records and watchlists stay in the systems that already hold them. Inference runs locally: the system scores alerts, resolves entities, maps payment networks and drafts case narratives without calling any external endpoint.

The perimeter is the mechanism. A zero-egress inbound design accepts data in and emits nothing out to a vendor. There is no outbound call carrying a transaction to be scored elsewhere. Every action is bound to a hardware-attested identity and written to a sealed audit chain as it happens.

There is a simple way to test the claim. Set the institution's egress firewall to deny all outbound traffic, then run a day of alerts. A sovereign system still scores and still produces cases. A cloud service goes dark.

What can an auditor or regulator check?

Everything, and offline. Each inference, each model version and each analyst action is recorded in an append-only ledger that can be verified without contacting any supplier. Because the record is local and sealed, an examiner reviews the same evidence the institution holds.

An auditor can pull, and independently verify:

• which model version scored a given alert, and when
• the inputs the model saw and the output it returned
• the analyst who reviewed or overrode each decision
• the cryptographic seal proving the entry has not been altered

Reproducibility is the standard to ask for: the same input against the same model version returns the same result, so a decision made in March can be re-examined in October and hold up.

Which rules make on-premise financial-crime AI necessary?

Several regimes point the same way. DORA, in force since January 2025, makes operational resilience and third-party concentration risk a board-level concern. NIS2 raises security obligations for essential and important entities. GDPR requires data minimisation and constrains international transfer. The US CLOUD Act lets US authorities reach data held by US-linked providers wherever it sits.

On the EU AI Act, AML scoring can fall within the high-risk category. The Annex III obligations once due on 2 August 2026 were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk duties moving to 2 August 2028 and the Article 50 transparency rules largely unchanged. We read that as a build window, not a reprieve. ISO/IEC 42001 gives a management-system standard to run the programme against in the meantime.

How is the audit ledger protected for the long term?

A suspicious-activity file may need to be trusted for a decade or more, which means its integrity must survive tomorrow's cryptography. We seal the audit ledger with post-quantum digital signatures. FIPS 204, the ML-DSA standard, is the primary signature scheme, with FIPS 205, the SLH-DSA standard, available as a hash-based alternative. Both sign and verify entries, so a tampered record fails verification.

Signing and encryption are different jobs. FIPS 203, ML-KEM, is a key-encapsulation standard used to protect data in transit, and it never signs anything, so the verifiability of the ledger rests on FIPS 204 and FIPS 205 alone. This defends against harvest-now-decrypt-later: an adversary who stores today's records cannot forge a valid signature once quantum computers arrive.

Does keeping AI in-house mean weaker or single-point models?

No, and the architecture is designed to avoid the single-model trap. Sovereign models run locally, sized to the operator's hardware. Where a decision is material, several models score the same case independently and the system uses cross-model consensus: agreement raises confidence, disagreement is flagged for a human. That reduces the blind spots and confident errors a single model can introduce into a narrative an investigator will rely on.

How do we know the system has not quietly phoned home?

Because the constraint is architectural, not a setting someone can switch off. The zero-egress inbound perimeter, the hardware-attested identity bound to the audit chain and the sealed ledger together make silent exfiltration observable and, under a deny-all egress rule, impossible at the network layer. The design behind this posture is the subject of 104 filed UK patent applications, comprising approximately 2,340 claims, owned by Mickai LTD, and marked patent pending.

“A financial-crime team should be able to run modern AI over every transaction and still prove that not one of those transactions ever left the institution.”

Frequently asked questions

Can a bank use a public AI service for anti-money-laundering work?

Not without sending data to a third party. Public cloud services process prompts on infrastructure the bank does not control, which crosses a regulatory and confidentiality boundary for transaction data. A sovereign, in-house system gives the same analytical assistance while keeping every record inside the institution.

What does zero-egress mean for financial-crime AI?

Zero-egress means the system takes data in but sends nothing out to any external endpoint. Alerts are scored and cases are built locally, with no outbound call carrying a transaction to a vendor. You can verify it by denying all outbound network traffic and confirming the system still works.

Is on-premise AML AI compliant with DORA and the EU AI Act?

Running AI inside your own perimeter directly supports DORA's resilience and third-party risk requirements and simplifies EU AI Act high-risk obligations by keeping data, model and audit trail under one accountable operator. The high-risk Annex III duties, once due on 2 August 2026, now apply from 2 December 2027 after the Digital Omnibus deferral. That is time to build the controls, not to skip them.

Does the US CLOUD Act affect cloud AML services?

Yes. The CLOUD Act allows US authorities to compel data held by US-linked providers regardless of where the servers are located. For a non-US institution, that is a jurisdictional exposure that on-premise, operator-owned processing removes, because there is no external custodian left to compel.

How can an auditor verify an offline AI system?

By checking the local audit ledger, which records every inference, model version and analyst action and is sealed with post-quantum signatures under FIPS 204. Verification is done offline against the institution's own copy, with no need to trust or contact a supplier. Reproducing a past decision from the same inputs and model version confirms the record is sound.