MiCA Customer Onboarding: A Practical Remote AML/KYC Playbook for EU CASPs
A practical remote AML/KYC playbook for EU CASPs, covering MiCA governance, EBA onboarding controls, crypto risk factors, the Travel Rule, migration and AMLR readiness.
In brief: MiCA does not prescribe a standalone remote-KYC process. A defensible onboarding journey for an EU crypto-asset service provider (CASP) combines MiCA governance and service requirements with the customer due diligence rules in the applicable national AML/CFT framework, the EBA Remote Customer Onboarding Guidelines, the EBA crypto-asset risk-factor guidance and, where transfers are offered, the EU Travel Rule. The practical objective is not merely to obtain an identity document: it is to reach a reasoned customer-risk decision and retain evidence that another reviewer can reconstruct.
Regulatory status: This guide reflects the framework reviewed on 19 August 2026. MiCA, Regulation (EU) 2023/1113 on information accompanying transfers of funds and certain crypto-assets (the TFR), national laws transposing Directive (EU) 2015/849 and the relevant EBA Guidelines are current. Regulation (EU) 2024/1624 (the AMLR) will generally apply from 10 July 2027. AMLA's Article 28 Customer Due Diligence RTS is discussed only as a draft: AMLA's regulatory-instruments tracker still listed the consultation as closed, rather than the text as final, at the review date.
Does MiCA itself require KYC?
The short answer is that MiCA makes AML/CFT controls part of CASP authorisation and governance, but the detailed customer due diligence process does not come from MiCA alone.
Article 62(2)(i) of MiCA requires a CASP applicant to describe the internal controls, policies and procedures it will use to identify, assess and manage money-laundering and terrorist-financing risks. The final Level 2 measure, Article 6 of Commission Delegated Regulation (EU) 2025/305, makes that expectation more concrete. An applicant must provide, among other things, its inherent and residual ML/TF risk assessment; CDD and suspicious-activity procedures; evidence of proportionality; the identity and competence of the person responsible; training resources; copies of its AML/CFT policies, procedures and systems; and its arrangements for testing their adequacy and effectiveness.
The operational CDD duties sit principally in the applicable national law transposing Directive (EU) 2015/849. Article 38 of the TFR brought CASPs into that framework as financial institutions from 30 December 2024. The definition excludes a provider whose only crypto-asset service is advice on crypto-assets; a firm may nevertheless be in scope because it provides another crypto-asset service, has another regulated status or is covered by national law. Scope should therefore be confirmed before a workflow is designed.
A practical regulatory map for MiCA customer onboarding. The fifth layer is future-facing: the AMLR applies generally from 10 July 2027 and AMLA's Article 28 CDD RTS was not final at the review date.
Regulatory layer
What it contributes to onboarding
Practical consequence
MiCA and Delegated Regulation (EU) 2025/305
Authorisation, governance and evidence that AML/CFT risks and CDD controls are understood and managed.
The onboarding framework must be consistent with the CASP's licensed services, business model and authorisation file.
AMLD and national law
Current legal duties to identify and verify customers and beneficial owners, understand the relationship, risk-rate it, monitor it and keep records.
Map every workflow to the home Member State's rules and any host-state requirements that apply.
Crypto-specific customer, product, delivery-channel and geographic risk factors, together with risk-sensitive mitigation.
Generic bank KYC is not enough; the assessment must account for how crypto-assets and services can be used.
TFR and EBA Travel Rule Guidelines
Information and traceability controls for crypto-asset transfers, including transfers involving self-hosted addresses.
Transfer controls should be designed alongside onboarding, but must not be confused with initial CDD.
Is remote onboarding automatically high risk?
No. Annex III to Directive (EU) 2015/849 identifies non-face-to-face relationships or transactions without certain safeguards as a potentially higher-risk factor. The absence or weakness of safeguards is critical. A reliable electronic-identification method, sound document and biometric controls, a clear manual fallback and effective ongoing monitoring can materially change the delivery-channel risk assessment.
This does not mean that a digital journey is low risk by default. The CASP should assess the combined customer, service, asset, geography, funding and delivery-channel risk. It should also be able to explain why the chosen verification route was appropriate for that combination. A control should never receive credit merely because a vendor markets it as “compliant”.
Build the control framework before switching the journey on
which customer types, legal forms, products, services and jurisdictions are eligible for remote onboarding;
which steps are automated, which require human intervention and which conditions trigger manual escalation or face-to-face verification;
who owns the policy, approves material changes, monitors performance and accepts residual risk;
how the solution affects ML/TF, fraud, legal, operational, ICT, data-protection and reputational risk;
how document authenticity, impersonation, presentation attacks, replay, synthetic identity and other relevant fraud scenarios are tested;
what end-to-end testing, quality assurance, sample review and management information will be used; and
how affected customer files will be identified and remediated if a defect is discovered later.
The management body should approve the remote-onboarding policies and oversee their implementation, while the AML/CFT compliance officer should ensure that they operate effectively and are reviewed. If a vendor performs identity checks, the allocation of tasks, access to evidence, change-notification duties, service levels, testing rights, data retention and exit arrangements should be explicit. Outsourcing a step does not outsource the CASP's responsibility for the result.
A defensible remote-onboarding workflow for EU CASPs
A defensible workflow joins identity evidence, customer-risk reasoning, MiCA service requirements and an auditable decision trail.
1. Confirm scope and eligibility
Identify the legal entity that will contract with the customer, the MiCA service requested and the jurisdictions from which that service may be offered. Test residence, location, service availability, customer type and product eligibility before collecting unnecessary personal data. Distinguish a new customer, an existing customer requesting a new service and a customer migrated from another provider. The workflow should also identify attempted circumvention, including inconsistent address, device, IP, telephone and payment-country information. Geolocation is a risk and regulatory input, not conclusive proof on its own.
2. Identify the customer, representatives and beneficial owners
For a natural person, define the mandatory identity attributes and the permitted sources. For a legal person, collect and verify the entity's existence, legal form, registered office, business activity and ownership and control structure. Identify each beneficial owner and any natural person acting on the entity's behalf, and verify the representative's authority. Avoid a journey that verifies the signatory successfully but leaves the corporate customer, ownership chain or authority to act untested.
3. Verify identity using reliable and independent evidence
Where an appropriate notified eID scheme at “substantial” or “high” assurance or a relevant qualified trust service is available, it can provide strong evidence. For document-based routes, determine whether the document type is acceptable and current; assess security features and signs of alteration; validate machine-readable data where available; compare OCR, MRZ or chip data with customer-provided information; and stop when capture quality, connection integrity or authenticity is doubtful. Evidence should be time-stamped, securely retained and readable for later review.
4. Match the person to the evidence and test presence
An unattended journey should establish that the image or video was captured during the session, perform appropriate liveness or presence checks and use a strong person-to-document match. An attended video process requires trained staff, reliable audio and image quality, and a consistent interview and escalation guide. Define confidence thresholds, retry limits and manual-review rules before launch. Where ambiguity remains, interrupt and restart the journey, change verification route or move to an appropriate face-to-face process; do not convert uncertainty into an automatic approval.
5. Understand, screen and risk-rate the relationship
Identity is only one component of CDD. Establish the purpose and intended nature of the relationship, expected services, anticipated transfer values and frequency, relevant jurisdictions, source of funds and, where risk requires, source of wealth. Screen the relevant persons for PEP, sanctions and other required risk indicators, and resolve potential matches rather than recording only that a search ran.
The customer-risk methodology should also capture crypto-specific exposure: products or features that favour anonymity, privacy-enhancing technologies, mixers or tumblers, self-hosted addresses, rapid cross-border movement, links to unregulated or non-EU providers, unusual funding methods and relevant blockchain-analytics indicators. No single score should replace a reasoned view of the whole relationship.
6. Apply EDD, escalate and make a recorded decision
Define what happens when risk is elevated, evidence conflicts, ownership is unusually complex or activity falls outside appetite. Enhanced measures may include additional independent sources, stronger source-of-funds or source-of-wealth evidence, senior approval, tighter product or transaction limits and enhanced monitoring. The final record should state the material risk factors, controls applied, unresolved limitations, resulting rating, approver and reasons. Rejection logic should also address whether facts require internal escalation or consideration of a report to the relevant FIU, without alerting the customer.
7. Apply the MiCA service layer
CDD approval should not automatically activate every crypto-asset service. Add the MiCA requirements relevant to the requested service: client information and contractual terms; custody arrangements where custody and administration are provided; and the suitability assessment required by Article 81 of MiCA for advice or portfolio management. Keep the records logically connected, but distinguish AML/CFT risk acceptance from investor-protection, appropriateness or suitability conclusions.
8. Activate controls and monitor the relationship
Use a hard activation gate: the first transaction should occur only after the required initial CDD measures have been completed, subject to any narrowly framed rule in applicable national law. Transfer permissions, velocity and value limits, wallet controls and monitoring scenarios should reflect the approved risk profile. After activation, compare actual behaviour with the stated purpose and expected activity, refresh information when events or risk require it, and monitor the onboarding solution itself through alerts, quality reports, sample testing and manual review. A defect in the solution may require review of the population already onboarded, not only a technical fix for future customers.
Customer migrations: data transfer is not CDD completion
The end of MiCA's transitional period produced a useful practical rule for future migrations and acquisitions. In its 23 June 2026 public statement, ESMA said that where clients are transferred to a MiCA-authorised CASP, the onboarding CASP should carry out all necessary onboarding procedures, including CDD and other required AML/CFT checks.
A receiving CASP may be able to rely on another obliged entity in circumstances permitted by law, but reliance, outsourcing and a simple data purchase are different legal and control models. Before treating migrated files as usable, map the source data to the receiving standard, test completeness and currency, resolve missing or contradictory evidence, identify high-risk cohorts for priority review and retain the basis on which any prior verification was accepted. Commercial urgency is not an evidential standard.
Where the EU Travel Rule connects to onboarding
The TFR and the EBA Travel Rule Guidelines have applied since 30 December 2024. They require information about the originator and beneficiary to accompany or be associated with crypto-asset transfers involving CASPs, and require procedures for detecting and managing missing or incomplete information.
For a transfer to or from a self-hosted address, often described as a self-hosted wallet, the relevant CASP must obtain and hold the required information and ensure that the transfer can be individually identified. If the amount exceeds EUR 1,000, the CASP must take suitable measures to assess whether the address is owned or controlled by the relevant customer. The threshold is therefore not a general exemption from Travel Rule information requirements; it triggers an additional ownership-or-control measure for the self-hosted address.
The EUR 1,000 threshold adds a self-hosted-address ownership or control assessment; it is not a general Travel Rule exemption.
Design this control before the customer attempts a transfer. Decide which ownership-or-control measures are suitable for the relevant circumstances, what evidence is retained, how failed or inconclusive checks affect the transfer, and how the outcome feeds the customer-risk assessment. The TFR data can strengthen the CASP's understanding of a customer, but it does not replace identity verification, beneficial-ownership work, purpose and intended-nature assessment or ongoing monitoring.
Design now for the AMLR transition
The AMLR will generally apply from 10 July 2027 and will replace much of the directive-based rule set with directly applicable requirements. At the review date, AMLA listed its Article 28 CDD RTS as consultation closed, not final. The draft should therefore inform change planning, not be represented as current law.
Draft Article 7 would require non-face-to-face verification to use an eIDAS electronic-identification means at “substantial” or “high” assurance or a relevant qualified trust service. Only where that route is unavailable or cannot reasonably be expected would a remote document solution be used, subject to safeguards for person-to-document matching, communication integrity, capture quality, interruption on technical failure or doubt, valid information, secure time-stamped records and supervisory demonstrability. The obliged entity would also need to justify why the primary electronic-identification route was not used. The final text may change.
Practical preparation means building optionality rather than hard-coding one vendor journey: maintain an inventory of eID coverage by market, record which fallback route was used and why, preserve evidence in an exportable format, and make thresholds and rules version-controlled. The AML Agent EU AML Regulatory Tracker can be used to monitor the status of the AMLA CDD RTS and related EU AML developments.
What should the onboarding evidence pack contain?
The approved remote-onboarding policy, procedure, risk appetite and responsibility matrix.
The business-wide and solution-specific risk assessments, including assumptions and residual-risk acceptance.
Customer, product, service, legal-form and jurisdiction eligibility rules.
Pre-implementation and regression test plans, results, defects and remediation.
The vendor due-diligence file, contract, data-flow map, assurance reports and change notices.
A control matrix mapping each legal and policy requirement to the workflow, system rule and retained evidence.
Identity-source snapshots, session records, document and person-match outputs, and manual-review evidence.
PEP, sanctions and other screening results with false-positive or match dispositions.
The customer-risk assessment, EDD evidence, decision reasons, approvals, overrides and restrictions.
Travel Rule and self-hosted-address evidence where transfer services are used.
Training records, quality-assurance results, management information, incidents and affected-file remediation.
Rule, model, threshold and policy versions sufficient to reconstruct what applied on the decision date.
Common implementation failures
Treating a successful biometric match as completion of CDD.
Applying the same automated route to every customer, service, legal form and risk level.
Verifying a corporate representative but not the legal entity, authority to act or beneficial owners.
Allowing repeated retries until a weak identity check eventually passes.
Recording a vendor score without the underlying evidence, threshold version or review rationale.
Confusing reliance on another obliged entity with outsourcing or a transfer of customer data.
Assuming that remote onboarding is always high risk—or that compliant technology makes it automatically low risk.
Treating EUR 1,000 as a general EU crypto Travel Rule exemption.
Letting AML approval activate services before the separate MiCA service conditions are met.
Fixing a solution defect prospectively without reviewing customers affected by the earlier failure.
Worked example: a corporate customer using a self-hosted address
Consider a MiCA-authorised CASP onboarding a privately owned trading company established in one Member State. Its authorised representative lives in another Member State, one beneficial owner resides outside the EEA and the customer expects to purchase crypto-assets and transfer some of them to a self-hosted address.
The CASP verifies the company's existence against an independent register, maps the ownership chain, identifies and verifies the beneficial owners and confirms the representative's authority. The representative completes a supported eID route. The non-EEA beneficial owner uses an approved remote-document route with liveness, document-authenticity and manual review because the primary eID route is unavailable. The decision record states why each route was used.
The company explains its business, expected volumes, funding account, transfer purpose and relevant jurisdictions. Screening and crypto-specific risk factors lead to an elevated, but within-appetite, rating, additional source-of-funds evidence, senior approval and initial transfer limits. MiCA contractual and custody requirements are completed separately. When the customer later requests a transfer exceeding EUR 1,000 to a self-hosted address, the CASP obtains the required Travel Rule information and applies its documented ownership-or-control measure. An inconclusive result goes to escalation; it does not retroactively convert the original CDD file into a complete transfer decision.
This is an illustrative control sequence, not a prescribed scoring model or a conclusion that the customer must be accepted.
MiCA customer onboarding FAQ
Does a MiCA licence replace AML compliance or CDD obligations?
No. MiCA authorisation incorporates scrutiny of the CASP's AML/CFT framework, while the CDD duties arise from the applicable AML/CFT regime. The responsible authorities and precise national implementation can differ.
Do the EBA Remote Customer Onboarding Guidelines apply to CASPs?
CASPs brought within the definition of financial institution under the AMLD framework should treat the Guidelines as applicable supervisory guidance. Confirm competent-authority compliance, national implementation and the precise service scope, particularly where a firm provides advice only.
Must every remote customer complete a live video call?
No. The EBA Guidelines are technology-neutral and contemplate attended and unattended routes. The chosen solution must be appropriate to the risk, meet the relevant safeguards and provide a reliable fallback when confidence is insufficient.
Can a CASP rely entirely on a KYC vendor?
No. A vendor can perform defined tasks, but the CASP remains responsible for its policy, risk decision, oversight, evidence access, quality assurance and remediation. The contract should support those responsibilities in practice.
Does the EUR 1,000 threshold remove Travel Rule duties below that amount?
No. For crypto-asset transfers involving a CASP, the threshold is not a general information exemption. It adds an ownership-or-control assessment when a transfer to or from a self-hosted address exceeds EUR 1,000.
Turn the workflow into an operating procedure
A useful procedure should specify inputs, decision rights, evidence, system behaviour, exception paths and review triggers. It should not just repeat legislation. The AML Agent EU AML Document Generator can produce an editable CDD procedure working draft based on an entity profile, including digital-only onboarding as a delivery channel. It is a documentation tool, not a KYC, screening or transaction-monitoring system; the resulting draft must be validated against the CASP's services, technology, national law, risk assessment and supervisory expectations.
Last reviewed: 19 August 2026. Review this article when AMLA finalises the Article 28 CDD RTS and before the AMLR applies generally on 10 July 2027.
This article provides general regulatory information and is not legal advice. CASPs should consider final AMLA standards, applicable national requirements and supervisory expectations.
