MiCA (Regulation (EU) 2023/1114) turns stablecoin and crypto-payment obligations into systems you have to run continuously: a reserve ledger reconciled every day against the tokens actually in circulation, per-day transaction counters that can legally force you to stop issuing, travel-rule metadata attached to every transfer, and an audit trail that can reconstruct any figure you filed. Most of the compliance work is data engineering.
The rules landed in stages. The stablecoin titles for asset-referenced tokens and e-money tokens applied from 30 June 2024. The service-provider regime and the recast travel rule applied from 30 December 2024. By now the question is no longer whether MiCA applies to a euro stablecoin or a crypto payments desk. It is whether your systems can produce the numbers on demand and defend how they were computed.
The reserve is a reconciliation problem
An EMT issuer holds reserves that fully back the tokens in circulation and redeems at par. An ART issuer maintains a reserve of assets with composition and custody constraints. Both obligations reduce, in practice, to one recurring engineering task: value the reserve as of a cut, count the tokens actually outstanding as of the same cut, and prove the two sides tie.
Neither side is trivial to pin down.
- Tokens in circulation is not the raw on-chain supply. You net out burned tokens, subtract what sits in treasury or is locked, and aggregate across every chain you deployed on. Bridged supply gets double-counted if you are not careful about which representation is authoritative.
- The reserve side needs point-in-time correctness. A NAV struck at 17:00 with prices that arrived at 17:40 is a lookahead bug wearing a compliance hat. The reserve figure you report has to be reproducible from the market data and custody balances that existed at the cut, not the ones that settled later.
- Segregation and custody rules mean the reserve ledger has to reconcile against external custodians and credit-institution deposits, each with its own statement cadence and its own way of naming the same position.
Build this as a daily reconciliation with a break register, not a month-end spreadsheet. When circulating supply and reserve NAV diverge beyond a tolerance, that is an event someone has to explain before it becomes a redemption problem. The lineage from a reported reserve figure back to the custodian statement and the block height that fixed supply is the thing an examiner will pull on.
Two counters that can stop you issuing
MiCA contains a provision engineers tend to miss because it reads like policy. For ARTs (Article 23) and for EMTs denominated in a non-EU currency (Article 58), if the token is used widely as a means of exchange within a single currency area, and the average daily transaction count exceeds one million and the average daily value exceeds EUR 200 million, the issuer must stop issuing and submit a plan to bring usage back down.
That is a hard limit expressed as a running aggregate, and it forces real design decisions.
- You have to classify transactions. A transfer between a user’s two own wallets, or an internal settlement leg on an exchange, is not the same as use as a means of exchange. Get the classifier wrong in either direction and you either trip a statutory threshold you were nowhere near, or you miss one you crossed weeks ago.
- You have to attribute activity to a currency area, which means mapping counterparties and endpoints to jurisdictions you can defend.
- You have to compute daily aggregates with point-in-time correctness and no leakage across the day boundary, then average them over the window the article specifies.
Do not wait for quarter-end to discover you crossed the line. Run a rolling estimate so the trend is visible while there is still time to act. The same discipline covers the significance criteria in Article 43. The EBA classifies an ART as significant only when at least three criteria are met at once, among them holder count above ten million, issued value above EUR 5 billion, and daily transaction figures above the stated lines. Once a token is significant, supervision passes to the EBA. Counting holders from addresses is its own entity-resolution problem. One person can control many addresses, and one custodial address can hold balances for millions of users. A naive address count is not a holder count, and reporting it as one is a defect you will have to unwind.
Travel rule and screening on the payments path
The recast Transfer of Funds Regulation (Regulation (EU) 2023/1113) applies the travel rule to crypto-asset transfers between service providers. Unlike traditional wires, there is no de minimis amount: originator and beneficiary information rides with every transfer, however small. Transfers to and from self-hosted wallets carry additional verification obligations above EUR 1000.
For the systems team this means a few concrete builds.
- Every outbound transfer needs complete, validated originator and beneficiary data attached, and every inbound transfer needs a path to detect missing or incomplete information and to hold, return, or follow up on it.
- Sanctions and PEP screening runs on names and identifiers that arrive messy, transliterated, and abbreviated. That is an entity-matching problem with a false-positive budget. Screen too loosely and you clear a sanctioned counterparty. Screen too tightly and your queue drowns, straight-through processing collapses, and legitimate payments stall.
- Self-hosted wallet flows need ownership evidence and address attribution, which pulls in on-chain analytics with their own confidence scores and their own drift as clustering heuristics change.
Treat screening thresholds as a tuned parameter with an eval set behind it, not a vendor default you inherited. You want a labelled set of prior alerts to measure precision and recall against before you move a threshold, because every move trades queue volume against escape risk.
What the audit trail has to reconstruct
MiCA issuers report to competent authorities on holders, reserve composition, and transaction activity, and CASPs sit under record-keeping and reporting obligations of their own. The binding constraint is reconstruction. Six months after you file a figure, you should be able to reproduce it exactly: same inputs, same cut, same code path, same result.
That is a lineage requirement, and it is unforgiving in a world of chain reorganisations, revised custodian statements, and late-arriving price data. Version the inputs. Freeze the computation. Keep the mapping from a reported number to the events that produced it, so that when the reserve figure in your quarterly return differs from the one in your white paper, you can say precisely why rather than guessing. The white paper itself is a claim about how the token works and how the reserve is composed, and reality has to keep matching it as the reserve turns over.
None of this is exotic infrastructure. It comes down to daily reconciliation done honestly and lineage you can walk backwards from any filed number. The firms that struggle with MiCA usually treated these figures as reports to generate on request, when they are invariants the system has to hold every day.
FAQ
Which MiCA category applies to a euro stablecoin?
A token that references a single official currency such as the euro is an e-money token (EMT) under MiCA Title IV. Its issuer must be an authorised credit institution or e-money institution and must redeem at par on demand.
What daily thresholds can force an issuer to stop issuing?
For asset-referenced tokens (Article 23) and EMTs denominated in a non-EU currency (Article 58), if average daily use as a means of exchange within a single currency area exceeds 1 million transactions and EUR 200 million, the issuer must stop issuing and file a plan with its competent authority.
Does the crypto travel rule have a de minimis threshold like wire transfers?
No. Under Regulation (EU) 2023/1113 the originator and beneficiary information travels with every crypto-asset transfer between providers regardless of amount. The EUR 1000 line only triggers extra verification for transfers to or from self-hosted wallets.