Travel rule specification
by Jan Smit, Angus Brown, James Belding on 08 January 2021
Expiry date
Applies to
Standard Stage
In Consideration Draft Internal Review Public Review Published Recommended
Thanks for submiting your comments!
The Travel rule specification in a nutshell

Since 1996, the FATF (Financial Action Task Force) has required banks to send information about the originators and beneficiaries of cross-border financial transfers of over 1,000 USD/EUR along with each transaction. Known as the ‘travel rule’, the objective was to promote greater transparency and controls on money laundering or terrorist financing in cross-border transactions. Luckily for the traditional financial system, they already had protocols like SWIFT in place which made it relatively easy to implement the travel rule. Butwhen the FATF extended the travel rule requirement to all global Virtual Asset Service Providers (VASPs) in June 2019, many feathers were ruffled. Though FATF recommendations are only required to be implemented by member jurisdictions, the change meant that in practical terms digital asset companies – exchanges and custodians – were now in the same position as traditional financial institutions when it comes to FATF obligations. In a bid to secure their own standing with regulators, major exchanges may demand non-custodial wallets to fall in line or be excluded from the ecosystem. To support them, the Travel Rule Working Group is creating a travel rule Standardised Format for BSV.

Read more

TS 2020.012-20

Travel rule specification

ProposersJan Smit, Angus Brown, James Belding
TSC SponsorAngus Brown
AuthorAngus Brown
ReviewersBernhard Müller, Daniel Connolly, Delphine Forma, Marcin Zarakowski, Neil Samtani, Sam Azad


a. Industry need

Original Travel Rule

In May 1996 the US FinCEN introduced the “Travel Rule” requiring all financial institutions to send the originator and beneficiary information along with each transfer over $ 3,000.- . Hence the name “Travel Rule”. The objective is to enable AML / CFT and sanctions screening across jurisdictions. The rule required financial institutions to store this information for five years.

FATF Recommendation 16

In June 2019 the G7’s Financial Action Task Force (FATF) extended the Travel Rule requirements with Recommendation 16 (R16), full name “Virtual Assets and Virtual Asset Service Providers – Guidance for a risk-based approach”, to all global Virtual Asset Service Providers (VASPs).

Art 33c of R16 defines that all wallets providing virtual asset transfer services are regarded as VASPs (“obliged entities”). The provision of custodial (“hosted”) services is an additional but not a necessary reason to qualify as a VASP:

FATF defines “Virtual asset service provider” as any natural or legal person who is not covered elsewhere under the Recommendations and as a business conducts one or more of the following activities or operations for or on behalf of another natural or legal person:

  1. Exchange between virtual assets and fiat currencies;
  2. Exchange between one or more forms of virtual assets;
  3. Transfer of virtual assets;
  4. Safekeeping and/or administration of virtual assets or instruments enabling control over virtual assets;
  5. Participation in and provision of financial services related to an issuer’s offer and/or sale of a virtual asset.“

FATF clarified the scope of R16 in the October 2020 amendment:

Countries may adopt a de minimis threshold for cross-border wire transfers (no higher than USD/EUR 1,000), below which the following requirements should apply:

  1. Countries should ensure that financial institutions include with such transfers:
    • the name of the originator;
    • the name of the beneficiary; and
    • an account number for each, or a unique transaction reference number.

Such information need not be verified for accuracy, unless there is a suspicion of money laundering or terrorist financing, in which case, the financial institution should verify the information pertaining to its customer.

  1. Countries may, nevertheless, require that incoming cross-border wire transfers below the threshold contain required and accurate originator information.

Art 16 of R16 further notes that “Countries should not necessarily categorize VASPs or VA activities as inherently high ML/TF risks.”

US threshold

FinCEN has announced on 23 Oct 2020 that the US Bank Secrecy Act applies to crypto assets, and the threshold will move to $250 for international transactions.

Implementation deadlines

The implementation deadlines are set by the related jurisdictions. For example US FinCen director Kenneth Blanco says R16 is actually already in effect (via the existing Bank Secrecy Act). Canada is expected to implement in 2021. The EU has not put forward a deadline as yet. R16 is said to be in force in Switzerland as well.

Final remarks

The primary purpose of this specification is to define a standardised protocol for VASPs on the BitcoinSV blockchain to collect and exchange the information required by the Travel Rule.

