KYC Status definition

The KYC status represents the progress of the user's KYC. This status includes the state of progress on all due diligences

KYC State Diagram

stateDiagram
    [*] --> Initialized : KYC demand created
		state fork_state <<fork>>
    Initialized --> Pending
    Pending --> fork_state
    fork_state -->	Incomplete : At least one diligence has been received by the provider
		fork_state --> AwaintingExpertise : All diligences are "validated" and "FinalDecision" = pending
	  fork_state --> FraudSuspicion : Decision = "KOFraud"
	  
	  state fork_state2 <<fork>>
	  Incomplete -->  fork_state2
	  fork_state2 --> Complete : All expected diligences are "Validated" and Decision "OK"
	  fork_state2 --> FraudSuspicion : Decision = "KOFraud"
	  fork_state2 --> AwaintingExpertise : All diligences are "validated" and "FinalDecision" = pending
      fork_state2 --> Rejected : -- the enduser refused the electronic T&C <br/> -- electronic signature expired <br/> -- number of SMS sent exceeded <br/> -- KYC file expired

	  
	  AwaintingExpertise --> Complete : "FinalDecision" = OK	  
      AwaintingExpertise --> Incomplete : All expected diligences are not 'Validated' 
	  AwaintingExpertise --> FraudSuspicion : "FinalDecision" = KOFraud	  
	  


    FraudSuspicion --> [*]
    Complete --> [*]
    Rejected --> [*]

KYC Sequence diagram

sequenceDiagram
autoNumber
Participant User
Participant Partner
Participant XPO
User ->> Partner : Account creation requested<br/>appUserId<br/>civility<br/>lastName<br/>...
Partner ->> XPO : POST / api/v2.0/users
XPO -->> Partner: HTTP/201
XPO --) Partner : Callback 34<br/>userRecordStatus :Initialized
XPO --) Partner : Callback 45<br/>Account Status :Initialized
Partner -->> User : Display KYC workflow choice<br/>(depends on partner implementation)
User -->> Partner: Choose KYC Workflow<br/>(depends on partner implementation)
Partner ->> XPO: POST /api/v3.0/user/{appUserId}/kyc/demand<br/>workflowCode: Electronic_Sign|Identity
XPO -->> Partner : HTTP/201
XPO --) Partner : Callback 4 - KYC Demand<br/>status:PENDING
XPO --) Partner : Callback 48 - Web View URL
XPO --) Partner : Callback 35 - SCA Wallet Initialization
alt using the webview
    Partner -->> User : Display WebViewURL <br/> Electronic_sign: ID & selfie <br/> Identity: ID
else using API, identity workflow only
    Partner -->> User : Request for identity document upload
    
end

📘

Workflow parameterization has to be made upstream during the environment parameterization. Partner choice is then taken into account by XPollens for the global workflow parameterization.

The XPollens recommandations by order of preference are as follow :

1- Electronic signature + Identity (in fallback)
2- Identity alone (not recommended)

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.

👍

XPollens recommend to use theIdentity workflow only in fallback when the user is not able to complete the Electronic signature workflow.

❗️

Steps 6 and 7 are optionnal and depends on partner implementation.

Workflow change

During user onboarding it is possible for the user to switch from the Electronic_Signature workflow to the Identity workflow (this way only, it is not possible to switch from Identity to Electronic_Signature).

This is possible as long as the user has not completed the Selfie+ID step in the Electronic_Signature workflow.

To handle the switch of workflow, partner should call the 🔗 KYC Demand by specifying the new workflow in the payload.

Example : 🔗KYC update

{
     "workflowCode" : "Identity"
}

🚧

Conversely, it is impossible to switch from the Identity workflow to the Electronic_Signature workflow.

KYC file expiry

❗️

A KYC folder expires after a period of 90 days from the date it was created.

If the user has not finalised or validated the file within this period, it will automatically expire.

As soon as the KYC is rejected, a callback 4 is sent with the statut Rejected. With a request to 🔗 KYC received , the decision is retrieved with the value "expired".The userRecordStatus does not change.

After expiry, the enduser always has the option of making a new KYC request.

Fraud suspicion

sequenceDiagram
autoNumber
Actor User
Participant Partner
Participant XPO
break Controls (5mins)
    XPO --> XPO: Controls (5mins) 
end
XPO --) Partner : Callback 4 - KYC Demand<br/>status:FraudSuspiscion <br/>receivedDiligences[{reason:"", diligenceType Identity, status:Refused}]

XPO --) Partner : Callback 34<br/>userRecordStatus : Refused
Note over User, XPO: Onboarding refused.<br/> The user can not try again.

KYC attempts limit

As part of strengthening our security against external attacks, a control rule is applied at onboarding: the number of possible KYC reopening attempts will now be limited to 5 attempts.
Once this limit is reached, the user account will become permanently unusable.

What counts as a reopening?

Considered as reopenings:

• Any new KYC request for an existing user
• Any reopening due to inconsistencies between the declared information and the data extracted from the submitted documents

Not counted as reopenings:

• Cases caused by document quality issues, unreadable documents ("undefined"), or unauthorized documents

Tracking remaining attempts

An attribute reopeningAttemptsRemaining has been added to the response of:
GET /kyc/demand It allows you to track in real time the number of remaining attempts for a given user.

If the limit is exceeded:

• The KYC request will be automatically rejected with the status Rejected
• The atribute Comment is populated with the message: "Case closed: Maximum number of attempts reached"
• Any further KYC creation attempts (POST /kyc/demand) will return an error: 422 Unprocessable Entity
• 
  

📌 Please note: The user account will become unusable, but its status will not be modified at this stage.