What KYC reliance is
Standard customer onboarding routes each declared control person through a Conduit-hosted identity verification flow: a selfie and government-ID check. KYC reliance is an alternative for organizations that already run their own KYC/IDV program. Instead of each person completing a fresh identity flow, you upload a verification report exported from your own provider for each control person. Conduit validates the report and clears the identity requirement when the report matches your submitted person data. The match centers on name and date of birth. Other identity fields in the report are cross-checked too.
Everything else in onboarding is identical. Business-entity fields, KYB documents, compliance screening, and the review pipeline all work the same way.
This guide covers only what reliance changes. It assumes you have read the standard flow: Onboard a Customer and The Onboarding Lifecycle.
Start from the standard requirements-discovery step in Onboard a Customer. That step tells you how many control persons to declare and which business documents to attach. This guide picks up at the attestation upload.
A control person is a beneficial owner or controlling person of the business — the individuals you list in ownership.persons[]. The discovery response’s individualRequirements[] tells you how many each country requires and which role each must hold. You attach one attestation PDF per control person, via that person’s ownership.persons[i].documentIds[].
Prerequisites
KYC reliance must be enabled for your organization before you can use it. It is off by default.
If KYC reliance is not yet enabled, contact your Conduit account
manager. Attestation documents submitted before the feature is enabled will
not satisfy the identity verification requirement.
What changes vs standard onboarding
| Standard onboarding | KYC reliance |
|---|
| Per-person identity verification | Each control person completes a Conduit-hosted flow | You upload one attestation PDF per control person |
| Document slot | No per-person document required | ownership.persons[i].documentIds[] |
| Outcome determination | Conduit-hosted provider verdict | Identity fields extracted from the PDF, matched against submitted data. Name and date of birth are the primary match fields; other fields in the report are checked too |
| Auto-clear | After the hosted flow completes | After a clean match on name, date of birth, and any other identity fields in the report |
| Operator review | On mismatch or inconclusive result | On mismatch, unrecognized provider, or non-valid classification |
What the attestation must contain
Upload a PDF exported from your KYC/IDV provider. The document must contain all of these:
| Required element | Examples |
|---|
| Provider name | ”Verified by Sumsub”, Veriff logo, “Jumio Verification Report” |
| Person’s full legal name | First name, last name — must match firstName + lastName in your submission |
| Verification result | ”Verified”, “Approved”, “Clear”, “Pass”, or equivalent |
| Verification or reference ID | A case ID, session ID, or transaction reference |
| Completion date | The date the verification was completed (the report’s own date — not matched against the submission) |
- One person per file. Do not combine multiple persons’ reports in a single PDF.
- The document must be legible and unedited. Redacted or altered PDFs are rejected.
- The name and date of birth in the report must match the values in your
ownership.persons[i] submission exactly. Other identity fields in the report, such as nationality or government ID number, are cross-checked too. Fields absent from the report count as inconclusive, not a mismatch.
How to export from your provider
The table below covers the most common providers. For providers not listed, export the verification summary or decision report from your provider’s dashboard or case management UI.
| Provider | Where to export |
|---|
| Sumsub | Dashboard → Applicants → select applicant → “Download Report” (PDF) |
| Veriff | Dashboard → Sessions → select session → “Export” → PDF summary |
| Onfido / Entrust | Dashboard → Reports → select check → “Download Report” |
| Jumio | Dashboard → Transactions → select transaction → “Export” → PDF |
| Persona | Dashboard → Inquiries → select inquiry → “Download PDF” |
| AiPrise | Dashboard → Verifications → select record → “Export PDF” |
| Plaid | Dashboard → Identity Verification → select session → “Export” |
| Trulioo | Dashboard → Verifications → select record → “Download Report” |
| Smile ID | Dashboard → Jobs → select job → “Download” → PDF report |
| IDwall | Dashboard → Processes → select process → “Export” |
| Incode | Dashboard → Sessions → select session → “Download Report” |
| Alloy | Dashboard → Applications → select entity → “Export” → PDF |
| Socure | Dashboard → Decisions → select decision → “Export” |
| Identomat | Dashboard → Verifications → select verification → “Download” |
| iDenfy | Dashboard → Verifications → select record → “Download PDF” |
| ID.me | Dashboard → Verifications → select record → “Export” |
| IDnow | Dashboard → Processes → select process → “Export Report” |
| Didit | Dashboard → Verifications → select session → “Export PDF” |
Provider dashboard layouts change over time. If the menu path above no longer
matches, look for an “Export”, “Download”, or “Generate Report” action on the
individual verification or session detail page.
Integration walkthrough
Step 1 — Upload each person’s attestation
Upload one PDF per control person. Use purpose: kyc and Content-Type: multipart/form-data. POST /v2/documents takes an optional purpose; identity attestations use purpose=kyc, while ordinary onboarding documents omit it or use the default.
curl https://api.conduit.financial/v2/documents \
-X POST \
-H "x-api-key: YOUR_API_KEY" \
-F "file=@alice-smith-verification.pdf" \
-F "name=IDV Attestation - Alice Smith" \
-F "purpose=kyc"
{
"id": "doc_01JABCDE12345EXAMPLE0001",
"name": "IDV Attestation - Alice Smith",
"purpose": "kyc",
"createdAt": "2026-06-01T10:00:00.000Z"
}
id. You attach it to the person in the next step.
Step 2 — Submit the onboarding application
Submit a standard POST /v2/onboarding request. For each control person, include the document ID in ownership.persons[i].documentIds[].
curl https://api.conduit.financial/v2/onboarding \
-X POST \
-H "x-api-key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: YOUR_IDEMPOTENCY_KEY" \
-d '{
"clientReferenceId": "your-customer-001",
"documentIds": ["doc_businessReg001", "doc_operatingLicense001"],
"businessInfo": {
"businessName": "Aurora Robotics Inc.",
"taxId": "12-3456789",
"website": "https://aurora-robotics.example.com",
"companyEmail": "compliance@aurora-robotics.example.com",
"companyPhone": "+15551234567"
},
"registeredAddress": {
"country": "USA",
"addressLine1": "1 Main St",
"city": "New York",
"state": "US-NY",
"zipcode": "10001"
},
"ownership": {
"persons": [
{
"firstName": "Aiko",
"lastName": "Tanaka",
"email": "aiko@aurora-robotics.example.com",
"birthDate": "1985-06-15",
"nationality": "USA",
"governmentIdType": "PASSPORT",
"governmentIdNumber": "A12345678",
"governmentIdCountry": "USA",
"roles": ["CONTROLLING_PERSON"],
"ownershipPercent": 100,
"documentIds": ["doc_01JABCDE12345EXAMPLE0001"]
}
]
},
"certification": {
"termsAndConditions": true,
"consentToElectronicSignatures": true
}
}'
ownership.persons[i].documentIds. The attestation PDF attaches there. The top-level documentIds carries business-entity documents only, such as registration and license.
Response:
{
"id": "app_01JABCDE12345EXAMPLE0002",
"type": "CUSTOMER_ONBOARDING",
"status": "processing",
"clientReferenceId": "your-customer-001"
}
Step 3 — Listen for the outcome
Configure a webhook listener for application.approved and application.rejected. See Webhooks for setup.
When the attestation matches the submitted data on name, date of birth, and any other identity fields in the report, the review pipeline clears the identity requirement. The application proceeds toward approval without operator intervention.
Acceptance and rejection expectations
A submitted attestation may be rejected for any of these reasons:
| Reason | What to do |
|---|
| Name or date of birth in the report does not match the submitted person data | Verify the names are an exact match (no initials, abbreviations, or transliteration differences) and re-upload the correct report |
| Provider cannot be identified from the document | Ensure the report contains a clear provider name or logo; try a different export format from your provider |
| Document appears illegible, edited, or corrupted | Re-export the report from your provider’s dashboard |
| Document classified as a raw ID rather than a verification report | Upload the provider-generated report (verification summary / decision PDF), not a scan of the government ID itself |
| Missing required attestation for a declared person | Upload one attestation PDF per control person and include each document ID in that person’s documentIds[] |
application.approved or application.rejected as normal — see The Onboarding Lifecycle for the decision webhooks. You receive an application.rejected webhook if the operator decides the application cannot proceed. To resubmit, cancel the rejected application and submit a new one with corrected documents.