How the TRP Travel Address Solves the FATF Travel Rule
In the previous post, we talked about what problems the Travel Address solves. Here, we’ll have a better look at how it does that.
Similar to a Bitcoin address, a Travel Address looks like an opaque string of characters:
LNURL1DP68GURN8GHJ7UM9WFMXJCM99E3K7MF0V9CXJ0M385EKVCENXC6R2C35XVUKXVS89HM
This, however, is not true. The Travel Address is a so-called LNURL (notice the prefix in the example!). It encodes a URL in the bech32 format, which helps the VASP make a Travel Rule compliant transaction. Our example Travel Address encodes this URL:
https://bitfinex.com/api?q=3fc3645b439c
It is now immediately evident that the beneficiary VASP is Bitfinex. The originating VASP now knows who the beneficiary VASP is.
Using the Travel Rule Protocol (TRP) standard, the VASP can now call the decoded URL. In essence, the response sent by the beneficiary VASP contains a cryptocurrency identifier and an address, encoded in a JSON document, for example.
1 2 3 4{ "asset": "bitcoin", "address": "bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4" }
With both the beneficiary VASP and cryptocurrency address now available to the originating VASP, it can send the virtual asset (in the example above, Bitcoin) and the required FATF Travel Rule information under the condition that the remainder of the TRP endpoints reside on the same domain. A TRP compliant implementation will ensure this.
The bech32 encoding does not prevent the user from tampering with the LNURL, which should not be changed as it holds the crucial Travel Rule information needed . Worst case is that the originator VASP can be tricked into calling an arbitrary URL. This can be prevented or mitigated by the originating VASP by creating a whitelist of domains or a set of heuristics such as, for example, verifying a TLS certificate. Or the request can be parked for a compliance officer to check. Again no assumptions are necessary in order for Travel Address to work. The freedom to do business as the VASP sees fit is maintained.
