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 clear on what data should be exchanged between the 'ordering' institution and the beneficiary institution.

Ordering VASP Travel Rule Requirements

The ordering institution must obtain and hold the following information:

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

(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. 

Self-hosted Wallets

Self-hosted wallets earn a separate section (section 179 and 180) in the updated guidance from the FATF. For one, self-hosted wallets are considered of higher risk in general. Also, when receiving a deposit from a self-hosted 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.