A crypto payment platform has finally obtained a MiCA CASP, and the sentence most likely to come next is: “So can we just start operating directly in France, Germany, and Spain?”
From a commercial team's perspective, this understanding is quite natural. One of MiCA's greatest values was precisely to establish a unified EU crypto-asset services market, so that firms no longer need to apply repeatedly for licenses in every member state for the same custody, exchange, or transfer service.
But when it comes to actual implementation, things are not that simple.
CASPBeing able to operate cross-border does not mean that all of a firm's products can go cross-border together;
What passporting can replicate is the service permissions that have already been approved, not the issuance of a pan-European universal financial license to the entire group.
For stablecoin payments, wallets, trading platforms, and global crypto groups, this distinction is very important. Because once a project truly enters multiple EU countries, it often simultaneously involves digital assets, fiat payments, group entities, customer agreements, website marketing, and other financial products, and these issues will not automatically disappear just because a CASP has been approved.
What exactly does MiCA passporting solve?
Before MiCA, one of the biggest problems in the European crypto market was regulatory fragmentation.
A project might have a VASP registration in one country, yet upon entering another member state still need to reassess local market-entry requirements. Different countries are not entirely consistent in their regulatory names, standards, and market-entry approaches for custody, exchange, wallets, and trading platforms.
MiCA changed this logic.
Under MiCA, after a CASP obtains formal authorization in its home member state, it may, by establishing a branch or providing services freely, extend its already-approved crypto-asset services to other EU member states. For CASPs providing cross-border services, MiCA in principle also does not require them to re-establish an entity in every target member state.
This means that what a project truly needs to focus on building can be a single CASP entity undertaking its core European business, rather than setting up four duplicate crypto license structures in France, Germany, Italy, and Spain respectively.
What passporting eliminates is
the cost of obtaining the same MiCA authorization repeatedly in multiple countries for the same type of MiCA business.
What passporting does not eliminate is
the work of reassessing the actual business boundaries after a project enters each market.
Obtaining a CASP authorization does not mean that "pan-European access" can begin the very next day.
Passporting is not a hidden feature that takes effect automatically once a CASP license is granted.
If an entity intends to provide services cross-border into other Member States, it must first submit relevant information to the home Member State competent authority, including the target Member States in which it intends to provide services, which crypto-asset services it intends to provide cross-border, the planned date for commencing the provision of services, and any other non-MiCA business in which the CASP is simultaneously engaged.
After the home Member State competent authority receives complete information, it shall, within 10 working days, transmit the relevant information to the target Member States, ESMA and EBA. The CASP may commence the cross-border provision of services after receiving confirmation from the home Member State competent authority that the notification has been completed; if such confirmation has not yet been received, it may commence no later than the 15th calendar day after submitting the relevant information.
01 Obtain CASP authorization in the home Member State 02 Determine the target markets and scope of services 03 Submit the cross-border notification 04 The competent authority completes transmission 05 Commence the provision of the corresponding services.
This process is not complicated, but it reminds project parties of one thing:
Passporting should be incorporated into the European market launch plan, rather than having formalities patched together on an ad hoc basis after the license is obtained.
The most easily misunderstood point: what passporting carries over is "existing permissions"
Assume that a CASP has obtained approval for only two business lines:
custody and administration of client crypto assets, and the provision of crypto asset transfer services on behalf of clients.
After passporting into France, Germany or Spain, the company may still provide only these two services on a cross-border basis.
Completing the cross-border notification does not automatically add crypto asset-to-fiat currency exchange, operation of a trading platform, order execution or investment advice.
MiCA requires that a CASP authorization expressly list the specific crypto asset services the undertaking is authorized to provide. If an undertaking intends to add new CASP services, it must apply to the competent authority of its original home Member State for an extension of authorization.
This is also the one thing most worth doing in advance when planning a European business:
Do not ask only what license is needed for the first phase; also ask what products are planned to be added over the next two to three years.
Because if the project plans to add custody, stablecoin exchange and institutional trading next year, while the first CASP application covers only a very narrow scope, it will still have to go through authorization extension again later.
Passporting replicates the boundaries of the license; it does not help a project break through those boundaries.
For crypto payment projects, the truly troublesome part is the other half outside the CASP.
This point is more important than passporting itself.
Many crypto payment projects appear to offer only one product from the user experience perspective, but from a regulatory perspective there are in fact two or even three business chains operating simultaneously.
For example, a customer pays the platform in stablecoins, the platform completes custody and asset transfer, then converts the assets into euros, and ultimately settles with the merchant.
Some of these digital asset activities may fall within CASP authorization, but fiat accounts, traditional payment execution, bank cards, merchant acquiring, or electronic money issuance will not automatically be covered merely because the CASP has been passported.
This is especially true for EMTs, that is, electronic money tokens.
The EBA has explicitly discussed the interface between MiCA and PSD2. The transfer of EMTs on behalf of customers, as well as certain custodial wallet services that allow customers to send and receive EMTs to and from third parties, may simultaneously fall within the scope of payment services regulation; after the relevant transitional arrangements end on March 2, 2026, specific businesses will need to further resolve PSD2 authorization issues. Conversely, the exchange between crypto assets and funds, and the exchange between different crypto assets, will not automatically constitute a PSD2 payment service merely because EMTs are involved.
Digital asset layer
What is the CASP responsible for?
Payment and fiat layer
What are PIs, EMIs, banks, or other institutions responsible for?
Rather than obtaining a CASP and then classifying all links under MiCA.
A CASP can be used cross-border, but it will not automatically become a PI, EMI, or banking license, nor will it cover securities, derivatives, and other financial businesses.
A group having a CASP does not mean the entire App is "regulated under MiCA"
This issue is especially typical in large trading platforms and global Crypto groups.
A company establishes a licensed CASP in the EU, but the group's app or website may simultaneously offer derivatives, lending, NFTs, certain DeFi products, and other services provided by overseas affiliates.
From the user's perspective, these products may all appear under the same brand and within the same app.
This gives rise to a very practical question:
When a page states "MiCA regulated," does it refer to a single EU CASP entity, or to all products across the entire group?
In 2025, ESMA specifically warned the market about this "halo effect," namely the license halo effect. Regulators are concerned that users, because an enterprise holds CASP status, may mistakenly understand that all products it offers are protected under MiCA regulation. ESMA therefore requires CASPs to clearly explain the regulatory status of different products during customer engagement and sales processes, so as to avoid misleading users.
The impact of this on projects goes far beyond adding a disclaimer.
Entity and product boundaries
Who contracts with European users, who appears in the user agreement, which entity controls customer assets, which entity actually provides the product, how different services within the app are linked, and whether marketing communications expand "CASP licensed" into "the entire group is regulated."
If these matters are not clearly articulated, the more countries Passporting covers, the more the risks may expand in tandem.
An EU CASP must not become a "funnel" for overseas business either
Another common idea is:
Since an EU CASP cannot offer certain products, can it first acquire customers and then direct users to the group's overseas platforms?
This approach requires great caution.
MiCA adopts a strict interpretation of reliance by third-country entities on reverse solicitation, that is, the exception for services requested by the client on the client's own initiative. The core logic of the relevant ESMA guidance is that third-country entities cannot circumvent MiCA market access requirements through marketing, promotion or other active means.
Therefore, if an EU CASP actively directs European clients to an overseas entity within the group that has not obtained the corresponding EU authorization, and that entity then provides regulated crypto services to the clients, it cannot simply be assumed that "the client ultimately clicked through on the client's own initiative" and that this therefore constitutes a client-initiated request.
For a group structure, a safer design is not to treat the EU CASP as a client acquisition channel, but first to clearly delineate the products:
which European clients are served by the CASP, which products can be provided by the CASP, which products cannot for the time being be offered to EU clients, and whether the overseas group company merely provides technology and back-office services or in fact provides services directly to clients.
MiCA governs not only where the license is held, but also who actually serves the client.
After passporting, the target country still cannot be entirely disregarded
With MiCA passporting, a CASP does not need to obtain a separate identical crypto license in each target member state.
However, this does not mean that when launching a project in France, Germany or Italy, one can simply replicate a single unified European page and be done.
MiCA itself requires CASPs to provide clients with fair, clear and non-misleading information, including marketing communications.
In addition, specific products may continue to involve local consumer protection, data protection, tax, contract, complaint handling and other issues that are not fully harmonized by MiCA.
For projects targeting ordinary consumers, further consideration must be given to local language, customer service, risk disclosure and user agreements.
Therefore, after passporting, what a project truly saves is 'duplicate licensing.'
It is not 'local establishment.'
A genuinely workable European solution should be mapped out before obtaining a license.
For a project planning to serve multiple EU member states, I would recommend designing the future European business together at the time of applying for the first CASP license.
It is not a matter of waiting until the license is granted and then discussing how to enter France and Germany.
A project should at least answer six questions in advance:
01Preliminary question
Which services will the CASP ultimately need to cover?
02Preliminary question
Which countries will be the first batch of target markets?
03Preliminary question
Which entity will European users ultimately enter into contracts with?
04Preliminary Questions
Through which companies and wallets do client assets and funds pass?
05Preliminary Questions
Which payment, EMI, banking or other financial licenses need to be coordinated?
06Preliminary Questions
How should websites, marketing and risk disclosures distinguish licensed from unlicensed products?
A truly complete deliverable should be a:
European Market Access Map
European market access map comprising the home Member State CASP + scope of services + target Member States + contracting entity + asset and fund flows + other license dependencies.
Only then does passporting truly become a tool that helps business expansion, rather than a process of continuously patching regulatory boundaries after the project goes live.
Conclusion: One CASP can serve all of Europe, but can only do "what it was originally authorized to do"
Key Issues
If we obtain a MiCA CASP license, can we operate across the entire EU?
Core answer
You can provide cross-border services throughout the EU, but not all business lines can be brought along.
What MiCA passporting truly addresses is the issue of duplicate licensing. A CASP can, through home Member State authorization and cross-border notification, extend its already-approved crypto-asset services to other Member States.
However, the scope of services will not expand as a result of passporting. PI, EMI, banking and securities licenses will not automatically be replaced by a CASP license, nor will a group's overseas business automatically acquire MiCA status merely because an EU company holds a license.
Therefore, the question a project should truly ask is not:
Do not merely ask
"Can this CASP license cover all of Europe?"
What should truly be asked is
"If in the future we plan to focus on building only one CASP across Europe, which business lines exactly should we place into this company?"
This is the true structural value of MiCA passporting.
