Skip to content

MiCA CASP authorisation and the EU crypto Travel Rule

How MiCA CASP authorisation works alongside the EU crypto Travel Rule, covering service categories, passporting, custody, transfers and self-hosted addresses.

Pillar
Licensing and regulation
Difficulty
Advanced
Published
Last updated
Legal status reviewed
Reading time
8 min
Intended audience
Fintech foundersCompliance teamsLegal teams
More Digital Assets guides
On this page

MiCA authorises crypto-asset services; the Transfer of Funds Regulation adds data-carrying duties to crypto transfers. These are two separate but parallel workstreams, and confusing them is a common planning error. Getting authorised to provide a service does not, by itself, satisfy the Travel Rule, and building Travel Rule tooling does not make you authorised. This article separates the two so you can scope each correctly.

Legal and regulatory status was reviewed on 7 July 2026.

Crypto-asset service categories under MiCA

MiCA defines a set of crypto-asset services — including custody and administration, operation of a trading platform, exchange, execution of orders, placing, reception and transmission of orders, advice, portfolio management and transfer services 1. Each is a distinct activity with its own conditions. ESMA’s interactive single rulebook is a practical reference for how these provisions fit together 3. Scope your permissions to the specific services you perform, not to a general “crypto” label.

Authorisation principle

The general principle is that providing crypto-asset services in the EU requires authorisation as a crypto-asset service provider, subject to the conditions MiCA sets 1. Authorisation is tied to the services applied for, so the scope of your permission reflects the services you requested and were granted. Do not assume authorisation for one service implies another.

Certain existing financial entities and Article 60 notification routes

MiCA contemplates that certain already-regulated financial entities may provide some crypto-asset services through a notification route rather than a full CASP authorisation, subject to conditions 1. This does not remove obligations; it reflects existing authorisation. Whether an entity qualifies, and for which services, is a specific analysis against the conditions — not a shortcut to assume.

Passporting

Authorisation under MiCA is designed to support providing services across the EU under the framework’s passporting arrangements 1. Passporting has procedural conditions and does not override service scope: you can only passport what you are authorised to do. Confirm both the home authorisation and the cross-border arrangements before relying on EU-wide reach.

Governance and conduct concepts

MiCA attaches governance, prudential and conduct expectations to CASPs, covering matters such as organisational arrangements, safeguarding of clients’ crypto-assets and funds, and conflict management 1. These are ongoing obligations, not one-time application items. Treat them as operating requirements that shape how the business runs.

Custody

Custody and administration of crypto-assets on behalf of clients is a defined service with expectations around control and safeguarding of client assets 1. Custody is distinct from merely offering wallet software — see crypto custody versus wallet-as-a-service. If you rely on a custodian, understand its authorisation and its segregation model.

Trading platforms

Operating a trading platform for crypto-assets is a separate service with its own rules on operation, transparency and orderly trading 1. Running matching or a venue is not the same as exchanging or executing on a client’s behalf, and each maps to different permissions.

Exchange

Exchanging crypto-assets for funds or for other crypto-assets is a defined service 1. Where exchange touches fiat, payment-services considerations can also arise separately, and a CASP authorisation does not by itself confer payment-services permissions.

Execution

Execution of orders for crypto-assets on behalf of clients is its own service category 1. It carries conduct expectations around acting in the client’s interest. Distinguish execution from advice or from operating a venue.

Placing

Placing of crypto-assets — offering them to purchasers on behalf of, or for, an offeror — is a separate defined service 1. It is distinct from issuance and from distribution generally, and should be scoped explicitly.

Advice

Providing advice on crypto-assets is a defined service with conduct and competence expectations 1. Advice is separate from execution and portfolio management; performing several of these means holding permissions for each.

Portfolio management

Managing portfolios of crypto-assets on a discretionary basis is a distinct service 1. It carries its own conduct duties and is not implied by holding custody or execution permissions.

Transfer services

Transfer services for crypto-assets on behalf of clients are recognised as a service category 1. Transfer activity is exactly where the Travel Rule data duties bite, which is why the two workstreams intersect operationally even though they are legally distinct.

Transfer of Funds Regulation

The Transfer of Funds Regulation applies from 30 December 2024 and extends transfer-information requirements to transfers of crypto-assets involving covered CASPs 2. It introduces originator and beneficiary information requirements and a risk-based treatment of transfers involving self-hosted addresses. It is not a single universal transaction threshold. Build the data flows to match the regulation rather than a simplified summary.

Originator and beneficiary information

The regulation requires specified information about the originator and the beneficiary to accompany covered crypto-asset transfers 2. Capturing, validating and transmitting this data reliably is an operational task that needs to be designed into transfer flows, not retrofitted.

CASP-to-CASP flows

Where a transfer moves between covered CASPs, the information duties govern what each side must send, receive and check 2. Interoperability with counterparties’ systems matters, because the data must actually reach the other side in a usable form.

Self-hosted addresses

Transfers involving self-hosted (unhosted) addresses receive risk-based treatment rather than a blanket rule 2. You must decide which interactions you support and what attribution or verification you apply, documenting the risk rationale. Do not reduce this to a single threshold.

Risk-based controls

