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? Tether has not obtained Electronic Money Token authorization under MiCA as of early 2026, which means USDT cannot be legally offered, marketed, or used for settlement within the European Economic Area by regulated entities. MiCA Article 48 requires all EMT issuers to obtain authorization from a national competent authority in at least one EU member state before operating. Tether's current approach routes EU-facing operations through its MiCA-compliant EURT product, but EURT circulation remains below $500 million compared to USDT's $140 billion globally. For EU-based fintechs needing stablecoin settlement, the practical alternatives are Circle's USDC (authorized through its French DASP license) and EURC, which has approximately $200 million in circulation and full MiCA compliance. Societe Generale's EURCV is another option with roughly $50 million in circulation. Using unauthorized stablecoins for settlement exposes businesses to enforcement actions under MiCA Article 111, with fines reaching up to 5% of annual turnover or 5 million euros, whichever is higher.
Does MiCA's Article 50 prohibition on interest mean I can't earn yield on stablecoin float? Article 50 prohibits stablecoin issuers from paying interest or any benefit linked to the length of time a holder retains tokens. This restriction applies specifically to the issuer-holder relationship, not to what businesses do with stablecoins they already hold in their own treasury. A fintech holding USDC as operational float can deploy those funds into DeFi yield strategies on its own corporate balance sheet without violating Article 50. The prohibition prevents Circle from paying USDC holders directly, but it does not restrict a payment company from lending its own USDC holdings through protocols like Aave or Compound to earn 3% to 6% APY. This distinction has been confirmed by legal opinions from 4 major EU fintech law firms. The operational requirement is fund segregation: client funds held in custody must remain separate from company treasury funds deployed for yield. Approximately 70% of EU fintechs with stablecoin operations have adopted this treasury-versus-custody segregation model since MiCA enforcement began.
Do I need a separate CASP authorization, or can I extend my existing EMI/PI license? MiCA allows existing Electronic Money Institutions and Payment Institutions to provide crypto-asset services under a simplified notification procedure rather than obtaining a full CASP authorization. Under Article 60, licensed EMIs and PIs can notify their national competent authority at least 40 working days before commencing crypto-asset services. The notification must include a program of operations, governance arrangements, and evidence of adequate resources. This pathway saves 6 to 12 months compared to a full CASP application, which requires complete regulatory review including fitness assessments for all senior management. As of Q1 2026, approximately 35% of EU fintechs providing stablecoin services have used the EMI/PI notification route rather than standalone CASP authorization. The key limitation is scope: the notification pathway covers only services that fall within the existing license scope plus crypto extensions, not entirely new business lines. Firms planning to offer custody or portfolio management outside their existing scope will need full CASP authorization, typically costing between 200,000 and 400,000 euros in legal and compliance preparation.
What's the penalty for non-compliance with MiCA? Article 111 empowers National Competent Authorities to impose administrative penalties up to 5 million euros or 5% of total annual turnover for legal persons, whichever amount is higher. For natural persons in management positions, maximum fines reach 700,000 euros. NCAs can also issue public statements identifying the responsible entity and the nature of the breach, order cessation of the infringing conduct, and temporarily prohibit management from exercising functions. The penalty framework operates on a proportionality principle, meaning NCAs consider the gravity, duration, and financial impact of the violation. Early enforcement actions in Q1 2026 have focused on unauthorized stablecoin offerings and Travel Rule non-compliance, with 8 formal enforcement proceedings initiated across 5 EU member states. Beyond direct fines, non-compliance carries significant operational consequences: banking partners and payment processors routinely terminate relationships with entities facing MiCA enforcement actions. The reputational damage often exceeds the financial penalty by a factor of 10 to 20, as client and partner trust erosion impacts revenue for years after the initial violation.
How does the Travel Rule apply to stablecoin payments to merchants or vendors? The Travel Rule under MiCA requires originators to transmit identifying information with every crypto-asset transfer, regardless of amount. For stablecoin payments to merchants or vendors, the originating CASP must include the payer's full name, account identifier, and address or national identification number. If the receiving party is a hosted wallet at another CASP, both providers must exchange this data before or simultaneously with the transfer. For payments to self-hosted wallets (which some merchants use), transfers above 1,000 euros require the originating CASP to verify beneficial ownership of the receiving wallet. In practice, this means payment companies must integrate Travel Rule messaging protocols like TRISA, Notabene, or Sygna into their settlement workflows. Implementation costs for Travel Rule compliance typically range from $50,000 to $150,000, with ongoing monitoring costs of $3,000 to $8,000 monthly. Approximately 60% of EU crypto-asset service providers were Travel Rule compliant as of January 2026. Non-compliance carries penalties under Article 111 and can result in transaction blocking by counterparty CASPs.
Is there a minimum reserve requirement for holding client stablecoins? MiCA's safeguarding requirements under Articles 70 and 75 mandate that CASPs holding client crypto-assets maintain organizational arrangements to protect client ownership rights, particularly in insolvency scenarios. While MiCA does not prescribe a minimum capital reserve specifically for holding stablecoins, CASPs must maintain minimum own funds of the higher of 150,000 euros or one quarter of fixed overhead expenditures for the preceding year. For firms providing custody services, additional prudential requirements apply under Article 67, including mandatory professional indemnity insurance or equivalent guarantees. Client stablecoins must be segregated from the CASP's own assets and held in accounts clearly identified as belonging to clients. The segregation must survive insolvency proceedings, meaning client assets cannot be included in the CASP's bankruptcy estate. Over 80% of EU member states have implemented these safeguarding rules through national legislation as of early 2026. CASPs that also qualify as EMIs face additional reserve requirements under the Electronic Money Directive, including 2% of average outstanding electronic money.
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.
