MiCA KYC Requirements in 2026: What Crypto Firms Must Do Before It’s Too Late

Key highlights

• MiCA is now law and in active enforcement, yet many European CASPs still run incomplete identity verification and pre-MiCA compliance setups that will not survive a regulatory examination.
• The full CASP provisions became applicable on December 30, 2024, the same day as the recast Transfer of Funds Regulation, and the transitional period for pre-existing CASPs ended on July 1, 2026 at the latest (earlier in Member States that shortened it).
• MiCA itself does not contain the KYC rules: customer due diligence for CASPs comes from national law transposing the AML Directive (the AML Regulation from 10 July 2027), which works as a single compliance surface with MiCA authorisation and the Transfer of Funds Regulation.
• The most common gaps regulators flag are missing audit trails, centralised PII storage without safeguards, missing checks on stablecoin issuers' MiCA authorisation, and incomplete Travel Rule implementation.
• Compliance is not a bolt-on: a MiCA-ready stack ties customer classification, tiered verification, ongoing monitoring, and five-year record-keeping together from day one.
• Self-hosted wallet transfers exceeding EUR 1,000 require the CASP to verify the wallet is owned or controlled by its customer, a Travel Rule step many firms have only partly built.

The KYC requirements that apply to crypto-asset service providers under MiCA oblige every CASP in the EU to verify client identity before onboarding, document AML/CFT procedures, and monitor relationships on an ongoing basis, but the rules themselves come from EU anti-money laundering law, not from MiCA's own articles. MiCA adds authorisation, governance and conduct rules, and the Transfer of Funds Regulation adds the Travel Rule, so CASPs need to treat all three as one compliance surface rather than separate obligations.

MiCA is now law. Most CASPs are still building. The Markets in Crypto-Assets Regulation has moved from policy debate to active enforcement, but a large number of crypto-asset service providers across Europe are still running incomplete identity verification, stitched-together AML procedures, and compliance setups that predate MiCA entirely. This guide covers what the regulation actually demands, where firms keep falling short, and how to close those gaps before regulators force the issue.

Since December 30, 2024, every CASP seeking to operate in the EU has had to meet MiCA’s full prudential and conduct-of-business requirements, alongside Know Your Customer obligations under EU AML law that go well beyond collecting an email address and a selfie. If your firm is still relying on a legacy onboarding flow, it is already behind. The transitional period for pre-existing CASPs ended on July 1, 2026 at the latest, and earlier where Member States shortened it (the Netherlands on 30 June 2025, Germany on 30 December 2025).

Below is a practical breakdown of what MiCA KYC requirements actually entail: the deadlines you need to track, the compliance gaps that trip up even well-funded teams, and a working framework for building an onboarding stack that satisfies the regulation.

Where do the KYC requirements under MiCA actually come from?

MiCA itself does not contain the customer due diligence rules. Articles 68 to 73 cover governance, information to competent authorities, safekeeping of client assets, complaints handling, conflicts of interest and outsourcing, and Article 68(8) requires CASPs to have procedures to comply with national law transposing the EU’s Anti-Money Laundering Directive (AMLD). The KYC obligations come from that national AML law today, and from the AML Regulation (EU) 2024/1624 from 10 July 2027. The Transfer of Funds Regulation (TFR) adds the Travel Rule, so CASPs need to treat all three as a single compliance surface.

Verified Customer Identity

The baseline rule: every CASP must verify client identity before establishing a business relationship or executing a transaction. That means collecting and validating government-issued identity documents, verifying residential address, and confirming beneficial ownership for corporate accounts. The standard is documentary verification that can hold up under supervisory scrutiny, not “best effort.”

For a step by step view of building this onboarding flow, see KYC for crypto exchanges in 2026.

For individuals, this means validating a passport or national ID card against the person presenting it, usually through document verification technology paired with biometric matching. For legal entities, it means verifying registration documents, identifying ultimate beneficial owners who hold more than 25% ownership, and mapping the entity’s control structure.

