Comment on page
- Fixed: low probability that user verification result not stored properly in the enclave DB.
- Modified to allow interoperability with CODE.
- Fixed a bug in the logic to remove information from the enclave when the user-verified VASP API returned information that was not in requiredBeneficiaryInfo .
- The verification failure issue with UNDEFINED-ERROR code on user verification VASP API request without ivms101 data fields has been resolved.
- An error occurrence from
commandstable on the Oracle database has been removed.
- The problem has been fixed that the authorization header value is misconfigured when
VEGA_VERIFICATION_AUTHORIZATION_TOKENvariable is not configured.
- The user address verification API was expanded to a user 'account' verification API.
- Utilize a robot VASP for more test cases coverage
- API policy of Transaction Result Report API has been updated.
- It requires to call this API as soon as the VASP finds the transaction ID (txHash) now, in contrast to the former version of the guide that required calling it after the transaction finality check.
- Error code specifications have been provided for each API.
- The name of an environmental variable has been changed as
User Address Verification APIis changed to
User Account Verification API.
- AS-IS: VEGA_VERIFICATION_ADDRESS_API_PATH
- TO-BE: VEGA_VERIFICATION_ACCOUNT_API_PATH
- Some enclave APIs were changed to work asynchronously.
- Data that was delivered with synchronous API response is now delivered through the callback VASP API.
The user verification process necessarily includes connections to other VASPs whose immediate completion is not able to be guaranteed.
In this situation, synchronous interlocking might result in the burden of staying connected until the response comes, which can be a bottleneck at the time of heavy requests.
Therefore, some APIs are now changed to work in a non-blocking way. Get the processing result through the newly added callback API from now on.
- Specific personal data specification requirements now can be designated in the request phase to VASP.
- Refer to the newly added code specification to designate the data requirements.
When sharing user personal information between VASPs, the required fields might vary along with the policy of each VASP or national regulation.
For example, a VASP may need an additional field such as the date of birth for sanction screening, or geographical address to meet the legal necessities.
Simply including the additionally required data fields upon the request or response enables the VASPs to collect required data without any unnecessary custom precessing. All the verification requester VASPs must fill the requested fields to satisfy the data request, or the verification should be DENIED.
- VASP API implementation policy updated.
VerifyVASP, a Travel Rule solution, is a collaborative protocol among multiple VASPs.
Each VASP has its own internal operating policy or different implementation standard, which makes it hard to orchestrate the system to work fine.
Accordingly, building a minimal consensus on the implementation policy can help the counter-side VASP reduce unexceptional errors and build the system easily.
- Now VerifyVASP supports a transaction in a single VASP, meaning a VASP can be both the originating VASP and beneficiary VASP of the transaction.
It is not mandatorily required for the users who trade virtual assets in the same VASP to be verified via VerfiyVASP.
However, the VASP might need to operate an additional system to track the verification history of internal transactions under the regulation. Integrating VerifyVASP for both internal and external transactions is recommended to reduce the operational overhead.
- User Verification API spec updated.
- requiredBeneficiaryInfo field was added to the request payload.
- Due to the change to work asynchronously, some fields from the response payload were discarded including verficiationUuid.
- The discarded data fields are now delivered through the Callback VASP API.
- Error report API specification updated.
- message field was added to the request payload.
- Callback API is newly added.
- The API is for getting notifications of the processing result asynchronously.
- Strongly recommended implementing the callback API: Polling way of implementation for all the processing transaction results without enough care might be a burden to both VASP itself and the VerifyVASP network.
- Implementation policies for each VASP API were updated.
- Error codes from the user verification API are now provided.
- The database table definition was updated.
- Added: commands table
- Modified: verifications table
- message column is added
- An environmental variable was added
- VEGA_VERIFICATION_CALLBACK_API_PATH: A variable for callback API endpoint setup
- IVMS101 Message Format Guide was updated.
- Address field expansion to support multiple addresses in addition to the parent address (e.g. XPR, EOS)
- The geographic address policy now requires corporations to fill out both headquarters address and branches.
- The problem in setting database port number adjustment has been fixed.
- The endpoint scanning process during enclave boot now checks the endpoints of transaction status query API and address verification API too.
- The Korean Site is open.
- Only the staging environment and site are open; the production environment and site are to open soon.
- Korean VASPs need to register to the Korean console site newly.
- The central server endpoint for the Korea region was added.
- Enclave server - version updated (VerifyVASP/enclave:v1.1.0)
- Enclave database - table definition updated.
- Enclave database - new tables
- Enclave database applies encryption to some columns
- Environment variables added
- VASP side need-to-implement APIs were added
- User address verification API (mandatory)
- Transaction status query API (mandatory)
- Decrypting database encryption key API (recommended)
- Specification update for user verification API
- symbol, amount fields moved into assetInfo object
- API version information was added to all API paths.
- Updated APIs
- VASP List API
- The list is changed to include VerifyVASP members only by default.
includesAllquery parameter is now supported.
- The response provides more detailed information including VASP health status.
- User verification API
- request body modified
- New APIs are now supported.
- Address verification API
- Error report API
- Transaction status query API
- A security guide page was added.
- IVMS101 standard guiding page was added.
- IVMS101 message format guide page was added.