KYC Flows Overview
An overview of Sila's two KYC flows.
Classic KYC Flow Order
To ensure the user_handle you're wanting to assign is unique.
Creates a new individual or business entity in the Sila ecosystem with associated PII. Does NOT begin KYC verification. Creates a Sila wallet for the user_handle.
NOTE: Prior to beginning KYC verification in the next step with /request_kyc, end users can update their information with /update.
Kicks off KYC verification for a specific user_handle.
Returns verification status of a specific user_handle.
Do not poll this endpoint. Instead, we recommend utilizing the KYC Status Update Event webhook.
Upload end user documentation to this endpoint is necessary to verify their identity.
Use the Triaging KYC Failures doc to determine what documents are needed based on the tags returned. Do NOT reveal the tags to end users, only what document to provide.
Advanced KYC Flow Order
Advanced KYC Flow is not SDK compatible
To ensure the user_handle you're wanting to assign is unique.
Creates a new individual or business entity in the Sila ecosystem with associated PII. Does NOT begin KYC verification. Creates a Sila wallet for the user_handle.
NOTE: Prior to beginning KYC verification in the next step with /request_kyc, end users can update their information with /update.
Kicks off KYC verification for a specific user_handle.
/get_verifications/<verification_uuid> or /get_verifications
Return the verification status of a single KYC application with /get_verification or a full list of all verification records for a specific user_handle with /get_verifications.
Important! New process when end user doesn't pass KYC
If your end user doesn't pass KYC, you have four total tries to get the user to pass:
- The first try will always be to update end user PII. Use /update. Once updated, use /resume_verification to restart the verification process.
- If the end user still doesn't pass, the next try will be to upload a doc. Once uploaded, use /resume_verification to restart the verification process.
- You are given two more tries to upload that same doc - you cannot upload a different doc, so be sure the one that is uploaded is the correct one. Continue to use /resume_verification to restart the verification process.
Which action to take - PII update or doc upload - will be indicated in an
action_neededfield in the webhook. Values are eitherentity_dataordoc_upload.
If an end user fails verification, use this endpoint to restart the verification process after PII has been updated or after uploading a doc to /documents.
Upload end user documentation to this endpoint if necessary to verify their identity. Only one doc can be uploaded, so be sure to upload the correct one on the first try.
Use the XX doc to determine what documents are needed based on the tags returned. Do NOT reveal the tags to end users, only what document to provide.
IMPORTANT: Since Journeys uses an automated review system, it's important that your end users upload clear photos of their docs.
Endpoints by Flow
| Classic-specific | Advanced KYC-specific | Shared |
|---|---|---|
| /request_kyc | /kyc | /register (including /add, /update, and /delete) |
| /check_kyc | /get_verification/<verification_uuid> and /get_verifications | /check_handle |
| Classic-specific failure triggers | /resume_verification | /get_entity and /get_entities |
| new Advanced KYC-specific failure triggers | /documents (including document-related endpoints, eg: /get_documents) | |
| new Advanced KYC-specific webhooks | KYB certification endpoints |
Number of KYC attempts allowed:
- End users get two total attempts to pass KYC or KYB, regardless if Advanced KYC or Classic is used.
Updated 4 days ago