Talk to usTry the demo

Crypto-Asset Service Providers: Customer Due Diligence Under MiCA and the EU Transfer Rules

KYC, AML and digital identification

For: Compliance officer or product owner at a crypto-asset service provider

What an EU crypto-asset service provider must identify, verify and pass on: authorisation under MiCA, customer due diligence, the information that travels with a transfer, and self-hosted addresses.

You run compliance or product at a firm that provides crypto-asset services to customers in the European Union, and you want one answer: which identity data must you collect and verify about a customer, when must you do it, and what must travel with a transfer to the next provider? This article reads the texts that answer it, namely the Markets in Crypto-Assets Regulation (MiCA), the EU regulation on information accompanying transfers of funds and certain crypto-assets, the EU Anti-Money Laundering Regulation, the European Banking Authority guidelines on the travel rule, and the FATF Recommendations.

For information; not legal advice.

The article describes the travel rule as a concept, that is, as a duty to carry identity data with a transfer.

Three layers, one chain of duties

Three bodies of rules meet in a crypto-asset service provider. The first is the licence: MiCA decides who may offer crypto-asset services in the Union and what the provider must show to the supervisor. The second is the customer due diligence regime of the anti-money laundering framework, which decides whom the provider must identify and verify. The third is the transfer regulation, which decides what identity data accompanies each transfer of crypto-assets between providers.

Dates matter here, because the layers do not apply from the same day. Regulation (EU) 2023/1113 states that it applies from 30 December 2024. The EBA guidelines on information requirements for transfers state that they apply from 30 December 2024 as well. The Anti-Money Laundering Regulation, Regulation (EU) 2024/1624, applies from 10 July 2027, with the date of 10 July 2029 for two categories of obliged entities named in Article 3. The texts of MiCA and of the transfer regulation themselves refer to Directive (EU) 2015/849 and to the national law that transposes it for the customer due diligence duties. The Liechtenstein supervisor, as one national example, records that MiCA has been fully applicable within the Union since 30 December 2024 and that its national implementation act entered into force on 1 February 2025.

The international frame is older than any of these texts. The Financial Stability Board finalised a global framework for crypto-asset activities in July 2023, built on the principle of "same activity, same risk, same regulation". The FATF section below sets the European texts beside the international standard.

Who counts as a crypto-asset service provider

MiCA defines a crypto-asset service provider as a legal person or other undertaking whose occupation or business is the provision of one or more crypto-asset services to clients on a professional basis, and that is allowed to provide crypto-asset services in accordance with Article 59. The same Regulation lists the services in Article 3(1), point (16). They are custody and administration of crypto-assets on behalf of clients, operation of a trading platform, exchange of crypto-assets for funds, exchange for other crypto-assets, execution of orders on behalf of clients, placing, reception and transmission of orders, advice, portfolio management, and providing transfer services for crypto-assets on behalf of clients.

The anti-money laundering regulation takes the same definition. It defines a crypto-asset service provider by reference to Article 3(1), point (15), of MiCA where the entity performs one or more crypto-asset services, and it excludes only the service of providing advice from the services that count.

Article 59 sets the rule of access to the market. A person shall not provide crypto-asset services within the Union unless authorised as a provider in accordance with Article 63 or allowed to do so under Article 60, which covers entities such as credit institutions, investment firms and electronic money institutions. Authorised providers must have a registered office in a Member State where they carry out at least part of their services, their place of effective management in the Union, and at least one director resident in the Union. An authorisation is granted for the services it names, and it allows services throughout the Union.

The authorisations are listed in a central register. The European Securities and Markets Authority explains that Articles 109 and 110 of MiCA empower it to publish a register of white papers, authorised crypto-asset service providers and non-compliant entities. It publishes an interim register as a set of five files and states that it will publish the latest version at weekly intervals. For a counterparty check, that register is where a provider can look up whether another provider is authorised.

What the licence application says about financial crime controls

The application for authorisation is not a customer due diligence document, but it fixes the standard that supervisors will later hold the provider to. Article 62(2) lists the information that the application must contain, and point (i) reads as follows.

a description of the applicant crypto-asset service provider's internal control mechanisms, policies and procedures to identify, assess and manage risks, including money laundering and terrorist financing risks, and business continuity plan;

