Updated FATF Travel Rule Guidance: New Clarifications
In October 2021, the Financial Action Task Force (FATF) released an update to the Travel Rule guidance. This is a lengthy document that clarifies some aspects of the previously released guidelines.
The FATF is actually quite clear on what data should be exchanged between the 'ordering' institution and the beneficiary institution. (Note that nowadays, the FATF uses the term 'ordering' institution and the Travel Rule Protocol (TRP) specification uses 'originating'.)
Ordering VASP Travel Rule Requirements
The ordering institution must obtain and hold the following information:
| Information | Verified? |
|---|---|
| Originator name | yes |
| Originator account number | n/a |
| Originator address OR national identity number OR customer identification number OR date and place of birth | yes |
| Beneficiary name | no |
| Beneficiary account number | no |
(source page 53, bullet point 158)
It is essential to realise that the FATF lists these requirements on the originator information to identify them uniquely.
For the reason why there's a difference between verified and unverified data, one must look at the reasoning behind this soon-to-be legal requirement. When an auditor or financial crime investigator starts pulling a thread, not all data must be verified everywhere. That's because the auditor can go from a beneficiary VASP with unverified originator data to the ordering VASP and find the verification data on the originator there.
Beneficiary VASP Travel Rule Requirements
For the beneficiary VASP, the requirements are mirrored:
| Information | Verified? |
|---|---|
| Originator name | no |
| Originator account number | n/a |
| Originator address OR national identity number OR customer identification number OR date and place of birth | no |
| Beneficiary name | yes |
| Beneficiary account number | yes |
(source page 53, bullet point 159)
When the data is exchanged, the beneficiary VASP should also match the beneficiary's received information with its own records. It should be flagged when they don't (sufficiently) match the transaction.
Besides all these requirements, both VASPs need to run sanction checks on the, for them, unknown users. So the beneficiary VASP runs checks on the originator user, and the originating VASP runs checks on the beneficiary user.
Unhosted Wallets
Unhosted wallets (self-hosted wallets) earn a separate section (section 179 and 180) in the updated guidance from the FATF. For one, unhosted wallets are considered of higher risk in general. Also, when receiving a deposit from an unhosted wallet, a VASP must gather the same data as in a VASP-to-VASP transaction. That means that the VASP needs to obtain the originator information, but that data can be unverified. The beneficiary data should again be acquired from the originator, which would be the unhosted wallet system in the mentioned case of a VASP that receives a deposit.
Travel Rule Protocol (TRP)
So how does the Travel Rule Protocol (TRP) fare against these requirements? TRP is first and foremost a protocol for exchanging information. That means that sanction checking or the duty of the beneficiary VASP to match the received beneficiary data against its records is out of scope. That is in the spirit of the protocol, as it doesn't force or presume how a business is run. Unhosted wallets can also not be addressed in TRP as there is no counterparty to talk to. (We've built a solution for this challenge called Address Ownership Proof Protocol, or AOPP for short.)
The remaining requirements are solidly covered with TRP. All the FATF mandated elements are present in the Travel Rule Protocol.
TRP as a standard provides a straightforward and extensible (as you can learn more here) way to comply with the Travel Rule. It also enables your company to exchange Travel Rule information with your counterparty VASP, leveraging excellent user experience and flexibility for your VASP to customise.
However, the biggest challenge the FATF introduces with its Recommendation 16 (the so-called Travel Rule) is discoverability: the ability of companies to know which VASP is responsible for the beneficiary address and how to communicate to it in an automated, timely manner. In this sense, TRP differentiates for being decentralised and facilitating the counterparty's identification via its Travel Address.
We believe TRP is a strong candidate to be the market standard, but that doesn't mean we will not have you covered when transacting with VASPs that do not support it. That is why our software also supports any relevant protocols to guarantee you can communicate the needed information with your counterparty.
