Home
Guides

Individuals onboarding

This documentation applies to the creation of an individual to get payment services.

Expected onboarding journey


User status diagram: UserRecordStatus

The userRecordStatus is the user's onboarding status.

It includes:

  • the KYC status,
  • the T&C validation,
  • the PEP Sanction filtering status,
  • the FACTA/EAI status.
stateDiagram
    [*] --> Initialized: User created
    Initialized --> InProgress : At least one of the expected onboarding step is done
	  	note left of InProgress: Onboarding steps <br/>  - KYC demand <br/> - Declaratives <br/> - PPE/Sanction <br/> - Facta/Eai <br/> - T&C

    InProgress --> Refused : If (Sanction = true and/or PPE = true) <br/> and finalDecision = false
		InProgress --> WithoutKYC : If accountType = ElectronicMoney <br/> and declarative info is received

	  WithoutKYC --> Refused : If (Sanction = true and/or PPE = true) <br/>  and finalDecision = false
	  InProgress --> Validated : If accountType <> ElectronicMoney <br/> and all expected onboarding step are validated
	  WithoutKYC --> Validated : If accountType = ElectronicMoney <br/> and kycStatus = Complete <br/> and PPE/Sanction = false
	  
    Refused --> [*]
    Validated --> [*]
		note right of Validated: PPE/sanction is "OK" if  <br/> - PPE false and Saction = false  <br/> - PPE and/or Sanction = true and finalDecision = true

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.


User sequence diagram

Detailed user onboarding sequence diagram

sequenceDiagram
Title: User onboarding
autoNumber
Participant User
Participant Partner
Participant XPO

Note over User, XPO: User creation

User ->> Partner : Account creation requested<br/>appUserId<br/>civility<br/>lastName<br/>...
Partner ->> XPO : POST / api/v2.0/users
XPO -->> Partner: HTTP/201
autonumber off
note over Partner, XPO : callbacks are sent asynchronously after a POST /api/v2.0/users
par send callback 34 - User Status
autonumber 4
XPO --) Partner : Callback 34<br/>userRecordStatus :Initialized
autonumber 4
and send callback 45 - Account Status
XPO --) Partner : Callback 45<br/>Account Status :Initialized
end

Note over User, XPO: Digiatl scoring  -- See dedicated section --
XPO --) Partner : Callback 34<br/>digitalScoring.status :Validated


Note over User, XPO: KYC -- See dedicated section --
autonumber 5
rect rgb(104, 180, 255, 0.1)
	Partner ->> XPO: POST /api/v3.0/user/{appUserId}/kyc/demand<br/>workflowCode: Electronic_Sign|Identity
	XPO -->> Partner : HTTP/201
	autonumber 7
	note over Partner, XPO : callbacks are sent asynchronously after a POST /api/v3.0/kyc/demand
	par Send callback 35 - Strong Authentication
		rect rgb(255, 255, 255, 1)
			XPO --) Partner : Callback 35<br/>Strong authentication enrollment [Note1]
		end
	autonumber 7
	and send callback 34 - User Status
		rect rgb(255, 255, 255, 1)
			XPO --) Partner : Callback 34<br/>userRecordStatus :InProgress
		end
	autonumber 7
	and send callback 48 - KYC web view
		XPO --) Partner : Callback 48 - KYC web view
	autonumber 7
	and send callback 4 - KYC status
		XPO --) Partner : Callback 4<br/> KYC status<br/>(Incomplete|Complete|..)
	end
end
rect rgb(104, 180, 255, 0.1)
	Note over User, XPO: T&C -- See dedicated section --
	alt Electronic_sign <br/> T&C included in the KYC workflow
	else Identity
		autonumber 8
		User ->> Partner: T&C validated
		Partner ->> XPO : POST /api/sca/v2.0/users/{AppUserId}/cgu
		XPO -->> Partner : HTTP/201
end
autonumber 11
note over Partner, XPO : callbacks are sent asynchronously after a POST /api/v2.0/cgu
rect rgb(255, 255, 255, 1)
			par Send callback 4 - KYC status		
				XPO --) Partner : Callback 4<br/>KYCStatus : Complete
		 autonumber 11
			and send callback 34 - User Status
				XPO --) Partner : Callback 34<br/>userRecordStatus : InProgress
			end
		end