The same list asks for proof that the members of the management body are of sufficiently good repute, the identity of shareholders with qualifying holdings, and, for providers that intend to offer transfer services, information on the manner in which such transfer services will be provided.

When the supervisor assesses the application, Article 63(6) allows it to consult the authorities responsible for anti-money laundering and the financial intelligence units, to verify that the applicant has not been the subject of an investigation into conduct relating to money laundering or terrorist financing. Article 63(10) obliges the supervisor to refuse authorisation where there are objective and demonstrable grounds that the management body exposes the applicant to a serious risk of money laundering or terrorist financing. The decision period is 40 working days from a complete application.

Article 64(1), point (f), requires the supervisor to withdraw an authorisation where the provider fails to have in place effective systems, procedures and arrangements to detect and prevent money laundering and terrorist financing in accordance with Directive (EU) 2015/849. Article 68(8) requires providers to have effective procedures and arrangements for risk assessment, to comply with the provisions of national law transposing that Directive, and to evaluate on a regular basis the adequacy and effectiveness of those mechanisms. Article 68(9) adds that records of all crypto-asset services, activities, orders and transactions are to be kept for five years and, where the competent authority requests it before five years have elapsed, for up to seven years.

Customer due diligence for crypto-asset service providers

The Anti-Money Laundering Regulation sets the duty to apply customer due diligence in Article 19(1). Obliged entities apply it when establishing a business relationship, when carrying out an occasional transaction of at least the stated value, when there is a suspicion of money laundering or terrorist financing, and when there are doubts about the veracity or adequacy of previously obtained customer identification data. It also applies when there are doubts as to whether the person they interact with is the customer or a person authorised to act on the customer's behalf.

For crypto-asset service providers, Article 19(3) replaces the general value threshold for occasional transactions.

By way of derogation from paragraph 1, point (b), crypto-asset service providers shall: (a) apply customer due diligence measures when carrying out an occasional transaction that amounts to a value of at least EUR 1 000, or the equivalent in national currency, whether the transaction is carried out in a single operation or through linked transactions; (b) apply at least customer due diligence measures referred to in Article 20(1), point (a), when carrying out an occasional transaction where the value is below EUR 1 000, or the equivalent in national currency, whether the transaction is carried out in a single operation or through linked transactions.

Two points follow from the wording. Below EUR 1 000 the provider still identifies and verifies the customer's identity, because Article 20(1), point (a), is the measure of identifying the customer and verifying the customer's identity. At or above that value, the full set of measures applies, and linked transactions count together.

Article 20(1) lists the measures. Besides identifying and verifying the customer, they include identifying the beneficial owners and taking reasonable measures to verify their identity, assessing the purpose and intended nature of the business relationship, verifying whether the customer or the beneficial owners are subject to targeted financial sanctions, and assessing the nature of the customer's business. Article 20(2) says that the extent of the measures is set on the basis of an individual analysis of the risks, and Article 20(4) says that obliged entities shall at all times be able to demonstrate to their supervisors that the measures taken are appropriate in view of the risks identified.

Article 22(1) sets the minimum information to identify the customer, any person purporting to act for the customer, and the natural persons for whom a transaction or activity is conducted. It does so with the exception of cases of lower risk to which the simplified measures apply, and irrespective of additional measures in cases of higher risk. For a natural person the list is: all names and surnames, place and full date of birth, nationalities or, where applicable, statelessness and refugee or subsidiary protection status, the national identification number where applicable, and the usual place of residence. Only if there is no fixed residential address with legitimate residence in the Union does the postal address at which the person can be reached take the place of the residence, and the tax identification number is added where available. Article 22(6) gives two routes of verification, the submission of an identity document with, where relevant, information from reliable and independent sources, or the use of electronic identification means at the assurance levels "substantial" or "high" under Regulation (EU) No 910/2014 and relevant qualified trust services as set out in that Regulation. Remote verification under these provisions is described in a separate article on the EU AML Regulation and remote customer identification.