We break down beneficial ownership and entity verification in our KYB software guide.

Documented AML/CFT Procedures

MiCA requires the authorisation file to describe the CASP's internal controls and procedures for money laundering and terrorist financing risks (Article 62), and Article 68(8) requires effective procedures to comply with national AML law. That AML law is what requires written internal policies, procedures, and controls for AML/CFT compliance, approved by senior management and producible to competent authorities on request. A one-page policy document won’t cut it. Regulators want to see procedures that map directly to the firm’s risk profile, customer base, product range, and geographic exposure.

The procedures must cover customer due diligence (CDD), enhanced due diligence (EDD) for high-risk customers and politically exposed persons (PEPs), suspicious transaction reporting to Financial Intelligence Units (FIUs), record-keeping with a minimum five-year retention period, and employee training programmes. Crypto firms also need controls for crypto-specific risks: on-chain transaction monitoring, wallet clustering analysis, and flagging transactions that involve privacy coins, mixing services, or high-risk jurisdictions. Those controls follow from the firm's own AML risk assessment rather than from MiCA's text, which only bars trading platforms from admitting crypto-assets with an inbuilt anonymisation function unless their holders and transaction history can be identified (Article 76(3)).

The distinctions between these tiers are explained in CIP, CDD and EDD compared.

Ongoing Monitoring

KYC doesn’t stop at onboarding. CASPs must monitor the business relationship on an ongoing basis, which means scrutinising transactions against what the firm knows about the customer, their business profile, and their risk assessment. Re-verification is periodic, with the frequency set by risk classification. High-risk customers typically need annual review; standard-risk clients might be reviewed every three years.

Ongoing monitoring also includes continuous screening against EU and UN sanctions lists, PEP databases, and adverse media sources. For crypto-native firms, this means running transaction monitoring systems that can catch on-chain anomalies: unusual patterns, interactions with flagged wallet addresses, and transfers that don’t fit the customer’s established profile.

For what these screens tend to miss, read our adverse media screening guide.

Bottom line: MiCA doesn’t invent a new KYC model. It brings crypto in line with what banks and payment institutions have been doing for years, then adds crypto-specific layers on top. The firms that struggle most are the ones that treated KYC as a growth-stage problem instead of a day-one infrastructure decision.

What are the key MiCA deadlines and how does the phased rollout work?

MiCA didn’t land all at once. The regulation was designed as a phased rollout, with different obligations kicking in at different stages. Here’s the timeline every CASP compliance team should know cold:

June 29, 2023, MiCA entered into force, twenty days after its publication in the Official Journal of the EU on June 9, 2023. The clock started on transition periods. No immediate operational obligations for CASPs, but the direction was set.

June 30, 2024, Stablecoin provisions (Titles III and IV) took effect. Issuers of asset-referenced tokens and e-money tokens were required to hold authorisation, maintain reserves, and meet disclosure and redemption requirements. Several major stablecoin projects were caught flat-footed.

December 30, 2024, Full CASP provisions became enforceable. Title V, covering authorisation and operating conditions, went live. This is when MiCA’s conduct-of-business obligations became mandatory for all new CASPs seeking authorisation, and the recast Transfer of Funds Regulation started to apply the same day.

July 1, 2026, The transitional period ended. Member States were allowed to let CASPs already operating under national regimes continue for up to 18 months without full MiCA authorisation, or to shorten that period: the Netherlands allowed six months and Germany twelve. Since this date at the latest, every CASP operating in the EU must hold a MiCA authorisation or stop.

June 30, 2027, The European Commission’s final report on the application of MiCA is due (Article 140), following an interim report due by June 30, 2025. Alongside it, ESMA, in cooperation with the EBA, reports every year on the application of MiCA and crypto-asset market developments, with the first report due by December 31, 2025 (Article 141).

If you’re a pre-existing CASP: If your firm was operating under a national registration like France’s PSAN regime or Germany’s BaFin crypto custody licence, the transitional period has ended (in France on July 1, 2026, in Germany on December 30, 2025), and you need full MiCA authorisation to keep serving EU clients.

