"Is this counterparty MiCA authorised?" sounds like a question with a lookup answer. It mostly is, but the lookup is less obvious than people expect, and the way ESMA publishes the data means a lot of teams are checking the wrong file, or checking a copy of it without knowing.
Here is what actually exists and how to use it.
It is five files, not a register
ESMA publishes an interim MiCA register as a set of CSV files, available from the MiCA webpage and the Databases and Registers page. Formal integration into ESMA's IT systems is planned for mid-2026, so until then it is downloads rather than a queryable service.
The five files are:
- White papers for crypto-assets other than asset-referenced tokens and e-money tokens
- Issuers of asset-referenced tokens (ARTs)
- Issuers of e-money tokens (EMTs)
- Authorised crypto-asset service providers (CASPs)
- Non-compliant entities
Most people mean file 4 when they say "the register". Files 2 and 3 are the ones you need for a stablecoin question, and file 1 for an offering. They are separate downloads with separate structures, which is exactly why a quick search tends to land on a third-party mirror instead.
The update cadence is a trap
ESMA states that it will publish the latest version of the register at weekly intervals. Information reported by a national competent authority does not appear immediately.
That matters in one specific direction. A firm that was authorised this week may not be in the file you downloaded. Absence from the register is therefore weak evidence at the moment of authorisation, and strong evidence a month later. If a counterparty tells you they were just authorised and you cannot find them, ask for the decision reference from the national authority rather than concluding anything.
The reverse is safer: presence in the file is a positive confirmation you can rely on, because entries get there by a competent authority reporting them.
File 5 is the one worth subscribing to
The non-compliant entities file gets far less attention than the CASP list and is arguably more operationally useful. A counterparty missing from the authorised list might simply be slow paperwork. A counterparty on the non-compliant list is a different conversation, and one you would rather have before the relationship than after.
If you are building any kind of periodic check, check both directions. Most teams only diff the authorised list.
Grandfathering is why older checks may mislead you
Under the Article 143(3) grandfathering clause, entities that were providing crypto-asset services under national law before 30 December 2024 could continue to do so until 1 July 2026, or until a MiCA authorisation was granted or refused, whichever came first. The window length varied by member state, and ESMA publishes a separate list of grandfathering periods per jurisdiction.
The practical consequence for today: a due diligence file assembled during the transitional window may record a counterparty as legitimately operating without a MiCA authorisation, because at that time it was. That record is now stale. Any counterparty assessment written before mid-2026 and not revisited is worth re-running, and the reason is not that anything went wrong, only that the legal basis it relied on has expired.
Checking a counterparty properly
The register answers whether an entity is authorised. It does not answer the questions that usually matter next.
Which services. A CASP authorisation is not a single permission. Custody, exchange, execution, placement, transfer and advice are distinct. An entity authorised for custody is not thereby authorised to operate a trading platform. Check the services column, not just the presence of a row.
Which entity. Groups operate multiple legal entities, and the one you are contracting with is not always the one holding the authorisation. Match on legal identifiers rather than on brand name. This is the single most common error in counterparty files.
Which member state. Passporting means a firm authorised in one member state can serve others, but the supervisor you would ultimately be dealing with is the home one. Worth knowing before you need to know.
Why third-party trackers exist, and when to use them
Because the official source is five CSVs updated weekly, a number of third-party dashboards have appeared that present the same data with filtering and search. They are genuinely convenient and several are well maintained.
We run one of these ourselves, a browsable view of the register at mica.seqlense.com, so treat what follows as applying to us as much as to anyone.
Use them to explore. Do not use them as the record. For a file that has to stand up, cite the ESMA source and the date you pulled it, because that is the version a supervisor can reproduce. A screenshot of a third-party dashboard, ours included, is not a bad starting point and is not an acceptable ending one.
A workable routine
For most compliance functions, this is enough:
- Pull the CASP file and the non-compliant file monthly, keep the dated copies
- Diff against your counterparty list, in both directions
- On any new relationship, check at onboarding and record the pull date
- Re-check anything assessed before mid-2026, because grandfathering has lapsed
- Match on legal identifiers, never on trading names
- Read the services column and compare it to what you are actually buying
None of this is difficult. It fails in practice for boring reasons: someone checks once at onboarding, saves a screenshot, and nobody looks again for two years. The register is weekly for a reason.
If you track regulator output continuously, ESMA register updates are one of the feeds worth having in the same place as everything else, which is part of what Seqlense DOC does. But the routine above works with a calendar reminder and a folder, and that is a perfectly respectable place to start.
Sources
- ESMA, Markets in Crypto-Assets Regulation (MiCA), interim register files and publication cadence
- ESMA, List of MiCA grandfathering periods under Article 143(3)
- ESMA, Public Statement on the end of the MiCA transitional period