Timing is set by Article 23(1). Verification of the identity of the customer and of the beneficial owner shall take place before the establishment of a business relationship or the carrying out of an occasional transaction, with a limited allowance for lower-risk situations. Article 21(1) states what follows when the provider cannot complete the measures: it shall refrain from carrying out a transaction or establishing a business relationship, and shall terminate the business relationship and consider reporting a suspicious transaction to the financial intelligence unit. Article 21(3) requires the provider to keep a record of the actions taken, including the decisions and the supporting documents and justifications, and the duty also covers cases where the provider refuses to enter into a business relationship.

A prohibition that shapes product design

Article 79(1) prohibits crypto-asset service providers from keeping anonymous crypto-asset accounts and any account otherwise allowing for the anonymisation of the customer account holder, or the anonymisation or increased obfuscation of transactions, including through anonymity-enhancing coins. The recital explains the reasoning: anonymous crypto-asset accounts do not allow the traceability of crypto-asset transfers and make it difficult to apply an adequate level of customer due diligence. The prohibition does not apply to providers of hardware and software or to providers of self-hosted wallets, insofar as they do not possess access to or control over those wallets.

What travels with a transfer

Regulation (EU) 2023/1113 lays down rules on the information on originators and beneficiaries accompanying transfers of crypto-assets, for the purposes of preventing, detecting and investigating money laundering and terrorist financing. It applies to transfers where the crypto-asset service provider of either the originator or the beneficiary, or an intermediary, has its registered office in the Union. It does not apply where both the originator and the beneficiary are providers acting on their own behalf, nor to a person-to-person transfer carried out without the involvement of a provider.

The Regulation defines the parties precisely. The originator is a person that holds a crypto-asset account with a provider, a distributed ledger address or a device allowing the storage of crypto-assets, and allows a transfer from it, or a person that orders or initiates a transfer. The beneficiary is the intended recipient of the transfer. An intermediary provider is a provider that is not the provider of the originator or of the beneficiary and that receives and transmits a transfer on behalf of one of them or of another intermediary. A self-hosted address is a distributed ledger address not linked to a crypto-asset service provider or to a non-Union entity providing similar services.

Article 14(1) lists the information on the originator that the provider of the originator shall ensure accompanies each transfer.

(a) the name of the originator; (b) the originator's distributed ledger address, in cases where a transfer of crypto-assets is registered on a network using DLT or similar technology, and the crypto-asset account number of the originator, where such an account exists and is used to process the transaction; (c) the originator's crypto-asset account number, in cases where a transfer of crypto-assets is not registered on a network using DLT or similar technology; (d) the originator's address, including the name of the country, official personal document number and customer identification number, or, alternatively, the originator's date and place of birth; and (e) subject to the existence of the necessary field in the relevant message format, and where provided by the originator to its crypto-asset service provider, the current LEI or, in its absence, any other available equivalent official identifier of the originator.

Article 14(2) lists the information on the beneficiary: the name, the distributed ledger address and the account number where they exist, and, under the same condition as for the originator, the legal entity identifier or an equivalent official identifier. Notice what the list contains. Two of the five items on the originator come from the customer file that the provider built during identification: the name, and the item that combines the address with the official personal document number and the customer identification number, or the date and place of birth. The sending provider therefore needs verified identity attributes in a structured form, not an image of a document.

Two further rules shape the workflow.

The information referred to in paragraphs 1 and 2 shall be submitted in advance of, or simultaneously or concurrently with, the transfer of crypto-assets and in a secure manner and in accordance with Regulation (EU) 2016/679.

The Regulation adds that the information shall not be required to be attached directly to, or be included in, the transfer of crypto-assets. Paragraph 6 requires the provider of the originator to verify the accuracy of the information on the originator before transferring, on the basis of documents, data or information obtained from a reliable and independent source. Paragraph 7 deems that verification to have taken place where the identity of the originator has been verified under Article 13 of Directive (EU) 2015/849 and the information obtained has been retained under Article 40 of that Directive. Paragraph 8 ends the sequence with a hard stop: the provider of the originator shall not allow for the initiation, or execute any transfer, of crypto-assets before ensuring full compliance with the Article.

The receiving side and intermediaries

The provider of the beneficiary has a verification duty of its own. Article 16(3) requires it to verify the accuracy of the information on the beneficiary before making the crypto-assets available to the beneficiary. Article 16(1) requires effective procedures to detect whether the information on the originator and the beneficiary is included in, or follows, the transfer.

Article 17 handles the case where information is missing or incomplete.

