MiCAR imposes reserve requirements, redemption obligations, and transaction monitoring duties on stablecoin issuers and crypto-asset service providers. These are not trading desk rules. They are compliance architecture requirements that land directly on core banking infrastructure, and most compliance modules built for fiat deposits are not structurally equipped to satisfy them.
The Qivalis consortium (37 European banks across 15 countries, chaired by Sir Howard Davies) is targeting H2 2026 for a MiCAR-compliant euro stablecoin. Only 0.2% of global stablecoins are euro-denominated today. When that changes, the compliance workload lands on the institutions that issue and custody the token. The infrastructure decision is not whether to comply with MiCAR. It is whether the compliance architecture can satisfy MiCAR's requirements without a complete rebuild.
What MiCAR Actually Requires
MiCAR (Regulation EU 2023/1114, fully enforceable from June 2024) introduces two distinct regulatory categories relevant to core banking:
E-Money Tokens (EMTs) are tokens that maintain a stable value by reference to a single official currency. A euro-denominated stablecoin issued by a bank is an EMT. The issuer must hold 100% reserve backing in high-quality liquid assets, maintain them in a segregated account separate from operational funds, and redeem any token at par value on demand within one business day.
Asset-Referenced Tokens (ARTs) reference a basket of assets: currencies, commodities, or other tokens. The reserve requirement is at least 2% of average outstanding issuance, also segregated.
For both token types, MiCAR requires continuous transaction monitoring under the same AML obligations as fiat instruments. Article 83 explicitly extends AMLD5/6 obligations to crypto-asset service providers and issuers. A euro stablecoin issuer must screen token transactions against sanctions lists, apply CDD to token holders, and maintain audit trails for token movements, using the same legal standards that apply to SEPA Credit Transfers.
The compliance workload is not additive. It is structurally new.
Where Existing Compliance Modules Break
Most core banking compliance architectures operate on a clean separation: fiat CDD is handled by one pipeline (identity verification, AML screening, CDD policy evaluation), and any crypto exposure goes through a separate, often manually operated process. This separation made sense when crypto activity was marginal and token instruments were not legally equivalent to deposits.
Under MiCAR, the separation creates three concrete failure modes.
Fragmented CDD records. If a customer holds both a euro demand deposit and a euro stablecoin in the same institution, they are one customer with one risk profile. A unified CDD record must cover both exposures. Separate compliance pipelines for fiat and token instruments produce separate risk assessments, separate document storage, and separate audit trails for the same legal person, creating the appearance of two distinct compliance subjects when regulators examine the records.
Inconsistent transaction monitoring. An AML rule that flags EUR 10,000 cash transactions must apply the same threshold to EUR 10,000 token transfers. If the fiat monitoring system and the token monitoring system do not share threshold configuration and watchlist subscriptions, a transaction that would trigger a flag in one system will pass through the other. During regulatory examination, this inconsistency is a material finding, not a technical footnote.
Reserve segregation without ledger enforcement. MiCAR requires that reserve assets backing EMTs be held in accounts that are legally and operationally separate from the issuer's own funds. This is the same obligation as EMD2 safeguarding for e-money, but applied to tokenized liabilities. A compliance module that tracks the reserve balance as a reporting field, rather than enforcing segregation as a ledger constraint, cannot prevent commingling. Commingling detected at month-end is already a regulatory violation.
The Unified Compliance Architecture
Satisfying MiCAR without rebuilding the compliance stack requires a model where tokenized and fiat instruments flow through the same compliance primitives, with token-specific parameters applied at the policy layer, not hardcoded in separate code paths.
Unified CDD records. A customer's CDD record is an entity, not a transaction. It covers all instruments the customer holds at the institution, regardless of whether those instruments are fiat balances, token holdings, or custody positions. When a new instrument type is added, such as a new stablecoin product or a new ART, the CDD requirements are resolved by looking up the applicable policy for the instrument type and the customer's risk level. No new code path. A new policy record.
Shared AML pipeline. Transaction monitoring applies regardless of instrument type. The AML screening engine receives a normalized transaction event (amount, currency or token identifier, counterparty, direction, timestamp) and evaluates it against the same sanctions list, PEP database, and threshold configuration that applies to fiat transactions. The token identifier is a parameter, not a branch in the monitoring logic.
Ledger-enforced reserve segregation. The reserve account backing a stablecoin issuance must be a first-class account type in the ledger, with the same structural isolation that EMD2 safeguarding accounts receive. Transfers from the reserve account to operational accounts are blocked unless they pass through an authorized workflow: the same durable, journaled workflow that governs fee extraction from e-money safeguarding accounts. Compliance is enforced by the ledger architecture, not by a reporting query that checks the balance after the fact.
The Redemption Right as a Ledger Constraint
MiCAR Article 48 grants token holders the right to redeem any EMT at par value at any time. The issuer must execute redemption within one business day. This is not a contractual option. It is a regulatory obligation with a 24-hour settlement deadline.
For core banking infrastructure, redemption-on-demand means the ledger must be able to execute a token-to-fiat swap (decrease the customer's token balance, increase their demand deposit or initiate a fiat transfer) within one business day for any token volume at any time. The reserve account must hold sufficient liquid assets to cover the redemption without delay.
This creates a liquidity management requirement that feeds back into the reserve architecture. The reserve must not only exist and be segregated. It must be immediately accessible for redemption. An institution that invests EMT reserves in 30-day instruments satisfies the "low-risk assets" requirement of MiCAR Art. 36(1)(b) but cannot meet the 24-hour redemption deadline. The liquidity constraint is as strict as the reserve requirement.
From a workflow architecture perspective, EMT redemption is a multi-step operation: validate token balance, verify reserve coverage, execute the debit of the token account and the credit of the fiat account, update the reserve balance, confirm to the customer, and produce an audit record. All steps must complete within one business day. If any step fails, the workflow must compensate cleanly: the token balance is not debited if the fiat credit cannot execute. A durable execution engine with exactly-once guarantees provides this property structurally.
Germany, Italy, and the Kill-Switch Proposal
Germany and Italy have jointly proposed an EU "kill switch" mechanism for non-compliant global stablecoins: the ability for European regulators to block or restrict specific token types that present systemic risk or violate MiCAR obligations. This proposal, under review as of mid-2026, has direct architectural implications.
A kill switch requires that the compliance layer can act on a policy decision in real time: blocking new token issuance, blocking redemptions from specific addresses, or blocking transfers above defined thresholds, without manual intervention in each transaction. The compliance engine must be able to receive a policy update (a new restriction on a specific token or token category) and apply it immediately to all subsequent transactions.
This is exactly the requirement that hardcoded compliance logic cannot satisfy. If the restriction logic is embedded in application code, applying a new restriction requires a deployment. In a regulatory environment where a kill switch may need to activate in hours, a deployment cycle is not a viable response time. Configuration-driven compliance policy, where a new restriction is a new policy record applied at the evaluation layer, handles this without a code change.
Trade-offs
Unifying fiat and token compliance through a shared architecture has costs.
Data model complexity. A CDD record covering multiple instrument types requires a more abstract data model than one covering fiat accounts only. The instrument-type parameter must be explicit throughout the compliance pipeline: screening queries, risk scoring rules, audit record format, and reporting templates all need to be parameterized on instrument type rather than assuming fiat.
Regulatory uncertainty. MiCAR's technical standards are not fully settled. The EBA and ESMA are still issuing regulatory technical standards (RTS) clarifying reserve composition, redemption procedures, and AML obligations for specific token categories. A compliance architecture built for the current MiCAR text must be designed for policy change: the rules will be refined, and the implementation must absorb those refinements through configuration, not code rewrites.
Reserve management overhead. Segregated reserve accounts require their own reconciliation, their own liquidity monitoring, and their own regulatory reporting. For institutions that have never managed EMT reserves, this is new operational scope.
Fernel Context
Fernel's compliance engine models CDD policies as versioned records with four dimensions: jurisdiction, risk level, check type, and depth. The same policy model applies regardless of instrument type: a euro stablecoin holder's CDD requirements are resolved by the same policy evaluation logic as a fiat account holder's. AML screening accepts a normalized transaction event and applies shared threshold configuration. The ledger enforces reserve segregation through explicit account type constraints: transfers from reserve accounts to operating accounts are blocked unless they pass through authorized durable workflows. Policy changes take effect through record updates, not deployments.
Read more: Compliance Infrastructure | Automating Customer Due Diligence | Safeguarding Architecture for E-Money Institutions
Sources:
- MiCAR, Regulation (EU) 2023/1114, Art. 36 (Reserve requirements for EMTs), Art. 48 (Redemption rights), Art. 83 (AML obligations for CASPs)
- Qivalis consortium public announcement: 37 European banks, 15 countries, Sir Howard Davies as Chairman, H2 2026 target launch
- Cambridge Centre for Alternative Finance, Tokenized RWA Data Q1 2026: $27.5 billion on-chain, only 0.2% of global stablecoin value euro-denominated
- EBA, MiCAR Implementation Guidance and Draft Regulatory Technical Standards (2024-2025)
- EMD2, Directive 2009/110/EC, Art. 7-10 (Safeguarding), for comparison with MiCAR reserve obligations
- AMLD5, Directive 2018/843, as extended to CASPs by MiCAR Art. 83