When a group entity holds a different permission: what to do first
Identify which entity in the group actually performs the regulated activity, then check whether that entity's own permission covers it. A permission held by a different group entity does not transfer across the group. Stop any client-facing step through the wrong entity before doing anything else, and only then work through notification and correction.
The basis: whose permission actually applies
Authorisation under Regulation (EU) 2023/1114 (MiCA) attaches to the entity named on the authorisation, not to the corporate group around it. A parent, a sister company, or a jointly branded affiliate does not inherit that authorisation by association. Where the activity includes moving crypto-assets between parties, Regulation (EU) 2023/1113 (TFR) attaches its own information duties to the entity that actually executes the transfer, again regardless of which group company holds a different permission for a different activity.
The same separation shows up outside authorisation law. Ownership of the platform a group uses is a distinct question from the licence that lets an entity operate on it, and groups that never wrote this down run into the same gap addressed in The contract says work for hire and nothing else. A permission mismatch and an ownership gap often surface together during the same internal review.
Why this matters inside the group right now
If the entity dealing with clients is not the entity that holds the matching permission, every transaction it processes sits outside its own authorisation. That is not a paperwork gap the group can close later; it is a live exposure for as long as the activity continues. Reporting built on the assumption that the authorised entity is the one acting will also misfire, because TFR obligations follow the entity performing the transfer, not the entity with the correct paperwork sitting elsewhere in the group.
Groups discover this kind of misalignment in unrelated ways. A brand filing that stalls can expose it, in the same manner covered in When an office action refuses your application, because both processes force the group to state, formally, which entity is the real applicant. Once that question is asked once, it tends to be asked again.
What to do first
- Map every entity in the group against every permission it holds, using the authorisation register rather than internal branding.
- Identify, separately, which entity is contractually and operationally in front of the client for the activity in question.
- Where the two do not match, pause onboarding through the unauthorised entity immediately, not after the review concludes.
- Check whether a MiCA passporting notification has already been filed in the name of the wrong entity, and prepare a correction if so.
- Update client-facing terms and disclosures to name the entity that actually holds the matching permission.
- Route the finding to group compliance and legal together, since realignment usually needs both a contractual fix and a supervisory notification.
This kind of mismatch surfaces most often through an unrelated internal audit rather than through a self-check, the same way a review triggered by When an employee monitoring tool is deployed can expose gaps nobody was looking for. Treat the discovery as routine, not as a crisis to manage quietly.
Who decides, and on what evidence
The national competent authority that granted the authorisation decides whether an activity fell within its scope, and it works from the authorisation register, the group's own client contracts, and its published service descriptions. It does not take the group's internal org chart as evidence of who is legally acting.
| Question | Where the answer sits | Why it comes first |
|---|---|---|
| Which entity actually deals with the client? | Client contracts and public-facing disclosures | This, not internal reporting lines, fixes which permission is relevant |
| Does that entity's permission cover this activity? | The authorisation register held by the competent authority | An authorisation under Regulation (EU) 2023/1114 (MiCA) is entity-specific, not group-wide |
| Does the activity include a crypto-asset transfer? | Internal transaction records | Regulation (EU) 2023/1113 (TFR) attaches its information duties to the entity performing the transfer |
If your situation differs
If the different permission was issued under a national regime before MiCA applied, the group is likely inside a transitional arrangement rather than a straightforward mismatch. The exact cut-off for that arrangement sits in the transitional provisions and is confirmed by the national competent authority, not assumed internally.
If the entity in front of clients has never held any crypto-asset permission at all, this is not a mismatch to correct but an unauthorised activity to stop first and remedy second.
If the entity holding the different permission also runs a tokenised collection built on third-party material, resolve that separate rights question before touching the authorisation question, following the sequence in A collection uses third-party artwork tokenised rights. The two issues do not share a fix, even when they share a filing deadline.
What this page does not resolve
This page does not resolve group restructuring, tax consequences of moving an activity between entities, or the drafting of a new intra-group services agreement. It also does not replace a formal reading of the passporting notification already on file, which needs the notification itself, not a summary of it.
Related situations
If a supervisor has already issued a public measure against either entity, the sequence changes and the correction above is no longer the first step. See The supervisor publishes a measure authorisation for that separate starting point.
Verified
Checked against the current text of Regulation (EU) 2023/1114 (MiCA), in force from 30 December 2024, and Regulation (EU) 2023/1113 (TFR), in force from the same date. No national implementing measure is cited on this page; where one applies to your entity, confirm it separately with the relevant national competent authority.
Frequently asked questions
What is the first step when a group entity holds a different permission?
Identify which entity performs the activity, then check whether its own permission covers it. Do not rely on another group entity's permission as a substitute.
Which deadline is already running?
If a permission predates MiCA, a transitional window may already be running. Its exact length is set in the transitional provisions and confirmed by the national competent authority, not assumed from the group's internal timeline.
Who decides, and on what evidence?
The competent authority that granted the authorisation decides, working from the register entry, the client-facing contracts, and the actual service descriptions, not from the group's internal reporting structure.