Which MiCA compliance gaps trip up even well-funded teams?

We’ve reviewed crypto compliance stacks across dozens of firms, and the same failure patterns keep showing up. These are the gaps that national competent authorities are most likely to flag during authorisation, and the ones most likely to trigger enforcement action afterwards.

No Audit Trail

This is the most common gap, and the most damaging. Many CASPs collect identity documents at onboarding but don’t maintain a complete, timestamped record of every verification decision, document review, and risk assessment performed throughout the customer relationship. AML law requires CDD records to be kept for five years after the business relationship ends, MiCA Article 68(9) requires records of all crypto-asset services, orders and transactions to be kept for five years (up to seven if the competent authority asks), and both sets of records must be producible to competent authorities on request. If your verification vendor gives you a pass/fail result but your system doesn’t log the underlying evidence (the document images, biometric match score, data sources checked, analyst decision), that gap will not survive a regulatory examination.

Centralised PII Storage Without Adequate Safeguards

You can’t do KYC without collecting sensitive personal data. But storing it in a single database without encryption at rest, access controls, or data minimisation is a liability under both MiCA and GDPR. CASPs have to satisfy two regulatory regimes at once: AML law and MiCA say retain records for supervisory access; GDPR says minimise collection, limit retention, and protect data subjects’ rights. Firms that dump raw identity documents into a centralised S3 bucket and call it done are exposed on both fronts. What’s needed is a privacy-by-design architecture: encrypted storage, role-based access, data partitioning, and retention and deletion policies that reconcile the two frameworks.

This liability is the focus of our piece on centralized PII storage risk.

No Stablecoin Issuer Documentation

If your CASP lists, trades, or custodies stablecoins, the first check is the issuer. MiCA generally requires e-money tokens and asset-referenced tokens offered to the public or admitted to trading in the EU to come from an authorised issuer, so supporting a token without checking its issuer’s authorisation is a gap. Many firms either don’t track this at all, or they rely entirely on the issuer’s self-reported attestations. Reserve and redemption obligations sit with the issuer rather than the CASP, but keeping the issuer’s authorisation, white paper and reserve reports on file is what lets you explain each listing when a supervisor asks.

Incomplete Travel Rule Implementation

The EU’s recast Transfer of Funds Regulation requires CASPs to collect and transmit originator and beneficiary information for crypto-asset transfers (the Travel Rule). This has been a known requirement for over a year, but many CASPs have only partly implemented it, especially for transfers involving self-hosted wallets. For transfers to or from a self-hosted wallet exceeding EUR 1,000, the CASP must verify that the wallet is owned or controlled by its customer. If you don’t have the tooling or processes to do this, you’re non-compliant.

For a practical walkthrough, see our FATF Travel Rule compliance guide.

How do you build a MiCA-ready onboarding stack?

You can’t get to MiCA compliance by bolting a KYC vendor onto an existing signup flow. What’s needed is an onboarding architecture that ties together identity verification, risk assessment, ongoing monitoring, and record-keeping from the ground up. Here’s a working framework.

Start with customer classification. Before collecting a single document, your system should categorise the incoming customer by risk level based on geography, product type, transaction volume, and entity type. This classification drives everything downstream: it determines how much due diligence is required, and it must be documented and defensible.

From there, tier your identity verification. Not every customer needs the same verification intensity under MiCA’s risk-based approach. Standard-risk individuals can be verified through automated document checks and biometric matching. High-risk customers, PEPs, and corporate entities need enhanced due diligence: source-of-funds documentation, deeper screening, and sometimes manual review by a trained compliance analyst.

The audit trail needs to exist from day one. Every verification event (document submission, biometric check, sanctions screening, risk scoring, manual review decision) must be logged with a timestamp, an immutable record of inputs and outputs, and a clear chain of custody. This is the first thing regulators will ask for during a supervisory examination.

