Today, I wanted to talk (again 😬) about the “Travel Rule” for blockchain transfers and what might be the first simplified implementation of it for a FInTech startup that’s getting very confused by various complex solution providers and consortia offerings. 

1. Scope – What is the “Travel Rule”?

FATF issued specific recommendations with respect to VASPs (Virtual Asset Service Providers), essentially stating that VASPs should be subject to AML obligations similar to financial institutions.

FATF recommendations do not directly apply to companies, FATF obliges its member countries to implement legislation (which may be more stringent but cannot be lighter) than FATF recommendations, but since most countries are FATF members (otherwise you have a different problem). So in addition to looking at FATF language, we must look at how FATF provisions are implemented into the national laws and aim to deploy rules that comply with both.

Here is what is required in general:

• VASPs must have an AML program in place and must identify their customers and perform KYC and transaction monitoring to detect illegal activities and report suspicious transactions.
• VASPs must collect certain information and make sure that this information is “accompanying funds transfers” under certain limits and conditions for both incoming and outgoing transfers. This is the so-called funds “Travel Rule”.
• VASPs must have measures in place to “pause”, “freeze” or otherwise make funds “not available” to the users or “not execute certain transactions” in cases where the user refuses to provide information or where there are other reasons to suspect crime and money laundering.

I would like to suggest that there is currently no majority consensus in the industry on how to implement these requirements, which is why it makes sense to plan the implementation in stages and see what happens. Regulators have not provided very specific guidelines or details. Therefore, we can assume that they are waiting for industry participants to generate ideas and solutions and test them and it is likely that each company must make its best efforts to implement what they see fit, but there won’t be harsh penalties for not having perfect solutions.

2. Summary of the Requirements in the EU and Singapore (as examples)

2.1. FATF Guidelines

VASPs must collect at least the following information:

• Originator’s (sender’s) name
• Sender’s account number (with your entity, not with others)
• Originator’s physical address/national id number/customer identification wallet date/place of birth
• Beneficiary’s name (does not have to be exact, can trust customer declaration)
• Beneficiary account number, where available and used in the transaction

This information must be transmitted immediately and securely, protecting the integrity and the availability of the information, between the VASPs, and facilitating the transfer, if the transaction exceeds 1,000 USD.

Customer screening is also necessary to comply with freezing orders and sanctions lists.

If the transfer is a transaction with self (e.g. top-up or withdrawal) or with a non-regulated institution, regulated VASPs must not transfer any information, but still have to have it with respect to their own customer.

2.2. EU: Transfers of funds must be accompanied by the following information on the payer/sender

(When a transaction or a series of linked transactions is normally defined as transactions between the same parties within 24 hours):

✅ FOR VASPs SERVICE PROVIDERS OF THE SENDERS:

• the name of the sender;
• sender’s account number (blockchain address or another unique number, which can be a unique transaction number or a unique customer number that’s assigned by the VASPs to all customers or transactions in a systematic way)
• sender’s address, official personal document number, customer identification number, or date and place of birth (essentially information allowing to uniquely identify the sender

✅ VASP or service provider of the SENDER/PAYOR must ensure that transfers of funds are accompanied by the following information on the payee/recipient

• name of the payee/recipient
• payee’s/recipient payment account number.

Before transferring funds, the VASP/PSP or service provider of the sender shall verify the accuracy of the information that must accompany the funds’ transfer on the basis of documents, data, or information obtained from a reliable and independent source (which could be a customer) ➝ we can interpret that in a way that the customer must be KYC-ed and we trust customer’s declarations for the info that’s not related to KYC (not related to POI and POA).

EEA exception (done for IBANs but can potentially be re-used for blockchain): Where all service providers involved in the payment chain are established in the Union, transfers of funds can be accompanied by at least the payment account number of both the payer and the payee or the unique transaction identifier (where there are no account numbers) and unless there are suspicious of money laundering. In other words, if customers send funds to or from regulated exchanges or custodians within the EU, we can potentially assign the number to the transaction (e.g. blockchain hash) and don’t technically need to implement funds transfer rules, but:

• If the service provider of the recipient wants to receive info about the customer that normally must accompany the transfer, the VASP or PSP of the sender must within 3 days provide the required information.

2.3. Singapore MAS Guidelines

Value Transfer (Travel Rule) – PSN02

The definition of “value transfer” refers to any transaction carried out on behalf of a value transfer originator through a financial institution with a view to making one or more digital payment tokens available to a beneficiary person at a beneficiary institution, irrespective of whether the originator and the beneficiary is the same person.

All crypto transactions (</= SGD 1,500) that are sent from the e.g. wallet or crypto exchange (i.e. withdrawals) would need the following information and this must be included in the payment instruction:

• the name of the sender;
• the sender’s account number (or unique transaction reference number where no account number exists);
• the name of the recipient and
• the recipient’s account number (or unique transaction reference number where no account number exists).

All crypto transactions (> SGD 1,500) that are sent from the e.g. wallet or exchange wallet would need the following information, in addition to the information above either DOB or residential address or identification number.

Note that by sending SGD 1,500 worth of crypto, the user needs to also be KYC-ed.

All crypto transactions that are received into a wallet from external wallets would require the following actions to be taken:

• when to execute, reject, or suspend a value transfer lacking required sender or recipient information; and
• the appropriate follow-up action i.e. to file a STR if necessary.

3. Simplified Ideas about Possible Implementation

3.1. Outgoing funds – your entity is the VASP/PSP of the sender

(and transaction or linked transactions defined as same parties within 24 hours or same day is above 1,000 USD/EUR):

• Users must be verified if they try to send over 1,000 EUR/USD (but let’s assume it’s already the case, otherwise they would not have this balance with you).
• Users are asked who is the beneficiary (is it themselves or someone else) and if is it a personal payment or payment for goods or services (no need to ask for the purpose, can be dropdown)
• Funds are sent (let’s assume here you have a way of detecting and blocking suspicious withdrawal requests or transfers to obviously dark web places)
• Email is also sent to the user with a link to an encrypted message and separately a key to decrypt with transaction details (amount, and all things required as per section 2.1.).

Essentially the idea here is that instead of figuring out a way how to connect to various exchanges and send them the info, you might give the user an encrypted message and a key that they can share with the service provider/exchange/custodian of the destination wallet.

3.2. Your entity is PSP/VASP of the recipient (e.g. deposits)

• You can publish an email address that will accept information on incoming transfers in a specific format and the list of info you need as per section 2.1. 
• You can also define and publish the format online on your help pages on how to send this information to you.
• You can request users who receive amounts above 1,000 EUR/USD to self-declare the nature of the incoming deposits using a few dropdown menus, for example, is it a transfer from another account that you own (where) or is it a transfer from a 3rd person (who is the sender and what is it for). You give people some time to respond and don’t make the funds available until they do.

Happy to hear your thoughts on this! 💭