Know Your Customer - Fill-in API
Know Your Customer Fill-in (0.1.1)
Download OpenAPI specification:Download
This API provides the customer with the ability request and receive the information for a particular user, which on file (and verified) by the user's Operator in their own KYC records, in order for the SP to confirm the accuracy of the information and provide a specific service to the user.
- KYC: stands for Know Your Customer and it is the process of a business verifying the identity of their clients and assessing their suitability, along with the potential risks of illegal intentions towards the business relationship.
This API allows API clients to request for API provider / MNO to provide information related to a mobile phone user, derived from the account data bound to their phone number. The API is intended to be used in the following scenario, for example:
- To fill-in the user personal data during the digital registration of an account to a 3rd party service.
The following figure is the generic high-level flows of this API.
Note:
Before calling this API, 3rd parties / enterprise customers who want to use this API should make contract with API provider/ Operator for use of this API. As that will depend on each API provider / MNO's business processes as well as GSMA Open Gateway standard process, it is out of scope of this API definition.
When calling this API, at the beginning, there should be required processes for Authentication / Authorisation / End User Consent capturing. As those processes are to be defined as CAMARA commonality standards, they are out of scope of this API definition, however, use of the OpenID Connect (OIDC) is stated as security scheme. As an important note, capturing end user consent is necessary, because this API provides end user information (PII).
For this version of the KYC Fill-in API, the request body of the Fill-in Request does not include any parameters/attributes. The above mentioned AuthN/AuthZ/End User consent capturing processes can give the API provider/ MNO the 3rd party identity (with the Access Token) and the end user identity (with the ID Token), so the API provider/ MNO can identify the 3rd party / enterprise customer and the end user. Then, it is up to API provider/ MNO to decide which information the 3rd party will receive by calling the API, and also the API provider / MNO is responsible for security and privacy issues.
For example, below is a potential operation:
- when making contract with API provider/ MNO, a 3rd party / enterprise customer receives its 3rd party identity and also decide which information (attributes) it will receive for its API call
- when calling this API, the client of a 3rd party / enterprise customer put its 3rd party identity (only) in the request body
- then, API provider / MNO will provide information (attributes) which the 3rd party / enterprise customer is allowed to receive by the contract.
The API provides the following endpoint:
- An endpoint to request information related to an end user against the account data bound to their phone number.
Operations to provide information related to a customer identity stored the account data bound to the customer's phone number.
Providing information related to a customer identity stored the account data bound to the customer's phone number.
Authorizations:
header Parameters
| x-correlator | string Correlation id for the different services |
Responses
Response samples
- 200
- 400
- 401
- 404
- 500
- 503
{- "phoneNumber": "+34629255833",
- "idDocument": "66666666q",
- "name": "Federica Sanchez Arjona",
- "giventName": "Federica",
- "familyName": "Sanchez Arjona",
- "nameKanaHankaku": "federica",
- "nameKanaZenkaku": "Federica",
- "middleNames": "Sanchez",
- "familyNameAtBirth": "YYYY",
- "address": "Tokyo-to Chiyoda-ku Iidabashi 3-10-10",
- "streetName": "Nicolas Salmeron",
- "streetNumber": 4,
- "postalCode": 1028460,
- "region": "Tokyo",
- "locality": "ZZZZ",
- "country": "JP",
- "houseNumberExtension": 36,
- "birthdate": "1978-08-22",
- "email": "abc@example.com",
- "gender": "male"
}