Change Log

Version 1.5.7

Enclave

  • (Bugfix) Fixed a hashing error during legal person verification

Version 1.5.6

Enclave

Version 1.5.5

Enclave

  • Fixed to not throw INVALID-FORMAT error

Version 1.5.4

Enclave

  • Added dateOfIncorporation field in IVMS101 Standard where you can fill in the date of incorporation for LegalPerson.

  • In the geographic address data type in IVMS101 Standard, townName is no longer a required field.

  • (Bugfix) Fixed a bug where buildingNumber and buildingName were transposed when saving personal information with a geographic address.

Version 1.5.3

Major changes

  • To minimize wallet address or transaction ID mismatches, we provide the Wallet address and transaction ID standards.

  • To improve security, the Enclave server has been modified to operate as a non-root user.

  • Added the option to use a custom schema instead of using the public schema when using PostgreSQL.

Enclave Bugfix

  • Fixed an uncommon IVMS101 parsing error that occurred very infrequently.

  • Fixed a rare occurrence of a database deadlock bug.

Version 1.5.2

Major changes

Version 1.5.1

Enclave Bugfix

  • Fixed a bug where changing the connection state with other VASPs through the 'Vasp Connect' feature did not immediately apply the connection state.

Version 1.5.0

Major changes

Version 1.4.1

Enclave Bugfix

  • Fixed: low probability that user verification result not stored properly in the enclave DB.

Version 1.4.0

Major change

  • Modified to allow interoperability with CODE.

Enclave

  • VASPs using CODE protocol are also displayed in the list when the list lookup API is called.

  • VASP List API CountryCode and protocol items have been added in the return value..

  • VASP List API Added new vaspStatus value (INTEROPERATED) in return value.

Version 1.3.9

Enclave Bugfix

  • 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 .

Version 1.3.6

Enclave Bugfix

  • The verification failure issue with UNDEFINED-ERROR code on user verification VASP API request without ivms101 data fields has been resolved.

Version 1.3.4

Enclave Bugfix

  • An error occurrence from commands table on the Oracle database has been removed.

Version 1.3.2

Enclave Bugfix

  • The problem has been fixed that the authorization header value is misconfigured when VEGA_VERIFICATION_AUTHORIZATION_TOKEN variable 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.

Version 1.3.0

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.

    • See User Account Verification API for more details.

  • 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.

    • See Robot VASP page for more details.

Enclave API

  • 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.

VASP API

  • User Verification API implementation policy has been updated.

    • Only required beneficiary information fields need to be filled out.

  • verificationUuid field is newly added to the request payload of User Verification API.

  • Callback API implementation policy regarding the idempotent has been added.

  • User Account Verification API was updated to verify the beneficiary name in case of the transaction amount exceeds the legal baseline.

Enclave

  • The name of an environmental variable has been changed as User Address Verification API is changed to User 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_at is added to the index.

    • See Database page for more details.

Version 1.2.0

Major changes

  • Some enclave APIs were changed to work asynchronously.

    • Data that was delivered with synchronous API response is now delivered through the callback VASP API.

Why did VerifyVASP introduce asynchronous processes?

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.

Background of using personal data field code

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.

VASP API policies

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.

Supporting transaction inside a VASP

It is not mandatorily required for the users who trade virtual assets in the same VASP to be verified via VerifyVASP.

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.

Enclave API

VASP API

  • 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.

Enclave

  • 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

  • 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.

Bugfix and minor updates

  • 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

Version 1.1.0

Consol Site

  • The Korean Site is open.

    • Only the staging environment and site are open; the production environment and site are to open soon.

  • The address of the Korean VerifyVASP console site updated (https://kr.verifyvasp.xyz).

  • Korean VASPs need to register to the Korean console site newly.

Central Server

  • The central server endpoint for the Korea region was added.

Enclave Server

  • 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 API

  • 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

Enclave API

  • 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.

      • includesAll query 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.

PreviousWelcomeNextGetting Started with VerifyVASP

Last updated