MiCA’s Travel Rule Explained

Introduction

Travel Rule Requirements Under MiCA

1. Information Collection (TFR: Article 14(1) and (2)):
1. Originator: name, crypto-asset account number or distributed ledger address, address (including country), official personal document number, customer ID number (or date and place of birth), and LEI (if available).
2. Beneficiary: name, crypto-asset account number or distributed ledger address, and LEI or, in its absence, any other available equivalent official identifier of the beneficiary.

2. Verification (TFR: Article 14(6) and Article 16(3)):
1. The originator's CASP must verify the accuracy of the originator's information before initiating a transfer. This verification should be based on documents, data, or information from reliable and independent sources.
2. The beneficiary's CASP must verify the beneficiary's information before making the crypto-assets available. This is to ensure the integrity of the information throughout the transfer chain.

3. Transfer of Information (TFR: Article 14(4)):
1. All required information must accompany the transfer of crypto-assets.
2. The information should be submitted securely, either in advance of the transfer, simultaneously with it, or concurrently.
3. The information doesn't need to be attached directly to the transfer itself, but it must be readily available to appropriate authorities upon request.

4. Risk-Based Procedures (TFR: Article 16(1) and 17(1); EBA Guidelines: Section 4.5 and 4.6):
1. CASPs must implement effective procedures to detect transfers with missing or incomplete information.
2. They need to establish risk-based procedures to determine whether to execute, reject, return, or suspend such transfers.
3. These procedures should include monitoring during and after transfers, and should be commensurate with the level of ML/TF risk associated with the transfer.

5. Self-Hosted Wallets (TFR: Article 14(5) and 16(2)):
1. For all transfers involving self-hosted wallets, CASPs must obtain and hold the required information on both the originator and the beneficiary.
2. For transfers exceeding €1,000 to or from a self-hosted address, CASPs must take adequate measures to assess whether the address is owned or controlled by their customer.
3. This may involve using blockchain analytics tools or other verification methods.

6. Record Keeping (TFR: Article 26(1)):
1. CASPs must retain all collected information for a period of five years.
2. After this period, personal data should be deleted unless national law provides otherwise.
3. Member states may allow or require further retention for up to an additional five years if necessary for preventing, detecting, or investigating money laundering or terrorist financing.

7. Compliance and Reporting (TFR: Article 23 and 18; EBA Guidelines: Section 4.7):
1. CASPs must implement internal policies, procedures, and controls to ensure compliance with the regulation.
2. They must report suspicious transactions to the relevant Financial Intelligence Unit (FIU).
3. This includes considering missing or incomplete information as a factor when assessing whether a transfer is suspicious.

8. Data Protection (TFR: Article 25):
1. All personal data processing must comply with the General Data Protection Regulation (GDPR).
2. CASPs must provide new clients with the information required under GDPR Article 13 before establishing a business relationship or carrying out an occasional transaction.
3. The processing of personal data under this regulation should be only for the purposes of preventing money laundering and terrorist financing.

9. No De Minimis Threshold (TFR: Recital 30):
1. There is no general de minimis threshold for crypto-asset transfers between CASPs. All such transfers, regardless of amount, are subject to the Travel Rule requirements.
2. For transfers involving self-hosted wallets (TFR: Article 14(5) and 16(2)):
1. Basic information collection is required for all transfers.
2. For transfers exceeding €1,000, CASPs must take additional steps to assess whether the self-hosted address is owned or controlled by their customer.

10. Batch Transfers (TFR: Article 15):

1. For batch transfers from a single originator, individual transfers within the batch don't need to include all the originator's information, provided that:
1. The batch file contains full information on the originator (as required in Article 14(1)).
2. Individual transfers carry the originator's distributed ledger address or crypto-asset account number.
3. The batch file contains full information on the beneficiary (as required in Article 14(2)).

2. The originator's CASP must verify the accuracy of the information in the batch file before transmission.

3. The information on the originator and beneficiary in the batch file must be fully traceable.

4. CASPs should ensure that batch transfers are not used to circumvent individual transfer requirements.

5. Intermediary CASPs (TFR: Article 19):

1. Ensuring all received information on the originator and beneficiary is retained with the transfer.

