Note |
---|
Please familiarize yourself with the Travel Rule here.
|
...
BUY - cash to crypto | |||
---|---|---|---|
Customer (Payer) inserts cash into the crypto-ATM machine and scans the destination wallet address. | |||
Scenario A | BUY - destination address is hosted | This is CASP to CASP transfer. CASP is required to send the Envelope to the 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. |
...
Version 20241001 - Delivered
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.
Releasing PDF support ahead of time gives operators time to customize their PDF wallets templates to better explain customers how to use them.
Version 20241101 - Delivered
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.
Version 20241201 - Delivered
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.
Version 20250101
Added support for scenario A using NotaBene travel rule provider.
Added Extensions API to add your own Travel Rule Provider implementation.
Version 20250201
Added support for scenario D,E,F using NotaBene travel rule provider.
Version 20250301
...
IMPORTANT note on version 20241201
The Travel Rule currently (version 20241201) requires that every BUY order must be sent to your customer via
A paper wallet, https://generalbytes.atlassian.net/wiki/spaces/ESD/pages/963281004/Terminal+Settings#Printing-Settings-(for-BATMs-with-attached-printers)
A PDF wallet (see: PDF Wallet Generation),
SMS,
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
...
.