European fintech regulation is not a single gate. A product that holds customer funds, executes payments, issues card credentials, or facilitates crypto-asset exchange may intersect the Electronic Money Directive, the Payment Services Directive, banking law, anti-money-laundering obligations, and—since 2024—the Markets in Crypto-Assets Regulation. Founders and infrastructure teams frequently ask whether they need an EMI licence, a MiCA authorisation, or a banking licence. The accurate answer begins with activity mapping, not acronym preference.
MiCA vs EMI is a common shorthand, but it can mislead. These frameworks regulate different activities with different definitions of client assets, custody, issuance, and reporting. Some groups require neither directly if they operate as technology providers to authorized firms. Others need multiple authorisations across entities. Multi-brand portfolios add complexity: one brand may offer e-money wallets while another facilitates crypto-asset services, each with distinct perimeter questions.
This article explains the EU regulatory stack relevant to fintech products, how MiCA and EMI relate and diverge, and how infrastructure-first groups should centralize compliance workflows without assuming that shared technology substitutes for authorisation. It is general information, not legal advice; specific structures require qualified counsel and supervisor engagement.
This analysis connects to FinDech's Crypto Core, part of the Seven Cores infrastructure model.
The EU regulatory stack in plain terms
At a high level, EU financial services law allocates activities to authorisation categories. Credit institutions (banks) may accept deposits and conduct a broad range of lending and payment activities subject to significant prudential requirements. Electronic money institutions issue electronic money—stored monetary value accepted by third parties—and provide limited payment services linked to that e-money. Payment institutions provide payment services without issuing e-money as their core model. Investment firms and asset managers fall under MiFID and related rules. MiCA adds a dedicated regime for crypto-assets, crypto-asset service providers, and issuers of asset-referenced and e-money tokens.
Anti-money-laundering rules apply horizontally. The AML Regulation and Directive require customer due diligence, ongoing monitoring, and reporting for obliged entities—which include many authorized firms and, under national transposition, certain crypto-asset service providers even before MiCA fully harmonized the field.
Technology platforms that orchestrate APIs, configure workflows, and aggregate provider connections are not automatically exempt. Substance matters: who holds funds, who contracts with the customer, who executes transactions, and who makes decisions affecting client assets determine perimeter. A platform can be out of scope while its partner EMI is in scope—or vice versa if structuring slips from delegation into unauthorized activity.
- Banking: deposits, broad lending, significant capital and governance requirements.
- EMI: issuance of electronic money and related payment services.
- PI: payment services without e-money issuance as the primary model.
- MiCA: crypto-asset services, issuance of ARTs and EMTs, CASP authorisation.
- AML: cross-cutting obligations for obliged entities and certain crypto activities.
Electronic money institutions: scope and constraints
An EMI licence under the Electronic Money Directive (EMD2) authorizes issuance of electronic money. Electronic money is electronically stored monetary value representing a claim on the issuer, issued on receipt of funds, and accepted by persons other than the issuer. Prepaid wallets, certain stored-value accounts, and some multi-purpose payment instruments may fall here depending on structure.
EMIs are subject to safeguarding requirements for funds received in exchange for e-money, capital requirements, governance standards, and AML obligations. They may provide payment services ancillary to e-money issuance. They are not full banks: deposit-taking beyond e-money rules, credit provision beyond narrow exceptions, and some investment activities remain outside standard EMI permissions unless additional authorisations apply.
Passporting allows authorized EMIs established in one EU member state to provide services in others through notification procedures—subject to host country conduct rules and operational setup. Passporting is not automatic market entry; operational, tax, and consumer protection obligations still require implementation.
MiCA: crypto-assets, CASPs, and stable tokens
The Markets in Crypto-Assets Regulation (Regulation (EU) 2023/1114) establishes harmonized requirements for issuers of asset-referenced tokens (ARTs), e-money tokens (EMTs), and crypto-asset service providers (CASPs). It entered into force with phased application; CASP authorisation requirements apply from late 2024 onward with transitional arrangements for firms previously operating under national regimes.
CASPs include services such as custody and administration of crypto-assets, operation of trading platforms, exchange of crypto-assets for funds or other crypto-assets, execution of orders, placement, reception and transmission of orders, advice, portfolio management, and transfer services. Issuance of ARTs and EMTs triggers issuer-specific obligations, including white papers, governance, and reserve requirements for certain token types.
MiCA does not replace EMI or banking law for fiat e-money products. An e-money token under MiCA is a specific category with ties to credit institution or EMI issuance rules for certain structures. Product teams must analyze token economics and redemption rights carefully—labels in marketing materials do not determine classification.
MiCA vs EMI: how the comparison should be used
Compare MiCA and EMI by activity, not by product slogan. Fiat-denominated stored value with general third-party acceptance may be e-money within EMI perimeter when the firm issues the claim. Facilitating exchange of Bitcoin for euro on a platform may be a CASP activity under MiCA. Holding crypto-assets on behalf of clients may trigger custody rules under MiCA. Providing payment initiation against a bank account may be a payment service under PSD2 through a PI or EMI.
A single consumer app can touch multiple regimes. A wallet that holds fiat e-money, initiates SEPA transfers, and offers a crypto swap feature may involve EMI permissions for the fiat wallet, CASP authorisation or partnership for the swap, and robust AML across both. The comparison MiCA vs EMI is therefore not exclusive or; it is a prompt to decompose features into regulated activities.
Groups building shared infrastructure should encode activity tags in product configuration—this feature is fiat e-money, this feature is crypto transfer, this feature is payment initiation—so compliance reviews and partner due diligence trace consistently across brands.
1. Inventory user-facing capabilities
List every way customers can move, hold, or exchange value, including off-ramps, internal transfers, and staking-like features.
2. Map capabilities to EU activity definitions
Use EMD2, PSD2, MiCA, and national guidance—not internal feature names—to classify each capability.
3. Assign entity or partner execution
Decide which authorized firm executes each activity and document outsourcing or delegation chains.
4. Align monitoring and reporting
Ensure transaction monitoring rules, travel rule handling, and regulatory reports match the assigned entity and activity.
Implications for multi-brand fintech groups
Portfolio brands amplify perimeter risk when shared technology blurs customer-facing boundaries. Each brand should have clear customer contracts, disclosures, and activity scope. Shared KYC and transaction monitoring can centralize operations, but case disposition must respect which entity is obliged for reporting in a given scenario.
Passporting and market entry strategies differ by authorisation. An EMI passport does not passport CASP services under MiCA. A group planning both fiat wallets and crypto exchange across several EU markets needs a matrix of authorisations, partners, or restrictions—not a single licence narrative for investors.
Infrastructure providers like FinDech describe reusable Cores—Crypto Core, Payments Core, Banking Core, Risk Shield— as technology and operating domains connecting products to appropriate infrastructure and authorized providers. Shared Cores do not confer licences on the platform or its brands. Regulatory strategy remains a group and entity-level responsibility, informed by product scope and supervisor expectations.
Compliance as shared infrastructure
Rather than replicating compliance teams per brand, groups can centralize customer due diligence workflows, sanctions screening, transaction monitoring, case management, and record retention in shared Risk Shield capabilities. Centralization improves consistency and auditability if policy engines apply brand- and entity-specific rules.
Shared compliance infrastructure must support different obliged entity configurations: which AML program applies, which reporting formats export, which thresholds trigger enhanced due diligence. Technical multi-tenancy must mirror legal multi-entity structures.
Regulatory change management also benefits from centralization. MiCA technical standards, EBA guidelines on ICT risk, and FATF travel rule updates propagate once through shared systems rather than through ad hoc brand patches.
Jurisdiction and entity strategy without shortcuts
Member states differ in supervisor responsiveness and interpretive guidance even under harmonized EU law. Groups choose home member states based on activity mix, staffing, and passporting plans.
Some teams explore third-country hubs for technology while keeping EU regulated activities in EU entities. That split requires clear outsourcing agreements; supervisors scrutinize where decisions are made and where customer funds sit. Licence claims should match actual authorisations on record.
Practical next steps for product and compliance leaders
Commission a perimeter memo from qualified EU financial regulatory counsel before scaling marketing or partner negotiations.
Maintain a living activity matrix shared between legal, compliance, product, and engineering. Infrastructure tags in configuration should reference matrix identifiers.
Engage supervisors or sandbox programs early where available to test classification assumptions before irreversible build decisions. Plan operational readiness—safeguarding, reporting, complaints handling—as authorisation conditions, not post-launch paperwork.
Practical takeaways
MiCA and EMI sit in a broader EU regulatory stack alongside payment services, banking, investment, and AML rules. The useful question is not which acronym sounds modern, but which activities a product performs and which authorisations or partners those activities require.
Multi-brand fintech groups should centralize compliance workflows and infrastructure where consistency helps, while preserving entity clarity and activity-specific controls. Shared technology accelerates configuration; it does not collapse regulatory perimeter.
Treat regulatory strategy as a product input reviewed on every major roadmap decision—new asset type, new corridor, new token, new brand—not as a one-time legal memo filed away after incorporation.