2. Implementing effective procedures to detect whether the required information is missing.

3. Establishing risk-based procedures for determining whether to execute, reject, or suspend a transfer lacking required information.

4. Taking appropriate follow-up action when they detect missing information.

5. Considering missing information as a factor when assessing whether a transfer is suspicious and should be reported to the Financial Intelligence Unit (FIU).

6. Retaining records of any information received for five years.

7. Handling Repeatedly Failing CASPs (TFR: Article 17(2); EBA Guidelines: Section 4.7.1):
1. CASPs should establish quantitative and qualitative criteria to determine when another CASP is "repeatedly failing." This might include:
1. The percentage of transfers with missing information from a specific CASP within a certain timeframe.
2. The percentage of follow-up requests left unanswered or inadequately answered.
3. The level of cooperation in previous requests for missing information.
2. When a CASP is identified as repeatedly failing, the receiving CASP should:
1. Take steps, which may include issuing warnings and setting deadlines for improvement.
2. If non-compliance continues, consider rejecting any future transfers from the failing CASP.
3. Consider restricting or terminating the business relationship with the failing CASP.
3. The CASP should report the repeatedly failing CASP to the competent authorities. This report should be made without undue delay and no later than three months after identifying the repeatedly failing CASP.
4. The report to authorities should include:
1. The name of the repeatedly failing CASP.
2. The country where it's authorized.
3. The nature of the breaches.
4. Details of the steps taken by the reporting CASP.
5. CASPs should consider how repeated failures affect the ML/TF risk associated with the failing CASP and adjust their risk assessment and due diligence measures accordingly.

8. Technical Requirements (EBA Guidelines: Section 4.3.1):
1. Implement robust, interoperable systems for error-free information transfers across multiple platforms.

9. Sanctions Screening (TFR: Article 23):
1. CASPs must have internal policies, procedures, and controls to ensure compliance with EU and national restrictive measures (sanctions).
2. These policies should cover how CASPs will implement restrictive measures when performing transfers of crypto-assets.
3. CASPs should include screening measures against EU and national lists of designated persons.
4. The EBA is required to issue guidelines by December 30, 2024, specifying these measures in more detail.

10. Transitional Period (EBA Guidelines: Section 4.3.1, paragraph 24):
1. CASPs have until July 31, 2025, to fully comply with the technical requirements.
2. During this period, CASPs may exceptionally use infrastructures or services where technical limitations regarding data completeness exist.
3. These limitations must be compensated by additional technical steps or fixes to fully comply with the Guidelines.
4. CASPs should implement alternative mechanisms for collecting, holding, and making available to the receiving CASP the information that cannot be transmitted due to technical limitations.
5. This transitional period applies to all technical-related provisions that CASPs will have to implement.

11. Risk Assessment for Third-Country Transfers (TFR: Recital 34):
1. When transferring crypto-assets to a CASP not registered in the EU, the originator's CASP must assess the ability of the beneficiary's CASP to receive and retain the required information in compliance with GDPR.
2. The European Data Protection Board, after consulting with the EBA, will issue guidelines on the practical implementation of data protection requirements for transfers of personal data to third countries in the context of crypto-asset transfers.
3. The EBA will issue guidelines on suitable procedures for determining whether to execute, reject, or suspend a transfer of crypto-assets in situations where compliance with data protection requirements for third-country transfers cannot be ensured.
4. CASPs should implement appropriate risk-mitigating measures, considering the potential higher risk of money laundering and terrorist financing posed by unregistered and unlicensed entities.
5. When establishing a new correspondent relationship with a respondent entity in a third country, crypto-asset service providers should apply specific enhanced due diligence measures to assess and mitigate risks.

