The MiCA CASP authorization deadline passed on July 1, 2026, and most European crypto exchanges are still unlicensed. This is a triage guide for firms mid-application or still exposed: what ESMA's wind-down statement actually requires this week, and why the AML and travel-rule infrastructure exchanges are racing to build now will need to be rebuilt again the moment inter-CASP data exchange kicks in, unless it's built on reusable credentials from the start.
If you're reading this in mid-September 2026, the MiCA transitional period isn't a future risk you're planning around. It's a deadline that closed six weeks ago, and the compliance status of your exchange changed the moment it did. Article 143(3) of the Markets in Crypto-Assets Regulation gave pre-existing crypto-asset service providers an 18-month maximum window to keep operating under national law while they pursued full CASP authorization. That window expired EU-wide on July 1, 2026 (Elliptic). From that date, Article 59 applies without exception: providing crypto-asset services to EU clients without CASP authorization is a breach of EU law, full stop.
MiCA Regulation for Crypto Exchanges: Where Enforcement Stands in August 2026
The Numbers Behind the Deadline Passing
The scale of the miss is worth sitting with. Of the more than 1,200 crypto entities that held national VASP registrations across the EU and EEA before MiCA, only about 210 had converted to full CASP authorization, what the industry commonly shorthands as a MiCA license, by the July 1 cutoff, a conversion rate of roughly 17% (Yahoo Finance). That leaves 83% of Europe's crypto firms without a MiCA license as the deadline arrived, and as that Yahoo Finance analysis put it, "the other 83% either missed the window, are mid-process with no legal standing to continue operating, or have quietly exited."
ESMA's public register is the ground truth here, and it's moving weekly. As of the July 31, 2026 update, its fourth revision since the transitional deadline, ESMA listed 321 authorised CASPs and 41 e-money token issuers, alongside 167 entities on its non-compliant register, including three new notifications from Italy's CONSOB that cycle (GN Crypto News). An earlier snapshot of 213 authorised CASPs across 23 jurisdictions had Germany leading with 55, followed by the Netherlands (26), France (19), Malta (15), and Ireland and Cyprus tied at 12 each, with the top five jurisdictions accounting for roughly 60% of all authorizations (Elliptic). That was captured before the total count passed 320, so treat it as a picture of which regulators moved first, not the current tally.
Not every firm was working against the same July 1 date, either. Several member states set shorter national transitional periods that closed months earlier: Latvia, Hungary, the Netherlands, Poland, and Slovenia cut theirs to six months, closing in mid-2025, well ahead of the EU-wide backstop (Zyphe). If your exchange operates across multiple member states, the rule is the earliest deadline among all of them governs you, not the EU-wide July 1 date. A firm that assumed it had until July 1 because that's the headline date may have already been in breach for the better part of a year in the jurisdictions that moved first.
What "Technically in Breach of EU Law" Means Day to Day
`"There is no intermediate status after July 1. A firm is either authorized under MiCA or it is in breach of EU law."
ESMA's position, as reported by Yahoo Finance`
Having submitted an application, having a hearing scheduled with your national competent authority, or being weeks from a decision doesn't change your status. Pending authorization confers no right to keep onboarding, marketing, or trading with EU clients in the interim.
For a firm in this position, the immediate reality is exposure on two fronts: to enforcement action from national competent authorities, and to a reputational signal to counterparties and clients that your exchange is operating outside its regulatory perimeter. Neither resolves until authorization is granted or you wind down.
The MiCA CASP Authorization Deadline Passed: What ESMA's July 1 Statement Changes for Firms Mid-Application
ESMA didn't wait for the deadline to pass in silence. On June 23, 2026, ahead of the July 1 cutoff, it published a public statement calling on unauthorised crypto-asset service providers to wind down in an orderly manner while safeguarding client interests (AMF France). That statement is the operative guidance for any exchange still in the queue, and it's worth reading as instructions, not commentary.
No Grace Period, No Intermediate Status
ESMA's statement instructs unauthorised CASPs to immediately stop onboarding new EU clients, stop opening new accounts, and stop all marketing and solicitation activity. Services should be limited to what's necessary to let existing clients sell or transfer their assets and close positions, an orderly exit, not a continuation of business as usual under a different label (AMF France).
Reverse solicitation is not the workaround some firms are hoping it is. Article 61 permits serving EU clients without authorization only when the client initiates contact entirely on their own, and ESMA reads that exception narrowly: any advertising, app store listing, affiliate arrangement, influencer post, or search marketing aimed at EU users breaks the exception (Elliptic). If your growth team ran a campaign targeting EU users last quarter, the clients who signed up through it don't count as reverse-solicited, regardless of how the account was technically opened.
Critically, the wind-down obligation doesn't relax AML and CFT duties. Unauthorised providers must maintain full customer due diligence, transaction monitoring, sanctions screening, and record-keeping for the entire exit period, not just during active client relationships (AMF France). You don't get to stop verifying identities just because you've stopped taking new business.
The Three Paths Left Open: Authorize, Passport, or Wind Down
For an exchange without CASP authorization today, there are exactly three viable paths, and ESMA's statement makes clear there isn't a fourth:
Complete authorization (get a MiCA license)
Finish the CASP application with your national competent authority, including documented AML controls, capital requirements, and governance. Best fit for firms with an application already in progress and the resources to see it through.Rely on an existing CASP passport
Operate as a tied agent or through a partnership with an already-authorised CASP under MiCA's passporting provisions. Best fit for firms that can't clear authorization alone but have a credible partner relationship.Wind down orderly
Stop onboarding and marketing immediately, close out or transfer existing positions, maintain AML obligations throughout. Best fit for firms that missed the window with no near-term path to authorization.
There's no fourth path for "keep operating quietly while the application is pending." That option closed on July 1.
What National Regulators Expect From Firms Still in the Queue
If you're mid-application, your national competent authority expects to see the same wind-down discipline ESMA describes applied to the parts of your business that fall outside what you're authorized to do today. That means: no new EU client onboarding until authorization clears, continued and demonstrable AML/CFT controls, and clear, repeated communication with existing clients about asset protection and any exit timeline that applies.
"Communicate clearly, promptly and repeatedly with clients (retail and institutional) about the measures taken to safeguard their assets and the wind-down plans."
ESMA's public statement, via AMF France
Silence, or a single blog post announcing "we're working on it," doesn't meet that bar.
One detail that catches firms off guard: if you transfer clients to an already-authorised CASP as part of a wind-down or a partnership, the receiving CASP has to run full onboarding, including fresh KYC checks, on every client it takes on (AMF France). Your existing verification records don't travel with the client. That's not a compliance footnote, it's the same reverification problem that's about to define the next section of this post.
The KYC Rebuild Trap: Why Exchanges Racing to Get Licensed Are Re-Architecting Twice
Here's the trap firms are walking into right now. Under deadline pressure, an exchange builds or buys whatever AML and KYC infrastructure clears its national competent authority's bar for CASP authorization, ships it, and treats the box as checked. Then the travel rule and inter-CASP data-exchange requirements land on top of a system that was never designed to hand data to another provider, and the exchange is back in a build cycle it thought was finished.
Why a National VASP-Era KYC Stack Doesn't Clear CASP Authorization
MiCA licensing is conditioned on demonstrating AML readiness before authorization is granted, not after. Regulators won't license a firm without proof of "robust internal controls, policies, and procedures" for managing money-laundering risk already in place (Flagright). A KYC stack built to satisfy a national VASP registration, often a lighter-touch regime with looser documentation and monitoring standards, generally doesn't clear that bar on its own. It has to be extended: five-year retention of transaction records, KYC documentation, and compliance decisions, with a complete, immutable audit trail showing who reviewed what and when (Flagright). "Audit-ready" isn't a phrase for application day. Under MiCA, it's a standing requirement.
The Travel Rule and Inter-CASP Data Exchange Nobody Budgeted For
The Crypto Travel Rule, MiCA's implementation of the FATF's Recommendation 16 standard for virtual-asset transfers, is where a lot of AML rebuilds run into their second wall. CASPs must collect and transmit originator and beneficiary information for any transfer of EUR 1,000 or more moving to another VASP, and doing that requires infrastructure to exchange that data with counterparty CASPs, either built in-house or bought as a third-party solution (Flagright). Most national-registration-era KYC systems were built to verify a user once, internally, and store the result. They weren't built to package identity data for transmission to a counterparty's compliance system on every qualifying transfer. That's a structurally different requirement, not an incremental one, and it's exactly the kind of thing that gets discovered mid-application rather than planned for at the start.
The Hidden Cost of Building AML Infrastructure Under Deadline Pressure
The real cost of racing to build this under deadline pressure isn't the first build. It's the second one. An exchange that stands up KYC and AML infrastructure fast enough to clear authorization, using whatever document-verification vendor or in-house system was quickest to integrate, is optimizing for a single checkpoint: the application review. But the travel rule's inter-CASP data-exchange requirement and the five-year audit-trail obligation both assume identity data that's portable and cryptographically verifiable at the point of transfer, not a scanned passport sitting in a centralized database that has to be manually packaged for every counterparty request.
Firms that build for the checkpoint end up re-architecting once authorization clears and the travel-rule and passporting demands start hitting in production. That's two builds, two integration cycles, and two rounds of vendor risk, all to solve what is, underneath, one problem: proving who a client is, in a form that can move with them.
Where Reusable Credentials Shorten the Path From Application to Authorization
A credential-based KYC stack collapses that two-step rebuild into one, because it's built around portability from day one rather than bolting portability on after the fact.
Verify-Once-Use-Everywhere vs. Rebuilding Onboarding From Scratch
The alternative to a document-storing, single-use verification model is one built on verifiable credentials: a user completes identity verification once, and the result is issued as a W3C-standard verifiable credential the user holds in their own encrypted vault, not a record locked inside your database (Hypersign, on Web3 KYC provider comparisons). That single credential can then be presented, with the user's consent, to any platform or counterparty that accepts it, without re-collecting documents or rerunning verification from scratch. Hypersign's own writing on this describes reusable KYC as "the practice of completing identity verification once and carrying that verified status as a portable credential presentable to any platform that accepts it," with the model already live across platforms including projects on Nibiru Chain (Hypersign). That's the claim, not the document, moving between systems, and it's the structural shift that makes inter-CASP data exchange tractable instead of a bolt-on integration project.
What a Credential-Based Stack Gets Exchanges That a Ground-Up Build Can't
Walk through what that difference looks like on a single transfer. A CASP authorised in Ireland receives a EUR 1,500 transfer instruction from a counterparty CASP in Germany, above the travel rule's EUR 1,000 threshold, so originator and beneficiary information has to move with it. Under a document-storing KYC system, clearing that request usually means a compliance analyst pulling the client's file, manually extracting the specific fields the travel rule requires (full name, wallet address, and, where the counterparty asks for it, a national ID reference), redacting everything outside that request, and sending it back, a manual step repeated for every qualifying transfer to every counterparty. Under a credential-based system, the German CASP's request specifies the exact claims it needs; the client's wallet presents only those fields from the verifiable credential already on file, cryptographically signed by the original issuer, and the Irish CASP's system checks the signature chain instead of reopening the underlying document. That's not a modest speed gain. It's the difference between a repeatable, API-level presentation and a manual compliance task redone for every counterparty request.
Concretely, a credential-based architecture changes three things a ground-up build has to solve independently:
- Data doesn't sit in one custodial database. The credential is held by the user in an encrypted vault; Hypersign doesn't retain the underlying documents (Hypersign, on validator KYC). That directly narrows the single-point-of-failure exposure a centralized KYC database represents, which matters given how much scrutiny data-breach exposure at document-storing KYC vendors has drawn in this sector.
- Transfer is a presentation, not a re-verification. When a client moves to an authorised CASP, or when a counterparty CASP needs originator/beneficiary proof under the travel rule, the receiving party can request a specific claim from the credential rather than triggering a full document reverification cycle.
- Compliance signals travel with the credential. AML screening results and risk scores can be embedded in the credential itself, cryptographically bound so they can't be transferred between individuals, rather than living in a separate system that has to be queried and reconciled on every hop.
Mapping Verifiable Credentials to ESMA's Documented-Evidence Expectations
None of this is a substitute for CASP authorization, and it's worth being precise about that boundary: reusable credentials don't get you licensed, they change how expensive it is to build the evidence layer authorization and the travel rule both require. ESMA's expectations, and MiCA's five-year retention rule, come down to being able to show, on demand, who was verified, when, by what standard, and what happened to that verification afterward (Flagright). A verifiable credential carries that provenance natively: issuer, timestamp, and status are part of its structure, not metadata bolted onto a document scan after the fact. That's a smaller gap to close between "verified for authorization" and "auditable for the travel rule and inter-CASP exchange" than a system built around static document storage ever gets to on its own.
What Unlicensed Exchanges Should Do Now
Under the EU MiCA framework, the right next step depends on where your exchange actually sits today, mid-application or not yet in the queue, and the two paths diverge from here.
If You're Mid-Application
Stop onboarding and marketing to new EU clients immediately if you haven't already; that instruction from ESMA's statement isn't optional guidance, it's the baseline for staying inside the wind-down exception rather than active breach (AMF France). Audit your current KYC and AML stack specifically against the travel rule's inter-CASP data-exchange requirement, not just against your national competent authority's authorization checklist, because that second requirement is the one most application-stage builds haven't tested yet. If your verification data is locked in a proprietary format that can't be exported or presented to a counterparty CASP, that's the rebuild waiting for you on the other side of authorization, and it's cheaper to address now than after your license is granted.
If You Haven't Applied Yet
Don't build the AML and KYC layer to clear the application checkpoint alone. Build it to satisfy the travel rule's data-portability demands from the start, so authorization and inter-CASP readiness are the same project instead of two. Evaluate whether a credential-based vendor gets you to defensible, audit-ready MiCA compliance faster than an in-house build, and be honest about where you are in the queue: national competent authorities are processing a large backlog, and firms that haven't yet filed are, by definition, further from authorized status than the roughly one in six firms that already converted. Review Hypersign's documentation at docs.hypersign.id for the technical detail on how credential issuance and verification work, and see how a verify-once model maps onto your specific onboarding flow before you commit engineering time to a build you may have to redo.
