Markets in Crypto-Assets Regulation (MiCA) came fully into force for crypto-asset service providers (CASPs) in December 2024. For firms running AI-driven trading bots, Articles 68–75 impose operational resilience requirements that go well beyond standard software reliability engineering.
This post unpacks what those requirements mean for autonomous trading agents — and what technical and procedural controls actually satisfy them.
What MiCA Defines as Operational Resilience
MiCA Article 68 requires CASPs to "have in place adequate policies and procedures to ensure the continuity and regularity in the performance of their services." For algorithmic trading, this means:
1. The trading system must operate predictably within defined parameters at all times.
2. Deviations from normal operation must be detected and responded to automatically, not after the fact.
3. Records of every system action must be retained and retrievable for supervisory review.
For human traders, these obligations are met by trading desks, risk officers, and post-trade surveillance. For AI agents, they must be met programmatically — the agent is both the trader and the first line of risk control.
The Three Resilience Pillars
Pillar 1 — Defined Authority Limits
Operational resilience starts before the agent executes its first trade. Every trading bot must operate within a documented authority limit: maximum trade size, permitted instruments, permitted counterparties, permitted geographies, and permitted hours.
These limits cannot live only in configuration files — configuration can be changed without audit trail. Kakunin embeds authority limits in the agent's X.509 certificate as custom extensions, signed by a KMS-backed CA. Changing the limits requires certificate reissuance, which is logged and auditable.
A trading bot certificate scope might look like:
— maxTransactionSize: €500,000
— allowedInstruments: [BTC_EUR, ETH_EUR, SOL_EUR]
— allowedCounterparties: [exchange_a, exchange_b]
— allowedHours: 07:00–20:00 UTC, Monday–Friday
— allowedRegions: [eu-west-1, eu-central-1]
Any action outside these bounds is rejected at the cryptographic enforcement layer — the LLM's decision is irrelevant if the certificate says no.
Pillar 2 — Continuous Anomaly Detection
MiCA Article 72 requires "robust procedures for testing and monitoring" of algorithmic trading systems. Periodic testing is insufficient — the system must be monitored continuously.
Kakunin's behavioral monitoring establishes a baseline of normal trading patterns during an initial observation period (typically 7–14 days). Every subsequent action is scored against this baseline using a weighted anomaly model covering:
— Transaction size vs. historical p50 and p99
— Hourly transaction frequency vs. historical average
— Instrument concentration vs. historical distribution
— Time-of-day vs. historical active periods
— Geographic origin of signing events
Scores above 0.75 trigger a pre-revocation warning to the operator. Scores above 0.85 trigger automatic certificate revocation — the bot halts immediately without waiting for human intervention.
This satisfies the "automatic circuit breaker" requirement implicit in MiCA's operational continuity obligations: when a system behaves outside its normal parameters, it must stop, not continue trading while a human reviews.
Pillar 3 — Immutable Audit Trail
MiCA Article 71 requires record-keeping of all services and transactions for five years. For algorithmic trading, every executed order — including the agent's reasoning, the risk score at the time of execution, and the cryptographic signature proving the agent was authorised — must be retained.
Kakunin's audit log is WORM: PostgreSQL rules block UPDATE and DELETE at the database level. Application code cannot modify or delete records, even with the service role. Every record includes the agent's certificate fingerprint and a KMS signature over the action payload.
This creates non-repudiation: the agent cannot deny it executed a trade, and the operator cannot claim the agent's certificate scope permitted more than it did.
Incident Response Under MiCA
MiCA Article 68 requires CASPs to have documented incident response procedures. For AI trading agents, this means automated responses are required — by the time a human sees an alert, hundreds of additional trades may have been executed.
The Kakunin incident flow:
Risk score ≥ 0.75 → Pre-revocation warning webhook → On-call notified → 5-minute investigation window
Risk score ≥ 0.85 → Automatic revocation → Agent halts → Replacement agent queued → Compliance team notified
All events are written to the audit log with timestamps, risk scores, and resolution status. This produces the incident timeline regulators require when reviewing a market disruption event.
Supervisory Verification
MiCA grants national competent authorities (NCAs) the right to request records and system documentation. Kakunin's compliance export generates the package regulators ask for:
— Agent registration record (who created it, when, for what purpose)
— Certificate chain (authority limits, validity, CA signatures)
— Behavioral baseline (approved by compliance officer, dated)
— Audit log extract (signed, WORM, 5-year retention)
— Incident history (all anomaly alerts, resolutions, revocations)
The package maps directly to MiCA Articles 71 and 67(1) disclosure requirements.
What Still Requires Human Process
Kakunin automates the technical compliance layer. Two elements still require human governance processes:
1. Initial scope approval — a qualified person must sign off on the authority limits before the certificate is issued. This is the equivalent of a trading mandate approval.
2. Post-incident review — after any revocation event, a human must review the incident, determine root cause, and sign off on the replacement agent's baseline before it operates in production.
MiCA's "governance, risk and internal control framework" (Article 67) requires documented human accountability. Kakunin provides the evidence; the governance process must sit with the CASP.
Summary
MiCA operational resilience for AI trading bots requires three technical capabilities: cryptographically enforced authority limits, continuous anomaly detection with automatic circuit breakers, and immutable audit trails with five-year retention. Kakunin implements all three. The remaining compliance obligation is the governance process that authorises the agent's scope and reviews incidents — that must sit with the CASP's compliance function.