TRISA stands for Travel Rule Information Sharing Alliance. It’s a formal organization created by Ciphertrace. TRISA sets out to provide a solution for the FATF Travel Rule guidance. Work on the solution began in January 2019.
TRISA revolves around two centralized entities. The Certificate Authority and the VASP Directory. These are used to validate and discover VASPs, but the actual Travel Rule data is exchanged between the VASPs in a peer to peer fashion.
The Certificate Authority
VASPs identify each other based on specially issued certificates. To obtain a certificate, the VASP petitions the TRISA organization. TRISA requires information ranging from when and where the business is incorporated to business, technical, compliance, and billing contact details. It also inquires about the applied KYC and CDD policies. The details are vetted, and once it is found satisfactory, a certificate is issued. It is unclear how the information is handled or which requirements there are to keep it up to date.
This certificate is used in the day to day operations. When an originating VASP wants to send a transaction to a beneficiary VASP, it queries the directory to obtain the counterparty VASP’s certificate and the API endpoint.
Both sides need to verify the certificate of any request by looking it up in the directory.
The directory does not provide any address resolution. When an Originating VASP receives an address from a user, it is suggested to use a chain analysis company like Chainalysis to determine the beneficiary VASP. Or alternatively, ask the user.
Once both parties’ authenticity is established via the directory, data is exchanged between the VASP in a peer to peer fashion. The data is mostly InterVASP IVMS101 compliant and is exchanged via gRPC. The necessary protocol buffer definitions can be found on their public GitHub repository. Each message is wrapped in an encrypted envelope. The goal of this is to be able to store the messages as-is and maintain full repudiation. Multiple encryption schemes are to be implemented in the future.
The exchange takes several steps:
1. Originator sends the beneficiary an identifier
2. Beneficiary replies with a signed response
3. Originator sends the blockchain transaction
4. Originator sends transaction ID plus the previously registered ID to the beneficiary
This flow is asynchronous, but it is unclear when exactly the Travel Rule information is exchanged.
TRISA positions itself as being an interoperability layer between other protocols and solutions, but it is unclear how and if that works.
Although TRISA managed to get a lot of attention in its earlier days, it only partially solves the FATF Travel Rule challenge. With two centralized components (the certificate authority and the directory), it also doesn't fulfil our requirements to keep the crypto ecosystem open and decentralized. Additionally, TRISA depends on information from chain analysis companies, which is not required for VASP-to-VASP transactions using TRP or OpenVASP.
For these reasons, we decided not to implement TRISA. However, if TRISA gets more adoption by the broader ecosystem despite those flaws, we will also add it to our list of supported protocols.