The urgent MiCA question is obvious: can this firm keep operating in Europe?
The quieter question comes right after it: once the licence is in place, how much identity data will the platform keep every day to prove that it is operating properly?
That second question matters because the transition period is ending. ESMA explains that entities already providing crypto-asset services under national law before 30 December 2024 may continue under MiCA's grandfathering clause until 1 July 2026, or until they are granted or refused a MiCA authorisation. Not every Member State used the full period, and authorisation can cut it short. Still, 1 July is the outer edge of the longest transition.
For CASPs still working through authorisation, the deadline creates pressure. For foundations and application teams, it exposes a design choice.
Do compliant crypto products keep solving identity by collecting more documents, keeping more copies and spreading sensitive data across every application? Or do they build a proof layer that lets a platform verify the claim it needs without taking custody of the full identity record behind it?
MiCA does not answer that product question for them.
What changes as the MiCA transition closes?
MiCA gives the EU a more uniform framework for crypto-assets and related services. The European Commission describes it as a harmonised framework for issuing crypto-assets and providing services around them. ESMA points to authorisation, supervision, transparency, disclosure, market integrity and consumer protection as core parts of the regime.
In plain terms, crypto firms can no longer treat Europe as a patchwork of loosely connected national interpretations. CASPs need a clearer operating model: who they serve, what services they provide, what records they keep, how they supervise risk, and how they demonstrate that to competent authorities.
MiCA also sits inside a broader compliance environment. The Commission notes that crypto-asset service providers covered by MiCA are included as obliged entities under the EU AML/CTF framework. That distinction matters. MiCA is not a magic container for every KYC or AML duty. CASPs operate across MiCA, AML/CTF rules, sanctions controls, data protection rules, operational resilience expectations and national implementation details.
Architecture matters because those obligations hit the same product surface. If each one turns into another raw data collection flow, the platform may become compliant in one sense while increasing its security, privacy and data liability in another. Compliance teams get evidence, but the business gets more sensitive data to protect, more vendors to govern, more logs to explain and more user friction to absorb.
Authorisation is not the end of the operating model
A licence answers whether a firm may operate. It does not answer how identity should move through the product after approval.
Everyday compliance still touches onboarding, business verification, eligibility checks, wallet and account risk, transaction monitoring, access decisions, sanctions screening, record keeping and audits. Some checks require personal or business data at the source. Some require a durable audit trail. Some require a platform to prove that a decision was made using valid information at a specific time.
But not every check requires every application to hold the raw identity file.
A platform may need to know that a user passed a required check. It may need to know that a business exists and is authorised to act. It may need to know that a wallet is not associated with a risk category, that a person is in an allowed jurisdiction, or that a credential has not expired or been revoked.
Those are claims. They are narrower than full identity records.
The old pattern treats the document as the answer. Upload the passport. Upload the company registry extract. Upload the proof of address. Upload it again when another app asks.
Familiar, yes. Inevitable, no.
Where eIDAS 2.0 changes the identity conversation
eIDAS 2.0 does not replace MiCA. It changes the surrounding identity environment.
The European Commission says the European Digital Identity framework requires Member States to provide EU Digital Identity Wallets to citizens by the end of 2026, in line with the regulation and implementing acts. The aim is user control: people and businesses should be able to choose which aspects of their identity and data they share with third parties.
For crypto platforms, that points toward a future where trusted digital credentials become more portable. A person or business may hold a credential once and present it across services. A relying party may verify a credential without rebuilding the whole issuance process.
Useful, but not enough.
Portability can reduce repeated onboarding. It can also make over-sharing easier if every relying party asks for too much. A digital wallet does not make a request privacy-preserving by default. If a service asks for a full identity presentation when it only needs jurisdiction or eligibility, the old problem has simply moved into a cleaner interface.
Credentials will be digital. The better question is whether applications learn to ask for smaller answers.
Stronger compliance does not have to mean more raw custody
The better model separates the claim from the underlying data.
A trusted source checks the raw information. The user or business receives a credential. Later, when an application needs to make a decision, it asks for a specific proof: this user is eligible, this business passed KYB, this wallet has a valid risk status, this credential is still current, this agent has authority to perform a defined action.
The application verifies the proof and records the evidence it needs for policy and audit. It does not receive the full document set behind the proof by default.
Selective disclosure makes that boundary practical. A user should not have to reveal a full identity profile to prove one narrow fact. A business should not have to send the same sensitive documents to every ecosystem app when the app only needs a verified status. A chain should not become an identity database simply because regulated applications need trust signals.
Zero-knowledge proofs can help, if they are used carefully. ZK can prove that a statement is true without revealing the underlying data used to establish it. But "uses ZK" is not a compliance strategy by itself. The system still needs issuer trust, revocation, policy mapping, audit evidence, operational controls and clear decisions about what the verifier receives and retains.
Privacy-preserving compliance still needs evidence. It just tries to stop evidence from turning into unnecessary exposure.
What should a CASP prove, log and retain?
A useful product exercise is to stop asking, "What data can we collect?" and ask instead, "What claim must we prove for this decision?"
For many crypto products, the list looks something like this:
- The user or business passed the required identity or business verification.
- The person, entity, wallet or transaction is eligible for the product action.
- The relevant jurisdiction, residency or access policy was satisfied.
- The credential came from a trusted source.
- The credential was valid when it was checked.
- The result can be audited later.
- The platform retained only what its policy and legal obligations require.
The last point is easy to say and hard to operationalise. It forces product, compliance and engineering teams to decide what counts as sufficient evidence. A yes/no result may be enough for one interaction. Another may require a signed verification receipt, timestamp, issuer reference, policy version, risk category or revocation status.
Design those records directly.
If a platform keeps the raw identity file only because it has no better way to prove what happened, the data store is compensating for weak verification architecture.
Why chain foundations need reusable identity primitives
The problem does not stop at CASPs. It spreads across the ecosystem.
When every application rebuilds identity, every application creates another user journey, another vendor path, another storage decision and another place where sensitive data can leak. One product can manage that. Across a chain ecosystem, it becomes a pattern.
Foundations already think in primitives: wallets, execution, liquidity, messaging, oracles, interoperability. Identity deserves the same treatment because many applications need the same trust claims.
They need to know whether a wallet belongs to a real person or an eligible participant. They need to know whether a business passed verification. They need jurisdiction signals, KYT results, accredited investor status, access rights or agent authorisation. The policy may differ by application, but the rails for issuing, verifying, revoking and reusing credentials do not need to be rebuilt each time.
A reusable identity primitive should not mean a universal profile that follows a user everywhere. It should mean common infrastructure for narrow proofs.
The application asks for the claim. The user or business presents proof. The verifier checks issuer trust, validity, expiry and revocation. The app keeps the evidence it needs and avoids becoming the default custodian of everything else.
Trust can become composable without turning the ecosystem into a shared surveillance layer.
A privacy-preserving compliance architecture
At zkMe, we build around this problem: regulated crypto and open finance need credible verification, but they should not default to raw identity custody everywhere.
zkKYC and zkKYB can support privacy-preserving eligibility and entity proofs. KYT and risk signals help teams reason about transaction-level controls. Reusable credentials and selective disclosure reduce repeated exposure. Identity oracle infrastructure lets applications and chains verify claims programmatically instead of stitching together isolated identity flows.
No proof magically satisfies every legal obligation. Exact obligations depend on jurisdiction, product design, customer type, risk model and implementation.
But compliance architecture can still be designed around the claim that needs to be proven.
If a platform needs to prove that a user passed a check, it should not default to storing the full identity record. If an application needs a jurisdiction result, it should not default to collecting a home address. If a foundation wants regulated use cases in its ecosystem, it should not push every app toward a separate KYC silo.
MiCA raises the bar for crypto-asset services in Europe. eIDAS 2.0 points toward a more credential-based identity environment. The intersection is an opening to build better verification infrastructure before the old raw-data pattern hardens into the default.
Compliance needs evidence. It does not have to begin with another copy of the person.
About zkMe
zkMe provides protocols and oracle infrastructure for the compliant, self-sovereign, and private verification of Identity and Asset Credentials.
It is the only decentralized solution capable of performing FATF-compliant CIP, KYC, KYB, and AML checks natively onchain, without compromising the decentralization and privacy ethos of Web3.
By combining zero-knowledge proofs with advanced encryption and cross-chain interoperability, zkMe enables verifiable identity and compliance data to remain entirely under the user's control. This ensures that sensitive information never leaves the user's device while maintaining regulatory-grade assurance for partners and protocols.
