EMI Licence vs Crypto CASP Authorisation

A business that lets customers buy crypto with euros may appear to need one regulatory approval. In reality, the EMI licence vs crypto CASP authorisation question usually reveals two separate regulated activities: handling fiat payment flows and providing crypto-asset services. Choosing the wrong route can delay launch, restrict revenue lines, complicate banking and create a regulatory gap that becomes visible during due diligence.

For founders building an EU-facing exchange, wallet, OTC desk, payment product or token platform, the decision is not about which authorisation is easier to obtain. It is about matching the legal permissions, operating model and customer journey before the application is drafted.

EMI licence vs crypto CASP authorisation: the core difference

An electronic money institution, or EMI, is authorised under the EU payment services and electronic money framework, principally PSD2 and the Electronic Money Directive as implemented in the relevant Member State. Its role is fiat-facing. An EMI may issue electronic money, provide payment services and, within the applicable rules, operate payment accounts, execute transfers and support payment cards.

A crypto-asset service provider, or CASP, is authorised under the Markets in Crypto-Assets Regulation, commonly known as MiCA. A CASP provides defined services involving crypto-assets. Depending on the authorisation sought, this can include custody and administration, operating a trading platform, exchanging crypto-assets for funds or other crypto-assets, executing orders, placing crypto-assets, providing transfer services, portfolio management, advice and reception and transmission of orders.

The distinction is straightforward in principle. An EMI moves and stores regulated fiat value. A CASP provides regulated crypto-asset services. In practice, the two often sit within the same customer journey, which is why a single-company structure can become difficult to sustain.

A customer who deposits GBP or euros, converts it into crypto, stores the crypto in a hosted wallet and later withdraws fiat is interacting with both sides of the regulatory perimeter. The crypto exchange and custody activity falls within MiCA. The underlying collection, holding and movement of customer money may require an EMI, payment institution or a properly structured relationship with one.

What each authorisation allows - and does not allow

A CASP authorisation is not a payment licence. Even where a CASP exchanges crypto-assets for funds, that permission does not automatically allow it to issue payment accounts, provide payment cards or hold customer fiat balances as electronic money. Trying to treat a CASP permission as a substitute for regulated payments infrastructure is a common route to bank account closures, rejected applications and remedial work after launch.

Equally, an EMI licence is not permission to run a crypto exchange or offer custody of clients' private keys. An EMI may support a crypto business by providing safeguarding, payment account or e-money infrastructure, but it cannot rely on its EMI status to market itself as an authorised crypto custodian or exchange operator.

The position is especially significant for stablecoin models. Under MiCA, electronic money tokens, or EMTs, are crypto-assets referencing the value of one official currency. EMT issuers must generally be authorised as a credit institution or electronic money institution. A CASP may provide services around an EMT, such as custody or exchange where authorised, but CASP authorisation alone does not permit issuance of the token.

Asset-referenced tokens have a different issuer regime, while utility tokens and other crypto-assets may trigger separate white paper, marketing and governance requirements. The product classification should therefore be completed before selecting the licence route. Branding a token as a stablecoin does not decide its legal status.

Start with the money flow, not the product label

The fastest way to identify the correct regulatory architecture is to map the flow of funds and assets from first customer contact to final withdrawal. This exercise should cover the entity that contracts with the client, receives fiat, holds private keys, executes conversion, maintains the ledger, carries out screening and resolves complaints.

A fiat on-ramp illustrates the point. If an exchange accepts customer funds into a payment account held with a regulated EMI and instructs the EMI to execute the payment, the exchange may not need its own EMI licence. It will, however, need a clear contractual structure, appropriate disclosures and operational controls. The EMI will conduct its own onboarding and risk assessment, and it may reject models involving opaque transaction flows or weak source-of-funds processes.

If the business itself intends to issue e-money, retain fiat balances for customers, offer IBANs or control payment execution, reliance on a third-party EMI is unlikely to be enough. It may need its own EMI or payment institution authorisation, depending on the services and jurisdiction.

This is not merely a legal design question. It affects capital planning, safeguarding arrangements, outsourcing contracts, customer support, financial crime controls and the time needed to go live.