12. Enhanced Due Diligence (EBA Guidelines: Section 4.5.3):
1. CASPs should apply enhanced due diligence measures for high-risk transfers, particularly those involving: a) Self-hosted addresses b) Entities not established in the EU c) Transfers from or to countries associated with higher ML/TF risk d) Transfers involving anonymity-enhancing techniques, products, or services
2. CASPs should assess the risk associated with transfers using all available information related to: a) Originators and beneficiaries b) Transaction patterns and geographies c) Information from regulators, law enforcement, and third parties
3. For high-risk transfers, CASPs should implement one or more of the following measures: a) Collecting additional information on the origin and destination of the crypto-assets b) Verifying the identity of the originator or beneficiary, or their beneficial owner c) Conducting enhanced ongoing monitoring of the business relationship d) Obtaining approval from senior management before executing the transfer
4. For transfers involving self-hosted addresses, CASPs should: a) Assess whether the information on the originator or beneficiary is accurate b) Monitor for unusual or suspicious patterns of transactions c) Implement enhanced due diligence measures where higher risks are identified
5. CASPs should document their risk assessment process and the enhanced due diligence measures applied to high-risk transfers

13. Ongoing Monitoring (EBA Guidelines: Section 4.5.3):
1. CASPs should implement effective monitoring practices both during and after transfers
2. These practices should be commensurate with the level of ML/TF risk to which the transfers are exposed
3. CASPs should determine which transfers will be monitored in real-time and which will be reviewed after the transfer based on a risk-sensitive assessment
4. Monitoring should take into account various risk factors, including but not limited to: a) The value of the transfer b) The country or geographic area of the originator, beneficiary, or their CASPs c) Previous instances of incomplete or missing information from specific CASPs d) Use of complex transaction structures or anonymity-enhancing techniques
5. Monitoring should aim to detect whether required information on the originator or beneficiary is missing or incomplete
6. CASPs should consider missing or incomplete information as a factor when assessing whether a transfer, or any related transaction, is suspicious
7. Ongoing monitoring should include screening against updated sanctions lists and other relevant risk databases
8. CASPs should monitor for unusual transaction patterns that might indicate ML/TF activities, such as: a) Multiple small transfers that appear to be linked b) Transfers involving high-risk jurisdictions c) Unusual patterns in the frequency or size of transfers

Self-Hosted Wallet Verification

1. According to Section 4.8.4 of the Guidelines, CASPs should use at least one of the following verification methods for transfers exceeding €1,000:
1. Unattended verifications: Using remote customer onboarding solutions that display the address.
2. Attended verification: Remote verification with employee interaction.
3. Satoshi Test: Sending a predefined amount (preferably the smallest denomination of a given crypto-asset) from the self-hosted address to the CASP's account.
4. Digital signature: Requesting the customer to digitally sign a specific message into the account and wallet software with the key corresponding to that address.
5. Other suitable technical means: As long as they allow for reliable and secure assessment and the CASP is fully satisfied that it knows who owns or controls the address.

2. The Guidelines state that the decision on which method(s) to choose should depend on:
1. The technical capabilities of the self-hosted address
2. The robustness of the assessment each method can deliver
3. The ML/TF risk

3. If one method alone is not sufficiently reliable to ascertain the ownership or controllership of a self-hosted address, the CASP should use a combination of methods.

4. If a CASP is fully satisfied that a self-hosted address is owned or controlled by its customer, it may 'whitelist' this address for subsequent transactions. However, the CASP should have controls in place to identify changes in the ML/TF risk of the self-hosted address and its ownership or controllership.

Challenges in Implementing the Travel Rule

1. The "Sunrise Issue"
1. Problem: Uneven implementation of the Travel Rule across jurisdictions with varying requirements.
2. Implications: Complex compliance landscape, problematic cross-jurisdiction transactions, potential market fragmentation.

2. Self-Hosted Wallet Verification
1. Problem: Technically challenging to verify ownership/control of self-hosted wallets for transfers over €1,000.
2. Implications: Need for reliable verification methods, potential exclusion of legitimate users, increased transaction complexity.

3. Handling Missing or Incomplete Information
1. Problem: Managing transactions with insufficient Travel Rule information.
2. Implications: Need for clear handling policies, potential increase in customer support issues, risk of facilitating non-compliant transactions.

4. User Experience Impact
1. Problem: Additional steps and potential delays in the transaction process due to compliance requirements.
2. Implications: Risk of user frustration, potential customer loss, need for user interface redesign and user education.

5. Handling High-Risk Transactions
1. Problem: Enhanced due diligence requirements for high-risk transactions add complexity.
2. Implications: Need for clear risk identification criteria, potential transaction delays, increased resource requirements for manual reviews.