While the Travel Rule sounds similar to Know Your Customer (KYC), it does have a few key differences. The first is that during KYC, the data collected is only used by the organization that collects it. With the Travel Rule, that certain KYC information needs to be shared between VASPs. Secondly, KYC is an internal process while the Travel Rule is a process between entities. Thirdly, Travel Rule is a once-off obligation (at time of sending), whereas KYC / AML is an ongoing activity for the duration of the service to customer. wrote an excellent introduction on the Travel Rule as well.

b. Problem statement

To comply with the Travel Rule a joint working group of three global standard setting bodies in the crypto industry presented in May 2020 the “interVASP Messaging Standard – IVMS101”. This standard details the data formats and minimal requirements for the data which VASPs need to share (and review) prior to completing a transaction. It does not specify how this data should be communicated / messaged between VASPs. Furthermore the IVMS101 data model is yet to be ratified by the three global standard setting bodies.

The parties affected by R16 are not only VASPs but also outsourced Identity Services (“IS”) which may (i) provide and attest to user data based on KYC/KYB processes and (ii) perform checks of the entities involved on sanction lists.

To comply with the Travel Rule and IVMS101 standard the following is required:

  1. Data formatting standards for VASPs to exchange the relevant data
  2. Messaging flow standards to securely exchange this data
    • VASP to VASP
    • IS to VASP

c. Scope of the problem

Based on the above transactions can be split into:

  • Send from or Received by a Public key address: Typical use case is sending tokens to or from exchanges.
  • Send from and received by a Paymail address: This includes the following two subtypes:

Out of scope

  • As each jurisdiction has different specific requirements for compliance, it may be out of scope as to whether the specific information provided / shared is sufficient for full compliance. An example is that FAFT does not always require the full address of the beneficiary (and for example SWIFT messages only carry the full address of the originator, not the beneficiary), but US Bank Secrecy Act requires addresses of both parties. Each VASP must determine which regulations it must comply with (i.e. if there is a US nexus, the US Bank Secrecy Act may apply).
  • Send from or Received by a Public key address: VASPs to decide individually which exchange-protocols to adopt. Longer term exchanges may adopt BIP270 as well.
  • Paymail based transactions initiated by originator: As Travel Rule data needs to be shared and reviewed before committing to a transfer (non-custodial VASPs using mnemonics and known derivation paths usually can’t freeze funds) the current flow of P2P Transactions (=Originator initiated process) needs to be extended and preceded by additional steps / handshakes (this does not necessarily affect the UX). The current BIP270 (=Beneficiary initiated process) however does already contain the required handshakes leading up to the transfer of funds.
  • Non-protocol tokens: The Travel Rule also applies when tokens (e.g. stable coins or securities) with a value in excess of $ 1,000.- are transferred (note that in such cases the token issuer is potentially an “IntermediaryVASP”).
  • Alternative use cases: The Travel Rule data may be useful in other (non-Travel Rule) use cases. For example:
    • Sharing KYC/KYB details for use on (BIP 270) invoices
    • Onboarding in financial Apps (e.g. exchanges)
    • Onboarding in any other App (e.g. over 18 flag)
  • Validation / Attestation: VASPs and Apps using the Travel Data may want it to be validated / attested by a trusted party before using it.
  • Standards for on-chain storage of Travel Data: Storing privacy sensitive data (encrypted) on-chain may have onerous legal implications and may not be preferred by users. Therefore this standard does not mandate where the records are stored. The data structures should be stored by the VASP in a compliant way.

In scope

  • Data formatting standards: Defining the natural and legal person JSONs as per the IVMS101 standard par 5.2.1.. These 2 JSONs can describe all 4 or 5 parties involved:
    • Originator and OriginatingVASP
    • Beneficiary and BeneficiaryVASP
    • IntermediaryVASP (e.g. in case of central token issuer)
  • Messaging flow standards:
    • BIP270 Travel Rule enhancement
    • Identity Service – VASP Communication

d. Benefits of the standard (and to whom they apply)

  • A single Travel Rule standard:
    • Is more economical for VASPs to implement
      • Minimise interfaces which VASPs need to implement
      • Reduce regulatory risks
    • Makes it easier for non-VASP Apps to build on these standards (i.e. innovate)

e. Specific deliverables

See In-Scope section above. Note that JSON data structures are chosen as these are becoming the standard for relaying data. They are more verbose than certain alternatives (e.g. W3C’s URN ) but the additional storage cost of JSONs (especially if stored on-chain) is viewed as minimal.

Comments are closed

This Standard is at the internal review stage and comments are closed.

Become a Contributor
If you wish to join us on this mission to make BSV the public blockchain of choice please fill in our preliminary registration form below. We look forward to having you on board.