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 Page History

« Previous Version 6 Next »

If you haven’t read article on Travel Rule please do so before continuing further as you may need to get familiar with some abbreviations and basic concepts of Travel Rule first.

History

EU Travel Rule regulation became effective in EU on 1.1.2025. Regulation is independent from the fact whether you are MiCA regulated VASP or not. Main driver behind this regulation was anti-money laundering efforts during the war time in Europe between Russia and Ukraine and the fact that adoption of cryptocurrency and cryptocurrency services in EU will grow when MiCA regulation becomes effective.

Overview

CAS implementation of EU Travel Rule builds on following documents issued by EU ragulators:

  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 documents are for simplicity in English language posted bellow. If you prefer to read regulation in another language please use the links above.

Key concepts in EU regulation

  1. CASP

    1. CASP is a VASP in EU language.

    2. You are as a Cryptocurrency ATM operator a CASP.

  2. Where Travel Rule applies

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

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

  3. Proof of ownership for transactions with value above 1000 EUR.

    1. CASP is required to obtain proof of ownership/control from his customer when customer claims that he wants to send coins to a wallet that he has under the control. Such requirement is not needed for lower transactions.

  4. CASP should use available technical means to check that customer claimed self-hosted wallets are not in fact hosted wallets. It is understood that such check has technical limitations due to anonymous nature of crypto-currencies.

  5. PII needs to be sent to counter party CASP before or at the time of the transfer. Not after.

  6. When CASP is transferring cryptocurrency to a self- hosted wallet PII needs to be stored and archived by CASP.

  7. PIIs need to be archived at least for 5 years.

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

  9. Cryptographic proof

Individual ATM scenarios where TR applies

BUY - cash to crypto

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

Scenario A

BUY - destination address is hosted

This is CASP to CASP transfer. CASP is required to send PII to beneficiary’s CASP.

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

Scenario B

BUY - destination address is a self-hosted and amount is < 1000 EUR

This is CASP to un-hosted wallet transfer. CASP needs to perform best effort to check whether the address is not hosted.

Example: 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

BUY - destination address is a self-hosted and amount is > 1000 EUR

This is CASP to self-hosted wallet transfer. CASP needs to perform best effort to check whether the address is not hosted.

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

Example: 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 ATM Operator (CASP).

Scenario D

SELL - originating address is hosted

This is CASP to CASP transfer. CASP is required to receive PII from originating CASP.

Example: Customer sends coins to from his on Binance exchange account.

Scenario E

SELL - originating address is a self-hosted and amount is < 1000 EUR

This is un-hosted wallet to CASP transfer. CASP needs to perform best effort to check whether the address is not hosted.

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

Scenario F

SELL - originating address is a self-hosted and amount is > 1000 EUR

This is self-hosted wallet to CASP transfer. CASP needs to perform best effort to check whether the address is not hosted.

Example: 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.

CAS Components

CAS implements EU Travel Rule by following components.

image-20241212-155224.png

Outgoing Transfers

View the individual transfers (Envelopes/PIIs)

image-20241212-155149.png

Travel Rule Settings

Configure your Travel Rule settings.

image-20241212-155127.png

Travel Rule Providers

Add or adjust a Travel Rule Provider.

  • You may be your own Travel Rule Provider (“internal”), or you can facilitate with an external provider.

  • We will begin adding additional providers in 2025.

image-20241212-155057.png

VASPs

Add or adjust a VASP setting

image-20241211-155845.png

IMPORTANT

The Travel Rule currently requires that every BUY order must be sent to your customer via

  1. a paper wallet, https://generalbytes.atlassian.net/wiki/spaces/ESD/pages/963281004/Terminal+Settings#Printing-Settings-(for-BATMs-with-attached-printers)

  2. a PDF wallet (see: PDF Wallet Generation),

  3. SMS,

  4. or Email.

There is currently no way (using the TR) to send coin to any other type of wallet!

  • It is impossible to technically identify the owner of the customer-presented wallet, so

  • therefore those wallets do not comply with Travel Rule requirements.

What is this?

This feature enables you to comply with your regional Travel Rule legal requirements, and enables compliant transactions for your customers.

Example

This example enables immediate self-hosted compliance for your Organization.

  1. Create a Travel Rule Provider: “Internal”, see: Travel Rule Providers

  2. Create a new VASP, see: Travel Rule VASPs

  3. Add a new Setting, see: Travel Rule Settings

  4. Configure your AML/KYC setting to use the new Travel Rule, see: https://generalbytes.atlassian.net/l/cp/U57zcH33

  5. Configure your Terminal(s) to use the proper AML/KYC setting, see: https://generalbytes.atlassian.net/wiki/spaces/ESD/pages/963281004/Terminal+Settings#General-Settings

Any transaction that has been packaged via a Travel Rule can be viewed from the Transaction Log:

image-20241206-122806.png

An example Transfer/Envelope:

image-20241206-122403.png
  • No labels

Copyright © 2020-2024 General Bytes USA LLC