SEP: 0009
Title: Standard KYC / AML fields
Author: stellar.org
Status: Active
Created: 2018-07-27
Updated: 2018-09-11
Version 1.1.0
This SEP defines a list of standard KYC and AML fields for use in Stellar ecosystem protocols. Issuers, banks, and other entities on Stellar should use these fields when sending or requesting KYC / AML information with other parties on Stellar. This is an evolving list, so please suggest any missing fields that you use.
This is a list of possible fields that may be necessary to handle many different use cases, there is no expectation that any particular fields be used for a particular application. The best fields to use in a particular case is determined by the needs of the KYC or AML application.
ISO encodings are used for fields wherever possible. The table below lists the encodings used for different types of information.
| Field Type | Number of characters | Format / Encoding |
|---|---|---|
| language | 2 | ISO 639-1 |
| country | 3 | ISO 3166-1 alpha-3 |
| date | 10 | ISO 8601 date-only format |
| phone number | varies | E.164 |
| occupation | 3 | ISCO08 |
| Name | Type | Description |
|---|---|---|
family_name or last_name |
string | Family or last name |
given_name or first_name |
string | Given or first name |
additional_name |
string | Middle name or other additional name |
address_country_code |
country code | country code for current address |
state_or_province |
string | name of state/province/region/prefecture |
city |
string | name of city/town |
postal_code |
string | Postal or other code identifying user's locale |
address |
string | Entire address (country, state, postal code, street address, etc...) as a multi-line string |
mobile_number |
phone number | Mobile phone number with country code, in E.164 format |
email_address |
string | Email address |
birth_date |
date | Date of birth, e.g. 1976-07-04 |
birth_place |
date | Place of birth (city, state, country; as on passport) |
birth_country_code |
country code | ISO Code of country of birth |
bank_account_number |
string | Number identifying bank account |
bank_number |
string | Number identifying bank in national banking system (routing number in US) |
bank_phone_number |
string | Phone number with country code for bank |
tax_id |
string | Tax identifier of user in their country (social security number in US) |
tax_id_name |
string | Name of the tax ID (SSN or ITIN in the US) |
occupation |
number | Occupation ISCO code |
employer_name |
string | Name of employer |
employer_address |
string | Address of employer |
language_code |
language code | primary language |
id_type |
string | passport, drivers_license, id_card, etc... |
id_country_code |
country code | country issuing passport or photo ID as ISO 3166-1 alpha-3 code |
id_issue_date |
date | ID issue date |
id_expiration_date |
date | ID expiration date |
id_number |
string | Passport or ID number |
photo_id_front |
binary | Image of front of user's photo ID or passport |
photo_id_back |
binary | Image of back of user's photo ID or passport |
notary_approval_of_photo_id |
binary | Image of notary's approval of photo ID or passport |
ip_address |
string | IP address of customer's computer |
Where possible we use field names from schema.org. Words are separated with underlines as that convention has previously been established in Stellar protocols.
Address formatting varies widely from country to country and even within each country. See here for details. Rather than attempting to create a field for each possible part of an address in every country, this protocol takes a middle of the road approach. Address fields that are fairly universal can be encoded with the country_code, state_or_province, city, and postal_code fields. Full addresses, however, should be encoded as a single multi-line string in the address field. This allows any address in the world to be represented with a limited number of fields. If address parsing is necessary, parsing will be easier since the country, city, and postal code are already separate fields.