How Crypto Firms Meet MiCA Record-Keeping and Market-Abuse Duties Without Cloud AI

Crypto-asset service providers meet MiCA's record-keeping and market-abuse duties without sending transaction data to cloud AI by running the monitoring on operator-owned hardware behind a zero-egress perimeter. We built Mickai, a Sovereign Intelligence Operating System (a SIOS), to read order books, wallet flows and customer records locally, seal every action to a post-quantum signed audit ledger, and transmit none of the underlying data to any external service. The regulator receives a verifiable trail. The cloud receives nothing.

This matters in 2026 because MiCA is now live for crypto-asset service providers across the European Union, and the same firms carry Travel Rule duties under the Transfer of Funds Regulation, resilience duties under DORA, and network-security duties under NIS2. Every one of these regimes assumes rich transaction and customer data. The convenient answer, a cloud AI copilot, quietly exports exactly the data these rules were written to protect. A sovereign design keeps the data inside the operator's walls and still produces the evidence a supervisor asks for.

“The obligation is to prove what happened, not to broadcast it, so the intelligence should move to the data and the data should stay where it is.”

How does an on-premise agent actually do this?

Mickai runs offline on hardware the operator owns. Order data, wallet addresses, counterparties and know-your-customer records are read in place and never leave the perimeter. Three mechanisms carry the weight. First, a zero-egress inbound perimeter: connections flow in for supervision and control, and no channel exists for customer or transaction data to flow out. Second, hardware-attested identity: every operator and every automated action is bound to a device-level identity written into the audit chain, so the record shows who or what acted and on which machine. Third, a post-quantum signed audit ledger: each entry is sealed with a digital signature, so the trail cannot be altered after the fact without detection. The architecture is the subject of 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD, all patent pending.

Which MiCA and TFR rules make this necessary?

Three duties converge on the same data.

• Record-keeping. MiCA requires a crypto-asset service provider to retain records of all its services, activities, orders and transactions in a form a competent authority can inspect, complete and available on request.
• Market abuse. MiCA prohibits insider dealing, the unlawful disclosure of inside information and market manipulation, and requires firms to have arrangements to detect and report suspicious orders and transactions.
• The Travel Rule. The Transfer of Funds Regulation requires originator and beneficiary information to travel with a crypto transfer, which means matching sensitive customer identity data against every move.

Each duty argues for keeping the data close. None requires, or benefits from, shipping it to a third-party model.

What can an auditor or regulator actually check?

The point of the design is that the answer is checkable, not asserted. An auditor can verify the audit ledger offline, without a live connection to any vendor, because the signatures validate on their own. The signing rests on the NIST post-quantum standards: FIPS 204, the ML-DSA signature scheme, is the primary seal, with FIPS 205, the SLH-DSA scheme, available as a hash-based alternative. Because each entry carries a hardware-attested identity, the auditor can trace an action back to a specific operator and device. Because the ledger is append-only and sealed, a missing or edited entry is visible. The test is simple: take the ledger to an air-gapped machine and confirm every signature still verifies. Offline verifiability is the property that turns a claim into evidence.

Why can a firm not just use a public cloud AI service?

Public cloud AI services are capable, but they require the data to be sent to infrastructure the operator does not control. For a crypto-asset service provider that carries two problems. The first is exposure: wallet flows and customer identity data leave the perimeter and land under another party's operational control, and GDPR treats that transfer as a processing event the firm must justify. The second is jurisdiction: the US CLOUD Act can compel a US-based provider to produce data it holds, regardless of where the data is stored. A sovereign design removes both problems by never making the transfer.

How does market-abuse detection run without egress?

Detection runs as local inference. Sovereign models held on the operator's own hardware score orders and transactions for the patterns that matter: wash trading, spoofing, layering, insider-timed activity and manipulation across venues. Where a judgement is finely balanced, Mickai uses cross-model consensus, running more than one model over the same evidence and comparing outputs, so a single model's blind spot does not decide an alert. Every alert, every dismissal and every escalation is written to the sealed ledger. The firm keeps both the decision and the reason for it, with no round trip to an external service.

How does this fit DORA, NIS2 and the EU AI Act?

The sovereign design answers several regimes at once. DORA, in force since January 2025, demands operational resilience and control over third-party risk, and an on-premise agent removes a critical dependency on an external AI provider. NIS2 raises network and information-security duties for essential and important entities, and a zero-egress perimeter shrinks the attack surface it governs. ISO/IEC 42001 gives a management-system framework for the AI itself. On the EU AI Act, the high-risk 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 moved to 2 August 2028 and the Article 50 transparency rules largely unchanged. We read that as a build window, not a reprieve: the firms that put verifiable, sovereign monitoring in place now will not be rebuilding under deadline later.

Frequently asked questions

Does MiCA require crypto firms to use cloud AI for monitoring?

No. MiCA sets the outcome, complete records and effective detection and reporting of market abuse, and is silent on the tooling. A crypto-asset service provider is free to meet those duties with monitoring that runs entirely on its own hardware. Nothing in MiCA obliges a firm to send transaction data to any external model.

Can an on-premise AI agent satisfy MiCA market-abuse reporting?

Yes. Detection and reporting are duties about outcomes and evidence, not about location. An on-premise agent can score orders and transactions locally, raise and record alerts, and produce the trail a supervisor needs. Reporting a genuine suspicion to the competent authority is a deliberate, reviewable step, not an automatic egress of raw data.

How does a CASP keep Travel Rule data compliant without cloud transfer?

Travel Rule data under the Transfer of Funds Regulation is exactly the customer identity data a firm should not scatter across third parties. A sovereign design matches originator and beneficiary information against transfers inside the perimeter, so the checks happen without the data leaving. The record of each check is sealed to the local ledger.

What makes an audit ledger acceptable to a regulator?

A regulator can accept a ledger it verifies independently. That means append-only entries, each sealed with a digital signature that validates offline, and each tied to a hardware-attested identity so actions trace to a person or process and a device. With FIPS 204 signatures the trail stays verifiable even against future quantum attack. The strongest property is that verification needs no live connection to the vendor.

Is the EU AI Act deadline still 2 August 2026 for high-risk AI?

No. The high-risk Annex III obligations once due on 2 August 2026 have been deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk duties moved to 2 August 2028. The Article 50 transparency rules are largely unchanged. We treat the extra time as a window to build verifiable systems, not a reason to wait.