The crypto-asset service provider of the beneficiary shall implement effective risk-based procedures, including procedures based on the risk-sensitive basis referred to in Article 13 of Directive (EU) 2015/849, for determining whether to execute, reject, return or suspend a transfer of crypto-assets lacking the required complete information on the originator and the beneficiary and for taking the appropriate follow-up action.

Where the provider of the beneficiary becomes aware that the information is missing or incomplete, it shall, on a risk-sensitive basis and without undue delay, reject the transfer or return the transferred crypto-assets to the originator's account, or request the required information before making the crypto-assets available to the beneficiary. Where another provider repeatedly fails to supply the information, the receiving provider takes steps that may begin with warnings and deadlines and may end with rejection of future transfers or the restriction or termination of the business relationship, and it reports the failure to the competent authority. Article 18 adds that missing or incomplete information is a factor when the provider assesses whether a transfer is suspicious and whether it must be reported to the financial intelligence unit.

Intermediary providers have parallel duties in Articles 19 to 22. They must ensure that all the information received on the originator and the beneficiary is transmitted with the transfer, that records are retained and made available on request to the competent authorities, and that effective risk-based procedures exist for executing, rejecting, returning or suspending a transfer that lacks the required information.

Self-hosted addresses

A transfer to or from a self-hosted address has no second provider to receive the data, so the Regulation puts the duty on the provider that is involved. Article 14(5) requires the provider of the originator, for a transfer made to a self-hosted address, to obtain and hold the information referred to in Article 14(1) and (2) and to ensure that the transfer can be individually identified. Article 16(2) applies the same duty to the provider of the beneficiary for a transfer made from a self-hosted address.

For larger amounts a further step applies.

in the case of a transfer of an amount exceeding EUR 1 000 to a self-hosted address, the crypto-asset service provider of the originator shall take adequate measures to assess whether that address is owned or controlled by the originator.

Article 16(2) contains the matching sentence for transfers from a self-hosted address above the same amount. The Anti-Money Laundering Regulation adds a general duty in Article 40. Providers shall identify and assess the risk of money laundering and terrorist financing associated with transfers to or from a self-hosted address, and shall apply mitigating measures commensurate with the risks identified. The listed measures include taking risk-based measures to identify and verify the identity of the originator or beneficiary of a transfer made from or to a self-hosted address, and requiring additional information on the origin and destination of the crypto-assets.

The EBA guidelines say how a provider can show ownership. Paragraph 83 says that providers should use at least one of five verification methods. They are an unattended verification as specified in the EBA guidelines on remote customer onboarding solutions that displays the address, an attended verification as specified in the same guidelines, the sending of a predefined amount from and to the self-hosted address to the provider's account, a request that the customer digitally sign a specific message with the key corresponding to that address, and other suitable technical means as long as they allow for reliable and secure assessment. The choice of method should depend on the technical capabilities of the address, the robustness of the assessment each method can deliver, and the money laundering and terrorist financing risk. Where one method on its own is not sufficiently reliable, the provider should use a combination of methods.

Two details of the guidelines are useful to an engineering team. The provider determines whether a transfer reaches the threshold of EUR 1 000 using the exchange rate of the crypto-asset at the time of the transfer, regardless of any transaction fees. Once the provider is fully satisfied that the address is owned or controlled by its customer, it should document this and may not need to re-apply the measures to later transfers from or to the same address, provided that it has controls to identify a change in the risk of the address or in its ownership, and removes the address from its list when such a change occurs.

The first method on that list connects identity verification to the wallet. An unattended verification of this kind displays the address within a remote onboarding session. The session record can then serve as evidence for the ownership assessment, provided that the session ties a verified person to the address displayed.

What the EBA travel rule guidelines add

The European Banking Authority issued the guidelines because the Regulation itself does not set out in detail what providers should do. The executive summary states that the Regulation mandates the EBA to issue guidelines on the steps providers should take to detect missing or incomplete information accompanying a transfer, and on the procedures for managing a transfer that lacks the required information. Competent authorities will refer to the guidelines when assessing whether the procedures of providers are adequate and effective.

