An attempt to demystify the Travel Rule challenges for Virtual Asset Service Providers using practical step-by-step examples
Author is COO of bitFlyer Europe, a global crypto exchange and regulated VASP.
The global crypto-sphere is buzzing about the recent guidelines by the Financial Action Task Force (FATF) regarding it’s new Risk-Based-Approach (RBA) for Virtual Asset Service Providers (VASPs).
The FATF, one of the fewer global intergovernmental organisations that actually has teeth, issued several recommendations in this guidance (June 2019), but the one that has VASPs (like crypto exchanges) and financial institutions squawking is the so-called Travel Rule which from June 2020 will apply to virtual assets.
While many commentators appear to be simply lamenting for the challenges ahead, I’ve noticed few are actually explaining why it will be a challenge. So in this post I will explain what the Travel Rule is, why its implementation has been a hot topic, an overview of potential solutions that are emerging, and some example actual practical implications for VASPs.
What is this ‘Travel Rule’?
To describe the Travel Rule in two words is, simply, Audit Trail. Governments want to be able to trace the flow of virtual assets through the global financial system. The thing is, you can’t have an audit trail of transactions if you only have one out of the originator (sender) information and the beneficiary (receiver) information. You need both to follow funds, otherwise you can’t form a sequence of events and lose accuracy of provenance after the first hop. The trouble is, for blockchain transactions like those on the bitcoin network, one technically only needs a wallet address to send a transaction. Currently, for crypto exchange VASPs like bitFlyer, when someone makes a bitcoin withdrawal we have verified information about the originator (because they undergo KYC to join our platform) but we can’t know for sure the identity of the beneficiary, although there are analytical tools we can use to get a pretty good idea of this.
Under the new FATF recommendations, it’s clear that a ‘pretty good idea’ will no longer cut it. The Travel Rule will require countries to ensure that when crypto-businesses send money between each other, the sender VASP must guarantee accuracy of the originator information and share with the receiver, while the receiver VASP must guarantee accuracy of the beneficiary information and share with the sender. This applies for every transaction over $1,000 or equivalent.
This requirement brings the obligations on virtual asset transactions closely in line with the obligations already imposed on the existing financial system for traditional fiat payments. In fact, many are calling this effectively a move to establish a ‘SWIFT’ network for VASPs.
The Problem
Now, the problem is that most VASPs operate substantially all of their operations on the Internet, which is not a closed system like the banking system or the SWIFT network. As a result, there is no implicit trust that any counterpart in a transaction is necessarily doing what it should be. Even after implementing the Travel Rule, both sides of a transaction will still have to verify for themselves that the other party is compliant; they can’t just assume for themselves.
So the question is, how do we effectively implement and verify the Travel Rule on the internet, which is inherently an insecure, untrusted network?
Answer: Not very easily.
(But a lot of smart people are working on it.)
Emerging Solutions
Right now several categories of solution are being proposed for the Travel Rule.
Some early ideas involved somehow writing this additional required transaction information to the blockchain transactions themselves (e.g. storing more data in the blocks of the bitcoin blockchain). This was a non-starter, because of scalability limitations and also privacy / GDPR concerns; You can’t safely store retrievable personal information on a public ledger.
The easiest way would be some kind of centralised database that collected all the personal information of VASP customers, cross-referenced to public blockchain transactions, and made all this accessible to the necessary authorities upon request. But this option would be very unpopular ideologically, very difficult practically, but worst of all would create a huge centralised source of sensitive data. This stuff would be an irresistible honeypot for hackers. Unfortunately, even some of the world’s largest companies have shown through repeated, infamous data breaches that they could not guarantee to keep centralised data secure (Remember Yahoo x2, Facebook, Target?).
As far as I can observe to date, technical solutions to the Travel Rule fall across two dimensions: Firstly whether it’s a centralised or decentralised solution, and secondly whether the solution utilises a blockchain or not.
Ironically, the difficulties imposed by implementing the Travel Rule are due to the nature of public blockchain transactions, and yet many interesting solutions being proposed to address these difficulties are themselves blockchain-based solutions! That’s what I mean by ‘Uses Blockchain’ in the above table.
These different categories of solution all have different pros and cons, which all arise as a result of the same trade-offs:
Speed trade-offs, i.e. how fast can a FATF-compliant transaction be processed?
Trust trade-offs, i.e. to what extent (if any) does VASP A need to trust that VASP B is not misbehaving?
Cybersecurity risk trade-offs, i.e. does the solution result in a dangerous centralisation of sensitive personal information into huge honeypots, irresistible for hackers and with traditionally lesser security-savvy government authorities holding copies of the keys?
Blockchain Ideology trade-offs, i.e. can this solution work without compromising treasured ideological features of public blockchains like censorship-resistance and asset fungibility?
Some may ask, why does the last one matter? Well, actually privacy-related features are still extremely important to large segments of the blockchain & crypto community. While such ideologies may not always completely align with the ideals of the regulatory authorities, ignoring them could backfire as it potentially drives groups of virtual asset transacting users underground as a matter of principle, where they become even harder to monitor.
Visualising the Travel Rule’s Impact
Trying to balance these trade-offs brings enormous complexity. This is the reason we are seeing so many different flavours of solution being proposed, and the reason why there is so much noise from industry VASPs about the impracticalities of the Travel Rule’s implementation.
But why is it so impractical? Is it really as complicated as they are saying, or is the whole thing just overblown? To help shed some light on the practical differences that will be introduced by the Travel Rule, I’ve illustrated below the step-by-step process of three different transaction scenarios, in order of increasing complexity. We will start with a simple peer to peer blockchain transaction, and then show an example of the current situation of transactions between VASPs (pre-Travel Rule implementation), and finally an example of a transaction that will comply with the Travel Rule (post implementation).
Usually, to do a proper job of this explanation would involve a tangled array of sequence diagrams or flow charts. However, in the interests of coherency I’m going to spare you that and attempt to abstract the process using a medium we’re all familiar with: messaging!
Scenario 1 : Transaction between 2 non-VASPs (simple peer to peer)
Alice wants to send bitcoin to Bob. Alice and Bob both use their own wallets, with Alice transacting with Bob directly without using a Virtual Asset Service Provider.
Simple peer to peer transactions don’t involve VASPs and are straightforward.
Scenario 2 : Transaction between 2 VASPs before FATF Travel Rule implementation (status quo)
Alice wants to send bitcoin to Bob. Alice is originating the transaction directly from her hosted, “custodial” wallet (“VASP A”) and sending it to Bob’s account at bitFlyer, a regulated crypto exchange (“VASP B”).
Alice’s VASP needs some extra steps to do its own checks on Bob.
Alice’s VASP knows Alice, but it doesn’t know Bob. And Bob’s VASP doesn’t provide any information to Alice’s VASP before the transaction is attempted. Instead, Alice’s VASP does its own homework to make sure Bob’s VASP is legitimate and low risk.
Scenario 3 : Transaction between 2 VASPs after FATF Travel Rule implementation
Alice wants to send bitcoin to Bob. As before, Alice is originating the transaction directly from her hosted, “custodial” wallet (“VASP A”) and sending it to Bob’s account at bitFlyer, a regulated crypto exchange (“VASP B”). However, this time we assume that the FATF recommendations are in practice and the Travel Rule has been implemented.
As mentioned earlier, there are many solutions being proposed to implement the Travel Rule for VASPs, and below is just one possible implementation chosen as an example.
FATF Travel Rule transactions carry significant reciprocal additional overhead to be compliant.
What a difference!
Recall that to satisfy the Travel Rule requirements, the sender VASP must guarantee accuracy of the originator information and share with the receiver, while the receiver VASP must guarantee accuracy of the beneficiary information and share with the sender. Both VASPs have accurate information about their customers, Alice and Bob, and establish a secure connection to swap this information. But not before first validating each other’s VASP credentials (remember the internet doesn’t offer implicit trust), double checking their customers consent to the transaction, screening each other’s customers against OFAC sanction lists, and seeking explicit GDPR opt-in. That’s a lot more steps involved than in the previous two scenarios, not to mention that Alice and Bob already went through many additional steps prior to the transaction, to complete the KYC on-boarding process with their respective VASPs.
This particular implementation used in Scenario 3 assumes a decentralised approach using so-called certificate authorities, just like like the ones that verify the authenticity of websites you visit and cause the little padlock icons to appear in the browser bar. But there are plenty of other ways being proposed to achieve FATF-compliant transactions; this is just one of many. Moreover, this is one of the simpler implementations I have so far come across, if you can believe it.
Yet as I mentioned, even though this is one of the simpler or more elegant solutions, just like any solution it still faces plenty of its own challenges in trying to balance the various trade-offs of speed, trust, cybersecurity risk, and blockchain ideology. For instance, this model relies on trusting the certificate authorities that issue the certificates; isn’t this just moving risk from one entity to another? Next, the process requires both Alice and Bob to be online at the same time, in order to provide the various necessary authorisations. What if someone can’t get to their phone or desk? That’s just going to delay the transaction for an unknown amount of time. Aha, but what if Alice or Bob gives blanket approval to a certain VASP, whitelisting it for now and in future in order to save time? Well, doesn’t that create a situation where a misbehaving VASP can query and extract whole customer lists from a certain other VASP, simply by trying to initiate transactions with hundreds or thousands of addresses that it suspects belongs to an honest VASP, thus receiving credentials of those ‘white-listers’ without ever sending any funds? Finally, what if something goes wrong and funds are moved from VASP A to VASP B in error? There’s no such thing as a refund / rollback on the blockchain so how could these situations be addressed in a compliant manner?
Ultimately, as with most things, there will be no ‘perfect’ solution. Implementing the Travel Rule as recommended by the FATF will require some technical ingenuity to balance the various trade-offs in the most optimal way. While I have seen many different proposals so far, I’m expecting there will be many more. And while it seems many companies are currently rushing for their solution to become the ‘standard’ which can be adopted across the industry, I’m wondering what happens instead of one ‘winner’ standard we see a handful of solutions which succeed in on-boarding a majority or significant minority of VASPs each. Are we destined to move towards a global centralised SWIFT-like network for virtual assets, or perhaps the next round of innovation will be how to make several different Travel Rule implementations interoperable in any situation.
Only time will tell.
Andy
September 2019