Can fraud and financial-crime detection run in real time on your own hardware?

Yes. Fraud and financial-crime detection can run in real time on hardware you own, with every transaction scored inside your own perimeter and nothing sent to an external scoring service. The reason is architectural: when the model, the rules engine and the audit ledger all sit on operator-owned machines, a payment never has to cross your network boundary to be judged, so latency stays inside the authorisation window and data residency stays absolute.

This matters because most detection vendors still assume a cloud scoring call. A bank or payment firm sends transaction features to a hosted endpoint, waits for a risk score, and trusts a third party with the most sensitive records it holds. In 2026 that assumption is under pressure from regulators, from operational-resilience rules, and from the plain fact that an external scoring service is one more dependency that can fail, leak or fall under foreign jurisdiction. Sovereign, on-premise detection removes the round trip and the exposure that comes with it.

“If a transaction has to leave the building to be judged, the building has already lost control of it.”

How does real-time detection work on your own hardware?

Mickai is a Sovereign Intelligence Operating System, a SIOS that runs entirely offline on operator-owned hardware. Detection works as a local pipeline. A transaction arrives, is enriched with account and behavioural features, and is scored by sovereign models running on the same machines that hold the data. A rules engine applies your own typology library. A decision returns to the payment flow in milliseconds. No feature vector, no account identifier and no transaction body leaves the building. Every step is written to a sealed local ledger as it happens.

Why can a cloud scoring service not meet this requirement?

A cloud scoring service works by receiving your data. For most software that is acceptable. For financial-crime detection it is the problem itself. Sending transaction features to a hosted endpoint means the most sensitive records you hold transit a network you do not control and rest, however briefly, on hardware you cannot inspect. Public cloud AI services are built for this hosted model and cannot be used where the requirement is that data never leaves the operator's control. The US CLOUD Act sharpens the concern: data held by a US-linked provider can be subject to lawful access regardless of where the servers physically sit. On-premise scoring closes that exposure because there is no outbound call to compel.

What can an auditor actually check?

Auditability is the difference between a claim and a control. Mickai writes every decision, model version, rule fired and human override to an append-only ledger. Each entry is signed with a post-quantum digital signature under FIPS 204 (ML-DSA), the primary standard, with FIPS 205 (SLH-DSA) available as an alternative, so the record stays verifiable even against a future quantum attack. Identity is hardware-attested and bound to the audit chain, so every action traces to an attested device and a named operator rather than a shared credential. Because the ledger verifies offline, an auditor can confirm that a given alert was produced by a given model version at a given time without trusting the vendor and without a live connection. That is offline verifiability, and it is checkable rather than asserted.

Which rules make on-premise detection necessary?

Several regimes push in the same direction. DORA, in force across the EU since January 2025, holds financial entities accountable for the operational resilience of their critical systems, including third-party dependencies such as an external scoring service. NIS2 raises security duties for essential and important entities across the wider economy. GDPR governs the personal data inside every transaction and penalises unnecessary transfer. The EU AI Act treats much fraud and credit-risk scoring as high risk: its Annex III obligations were originally due on 2 August 2026, but the Digital Omnibus deferred them to 2 December 2027, with embedded Annex I high-risk systems moving to 2 August 2028 and the Article 50 transparency duties largely unchanged. We read that deferral as a build window, not a reprieve. ISO/IEC 42001 adds a management-system standard for the AI itself. A sealed-ledger, on-premise architecture answers all of these at once.

Is it fast enough and accurate enough offline?

Real time means a decision inside the authorisation window, and local scoring is often faster than a cloud call because it removes the network round trip entirely. Accuracy offline comes from cross-model consensus: rather than trusting a single model, Mickai runs several sovereign models and combines their judgements, so a false signal from one is checked by the others before an alert or a block is raised. Typology libraries and models are refreshed on your own schedule through controlled, signed packages, not through a live link to a vendor. The perimeter is zero-egress by design: the system accepts inbound data to score but has no path to send data out.

What does deployment on owned hardware look like?

Deployment runs on hardware the operator owns and controls, in your own data centre or secure enclave. The models, the rules engine, the ledger and the operator interface install as one sovereign stack, with no tenancy on shared infrastructure and no vendor telemetry phoning home. The design is deliberately the inverse of the hosted norm: comparable enterprise detection suites centralise scoring in the vendor's cloud, whereas a SIOS keeps the entire decision loop inside the buyer's boundary. Mickai LTD owns 104 filed UK patent applications covering approximately 2,340 claims across this sovereign architecture; these are filed applications, patent pending, and not granted patents.

Frequently asked questions

Can real-time transaction scoring really run with no cloud connection?

Yes. When the model, rules engine and audit ledger run on hardware you own, a transaction is scored inside your own perimeter and no external call is made. Mickai runs fully offline on operator-owned machines, so detection continues even with the outbound network physically disconnected.

Is on-premise fraud detection slower than a cloud scoring service?

No, it is usually faster. A cloud scoring service adds a network round trip to every decision, while local scoring returns a result inside the authorisation window without leaving the machine. Removing the external call also removes a dependency that can time out or fail under load.

How do you prove to a regulator that data never left the building?

Every decision is written to an append-only ledger and signed with a post-quantum signature under FIPS 204. The record verifies offline, so an auditor can confirm which model version scored which transaction and when, without trusting the vendor. Hardware-attested identity ties each action to an attested device and operator.

Does the EU AI Act require on-premise fraud detection?

The EU AI Act treats much fraud and credit-risk scoring as high risk. Its Annex III obligations were due on 2 August 2026 but were deferred by the Digital Omnibus to 2 December 2027, with embedded high-risk systems following on 2 August 2028. The Act does not mandate on-premise deployment, but keeping data and decisions inside your own boundary makes the transparency, logging and human-oversight duties far easier to satisfy.

What happens to model updates if the system stays offline?

Models and typology libraries are updated through controlled, signed packages applied on your own schedule, not through a live link to a vendor. You verify each package, install it on your hardware and keep a sealed record of the change. The system never needs an open outbound connection to stay current.