Basic Architecture
VerifyVASP is a simple API-based messaging service that enables VASPs to privately share all required transmittal compliance data.
An Alliance Member of VerifyVASP('VV') will be invited to connect to the Value Transfer Protocol Solution via API connectivity. Each Alliance Member is required to integrate with VV’s servers by downloading a Docker image and using it to host their enclave server in their own environment. The API key allows interaction between the enclave server hosted by the individual Alliance Member and VV’s Central API Server. Each Alliance Member must implement the User Validation API in order to access VV’s enclave server that is hosted in their own environment.

Basic Architecture

Verify VASP System Architecture
To initiate an information exchange with the other Alliance Members or VASP, a request for verification is first conducted by the Alliance Member who is initiating the Virtual Asset ('VA') transfer or in Travel Rule terminology, an Originating VASP. The Originating VASP initiates its enclave server to make an API call to VV’s Central API server and check if the receiving counterparty or Beneficiary VASP is within the Alliance. Upon confirmation that the Beneficiary VASP is within the Alliance, the Originating VASP’s enclave server would proceed to make an API call with the VV’s Central API server, to which a further similar API call is made to the Beneficiary VASP’s enclave server to generate a new unique key pair and request for the public key to be provided for the purpose of the required private data (i.e. identity information of the originating and beneficiary customer) encryption.
It is worth highlighting that both Originating and Beneficiary VASP’s respective enclave servers generate new key pairs, including both public and private key, unique to each information exchange transaction to ensure optimal security in the information being transmitted. Hence, no similar key pairs will be generated or used repeatedly for any information exchange transaction.
The Originating VASP’s enclave server will encrypt the private data using the unique public key generated and received from the Beneficiary VASP’s enclave server. The encrypted data will then be sent to and shared with the Beneficiary VASP’s enclave server.
Beneficiary VASP, upon receipt of the encrypted private data can proceed to decrypt with their unique private key generated for this information transfer transaction and confirm the completeness of the originator’s information and the accuracy of the beneficiary customer’s information (i.e., the name and address of the beneficiary customer), since the Beneficiary VASP is expected to have already performed KYC on the beneficiary. Once the Beneficiary VASP confirm the accuracy of the beneficiary customer’s information and that all information required of the originator is complete, such confirmation will be notified from the Beneficiary VASP’s enclave server to the Originating VASP’s enclave server. This will assure the Originating VASP that the originator and beneficiary’s private data shared to the Beneficiary VASP is complete and that the Beneficiary VASP has verified that the beneficiary’s information shared to be accurate. This assurance by the Beneficiary VASP to the Originating VASP is not a requirement under FATF Travel Rule or MAS Value Transfer. However, VV is of the view that this simple confirmation from Beneficiary VASP can enhance the verification process and improve customer’s due diligence, knowing at least that the information exchange is complete and accurate.
Should the Beneficiary VASP finds a mismatch of the transmitted beneficiary customer information sent by Originating VASP with their own KYC file, the Beneficiary VASP can reply an ‘error’ to the beneficiary information submitted by the Originating VASP on the Value Transfer Platform and a notification will subsequently be made to the Originating VASP’s enclave server of the error code. If the Beneficiary VASP’s internal policies and procedures allow, the correct data can be sent to the Originating VASP. If the Beneficiary VASP decides not to share the correct data with Originating VASP, then the VA transfer and exchange of information will be nullified and a fresh transfer / exchange initiated, if the originator still wants to make the same transfer with the correct originator / beneficiary information. This procedure allows the parties with the opportunity to rectify the information exchanged if any incomplete or inaccurate information is discovered.
All private data exchanged that has been completed is retained in each of the Originating and Beneficiary VASP’s respective databases. Once the VA transfer is completed, the Originating VASP will share the unique transaction identity number or TxID with the Beneficiary VASP and VV’s Central API server. Accordingly, the confirmation transaction hashes sent and saved in VV, Originating and Beneficiary VASPs respective databases for the purposes of record-retention after the VA transfer has been made.
Last modified 5mo ago
Copy link