Classic KYC
Legacy KYC System
With the introduction of Advanced KYC, all newly onboarding customers are required to use Advanced KYC rather than Classic KYC.
If you are onboarding with Sila, please see the Advanced KYC docs for an implementation guide.
Basic order of operations
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 if 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.
Classic KYC specific endpoints:
Updating End User Data
Prior to requesting KYC, you can use the /update/ endpoint to update any end user PII.
If an end user needs to update their PII after passing KYC, you must call /request_KYC on that entity again after the data has been updated. Exceptions to this rule are updating email or phone number.
IMPORTANT
Not all end user data can be updated while verification is pending or after verification has passed. Please see the /update/ doc linked above for specifics.
Mocking KYC Failures in Sandbox
In the Sandbox environment ONLY you can provide triggers to /register to test out KYC failures. For Classic KYC, you can find those here.
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 29 days ago