Several paragraphs bear directly on the identity data. Paragraph 35 says that for natural persons the originator's provider should provide the full names and surnames of the customer as they appear in the customer's identity document or in the electronic identification, and for legal persons the name under which the entity is registered. Paragraph 36 says that the address of a natural person is the usual place of residence or, where there is no fixed residential address, the postal address at which the person can be reached. Paragraph 38 says that alternatives to postal addresses, including post office box numbers and virtual addresses, should not be considered to meet the requirement. Paragraph 39 adds that the choice between the alternative items, such as the document number or the date and place of birth, should not only be based on availability but also on the set of information that provides most clearly for an unambiguous identification of the payer or originator.

Paragraph 13 says that providers should ensure that their policies and procedures are effective and remain effective, for example by testing a random sample from all processed transfers. Paragraph 24 allowed a derogation until 31 July 2025 for crypto-asset providers whose infrastructures had technical limitations, provided that additional procedures included alternative mechanisms for collecting, holding and making available the information that could not be transmitted.

For equivalent identifiers to the legal entity identifier, paragraph 41 sets the conditions: a single identification code that is unique to the legal entity, published in public registries, issued upon entity formation by a public authority in the jurisdiction in which the legal entity is based, allowing for the identification of the name and address elements, and accompanied by a description of the type of identifier used in the messaging system.

Data protection and retention

The transfer regulation is explicit about personal data. Article 25(2) allows providers to process personal data on the basis of the Regulation only for the purposes of the prevention of money laundering and terrorist financing, and prohibits processing for commercial purposes. Article 25(3) requires providers to give new clients the information required by Article 13 of Regulation (EU) 2016/679 before establishing a business relationship or carrying out an occasional transaction.

Information on the payer and the payee or on the originator and beneficiary shall not be retained for longer than strictly necessary.

Article 26(1) sets the period for the records of crypto-asset service providers at five years. Article 26(2) requires the provider to ensure that the personal data is deleted when the period expires, unless national law provides otherwise, and a Member State may allow or require further retention only after a thorough assessment of necessity and proportionality, for a period that does not exceed five years. The Regulation thus fixes both a minimum for records and an obligation to delete, which a verification flow must support in practice.

The FATF standard behind the European texts

The FATF Recommendations define a virtual asset service provider as a natural or legal person, not covered elsewhere under the Recommendations, who as a business conducts activities for or on behalf of another person, including exchange between virtual assets and fiat currencies and exchange between forms of virtual assets. Recommendation 15 requires countries to ensure that virtual asset service providers are regulated for AML/CFT purposes and licensed or registered. The Interpretive Note to Recommendation 15 states that VASPs should be required to be licensed or registered at least in the jurisdiction where they are created.

The note then applies the preventive measures to VASPs with two qualifications.

R. 10 - The occasional transactions designated threshold above which VASPs are required to conduct CDD is USD/EUR 1 000.

The second qualification concerns the travel rule. Countries should ensure that originating VASPs obtain and hold required and accurate originator information and required beneficiary information on virtual asset transfers, submit it to the beneficiary VASP or financial institution immediately and securely, and make it available on request to appropriate authorities. Countries should ensure that beneficiary VASPs obtain and hold the required originator information and accurate beneficiary information and make it available on request.

Questions to put to your own design

  • Do you identify and verify every customer, including a customer whose occasional transactions stay below EUR 1 000, at least by identity?
  • Do you hold the originator's name, address or date and place of birth, document number and customer identification number as structured fields that can be sent with a transfer?
  • For a self-hosted address, which of the five methods in the EBA guidelines do you offer, and what record of the session do you keep as evidence?

Where this sits in a verification flow

A verification flow built on NeuroVision KYC places the identity part of the customer file in one session: document, selfie, liveness and face match, with the scenario assembled in an editor. The document step detects, classifies and reads IDs, including printed and handwritten text and the machine readable zone with its checksum. Document anti-fraud checks, covering screen photos, photocopies, printouts, glued photos, drawn-on elements, erasures, edited images and logical data errors, are included in every package. The liveness step is active: the person moves the face closer through two ovals. Retention in days is a setting of each scenario, and erasure endpoints and an erasure confirmation webhook are available. To see how these steps look in your own scenario, contact the team.

Sources

All sources were fetched on 27 October 2026.

Ready to talk?

Tell us what you are building and we will help you plan the integration.

Talk to us