Travel Address Brings Flexibility to Travel Rule Compliance

In previous posts, we explained what the Travel Address is and how it works on a conceptual and a technical level. But there might be cases where the Travel Rule Protocol (TRP) defined Travel Address doesn’t cover the specific needs a virtual asset service providers (VASP) might have.

At every step of the protocol, TRP allows for ‘extensions’. These extensions can be used to modify or add to the TRP protocol. The Travel Address exchange is no different.

Imagine a beneficiary VASP with specific requirements on how it wants to receive coins. For example, no more than 10 Bitcoins can be received by users who have not yet completed a certain KYC process. When the originator VASP calls the URL as decoded from the Travel Address, the response contains additional information from the beneficiary VASP for the originator VASP to interpret.

The request stays the same, but instead of the standard response, the beneficiary VASP communicates user-specific limits to the originator VASP. The new information is returned in a specific place in the response. The specification also mandates that the beneficiary signals the use of additional data in a predetermined manner.

All communications happen via HTTPS with JSON documents. A regular response would look like this (some fields are omitted for the sake of clarity):

1
2
3
4
{
  "asset": "BTC",
  "address": "bc1q5pucatprjrqltdp58f92mhqkfuvwpa43vhsjwpxlryude0plzyhqjkqazp"
}

But with the additional information, it would look like this:

1
2
3
4
5
6
7
8
9
10
11
{
  "api-extensions": "userLimits",
  "extensions": {
    "userLimits": {
      "min": "0.1",
      "max": "10"
    }
  },
  "asset": "BTC",
  "address": "bc1q5pucatprjrqltdp58f92mhqkfuvwpa43vhsjwpxlryude0plzyhqjkqazp"
}

The specification mandates the `api-extensions` and the `extensions` part, but their content is not. The originator VASP should, of course, know what it means to get this information, but that’s up for the two VASPs to agree on.

This is one example of how to extend TRP. Nothing limits you from building on top of it to add anything additional required for your business compliance and operations. For this to work, both parties in the exchange need to support a particular extension.

We envision that many such extensions will exist in the future. And we encourage everyone to add their extension to our list of extensions. If an extension is valuable to many or all, it will be promoted into the core specification of TRP. 

Its extensions-mechanism is a significant benefit of the open-source standard built by the Travel Rule Protocol (TRP) working group. At 21 Analytics, we implement and support TRP and custom extensions so our clients can adapt it the best way to fit their specific needs.