Ongoing monitoring has to be baked into the core flow, not bolted on after launch. Transaction monitoring, periodic re-verification, and continuous sanctions screening should all be automated and tied to each customer’s risk profile. When anomalous transactions generate alerts, those alerts need to be triaged, investigated, and documented, whether or not they result in a suspicious transaction report.

Your data architecture needs to work for both GDPR and MiCA. Encrypt PII at rest and in transit, set up granular access controls, apply data minimisation to collection, and establish retention schedules that meet the five-year record-keeping periods in AML law and MiCA Article 68(9) without violating GDPR’s storage limitation principle. Getting this wrong creates liability on both sides.

We unpack the GDPR side of this overlap in GDPR transparency enforcement.

Finally, prepare for the conversation with your regulator. Build reporting that lets you produce compliance data on demand: customer risk distributions, verification completion rates, SAR filing statistics, audit trail exports. The firms that build regulatory confidence are the ones that can show their compliance posture clearly and quickly when asked.

How do Zyphe's verification flows align with MiCA?

Building this kind of onboarding stack from scratch takes serious engineering and compliance effort. That’s the problem Zyphe was built to solve. Zyphe provides identity verification flows designed specifically for CASPs operating under MiCA.

The verification infrastructure covers the full customer onboarding lifecycle: automated document verification for EU-issued identity documents, biometric liveness detection to block spoofing, real-time sanctions and PEP screening against consolidated EU and international watchlists, risk-based workflow routing that adjusts due diligence depth based on customer classification, and a complete, immutable audit trail that logs every verification event for regulatory production.

On the corporate side, Zyphe handles beneficial ownership verification, corporate registry lookups, and UBO identification workflows that meet AML requirements for mapping ownership and control structures. The data architecture is built for the GDPR-MiCA overlap, with encrypted storage, role-based access, and configurable retention policies that satisfy record-keeping obligations without creating data protection liabilities.

Zyphe’s ongoing monitoring integrations also cover continuous transaction screening, periodic customer re-verification triggers, and Travel Rule compliance tooling, so CASPs stay compliant through the full customer lifecycle, not just at the point of onboarding.

MiCA KYC Compliance Checklist

Use this checklist to assess your CASP’s readiness against MiCA’s KYC and AML requirements. Print or save for your compliance team.

CUSTOMER IDENTITY VERIFICATION

☐ Government-issued ID verification for all natural persons before onboarding

☐ Biometric liveness detection to prevent document fraud and spoofing

☐ Beneficial ownership identification for corporate clients (more than 25% threshold)

☐ Verification of corporate registration documents and legal entity structure

☐ Address verification through utility bills, bank statements, or registry data

AML/CFT POLICIES AND PROCEDURES

☐ Written AML/CFT policy approved by senior management

☐ Risk-based customer classification framework documented and implemented

☐ Enhanced due diligence procedures for PEPs, high-risk jurisdictions, and high-value accounts

☐ Suspicious transaction reporting process with designated MLRO

☐ Employee AML training programme with documented attendance

☐ Annual independent audit of AML programme effectiveness

ONGOING MONITORING

☐ Real-time transaction monitoring with risk-based alert thresholds

☐ Continuous sanctions and PEP screening against EU/UN watchlists

☐ Periodic customer re-verification schedule based on risk classification

☐ On-chain analytics integration for detecting high-risk wallet interactions

☐ Adverse media monitoring for existing customers

RECORD-KEEPING AND AUDIT TRAIL

☐ Timestamped, immutable log of all verification events and decisions

☐ Five-year minimum retention for all CDD/EDD records post-relationship

☐ Immediate producibility of records to competent authorities on request

☐ Document images, biometric scores, and data source logs retained

DATA PROTECTION (GDPR RECONCILIATION)

☐ PII encrypted at rest and in transit

☐ Role-based access controls for compliance data

☐ Data minimisation applied to collection processes

☐ Documented retention and deletion policy reconciling MiCA and GDPR