Beyond fixed data fields, the regulation expects risk-based controls, and screening remains part of the picture — see sanctions, PEP and adverse-media screening. Calibrate controls to your exposure and record how you reached that calibration.

Data protection

Collecting and transmitting originator and beneficiary information engages data-protection obligations. Handle the information lawfully, retain it appropriately and limit access. Travel Rule compliance and data-protection compliance must be reconciled, not treated as competing.

Travel Rule vendor role

Vendors can help capture, format and exchange Travel Rule information, but using a vendor does not transfer your responsibility. You remain accountable for meeting the requirements. Diligence the vendor’s coverage, counterparty reach and data handling as you would any critical dependency.

Why MiCA and Travel Rule compliance are separate workstreams

MiCA governs whether you may provide a service; the Transfer of Funds Regulation governs the information that must accompany transfers 12. One is an authorisation question, the other a data-and-controls question. Plan and resource them separately, while recognising they meet at the point of transfer.

Authorisation and Travel Rule comparison

Dimension MiCA CASP authorisation Transfer of Funds Regulation (Travel Rule)
Core question May you provide the service? What data must accompany the transfer?
Scope Defined crypto-asset services Covered crypto-asset transfers
Key concepts Service categories, authorisation, passporting Originator/beneficiary info, self-hosted treatment
Applies Per MiCA, generally from 30 December 2024 From 30 December 2024
Vendor effect Does not transfer responsibility Does not transfer responsibility

Provider checklist

  • The specific crypto-asset services you perform are identified and mapped to MiCA categories
  • The authorisation or notification route relied on is confirmed for each service
  • Passporting arrangements are verified against your cross-border plans
  • Custody and safeguarding arrangements for client assets are documented
  • Travel Rule originator/beneficiary data capture is designed into transfer flows
  • CASP-to-CASP data exchange interoperability is tested
  • Self-hosted-address policy is defined on a risk basis and documented
  • Data-protection handling of Travel Rule information is addressed
  • Vendor responsibilities are documented without assuming they transfer accountability

Questions to ask providers

  • Which MiCA crypto-asset services are you authorised for, and by whom?
  • Are you relying on full authorisation or a notification route, and for which services?
  • How does passporting apply to the markets we need?
  • How are client crypto-assets and funds safeguarded and segregated?
  • How do you capture and transmit originator and beneficiary information 2?
  • How do you interoperate with counterparty CASPs for the Travel Rule?
  • What is your risk-based policy for self-hosted-address transfers?
  • How do you handle the data-protection aspects of Travel Rule data?

Common failure modes

  • Assuming CASP authorisation satisfies the Travel Rule, or vice versa.
  • Assuming a CASP authorisation grants payment-services permissions.
  • Reducing the Travel Rule to a single universal transaction threshold 2.
  • Treating a notification route as a blanket exemption from obligations 1.
  • Retrofitting originator/beneficiary data capture after launch.
  • Assuming a Travel Rule vendor absorbs your responsibility.
  • Ignoring data-protection duties when handling transfer information.

What this does not cover

This article does not confirm any provider’s authorisation, determine whether a specific transfer is in scope, or state that any structure is compliant. It does not address non-EU regimes in detail. FATF virtual-asset and VASP guidance is an international standard, not directly applicable EU legislation 4. This is not legal advice.

FAQ

Does MiCA authorisation cover the Travel Rule?

No. MiCA governs service authorisation; the Transfer of Funds Regulation governs the information accompanying crypto transfers 12. They are separate workstreams.

Does being an authorised CASP let me provide payment services?

No. A CASP authorisation does not automatically grant payment-services permissions. Payment activity needs its own analysis.

Is there a single amount below which the Travel Rule does not apply?

Do not rely on that framing. The regulation sets information requirements and risk-based treatment, including for self-hosted addresses, rather than one universal threshold 2.

How should I treat transfers to self-hosted wallets?

Apply a risk-based approach, decide which interactions you support, and document the rationale 2. There is no blanket rule that removes the assessment.

Does using a Travel Rule vendor move responsibility to them?

No. Vendors can help operationally, but you remain responsible for meeting the requirements 2.

Official sources

Numbered references cited in this guide. Legal and regulatory status was reviewed on the date shown above.

  1. Regulation (EU) 2023/1114 on markets in crypto-assets

    European UnionLegislation

  2. Regulation (EU) 2023/1113 on information accompanying transfers of funds and certain crypto-assets

    European UnionLegislation

  3. MiCA interactive single rulebook

    European Securities and Markets AuthorityOfficial guidance

  4. Virtual assets and VASP guidance

    Financial Action Task ForceInternational guidance

Provider categories

About this guide

FintechMall compiles infrastructure guidance from official legislation, regulators, scheme documentation and provider materials. Content is reviewed periodically but may become outdated as rules and products change.

Report an issue with this guidePlease include the article title and URL, your suggested correction, a supporting official source and an email so we can follow up.

This article provides general information about fintech infrastructure and regulation. It is not legal, financial, tax or regulatory advice. Requirements depend on the product, activities, legal entities, customer types and jurisdictions involved. Confirm current requirements with qualified advisers, relevant providers and official authorities.

Digital-asset products introduce additional legal, operational, custody, liquidity, market and technology risks.

digital-assetsmicacasptravel-rule