end
rect rgb(104, 180, 255, 0.1)
	Note over User, XPO: FATCA EAI -- See dedicated section --
	par Declarative informations
		autonumber 12
		User ->> Partner: Declarative 
		Partner ->> XPO : POST /api/v2.0/users/{AppUserId}/declarative
		XPO -->> Partner : HTTP/200		
		XPO --) XPO : Callback 32<br/>Internal
	and Fatca eai
		autonumber 15
		User ->> Partner: Americaness & Tin info 
		Partner ->> XPO : PATCH /api/sca/v2.1/user/{appUserId}/fatcaEai
		XPO -->> Partner : HTTP/201		
		note over Partner, XPO : callbacks are sent asynchronously after a POST /api/v2.1/fatcaEai
		XPO --) Partner : Callback 44<br/>fatcaEaiStatus: OK
	end
end

rect rgb(104, 180, 255, 0.1)
	Note over User, XPO: Filtering -- See dedicated section --
	note over Partner, XPO : callbacks are sent asynchronously after filtering
	autonumber 18
	XPO --) Partner : Callback PoliticallyExposedPersonStatusCreatedOrUpdated <br/>results of PPE filtering and penalties
end
par send callback 34 - User Status
	autonumber 18
	XPO --) Partner : Callback 34<br/>userRecordStatus : Validated
and send callback 45 - Account Status
	autonumber 18
	XPO --) Partner : Callback 45<br/>Account Status : Activated
end
👍

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 T&C, 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.


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.

sequenceDiagram
Title: User onboarding
autoNumber
Participant User
Participant Partner
Participant XPO

Note over User, XPO: User creation

User ->> Partner : Account creation requested<br/>appUserId<br/>civility<br/>lastName<br/>...
Partner ->> XPO : POST / api/v2.0/users
XPO -->> Partner: HTTP/201
autonumber off
note over Partner, XPO : callbacks are sent asynchronously after a POST /api/v2.0/users
par send callback 34 - User Status
autonumber 4
XPO --) Partner : Callback 34<br/>userRecordStatus :Initialized
autonumber 4
and send callback 45 - Account Status
XPO --) Partner : Callback 45<br/>Account Status :Initialized
end
Note over User, XPO: T&C -- See dedicated section --
autonumber 5
User ->> Partner: T&C validated
Partner ->> XPO : POST /api/v2.0/users/{AppUserId}/cgu
XPO -->> Partner : HTTP/201
autonumber 6
note over Partner, XPO : callbacks are sent asynchronously<br/>after a POST /api/v2.0/cgu
autonumber 6
XPO --) Partner : Callback 34<br/>userRecordStatus : Validated
XPO --) Partner : Callback 45<br/>accountRecordStatus : Validated
❗️

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.

KYC workflow

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.

Control performed during user creation

The following controls are applied when creating a user:

Address Validation:

  • For users located in French territories (both metropolitan France and DROM-COM), in the attribute address, the city and zipcode fields must be consistent and refer to the same geographical location.

Birthplace Validation:

  • For users born in France (metropolitan France and DROM-COM), the birthCity and birthZipCode fields must also be consistent and match the same locality.

These validations are based on official governmental APIs, which are publicly accessible and free:

https://api.gouv.fr/documentation/api-geo with GET /communesand

https://api.gouv.fr/documentation/api_carto_codes_postaux with GET /api/codes-postaux/communes/codePostal

These controls are also performed during a PUT user.


APIs, callbacks and technical items

Create a user

🔗Create a User

Create a KYC demand

🔗Create a KYC Demand

Save User declarative

🔗Save User Declarative

Create and update FATCA information for a Customer

🔗FATCA information

Save User T&C acceptance (IDENTITY workflow only)

🔗TC acceptance

Callbacks

🔗Callback 34

🔗Callback 4

🔗Callback 44

🔗Callback 48

🔗Callback 35

🔗Callback 45

Terms & Conditions

📘

For the Electronic_Sign worlfklow, the T&Cs are signed through the webview.

For the Identity workflow, the T&C are signed though the dedicated API.


Updated 3 months ago

Did this page help you?