SEP: 0009
Title: Standard KYC Fields
Author: stellar.org
Status: Active
Created: 2018-07-27
Updated: 2024-04-22
Version 1.17.0
This SEP defines a list of standard KYC, AML, and financial account-related fields for use in Stellar ecosystem protocols. Applications on Stellar should use these fields when sending or requesting KYC, AML, or financial account-related 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 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 |
Where possible we use field names from schema.org. Words are separated with underlines as that convention has previously been established in Stellar protocols.
Field names should always be used as strings. For example:
{
"organization.name": "Stellar Development Foundation"
}The dot notation is not an indication that the fields described should be contained in a nested object under a top-level key.
| 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 |
string | 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 |
string | Mobile phone number with country code, in E.164 format unless specified differently on mobile_number_format field. It could be hashed in case mobile_number_format is defined as hash |
mobile_number_format |
string | Expected format of the mobile_number field. E.g.: E.164, hash, etc... In case this field is not specified, receiver should assume it's in E.164 format |
email_address |
string | Email address |
birth_date |
date | Date of birth, e.g. 1976-07-04 |
birth_place |
string | Place of birth (city, state, country; as on passport) |
birth_country_code |
string | ISO Code of country of birth |
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 |
string | primary language |
id_type |
string | passport, drivers_license, id_card, etc... |
id_country_code |
string | 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 |
photo_proof_residence |
binary | Image of a utility bill, bank statement or similar with the user's name and address |
sex |
string | male, female, or other |
proof_of_income |
binary | Image of user's proof of income document |
proof_of_liveness |
binary | video or image file of user as a liveness proof |
referral_id |
string | User's origin (such as an id in another application) or a referral code |
These fields should be used to request or provide information about off-chain
financial accounts. Because both natural persons and organizations can use the
same types of financial accounts, these fields can be used to request or
provide information about natural persons or organizations. The organization.
prefix should be used when requesting or providing fields related to an
organization.
Note that some of these fields are generic, such as bank_number, which could
potentially be used to identify a bank in any country, and some fields are
specific to a given country, such as cbu_number, which contains a bank number
in addition to other pieces of information. In order to optimize for the user's
experience, it is recommended that applications use fields that are the most
familiar, which are often specific to a given country or financial system.
| Name | Type | Description |
|---|---|---|
bank_name |
string | Name of the bank. May be necessary in regions that don't have a unified routing system. |
bank_account_type |
string | checking or savings |
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 |
bank_branch_number |
string | Number identifying bank branch |
external_transfer_memo |
string | A destination tag/memo used to identify a transaction |
clabe_number |
string | Bank account number for Mexico |
cbu_number |
string | Clave Bancaria Uniforme (CBU) or Clave Virtual Uniforme (CVU). |
cbu_alias |
string | The alias for a Clave Bancaria Uniforme (CBU) or Clave Virtual Uniforme (CVU). |
mobile_money_number |
string | Mobile phone number in E.164 format with which a mobile money account is associated. Note that this number may be distinct from the same customer's mobile_number. |
mobile_money_provider |
string | Name of the mobile money service provider. |
crypto_address |
string | Address for a cryptocurrency account |
crypto_memo |
string | (deprecated, use external_transfer_memo instead) A destination tag/memo used to identify a transaction |
| Name | Type | Description |
|---|---|---|
organization.name |
string | Full organization name as on the incorporation |
organization.VAT_number |
string | Organization VAT number |
organization.registration_number |
string | Organization registration |
organization.registration_date |
string | Date the organization was registered |
organization.registered_address |
string | Organization registered address |
organization.number_of_shareholders |
number | Organization shareholder number |
organization.shareholder_name |
string | Can be an organization or a person |
organization.photo_incorporation_doc |
binary | Image of incorporation documents |
organization.photo_proof_address |
binary | Image of a utility bill, bank statement with the organization's name and address |
organization.address_country_code |
string | country code for current address |
organization.state_or_province |
string | name of state/province/region/prefecture |
organization.city |
string | name of city/town |
organization.postal_code |
string | Postal or other code identifying organization's locale |
organization.director_name |
string | Organization registered managing director |
organization.website |
string | Organization website |
organization.email |
string | Organization contact email |
organization.phone |
string | Organization contact phone |
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.
To pass card (such as credit card) details to the application, the client
should pass card details via an object defined below. Note, that it's possible
to either pass card details to the application, or the token, representing the
card. This token may be fetched from a third-party source prior, for example,
it can be a Stripe token, or
any other service offering similar functionality may be used. When token is
used, application should notify clients about the type of the token that it is
expecting to receive. Usually, application would require either token, or set
of: number, expiration_date, cvc and holder_name to be provided, but
some applications may require extra fields.
| Name | Type | Description |
|---|---|---|
card.number |
string | Card number |
card.expiration_date |
date | Expiration month and year in YY-MM format (e.g. 29-11, November 2029) |
card.cvc |
string | CVC number (Digits on the back of the card) |
card.holder_name |
string | Name of the card holder |
card.network |
string | Brand of the card/network it operates within (e.g. Visa, Mastercard, AmEx, etc.) |
card.postal_code |
string | Billing address postal code |
card.country_code |
string | Billing address country code in ISO 3166-1 alpha-2 code (e.g. US) |
card.state_or_province |
string | Name of state/province/region/prefecture is ISO 3166-2 format |
card.city |
string | Name of city/town |
card.address |
string | Entire address (country, state, postal code, street address, etc...) as a multi-line string |
card.token |
string | Token representation of the card in some external payment system (e.g. Stripe) |
v1.18.0: Addmobile_money_number,mobile_money_provider, andbank_namefields to Financial Account Fields (#1498)v1.17.0: Addmobile_number_formatfield to Natural Person Fields (#1481).v1.16.0: Addexternal_transfer_memofield to Financial Account Fields (#1452).v1.15.0: Add fields for card details (#1430).v1.14.0: Addreferral_idfield (#1418).v1.13.0: Addcryptorelated fields to financial account fields section. (#1382)v1.12.0: Define financial account fields section. (#1367)v1.11.0: Addbank_account_typefor describing types of bank accounts. (#1344)v1.10.0: Removecvu_number, updatecbu_numberto also accept CVU numbers, and addcbu_aliasto Natural Person KYC fields (#1339)v1.9.0: Addcbu_numberandcvu_numberto Natural Person KYC fields (#1338)v1.8.0: Addproof_of_livenessto Natural Person KYC field (#1323).v1.7.0: Addproof_of_incometo Natural Person KYC fields (#1310).v1.6.0: Addclabe_numberto Natural Person KYC fields (#1202).