☐ Data processing agreements in place with all verification vendors

TRAVEL RULE COMPLIANCE

☐ Originator and beneficiary data collection for all crypto transfers

☐ Self-hosted wallet ownership verification for transfers exceeding EUR 1,000

☐ Integration with Travel Rule messaging protocol (e.g., TRISA, the OpenVASP Association’s Travel Rule Protocol (TRP), or equivalent)

STABLECOIN DUE DILIGENCE

☐ Verification that listed stablecoin issuers hold valid MiCA authorisation

☐ Reserve asset documentation on file for all supported stablecoins

☐ Monitoring of issuer compliance status and reserve audit reports

AUTHORISATION READINESS

☐ MiCA authorisation application submitted to national competent authority

☐ Governance arrangements and fit-and-proper assessments completed

☐ Minimum prudential capital requirements met

☐ Complaint-handling procedures documented

☐ Business continuity and wind-down plan in place

When is a single KYC vendor not enough for MiCA?

Bolting a KYC vendor onto an existing signup flow does not get you to MiCA compliance. If your verification vendor returns a pass or fail result but your own system does not log the underlying evidence, the document images, biometric match score, data sources checked, and analyst decision, that gap will not survive a regulatory examination. A vendor pass is not the same as a defensible audit trail.

The same caution applies to data architecture. Storing identity documents in a single database without encryption at rest, access controls, or data minimisation creates liability under both MiCA and GDPR at once. AML law and MiCA ask you to retain records for supervisory access; GDPR asks you to minimise collection and limit retention. A vendor that solves one side without reconciling the other leaves you exposed on both fronts, so treat KYC as day-one infrastructure rather than a growth-stage problem.

Zyphe’s KYC for crypto page shows how a CASP meets these KYC obligations in practice: document and liveness verification, sanctions and PEP screening, Travel Rule data structured at onboarding, and no central store of customer documents.

Frequently Asked Questions

What are the MiCA KYC requirements for CASPs?

Under EU AML law (national rules transposing the AML Directive today, the AML Regulation from 10 July 2027), CASPs must verify customer identity before onboarding using government-issued documents, establish documented AML/CFT procedures, perform ongoing transaction monitoring, apply risk-based due diligence, maintain auditable records of all verification activities, and report suspicious transactions to Financial Intelligence Units.

When do MiCA KYC requirements take effect?

MiCA’s full CASP provisions became applicable on December 30, 2024, the same day as the recast Transfer of Funds Regulation; the KYC obligations themselves come from EU AML law. The transitional period for pre-existing CASPs operating under national regimes ran until July 1, 2026 at the latest (shorter where Member States cut it), and full MiCA authorisation is now required to continue operating in the EU.

What happens if a CASP fails to comply with MiCA KYC rules?

Non-compliant CASPs face authorisation denial or revocation, administrative fines (MiCA requires Member States to allow maximum fines of at least EUR 5 million or 5% of annual turnover for legal persons and at least EUR 700,000 for natural persons), public disclosure of violations, and potential criminal liability under national AML transposition laws.

Does MiCA require ongoing monitoring or just onboarding KYC?

Both are required, though the obligation comes from EU AML law rather than from MiCA itself. CASPs must perform initial identity verification at onboarding and maintain ongoing transaction monitoring, periodic customer re-verification based on risk profiles, and continuous screening against sanctions lists. The approach is risk-based, as under the AML Directive.

How does MiCA’s KYC differ from traditional financial services KYC?

KYC for CASPs comes from the same EU AML rules that apply to banks and payment institutions. The crypto-specific layer comes mainly from the Transfer of Funds Regulation (Travel Rule data for crypto transfers, and ownership checks for self-hosted wallet transfers exceeding EUR 1,000) and from each firm’s own risk assessment (on-chain transaction monitoring and wallet attribution). MiCA adds stablecoin issuer authorisation rules and bars trading platforms from admitting crypto-assets with an inbuilt anonymisation function unless their holders can be identified.