6. Transfers to/from Unregistered or Unlicensed Entities
1. Problem: Additional risk-mitigating measures needed for transactions with unregistered entities.
2. Implications: New processes for identifying and handling such transactions, potential increases in due diligence requirements and delays.

7. Compliance with the Transitional Period
1. Problem: Managing the transition period until July 31, 2025, for full technical compliance.
2. Implications: Need for a phased implementation plan, potential confusion about applicable requirements during the transition.

8. Counterparty Due Diligence
1. Problem: Enhanced due diligence requirements for transactions with non-EU entities.
2. Implications: New processes for assessing and monitoring non-EU counterparties, potential delays or restrictions in international transactions.

9. Compliance-related Issues
1. Problems: Incorrect data collection/transfer, wrong communication chain, post-execution information sending, limited support for certain assets/amounts, difficulty retaining information or locating counterparty VASPs.
2. Implications: Need for robust data management and communication systems, potential transaction delays or rejections.

10. Manual Transaction Handling
1. Problem: Increased need for manual intervention in transactions.
2. Implications: Potential for blocked or delayed transactions, increased operational costs and time.

Key Considerations While Implementing Travel Rule

1. User Onboarding - Any additional information requirements for the current KYC process?

2. Transaction Flow
1. How to modify the transaction initiation process to include all required information?
2. How to display additional required information without compromising UX?
3. How to handle transactions with incomplete information?

3. Self-Hosted Wallets
1. What specific methods for verifying ownership/control of self-hosted wallets are compliant and be used in the existing journeys?
2. How to present additional verification steps for self-hosted wallet transfers?
3. How to store and manage information related to self-hosted wallet transfers?

4. Risk Assessment
1. What criteria should categorize transactions as high-risk?
2. How to present enhanced due diligence requirements for high-risk transactions?

5. Information Sharing
1. How to handle information requests from other CASPs post-transaction?

6. User Communication
1. How to inform users about new information requirements and their purpose?
2. How to explain Travel Rule implications for self-hosted wallet transfers?
3. How to communicate potential transaction delays without frustrating users?

7. Error Handling
1. How to handle scenarios with missing or incomplete information?
2. How to communicate transaction rejections or suspensions due to Travel Rule requirements?
3. How to design an efficient process for users to provide missing information?

8. Continuous Monitoring
1. How to implement ongoing monitoring of transactions for Travel Rule compliance?
2. What metrics should track the effectiveness of Travel Rule implementation?
3. How to design a system to flag and handle transactions with repeatedly non-compliant CASPs?

9. Cross-Border Transactions
1. How to handle transactions involving CASPs in jurisdictions with different or no Travel Rule implementation?
2. What additional steps are needed for transfers to/from non-EU countries?

10. Batch Transfers
1. How to modify the batch transfer process to comply with Travel Rule requirements?
2. How to present batch transfer information to users?

11. Privacy Considerations - What additional consent mechanisms are needed?

12. Regulatory Interpretation - How can "repeatedly failing" CASPs be interpreted as mentioned in the regulation?

13. Risk Assessment Criteria - What specific criteria should be used to categorize transactions as high-risk under the Travel Rule?

14. Sanction Screening - How to implement sanction screening for both the originator and the beneficiary in all transactions?

15. Sunrise Issue
1. How to handle transactions with CASPs in jurisdictions where the Travel Rule isn't implemented?
2. What's the legal stance on transactions where counterparties can't or won't provide the required information?

16. Compliance with the Transitional Period
1. How to plan the implementation of technical requirements in phases until the July 31, 2025, deadline?
2. What interim measures can be put in place during the transitional period?

Regulatory Resources

1. Information Accompanying Transfer of Funds and Certain Crypto-Assets (TFR)
1. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32023R1113

2. EBA Guidelines on information requirements in relation to transfers of funds and certain crypto-assets transfers under Regulation (EU) 2023/1113 (EBA Travel Rule Guideline)
1. https://www.eba.europa.eu/publications-and-media/press-releases/eba-issues-travel-rule-guidance-tackle-money-laundering-and-terrorist-financing-transfers-funds-and

Disclaimer