Skip to main content

User Onboarding Introduction

This documentation applies to the creation of a particular user in the contexte of payment accounts.

User status diagram: UserRecordStatus

The userRecordStatus is the user's highest status level. It includes:

  • the KYC status,
  • the CGU validation,
  • the PEP Sanction filtering status,
  • the FACTA/EAI status.

User & Account

A user can have several accounts. This is why there is a distinction between accounts and users. Today, the creation of a user automatically generates the creation of an account.

In the future, these two actions will be decoupled: the account should be created once the user has been created.

User sequence diagram

Eletronic_sign workflow

Identity workflow

Detailed user onboarding sequence diagram

The strong authentication wallet initialization is not a prerequisite for KYC validation if the choosen workflow is "electronic_sign". It can be done at any time after the user has been created.
Otherwise (if the workflow is "identity"), the wallet initialization is a prerequesite to sign CGU, and as a consequence a prerequesite to validate the user status.
This callback is received as soon as the KYC demand is created.
However, it is necessary for user validation, as sending FATCA/EAI information requires strong authentication.

The call sequence presented below is an example. Once the user is created, APIs related to KYC, T&Cs, Declarative, and FATCA can be called in the order chosen by the partner. The recommendation is as follows:

  1. User creation
  2. KYC request creation
  3. KYC completion (Identity or Electronic Signature)
  4. Since the KYC request may take some time to be validated, it is recommended, to avoid leaving the user waiting, to proceed with the following steps during the wait:
  5. Initialization of the Authentication Wallet
  6. Income Declaration
  7. FATCA / EAI (requires prior creation of the authentication wallet)
  8. T&Cs Signature (in the case of the IDENTITY workflow - Requires prior creation of the authentication wallet)

⚠ Note3
It is impossible to represent all possible cases. However, it is important to note the following:
Callbacks are triggered as soon as an action modifies data related to the callback (User status for callback 34, Account status for callback 45, KYC status for callback 4, etc.)

Detailed user onboarding sequence diagram - Anonymous Electronic Money Account

Anonymous Electronic Money accounts creation does not require most of the previous steps to be completed. The only requirement for anonymous electronic money account creation is the signature of terms & conditions.

⚠ Note4
For now, the authentication wallet can not be used with an electronic money account and thus, no callback 35 is sent to the partner.
For this reason the validation of T&C can be performed in this case and this case only without Strong Authentication.
In the future, the callback 35 may be sent as soon as the user is created in order to initialize the authentication wallet. The T&C signature may require a Strong Authentication in this case, even for anonymous electronic money accounts.

User status diagram: UserRecordStatus

In accordance with CNIL regulations and rules:

  • all customers have the right to refuse the use of biometrics when entering into a relationship with us
  • the service provider must offer a fallback solution, enabling the customer to enter into a relationship.

In the case of facial scanning, it is therefore mandatory to implement the "Identity" fallback solution with SCT IN diligence.

APIs, callbacks and technical items

Create a user

POST /api/v2.0/users

Create a KYC demand

POST /api/v3.0/users/{appUserId}/kyc/demand

Save User declarative

POST /api/v2.0/users/{AppUserId}/declarative

Create and update FATCA information for a Customer

PATCH /api/sca/v2.1/user/{appUserId}/fatcaEai

Save User T&C acceptance (IDENTITY workflow only)

POST sca/v2.0/users/{{appUserId}}/cgu


Callback 34

Callback 4

Callback 44

Callback 48

Callback 35

Callback 45


For the Electronic_Sign worlfklow, the CGU are signed through the webview. For the Identity workflow, the CGU are signed though the dedicated API.