Comment on page
Change Log
- Fixed: low probability that user verification result not stored properly in the enclave DB.
- Modified to allow interoperability with CODE.
- VASPs using CODE protocol are also displayed in the list when the list lookup API is called.
- 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 type mismatch issue on the
count(returned in string type) value in response payload of Verification Result List API has been fixed.
Major changes
- The user address verification API was expanded to a user 'account' verification API.
- Now it supports a selective name matching verification in addition to the existing wallet address check.
- Utilize a robot VASP for more test cases coverage
- Now you can experience more various error case handling when you test the withdrawal verification with the robot VASP.
- 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.
- Only required beneficiary information fields need to be filled out.
- User Account Verification API was updated to verify the beneficiary name in case of the transaction amount exceeds the legal baseline.
- The name of an environmental variable has been changed as
User Address Verification APIis changed toUser Account Verification API.- AS-IS: VEGA_VERIFICATION_ADDRESS_API_PATH
- TO-BE: VEGA_VERIFICATION_ACCOUNT_API_PATH
- A new environment variable for VASP API Authorization Token header setup has been added.
- The index definition of commands table updated.
- A new column
created_atis added to the index.
- 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.
- The Asynchronous process is introduced to these APIs below.
- 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.
- A diagram describing the transaction state transition has been added to the transaction status query API page.
- Parameter names have been changed.
- The query parameters for Verification Result List API are modified as follows. - fromAccount --> originatorAccountNumber - toAccount --> beneficiaryAccountNumber
- 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.
- verifications
- Enclave database - new tables
- counter_party_keys
- own_keys
- Enclave database applies encryption to some columns
- Environment variables added
- VEGA_ENCLAVE_PUBLIC_ENDPOINT
- VEGA_VERIFICATION_ADDRESSES_API_PATH
- VEGA_VERIFICATION_TRANSACTION_API_PATH
- VEGA_VERIFICATION_AUTHORIZATION_TOKEN
- VEGA_ENCRYPTION_KEY_BASE64
- VEGA_DECRYPT_API_ENDPOINT
- VEGA_PUBLIC_KEY_TTL
- VEGA_LOG_LEVEL
- 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.
Last modified 1yr ago