When cross-border services are added: what it costs to be wrong
Adding a service in another Member State is not an internal decision. Under Regulation (EU) 2023/1114 (MiCA), a crypto-asset service provider that extends its activity abroad without completing the notification file risks a supervisory order to stop, a delay in the new market, and a review of the whole authorisation. The cost of getting this wrong is measured in weeks and in trust, not in a fine.
Basis
The right to provide crypto-asset services across the European Economic Area follows from the authorisation itself, once granted under Regulation (EU) 2023/1114 (MiCA), in force from 30 December 2024. That right covers the services already listed in the authorisation. It does not extend automatically to a service the provider has never been authorised for at home.
In practice, the right depends on a notification reaching the home competent authority before the service starts in the host state. The notification is not a formality attached after the fact. It is the mechanism through which the authorisation becomes effective abroad.
Where the cross-border service includes a transfer of crypto-assets between providers or on behalf of clients, Regulation (EU) 2023/1113 (TFR) applies alongside the notification. It governs the information that must travel with the transfer, whatever Member State the counterparty is established in, and it does not pause because a notification is pending.
Practical consequence
Two clocks start at the same moment, and they are often confused. The notification clock runs from the date the home authority receives a complete file, not from the date the provider first sends something. The operational clock — the date the provider actually begins marketing or performing the service in the host state — must not run ahead of the notification clock.
A provider that opens a local sales channel before the notification is acknowledged has, in substance, provided an unauthorised cross-border service in that state, whatever the authorisation says at home. The consequence is not limited to the new market either. A finding in the host state can prompt the home authority to reopen the whole file, because the same governance failure is assumed to run everywhere.
Expansion of this kind rarely stays contained to one file. It typically coincides with a wider technical change: new onboarding flows, new data processors, sometimes a new AI-based screening layer added for the host market. When an AI feature changes the data flow in the same release cycle, the two files need to be assessed together, not filed separately and reconciled afterwards.
What to do
- The compliance officer lists every service actually being extended against the services already covered by the existing authorisation, service by service, before drafting anything.
- The compliance officer prepares the notification file for the home competent authority, describing the host state, the services, the start date, and the arrangements for supervising the local activity.
- The legal team checks whether the host-facing brand, domain, or marketing name is already registered, applied for, or contested locally before the file goes out, not after.
- The management body signs off on the file before any public step is taken in the host state — no soft launch, no waiting list, no local landing page live in the meantime.
- The compliance officer holds the launch until written acknowledgement of the notification is on file, not merely sent, and records the date it arrived.
- Where transfers of crypto-assets are part of the service, the operations team confirms that the originator and beneficiary information required under the transfer regime travels with every transaction from the first day of the host-state launch.
Who decides
The home competent authority is the first decision point. It receives the notification, checks it for completeness, and forwards it to the authority in the host state. It does not re-examine the underlying authorisation each time a new state is added.
The host competent authority does not re-authorise the provider. It receives the file and, from that point, may raise questions about the manner of provision in its own market — marketing practices, local disclosures, the language used with clients — rather than about the licence itself.
| Question | Who answers it |
|---|---|
| Is the notification file complete | Home competent authority |
| Can the service start in the host state | Determined by acknowledgement of the notification, not by the applicant's own timetable |
| Is the manner of provision in the host state compliant | Host competent authority, on an ongoing basis |
Forks
If the cross-border service is purely digital and no local entity or branch is set up, the file is shorter, but the notification is still mandatory before the first client in that state is onboarded. A purely digital model removes the corporate-law layer around the requirement, not the requirement itself.
If the expansion is accompanied by a rebrand or a new mark for the host market, clear the mark first. When an opposition deadline is running against the mark you are about to launch under, the notification file and the brand file need to move on the same timeline, not on separate ones set by different teams.
If part of the platform used in the new market was built by a contractor and the assignment paperwork was never finalised, resolve that before the launch, not after a regulator asks who owns the code. The assignment is unsigned but performed ownership of results is a common gap that surfaces exactly when a platform is scaled into a new jurisdiction.
If the service extended abroad involves enforcement against a token holder based in the host state, the cross-border notification does not change which court has jurisdiction over that dispute. Enforcement is sought against a holder tokenised rights what happens next raises a separate question that the authorisation file does not answer and was never meant to.
Limit
This page does not set out the content of the notification file line by line, and it does not replace a review of the specific services being extended into the new state. It does not cover activity that falls outside the scope of the regulation, and it does not address a host state that has raised a substantive objection rather than a purely procedural one — that situation needs its own file.
Where own funds are already close to the threshold before the expansion is even filed, that is a separate trigger, not a footnote to this one, and it can move faster than the notification itself.
Verified
Checked against Regulation (EU) 2023/1114 (MiCA) and Regulation (EU) 2023/1113 (TFR), both in force from 30 December 2024. This page was reviewed on the date of publication. Re-verify against the current consolidated text before relying on it for a specific filing, since implementing detail at national level is not covered here.
Related publications
A related situation worth checking alongside this one is what happens when Own funds fall below the threshold authorisation what it costs to be wrong — a separate supervisory trigger that can run at the same time as an expansion, for the same institution.
FAQ
What is the first step when cross-border services are added?
Confirm which services are actually being extended, checking each one against the existing authorisation rather than assuming coverage. Then prepare and file the notification with the home competent authority before any service is offered in the host state. The launch date follows the acknowledgement of that file, not the marketing calendar.
Which deadline is already running?
The notification period starts running from the date the home authority receives a complete file, not from the date something was first sent to it. Its length is set by the regulation and depends on completeness; an incomplete submission does not start the clock, and it does not stop the provider being treated as unauthorised abroad until acknowledgement arrives.
Who decides, and on what evidence?
The home competent authority decides on completeness of the notification file and forwards it to the host authority. The host authority then acts on that same file, plus whatever conduct of business it observes once the service is actually live in its market.