MiCA raises the standard for crypto operations

MiCA replaced the fragmented national approach to crypto registration and authorisation with an EU-wide framework, subject to transitional arrangements that vary by Member State. A business operating under a legacy virtual asset registration should not assume that it can continue indefinitely or passport its services across the EU.

A CASP application requires more than a policy pack. Regulators expect a viable programme of operations, a clear governance structure, suitably experienced management, prudential safeguards, ICT resilience, custody arrangements, conflicts controls, complaint handling and evidence that AML obligations work in practice.

For custody businesses, the operational detail is particularly demanding. The applicant must show how private keys are generated, stored, accessed, backed up and recovered; how client assets are segregated; how incidents are escalated; and how the business avoids using client crypto-assets for its own account. A generic technology description will not satisfy a regulator reviewing a high-volume or cross-border model.

The same applies to outsourcing. White-label exchange technology, cloud hosting, blockchain analytics and payment providers may be commercially efficient, but they do not transfer regulatory accountability. The authorised entity must retain control, document oversight and be able to evidence service continuity if a key supplier fails.

When a combined model makes commercial sense

There are three common structures. The first is a CASP working with an independent EMI or bank. This is often the quickest route for a crypto-only business that needs reliable fiat rails but does not intend to own the payment relationship. The trade-off is dependency on a third party's risk appetite, onboarding standards and commercial terms.

The second is a group structure with separate regulated entities: one CASP and one EMI or payment institution. This can support a stronger customer proposition and greater control over payments, but it requires careful governance, intercompany agreements, operational separation and additional capital.

The third is acquisition of a ready-made regulated vehicle, where available and appropriate. This can reduce the time spent on incorporation and initial structuring, but it is not a shortcut around due diligence. The buyer must assess the scope of permissions, regulatory history, ownership-change requirements, legacy liabilities, technology arrangements and whether the authorisation actually matches the intended model.

A combined model is justified where payments are central to the product and the business can support the compliance burden. It is not justified simply because owning more permissions sounds more credible to investors. Unused permissions still bring reporting, governance and control obligations.

Banking, safeguarding and AML are the practical pressure points

Many licensing plans fail after authorisation because fiat infrastructure was treated as a procurement task rather than a core regulatory workstream. Banks and EMIs review crypto businesses closely. They will ask how the business identifies customers, monitors blockchain activity, screens sanctions exposure, investigates alerts, handles high-risk jurisdictions and detects mule activity or fraud.

For an EMI, safeguarding is a central obligation. Relevant customer funds must be protected through the prescribed method, reconciled accurately and separated from the institution's own money. For a CASP, client asset protection and custody controls are equally central, but they are not the same regime. Combining fiat and crypto controls into one vague 'safeguarding policy' is a warning sign.

The AML framework must also reflect the actual services. A hosted-wallet provider needs wallet risk scoring, transaction monitoring and travel rule processes. An exchange requires controls over market abuse, suspicious order patterns and source-of-wealth triggers. A payments business needs fraud monitoring, payment screening and reconciliation controls. One template cannot credibly cover all three.

How to choose the right route before filing

The right question is not, “Do we need an EMI licence or a CASP authorisation?” It is, “Which regulated activities will our entity perform, in which countries, and who controls the customer assets at every stage?” That analysis should be translated into a jurisdiction comparison, licensing strategy, group chart, operating model and application evidence plan before any regulator-facing submission.

Where an EMI is required, assess the local authorisation process, capital requirements, safeguarding model and payment scheme strategy. Where CASP authorisation is required, define the MiCA service classes precisely and ensure the governance, custody, ICT and AML documentation reflects the real business. If both are required, decide whether separate group entities or a regulated partner model produces the better route to market.

NUR Legal supports this work from jurisdiction selection through to compliance build, documentation and regulator-facing execution. The objective is not to collect licences. It is to establish a structure that can obtain banking, satisfy ongoing supervision and support commercial growth without a costly redesign six months after launch.

Before committing to technology, marketing claims or a launch date, test the proposed customer journey against both payment and crypto rules. That early decision is often what separates a credible regulated business from a product that cannot scale once the first bank, investor or regulator asks who is really holding the money.