PII Verify Fields

Sometimes, companies using GTR Solution must complete personal identity verification in advance. In order to meet the needs of due diligence, we additionally support optional fields called: Verify Fields.

For Travel Rule Request Initiator, they will bring out the fields expectVerifyFields they want to check for verification. And put the expectVerifyFields in request payload, for example: Initiator API 5: PII Verification, you can bring the parameter

*Travel Rule Request Initiator could be Originator VASP or Beneficiary VASP.

{
  "requestId": "[YOUR REQUEST ID]",
  "ticker": "ETC",
  "address": "0x41ebF291D8BFb6481B4Ab1E26c412A96484b1454",
  "tag": "",
  "verifyType": 2,
  "network": "xxxxxxxx",
  "beneficiaryVasp": "xxxxxxx",
  "encryptedPayload": "[YOUR PAYLOAD]",
  "originatorPublicKey": "[YOUR PUBLIC KEY]",
  "beneficiaryPublicKey": "[BENEFICIARY PUBLIC KEY]",
  "fiatName": "USD",
  "amount": "1000",
  "fiatPrice": "6.66",
  "lawThresholdEnabled": true,
  "expectVerifyFields": [
    "111001", // Beneficiary Legal Person Name
    "110026" // Beneficiary Natural Person Name
  ]
}

For the Target VASP, they need to verify all the fields they can verify and bring out the results. And put the results into stage 3: receive PII results callback, for example: Receiver Callback API 3: PII Verification.

{
  "verifyStatus": 100000,
  "verifyMessage": "Success",
  "data": {
    "encryptedPayload": "....",
    "verifyFields": [
      {
        "type": "110026", // Beneficiary Natural Person Name
        "status": 1,
        "message": "match"
      }
    ]
    //...
  }
  // ...
}

GTR will return based on the fields mentioned by Initiator instead of returning all the verification of the Beneficiary. In other words, the verification field result obtained by Initiator is an Intersection.

For the verifying fields, we provide the list that you could refer to, if the field is not in the list, you still can name it, please use UPPER snake case to name it.

Common Type Name:

Name	FATF Name	JSON Path	GTR Enum
Beneficiary Legal Person Name	LegalPersonName	x.ivms101.Beneficiary.beneficiaryPersons[].legalPerson.name.nameIdentifier	111001
Beneficiary Natural Person Name	NaturalPersonNameID	x.ivms101.Beneficiary.beneficiaryPersons[].naturalPerson.name.nameIdentifier	110026
Beneficiary Natural Person Local Name	LocalNaturalPersonNameID	x.ivms101.Beneficiary.beneficiaryPersons[].naturalPerson.na Local Name is the non-english alphabet nameme.localNameIdentifier	110027
Beneficiary Natural Person Place of Birth	PlaceOfBirth	x.ivms101.Beneficiary.beneficiaryPersons[].naturalPerson.dateAndPlaceOfBirth.placeOfBirth	110024
Beneficiary Natural Person Date of Birth	DateOfBirth	x.ivms101.Beneficiary.beneficiaryPersons[].naturalPerson.dateAndPlaceOfBirth.dateOfBirth	110025
Beneficiary Natural Person Phonetic Name	LocalNaturalPersonNameID	x.ivms101.Beneficiary.beneficiaryPersons[].naturalPerson.name.phoneticNameIdentifier	110028
Beneficiary Natural Person Country Of Residence	CountryOfResidence	x.ivms101.Beneficiary.beneficiaryPersons[].naturalPerson.countryOfResidence	110048
Beneficiary Legal Person Country Of Registration	CountryOfRegistration	x.ivms101.Beneficiary.beneficiaryPersons[].legalPerson.countryOfRegistration	111022

*Verify Fields code names are distinguished by Originator/Beneficiary and need to be used in different scenarios.

Status Enum Type:

Status Enum Name	Status Enum Value (Integer)	Description
SKIP	0	GTR Response No Verify
MATCH / PASS	1	Full match Or Pass
MISMATCH	2	Not match
NOT_SUPPORT	3	Counter-Party VASP Response No Verify
INFO_MISSING	4	Info missing
INFO_EXISTS	5	Received / Exists

The error message will also give the Travel Rule Initiator two forms of information, one is the verification result expected by the Initiator, and the other is the verification result expected by the Receiver.

In Travel Rule Request Initiator

Among them, SKIP, MATCH/PASS, MISMATCH, NOT_SUPPORT will only appear in the expectVerifyFields required by the Initiator. In other words, only the items listed by the Initiator will be returned in the result.

*Travel Rule Request Initiator could be Originator VASP or Beneficiary VASP.

In Travel Rule Request Receiver

Among them, INFO_MISSING and INFO_EXISTS will appear in the information returned by the Receiver. They represent the required information required by the other party's VASP. Regardless of whether the Initiator is included in expectVerifyFields, the results required by the fields will be returned to the Initiator.

*Travel Rule Request Receiver could be Originator VASP or Beneficiary VASP.

You can use the VASP Detail API to query which fields are required by the Receiver, which are presented in the requiredPiiFieldsAsBeneficiary field.

You can also check supportedVerifyFields to check which fields Receiver VASP can help you verify.

See: GET /api/common/v3/vasp/detail