The European Fintech's Guide to Stablecoin Operations Under MiCA
We've had the high-level MiCA conversation dozens of times. Everyone knows the Markets in Crypto-Assets regulation exists. Everyone knows it's "important." But when a Head of Compliance at a Dutch payment processor or a Lithuanian neobank CTO asks us what they actually need to do — step by step, article by article — the conversation gets real quiet.
That's because most MiCA content out there is either written by lawyers for lawyers (dense, theoretical, disconnected from engineering reality) or by crypto marketers who cherry-pick the parts that make stablecoins look easy (ignoring the operational burden).
This is neither. This is the playbook we wish someone had given us when we started helping European fintechs integrate stablecoin infrastructure. It's specific. It references actual MiCA articles. It tells you what you need to build, what you need to document, and where the enforcement teeth actually are.
If you're already familiar with what stablecoins are and why they matter for payments, skip ahead to the compliance section. If you need the primer first, start with our Stablecoin Payments 101 guide.
MiCA in 60 Seconds: What It Actually Regulates
MiCA (Regulation (EU) 2023/1114) creates three token categories, but for payment and treasury operations, only one matters: Electronic Money Tokens (EMTs).
EMTs are stablecoins pegged to a single fiat currency. USDC (when issued by Circle's Irish entity, Circle Internet Financial Europe Limited) is an EMT. EURC is an EMT. USDT, as of early 2026, is not — Tether has not obtained EMT authorization in the EU, and several exchanges have delisted it for European users.
If you're a European fintech using stablecoins for settlement, treasury, or yield operations, you need to be using authorized EMTs. Full stop. Using a non-authorized stablecoin doesn't just create regulatory risk — it makes your banking partners nervous, your auditors unhappy, and your license renewal harder.
The rest of this guide assumes you're working with authorized EMTs. If you're not, the first item on your to-do list is switching.
Who Needs to Worry About What
Your obligations under MiCA depend on what role you play in the stablecoin flow. Here's the breakdown for the roles most European fintechs occupy.
You're Using Stablecoins for Settlement (Most Common)
You're a payment processor, a neobank, or a money transfer operator. You convert customer euros to USDC, settle through a stablecoin rail, and convert back to fiat at the destination. You're not issuing stablecoins — you're using them as plumbing.
Your primary MiCA obligations:
Article 68 — Authorization as a Crypto-Asset Service Provider (CASP). If you're providing services related to crypto-assets (including stablecoin exchange and transfer), you need CASP authorization from your national competent authority (NCA). If you already hold an e-money or payment institution license, there's a simplified pathway — your NCA may allow you to extend your existing authorization rather than obtaining a new one.
Article 70 — Obligation to act honestly, fairly, and professionally. This sounds vague, but it has teeth. It means you need documented policies for conflicts of interest, fee transparency, and client communication. Your compliance team needs to produce these.
Article 75 — Safeguarding of client crypto-assets. If at any point you hold stablecoins on behalf of clients (even transiently during settlement), you must segregate them from your own assets. This is the ring-fencing requirement. We'll go deep on this below.
You're Earning Yield on Stablecoin Float
You hold client settlement funds in USDC and earn yield during the holding period. This is what we help companies do, and it adds a layer of complexity.
Additional obligations:
Article 50 — Prohibition of interest. This is the big one. Article 50 explicitly prohibits EMT issuers from paying interest to holders. But — and this is critical — it does not prohibit holders from earning yield through independent strategies. The distinction matters: Circle cannot pay you interest for holding USDC. But you can deposit USDC into a third-party yield protocol or lending market and earn yield that way. The yield doesn't come from the issuer; it comes from the market.
This is the legal architecture we use. Our yield engine deploys client USDC into institutional lending markets on Solana. The yield is generated by borrower demand, not by the EMT issuer. We've had this structure reviewed by multiple EU-based legal counsel, and the consensus is that it's compliant with Article 50 — but your own counsel should confirm for your specific operating model.
Article 75 continued — Safeguarding still applies. Even when USDC is deployed into yield strategies, it must remain segregated per client. This is where ring-fenced vault architecture becomes essential. Each client's yield position must be isolated. If one client wants to withdraw during a yield cycle, their withdrawal shouldn't affect other clients' positions.
You're Offering Stablecoin Custody
If you're holding stablecoins on behalf of clients as a custodial service (not just transiently during settlement), your obligations expand significantly.
Key requirements:
Article 73 — Custody and administration of crypto-assets. You need specific CASP authorization for custody. You must maintain a register of positions, segregate client assets, ensure assets are not used for your own account (unless the client explicitly consents), and bear liability for any loss.
Article 74 — Liability. You are liable for the loss of crypto-assets held in custody up to the market value at the time of loss. This includes losses due to hacking, unless you can prove the loss was due to events beyond your reasonable control. Get cyber insurance.
The Ring-Fencing Playbook
Ring-fencing is where MiCA theory meets engineering reality. Here's what compliant ring-fencing actually looks like in practice.
What MiCA Requires
Article 75 requires that CASPs:
Hold client crypto-assets separately from their own
Keep records that distinguish each client's holdings
Do not use client crypto-assets for their own account unless explicitly authorized
Ensure that client crypto-assets are not part of the CASP's insolvency estate
How We Implement It
On Solana (where we operate), ring-fencing is implemented through program-derived addresses (PDAs). Each client gets a unique vault address derived from a combination of the program ID and the client's identifier. The vault is on-chain, auditable, and mathematically isolated from every other vault.
Here's what that means in practice:
No commingling. Client A's 100,000 USDC and Client B's 250,000 USDC are in separate on-chain addresses. They cannot be mixed even accidentally.
Independent yield positions. When Client A's funds are deployed into a yield strategy, the position is tracked per-vault. Client A's yield accrues to Client A's vault. No pooling, no averaging.
Auditable at any time. Any auditor can verify the balance of each vault address on the blockchain explorer. The record is immutable and timestamped.
Insolvency protection. Because the vaults are on-chain and segregated, they're not part of our balance sheet. In the unlikely event we went insolvent, client funds in ring-fenced vaults are not creditor-accessible.
If you're building this yourself, the key architectural decision is: per-client vaults (which we recommend) vs. omnibus wallets with internal accounting (which is cheaper to build but harder to audit and riskier from a regulatory perspective). MiCA's Article 75 doesn't explicitly require separate wallets, but per-client isolation is the cleanest way to demonstrate compliance. Your auditor will thank you.
DORA: The Regulation Nobody's Thinking About
Here's something most stablecoin guides miss entirely. If you're a financial entity in the EU using stablecoin infrastructure, you're also subject to the Digital Operational Resilience Act (DORA), which became fully applicable in January 2025.
DORA (Regulation (EU) 2022/2554) requires financial entities to manage ICT (information and communication technology) risk, including risks from third-party technology providers.
Why This Matters for Stablecoin Operations
If you're using a third-party provider for stablecoin settlement, yield infrastructure, or custody (including us), DORA classifies that provider as a "critical ICT third-party service provider" if their disruption would materially affect your operations.
Your DORA obligations related to stablecoin infrastructure:
Article 28 — Third-party risk management. You must assess the ICT risk of every provider in your stablecoin stack: the blockchain network itself, the on-ramp/off-ramp provider, the yield infrastructure provider, the wallet/key management system. Each one needs a risk assessment documenting what happens if they go down.
Article 30 — Contractual arrangements. Your contracts with stablecoin infrastructure providers must include specific provisions: service level agreements, incident notification timelines, audit rights, data location requirements, and exit strategy terms. If your current provider contracts don't have these, add them.
Article 26 — ICT incident reporting. If a stablecoin infrastructure incident affects your operations (blockchain congestion delays settlement, a yield protocol exploit affects client funds, an on-ramp provider goes offline), you must report it to your NCA within the DORA-specified timelines: 4 hours for initial notification, 72 hours for intermediate report, 1 month for final report.
Article 25 — Digital operational resilience testing. You must regularly test your stablecoin operations against failure scenarios. What happens if the blockchain is congested for 6 hours? What if the on-ramp provider suspends EUR conversions? What if a yield position can't be unwound within the expected timeframe? Document these tests and their results.
Most fintechs we talk to have DORA compliance programs for their traditional infrastructure but haven't extended them to cover stablecoin operations. This is a gap that regulators will notice, particularly during supervisory reviews.
Transfer of Funds Regulation (TFR): The Travel Rule
The EU's recast Transfer of Funds Regulation extends the Travel Rule to crypto-asset transfers. It became applicable alongside MiCA and requires that all crypto-asset transfers between CASPs include originator and beneficiary information — regardless of amount. There's no threshold; even a $1 transfer needs the data.
What you need to implement:
Outgoing transfers: Before sending stablecoins, you must transmit the originator's name, account number (wallet address), and either address/date of birth/national ID to the beneficiary CASP.
Incoming transfers: Before crediting received stablecoins, you must verify that the originator information was received and is not obviously incomplete.
Unhosted wallet transfers: Transfers to/from wallets not hosted by a CASP require additional due diligence for transfers exceeding EUR 1,000. This includes verifying that the unhosted wallet is actually controlled by your client.
In practice, this means you need a Travel Rule compliance solution integrated into your stablecoin transfer workflow. Several providers exist (Notabene, Chainalysis, Elliptic), and the integration is typically API-based. Budget 2-4 weeks of engineering time for the integration and testing.
Navigating MiCA compliance for your stablecoin operations? We've done this with payment companies across the EU. Book a working session — we'll map your specific regulatory obligations and show you how the infrastructure works.
The Enforcement Timeline: What's Live Now
Here's where things stand as of March 2026. MiCA enforcement is not theoretical — it's happening.
Fully enforced since June 30, 2024:
Title III (Asset-Referenced Tokens) and Title IV (Electronic Money Tokens). EMT issuers must be authorized. Non-authorized stablecoins cannot be marketed in the EU.
Fully enforced since December 30, 2024:
Titles II, V, VI, VII. CASP authorization requirements, market abuse rules, and supervisory powers are all live.
Grandfathering period expired:
CASPs operating under national regimes had until June 30, 2025 to apply for MiCA authorization (some member states extended this to December 2025). If you haven't applied yet, you're operating unlicensed. Fix this immediately.
ESMA technical standards rolling out throughout 2025-2026:
The European Securities and Markets Authority is publishing Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) that fill in the operational details. Key ones to watch: RTS on complaint handling (published), RTS on conflicts of interest (published), RTS on business continuity (in consultation), and RTS on record-keeping for CASPs (in consultation).
The practical implication: if you're a European fintech using stablecoins operationally today, you need to be either CASP-authorized or operating under a valid extension from your NCA. The gray zone is closed.
Country-Specific Nuances
MiCA is a regulation (not a directive), so it applies directly in all EU member states without national transposition. But NCAs have some discretion in implementation, and the practical experience varies by country.
Netherlands (AFM/DNB)
The AFM (Authority for Financial Markets) and DNB (De Nederlandsche Bank) have been among the most proactive NCAs. The Netherlands already had a national crypto registration regime before MiCA, so Dutch fintechs are relatively well-prepared. AFM has been responsive on CASP applications, with processing times of 3-6 months. DNB handles the prudential side and has published detailed guidance on safeguarding requirements.
If you're operating from the Netherlands: you're in one of the easier jurisdictions for MiCA compliance. The regulators understand the technology, and there's a growing ecosystem of legal and compliance advisors with hands-on MiCA experience.
Ireland
Ireland is significant because Circle chose it as the EU base for its EMT operations (USDC in the EU is issued by Circle Internet Financial Europe Limited, authorized by the Central Bank of Ireland). This means USDC's regulatory status in the EU flows from Irish authorization. If you're using USDC, your compliance argument starts with "we're using an EMT authorized by the Central Bank of Ireland."
Germany (BaFin)
BaFin has been thorough but slower. CASP applications in Germany are taking 6-12 months. BaFin has also published additional national guidance that in some areas goes beyond MiCA's baseline requirements, particularly around anti-money laundering and custody segregation. If you're operating from Germany, budget extra time and legal cost for the authorization process.
Lithuania (Bank of Lithuania)
Lithuania has been a popular jurisdiction for fintech licensing in general, and the Bank of Lithuania has been pragmatic about MiCA implementation. Processing times for CASP applications have been 4-8 months. If you already hold a Lithuanian EMI or PI license, the Bank of Lithuania has been relatively straightforward about extending authorizations to cover crypto-asset services.
A Practical Compliance Checklist
Here's the operational checklist we walk through with every European fintech we onboard. Not legal advice — consult your own counsel. But this covers the infrastructure and documentation you'll need.
Regulatory
Confirm you're using only authorized EMTs (USDC via Circle Ireland, EURC, etc.)
Obtain or extend CASP authorization from your NCA
File any required notifications under your existing license (PI/EMI)
Review Travel Rule obligations and integrate a compliance solution
Document your AML/CFT procedures for stablecoin flows
Appoint a compliance officer responsible for MiCA matters
Technical
Implement ring-fenced wallet architecture (per-client vaults)
Build or integrate real-time transaction monitoring (KYT)
Set up Travel Rule data exchange with counterparty CASPs
Implement key management with proper access controls and backup
Deploy monitoring for blockchain network health and congestion
Build incident detection and escalation for stablecoin infrastructure
Operational
Document DORA risk assessment for all ICT providers in the stablecoin stack
Update contracts with stablecoin infrastructure providers (Article 30 terms)
Create and test business continuity plan for stablecoin operations
Establish incident reporting procedures (4h/72h/1mo timelines)
Run digital operational resilience tests (Article 25)
Set up regulatory reporting templates for your NCA
Yield-Specific (If Earning Yield on Float)
Document legal opinion confirming yield strategy compliance with Article 50
Implement per-client yield tracking and reporting
Ensure yield positions can be unwound within your SLA timeframes
Document risk assessment for each yield source/protocol
Create client disclosure documents explaining yield mechanics and risks
Implement automated yield reporting for client transparency
What This Looks Like in Practice: A Timeline
For a European fintech that's currently processing payments via traditional rails and wants to add stablecoin settlement with yield-on-float, here's a realistic timeline.
Months 1-2: Legal and Regulatory Assessment Engage MiCA-specialized counsel. Determine your specific obligations based on your license type and operating model. Begin CASP application if needed. This runs in parallel with everything else.
Months 2-3: Infrastructure Selection and Integration Choose your stablecoin infrastructure stack: on-ramp/off-ramp provider, yield infrastructure (hi, that's us), wallet/key management, and Travel Rule compliance solution. Begin technical integration.
Months 3-4: Compliance Documentation Produce the documents your NCA will want to see: AML/CFT procedures for stablecoin flows, ring-fencing policy, incident reporting procedures, DORA risk assessments, client disclosures.
Months 4-5: Testing and Pilot Run stablecoin settlement on a single corridor with limited volume. Validate the economics, the compliance workflow, and the operational procedures. Fix what breaks.
Month 6: Scale Expand to additional corridors and increase volume. By this point, your compliance framework is documented, tested, and operational.
Six months is realistic for a fintech with an existing license and a motivated team. It can be faster if you're already partially set up (some companies we work with go live in 8-10 weeks), or slower if you need a new CASP authorization from scratch.
FAQ
Can I use USDT for settlement in the EU under MiCA? As of early 2026, Tether has not obtained EMT authorization in the EU. Several major exchanges have delisted USDT for European users. Using USDT for settlement operations by a CASP in the EU carries significant regulatory risk. We strongly recommend using USDC (authorized via Circle Ireland) or EURC. See our stablecoin comparison for the full analysis.
Does MiCA's Article 50 prohibition on interest mean I can't earn yield on stablecoin float? Article 50 prohibits EMT issuers from granting interest to token holders. It does not prohibit token holders from independently deploying their tokens into yield-generating strategies. The yield comes from market activity (lending, liquidity provision), not from the issuer. This distinction has been confirmed by multiple legal analyses, but you should get your own counsel's opinion for your specific model.
Do I need a separate CASP authorization, or can I extend my existing EMI/PI license? MiCA allows member states to create simplified authorization pathways for entities already holding certain financial licenses. In practice, most NCAs are allowing EMIs and PIs to extend their authorizations. The specifics vary by jurisdiction — check with your NCA. The process is typically faster and less costly than a standalone CASP application.
What's the penalty for non-compliance with MiCA? Article 111 gives NCAs the power to impose administrative fines of up to EUR 5 million or 3% of total annual turnover (whichever is higher) for natural persons, and up to EUR 15 million or 12.5% of total annual turnover for legal persons. For certain violations involving ARTs or significant EMTs, fines can go up to EUR 5 million or 12.5% of turnover. These are maximum penalties — actual fines depend on severity, duration, cooperation, and other factors.
How does the Travel Rule apply to stablecoin payments to merchants or vendors? If the receiving party is a CASP (or if the payment goes through a CASP's hosted wallet), full Travel Rule data must accompany the transfer. If the payment goes to an unhosted wallet (a self-custody wallet held by the merchant), additional due diligence applies for transfers over EUR 1,000. In practice, most B2B stablecoin payments flow between CASPs, so the hosted wallet scenario is more common.
Is there a minimum reserve requirement for holding client stablecoins? MiCA's safeguarding requirements (Article 75) focus on segregation and protection rather than capital reserves. However, your NCA may impose additional prudential requirements as part of your CASP authorization, particularly if you're providing custody services. DORA's operational resilience requirements may also factor into the NCA's assessment of your capital adequacy.
The Bottom Line
MiCA isn't the enemy. It's actually the best thing that's happened to European fintechs exploring stablecoins, because it replaced a patchwork of national rules with a single framework. The compliance burden is real — ring-fencing, DORA, Travel Rule, CASP authorization — but it's knowable and bounded. No more guessing what your regulator wants.
The fintechs that treat MiCA as a moat rather than a burden will win. Because compliance is hard, and that means your less-diligent competitors won't do it. The companies that get their stablecoin operations properly set up under MiCA today will have a structural advantage that compounds over time.
We've helped payment companies and neobanks across the EU navigate exactly this process. If you're at the stage where you know you need to move but aren't sure where to start, our board pitch playbook is a good next step. And if you're past the "should we" and into the "how do we," that's where we come in.
