When the Markets in Crypto-Assets Regulation came into full force across the European Union in December 2024, most of the industry conversation focused on stablecoin issuers and crypto-asset service providers. The obligations around licensing, capital requirements, and investor protection dominated the coverage.
What received considerably less attention was the section of MiCA that has the most direct implications for organisations deploying AI in crypto-asset operations: Articles 61 through 75, which govern algorithmic trading and the use of automated decision-making systems.
If you are deploying AI agents in any context that touches MiCA-regulated activities — trading, market-making, custody, settlement, AML screening — this section of the regulation is not optional reading. It defines the compliance obligations that apply to your agents right now.
The Scope of MiCA Articles 61–75
MiCA Articles 61–75 cover what the regulation calls "algorithmic trading" and "market manipulation prevention" requirements for crypto-asset service providers (CASPs). But the scope is broader than it might initially appear.
An AI agent that executes trades is obviously in scope. But so is an agent that recommends trades to human traders. An agent that performs portfolio rebalancing. An agent that sets bid-ask spreads for a market-making operation. An agent that detects suspicious transactions as part of an AML programme. The regulation uses the phrase "algorithmic trading" broadly — if code is making or influencing the trading decisions, and you are a licensed CASP, you are likely in scope.
The obligations in this section cluster around five themes:
1. Identity and accountability — who or what is taking the decisions
2. Pre-deployment testing and approval — demonstrating the system works before going live
3. Operational monitoring — ongoing verification that the system continues to work as intended
4. Revocation capability — the ability to halt the system when it does not
5. Audit and record-keeping — maintaining evidence that all of the above was done properly
Let us work through each.
Article 70: Certificate Validity and Identity Requirements
Article 70 is the anchor for identity requirements. It requires that algorithmic trading systems be identifiable — that the regulatory authority can, upon request, determine what system made which decision, under what authority, and at what time.
The practical implication is that each AI agent must have a unique, verifiable identity that is maintained throughout its operational life. An identity that can be revoked. An identity that produces a verifiable audit trail.
This is why X.509 certificates are the right technical implementation for MiCA compliance. The certificate is a cryptographic document that proves identity. It carries a serial number, an issuer, a subject, and a validity window. The validity window — 365 days in Kakunin's implementation — directly satisfies Article 70's requirement for time-bounded authority. When the certificate expires, the agent's authority to act expires with it. Renewal requires going through the same identity verification and approval process that initial issuance required.
For more detail on how certificate issuance works technically, the certificates documentation covers the full lifecycle from registration through renewal.
Article 72: Revocation Reason Logging
Article 72 is perhaps the most operationally specific provision in this section. It requires that any time an algorithmic trading system is stopped — whether voluntarily or involuntarily — the reason for stopping must be recorded, preserved, and available to the competent authority upon request.
This provision exists because regulators recognised that the ability to stop a system is only useful if you can reconstruct why it was stopped. If your AI agent was auto-revoked because its risk score exceeded a threshold, the regulator needs to know: what events drove the risk score up? Was this a legitimate operational anomaly? A security incident? A bug? Market manipulation?
Kakunin's audit log records revocations with structured reason codes and links every revocation to the specific behavioural events and risk score trajectory that preceded it. The audit log is WORM-backed — write once, read many — meaning entries cannot be modified after the fact. This creates exactly the kind of tamper-evident record that Article 72 demands.
The audit trail documentation covers the specific event types that are captured and how the revocation record links to the preceding behavioural evidence.
Article 73: Behavioural Monitoring SLA
Article 73 requires operators to implement monitoring mechanisms with defined response capabilities. The regulation specifically contemplates that something will go wrong with an automated system, and asks: what is your response time? What is your escalation path? What is your evidence that the monitoring worked?
The phrase that matters is "real-time monitoring." Article 73 does not permit monitoring that happens in batch, or retrospectively. It expects that anomalies be detected as they occur, not after they have run for hours.
This directly informs the architecture of a compliant AI agent deployment. You need:
- Event streaming from the agent to a monitoring system
- Real-time risk score computation
- Automated alert generation when thresholds are crossed
- A defined and documented response procedure
Kakunin's SLA on this is under 60 seconds from risk threshold breach to certificate revocation. That is the specific performance guarantee that corresponds to Article 73's intent. The SLA documentation covers the precise guarantees and the monitoring infrastructure backing them.
For compliance officers assessing whether this SLA meets Article 73's requirements, the key question is: is your current monitoring infrastructure capable of detecting and responding to anomalies in under 60 seconds? If the answer involves human review as a prerequisite for any action, the answer is probably no.
Article 75: Audit Trail Requirements
Article 75 is the capstone of the section. It requires that regulated entities maintain an audit trail sufficient to allow reconstruction of any trading decision, for a period of at least five years.
"Sufficient to allow reconstruction" is a high bar. It means the audit trail must capture:
- The identity of the agent that made the decision
- The inputs the agent had access to at the time of the decision
- The decision itself, with timestamp
- Any ancillary actions the agent took in connection with the decision (accessing data sources, calling external APIs)
- The cryptographic proof linking all of the above to a verified agent identity
This is not a summary log. It is a granular event-level record. And the "five years" requirement means you need to think carefully about your data retention and storage architecture. A high-frequency trading agent generating thousands of events per second will produce terabytes of data per year.
Kakunin's audit log is designed for this use case. Events are stored in append-only format with cryptographic hashing of each batch. The WORM properties mean the log is immutable after creation. Export capabilities allow compliance teams to produce a complete, formatted audit trail for any agent, covering any time period, in JSON or CSV format.
For organisations subject to GDPR as well as MiCA, there is a tension to manage: GDPR's right to erasure conflicts with MiCA's five-year retention requirement. The compliance documentation at /docs/concepts covers how this tension is typically managed through data minimisation in agent design (ensuring the audit log does not contain personal data that would trigger GDPR erasure rights).
Pre-Deployment Testing: The Article 63 Obligation
Articles 63 and 64 cover pre-deployment obligations — what regulated entities must do before an AI agent goes live.
Article 63 requires that algorithmic trading systems be tested in a simulated environment before deployment to production. The testing must demonstrate that the system behaves as intended under the range of market conditions the operator expects to encounter.
Kakunin's sandbox mode is designed to satisfy this requirement. Agents can be registered and tested in sandbox mode, generating the full audit trail and behavioural event history of a production deployment without executing real transactions. The sandbox produces the same event stream and risk scoring as production, which means you can validate your monitoring configuration — including threshold settings and alert routing — before going live.
The test results, including the risk score history from sandbox testing, are preserved in the audit log. When a regulator asks for evidence of pre-deployment testing, you can produce a structured report showing the test scenarios, the agent's behaviour in each scenario, and the risk scores generated.
For developers integrating with Kakunin, the sandbox documentation covers the API endpoints and configuration differences between sandbox and production mode.
Market Manipulation Prevention: Articles 66–68
Articles 66 through 68 deal specifically with market manipulation prevention. They require that CASPs implement controls to detect and prevent their systems from engaging in manipulative trading behaviours, including:
- Spoofing (placing orders with no intention to execute)
- Layering (placing multiple orders to create a false impression of market depth)
- Wash trading (buying and selling the same asset to generate artificial volume)
- Pump-and-dump (accumulating a position and then promoting the asset to inflate the price before selling)
An AI agent can engage in these behaviours accidentally — not because it was programmed to manipulate markets, but because its optimisation target produces emergent behaviours that happen to constitute manipulation. A reinforcement learning agent optimising for spread capture might develop a layering pattern without any human having explicitly programmed it.
The behavioural monitoring layer needs to include specific signals for these patterns. Transaction volume anomalies, unusual cancellation rates, and order-size clustering are the primary signals. Kakunin's event taxonomy includes specific event types for order placement, modification, and cancellation, allowing the risk scoring model to compute manipulation-specific signals alongside general behavioural risk.
The Financial Conduct Authority guidance on algorithmic trading provides detailed guidance on what regulators expect to see in manipulation prevention systems. This is UK-specific guidance, but given the alignment between FCA and MiCA standards on algorithmic trading, it is directly applicable to MiCA compliance planning.
What MiCA Compliance Looks Like in Practice
Putting the above together, a MiCA-compliant AI agent deployment in a CASP involves:
At registration:
- X.509 certificate issued with a 365-day validity window
- Agent identity recorded in the audit log with the KMS key ARN
- Sandbox testing completed and documented before production deployment
In production:
- Every agent action generates a structured event captured in the audit log
- Risk score computed continuously over a 30-day rolling window
- Pre-warning notifications generated at 0.75 threshold
- Auto-revocation within 60 seconds at 0.85 threshold
- All revocations logged with reason codes and linked to preceding behavioural evidence
For regulators:
- Public verification endpoint available for certificate status checks with no authentication required
- CRL updated in real time as revocations occur
- Full audit trail exportable in structured format covering any time period
- Compliance report mapping each Article 70–75 requirement to specific system capabilities and audit evidence
At annual renewal:
- Certificate expired and re-issued following identity re-verification
- Annual compliance review generating a fresh audit trail entry
- Updated risk baseline established for the renewed agent
For FinTech founders assessing the market opportunity, the /for-fintech-founders page covers the commercial case for MiCA compliance infrastructure. The regulatory gap between "we have a trading agent" and "we have a MiCA-compliant trading agent" is significant, and first movers have a meaningful time advantage.
The Competent Authority Perspective
MiCA designates national competent authorities (NCAs) in each EU member state as the bodies responsible for supervising CASP compliance. The EBA and ESMA have coordination roles at the EU level.
NCAs have the authority to request audit trails, conduct on-site inspections, and require CASPs to halt operations of specific systems if compliance cannot be demonstrated. The enforcement risk is real: MiCA's penalty framework includes fines of up to 10% of annual turnover for serious violations.
From the NCA's perspective, what they want is simple: give me the evidence that your system was compliant, and give it to me quickly. The organisations that can respond to a regulatory inquiry with a structured audit report within hours — not days — are the ones that demonstrate the kind of institutional readiness that NCAs are looking for.
The public verification endpoint that Kakunin provides is specifically designed for this scenario. A regulator can independently verify the status of any agent certificate with no credentials and no dependency on the CASP's cooperation. This is what the /for-regulators page describes in detail — a public API surface that gives supervisory authorities the verification capability MiCA anticipates.
Starting Your MiCA Compliance Journey
The compliance journey for MiCA Articles 61–75 is not a one-time project. It is an ongoing operational posture that requires:
1. Identity infrastructure (X.509 certificates) for all algorithmic trading agents
2. Behavioural monitoring with real-time event streaming and risk scoring
3. Pre-deployment testing with documented evidence
4. Defined response procedures for each risk threshold level
5. A WORM audit trail with five-year retention
The MiCA regulation itself is the authoritative source, and reading Articles 61–75 directly is worthwhile even if you work with legal counsel. The operational implications become clearer when you read the actual language rather than summaries.
Kakunin provides the technical infrastructure for items 1 through 4. The audit trail (item 5) is a core architectural feature that cannot be retrofitted — it needs to be in place from day one of production deployment.
If you are currently operating AI agents in a MiCA-regulated context without this infrastructure, the time to close the gap is now. The regulation is in force, NCAs are building their supervisory capacity, and the first enforcement actions will not be gentle.
---
Kakunin provides MiCA-compliant AI agent certification covering Articles 61–75. Certificate issuance via AWS KMS, real-time behavioural monitoring, and WORM audit trail from day one. View the compliance checklist or talk to a compliance officer who uses Kakunin.