Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Version History

« Previous Version 8 Next »

Please familiarize yourself with the Travel Rule here.

Content

History

The EU Travel Rule regulation became effective in the EU on January 1, 2025. The regulation applies whether you are a MiCA regulated VASP - or not. The driving force behind this regulation was AML (anti-money laundering) efforts triggered by the war in Europe between Russia and Ukraine, and the fact that the adoption of cryptocurrency and related services will grow in the EU when the MiCA regulation becomes fully effective.

Overview

Implementation of the EU Travel Rule builds upon the following documents issued by EU regulators:

  1. Regulation (EU) 2023/1113 of the European Parliament and of the Council of 31 May 2023 on information accompanying transfers of funds and certain crypto-assets and amending Directive (EU) 2015/849 (Text with EEA relevance)

  2. Guidelines on information requirements in relation to transfers of funds and certain crypto-assets transfers under Regulation (EU) 2023/1113

Both of the following documents are in English for simplicity. If you prefer to read the regulation in another language, please use the links provided above.

Key concepts in EU regulation

  1. CASP

    1. CASP and VASP are interchangeable terms in the EU regulation.

    2. As a Cryptocurrency ATM Operator, you are a CASP.

  2. CASPs exchange information about the transaction parties by sending PIIs (Personally Identifiable Information, aka Envelopes) via the Travel Rule Provider networks.

  3. Where does the Travel Rule apply?

    1. The Travel Rule applies in any crypto-currency transfers where at least one of the parties is a CASP.

      1. An Exchange, e.g. Binance is a CASP, as is your Organization.

    2. The TR doesn’t apply to transfers from one self-hosted wallet to another self-hosted wallet.

  4. Proof of ownership for transactions with a value exceeding €1000 EUR.

    1. The CASP is required to obtain the proof of ownership/control from his customer - when the customer claims that he wants to send coins to a wallet that he has under his control.

      1. The requirement is unnecessary for smaller transactions.

  5. The CASP should use their available technical means to verify the customer claim (that their self-hosted wallets are not - in fact - hosted wallets). It is understood that such a check has technical limitations due to the anonymous nature of cryptocurrencies.

  6. The Envelope needs to be sent to the counterparty CASP before - or at the time of - the transfer. Not after.

  7. When the CASP is transferring cryptocurrency to a self- hosted wallet, the Envelope needs to be stored and archived by the CASP.

  8. Envelopes need to be retained in your archive for at least for 5 years.

  9. The CASP is allowed to remember the customer wallet type from previous transactions to avoid asking him whether he uses self-hosted or hosted wallet multiple times.

  10. VASPs outside of the EU should be considered as CASPs too.

  11. The EU plans to review its Travel Rule measures on self-hosted wallets in 2026.

Example Travel Rule Scenarios

BUY - cash to crypto

Customer (Payer) inserts cash into the crypto-ATM machine and scans the destination wallet address.
The ATM Operator (CASP) on behalf of the customer sends coins to a payee.

BUY

destination address:

Classification:

Example:

Scenario A

  • hosted

CASP to CASP transfer.

CASP is required to send the Envelope to the beneficiary’s CASP.

Customer inserts cash and wants his coins to go to his wallet on Binance exchange.

Scenario B

  • self-hosted and

  • amount < 1000 EUR

CASP to self-hosted wallet transfer.

CASP needs to perform best effort to confirm the address is not hosted.

Customer inserts 100 EUR in cash and wants his coins to go to his mobile Trust wallet that has private keys in his mobile phone.

Scenario C

  • self-hosted and

  • amount > 1000 EUR

CASP to self-hosted wallet transfer.

CASP needs to perform best effort to confirm the address is not hosted.

CASP should require proof of ownership/control over the wallet.

Customer inserts 1000 EUR in cash and wants his coins to go to his mobile wallet that has private keys in his mobile phone.

CASP will require him to provide cryptographic proof.

SELL - crypto to cash

Customer (Payee) selects amount he wants to withdraw on the ATM and prints a redeem ticket. Customer or somebody else sends coins to a wallet address on a redeem ticket that belongs to the BATM Operator (CASP).

SELL - originating address is

Classification

Example

Scenario D

  • hosted

CASP to CASP transfer.

CASP is required to receive PII from originating CASP.

Customer sends coins to you from his Binance account.

Scenario E

  • self-hosted, and

  • amount < 1000 EUR

Self-hosted wallet to CASP transfer.

CASP needs to perform best effort to confirm the address is unhosted.

Customer sends coins worth of 100 EUR from his mobile Trust wallet that has private keys in his mobile phone.

Scenario F

  • self-hosted and

  • amount > 1000 EUR

Self-hosted wallet to CASP transfer.

CASP needs to perform best effort to confirm the address is unhosted.

Customer inserts 1000 EUR in cash and wants his coins to go to his mobile wallet that has private keys in his mobile phone.

CASP will require him to provide cryptographic proof.

Practical Recommendations for Operators

  1. It is recommended to enforce that Payee and Payer are same person via terms and services.

    1. This lowers the risk that customer is sending coins to a scammer

    2. Additionally customer is not required to fill additional information about the Payee which can be time consuming and service usability barrier.

  2. It is recommended to force customers get issued PDF paper wallet at the ATM for transactions that have higher value than 1000 EUR.

    1. Currently most of the mobile and desktop wallets don’t have means to perform proof of ownership.

  3. Travel Rule Provider network is immature be ready for struggles.

    1. Travel Rule Providers connect multiple providers into their network. However these networks are not interconnected yet. It will take years for Travel Rule Providers to achieve interoperability.

    2. Expect that counterpart CASP will not receive your messages and you will not receive their.

  4. Be discover-able.

    1. Register yourself as CASP to multiple registers to be found by other CASPS

    2. Write your CASP id on customer receipts including country.

  5. Be ready for authorities to review whether you are archiving PIIs for 5 years

  6. Apply existing KYC measures to make sure that your customers are not avoiding Travel Rule restrictions by performing multiple cryptocurrency transfers bellow 1000 EUR.

EU Travel Rule implementation Roadmap in CAS

EU Travel Rule implementation is being delivered in multiple stages to the bitcoin ATM operators with focus on minimal effort.

  1. Version 20241001 - Delivered

    1. PDF paper wallet support has been added allowing operators to test drive a new vehicle how to send coins to customer self-hosted wallet with proof of ownership requirement satisfied.

    2. Releasing PDF support ahead of time gives operators time to customize their PDF wallets templates to better explain customers how to use them.

  2. Version 20241101 - Delivered

    1. Input Queues were introduced. Input queues allow operators to review or suspend incoming coin transfers. This is feature is essential tool for KYC review when PII from originator’s CASP hasn’t arrived yet.

  3. Version 20241201 - Delivered

    1. Added support for scenarios B and C. GB has concentrated on supporting and usability these scenarios first as it is expected that CASP to CASP Travel Rule providers will be facing significant interoperability and usability issues at the beginning of year 2025.

  4. Version 20250101

    1. Added support for scenario A using NotaBene travel rule provider.

    2. Added Extensions API to add your own Travel Rule Provider implementation.

  5. Version 20250201

    1. Added support for scenario D,E,F using NotaBene travel rule provider.

  6. Version 20250301

    1. Added support for GTR and SumSumb travel rule providers.

  • No labels