Onboard with KYC Reliance

Test this flow in sandbox. Drive it end-to-end with simulated money and deterministic controls — start with the sandbox quickstart, then customer KYC simulation for this flow, and the cheat sheet for every magic value and simulate endpoint.

What KYC reliance is

Standard customer onboarding routes each declared control person through a Conduit-hosted identity verification flow: a government-ID capture, plus a live selfie where enhanced due diligence applies. 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 two things for each control person: a verification report exported from your own provider, and the original government ID the provider verified. 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 document uploads. 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 each control person’s report and ID images via that person’s ownership.persons[i].documentIds[]. For an individual customer they cover the account holder, the one person the application names — see Onboarding an Individual.

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 and the original ID document 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, printed with a label such as `Verification date: YYYY-MM-DD` (on an individual application, when you send `identityVerificationDate`, the two must agree within a few days)

Additional requirements:

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 tax ID number, are cross-checked too. Fields absent from the report count as inconclusive, not a mismatch.

The original ID document

Upload the government ID that your provider verified for the person: a passport, national ID card or driver’s license. The attestation does not replace it.

Upload the front of the document. If the document has a back, upload the back as a second file. A passport needs only its photo page.
Upload images or PDFs of the document itself. ID images embedded in the attestation PDF do not count as the original ID.
You do not upload a selfie. The API has no selfie document type.

You can also attach other documents your provider collected for the person, such as a proof of address or a second ID. Attach them in the same ownership.persons[i].documentIds[].

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 and ID

Upload the attestation PDF and the ID images for each control person, one file per call. 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"

Response:

{
  "id": "doc_034A1PiBrEXy0p2EpiUfBc",
  "name": "IDV Attestation - Alice Smith",
  "purpose": "kyc",
  "createdAt": "2026-06-01T10:00:00.000Z"
}

Upload the ID the same way, one call for the front and one for the back:

curl https://api.conduit.financial/v2/documents \
  -X POST \
  -H "x-api-key: YOUR_API_KEY" \
  -F "file=@aiko-tanaka-id-front.jpg" \
  -F "name=ID front - Aiko Tanaka" \
  -F "purpose=kyc"

Save each id. You attach them 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_034A1PiBr9Rncajg362NeF", "doc_034A1PiBr3GbN4Der5uviC"],
    "businessInfo": {
      "legalName": "Aurora Robotics Inc.",
      "taxId": "12-3456789",
      "website": "https://aurora-robotics.example.com",
      "companyEmail": "compliance@aurora-robotics.example.com",
      "companyPhone": "+14155550123"
    },
    "registeredAddress": {
      "country": "USA",
      "addressLine1": "1 Main St",
      "city": "New York",
      "state": "US-NY",
      "postalCode": "10001"
    },
    "operatingAddress": { "sameAsRegistered": true },
    "ownership": {
      "persons": [
        {
          "firstName": "Aiko",
          "lastName": "Tanaka",
          "email": "aiko@aurora-robotics.example.com",
          "birthDate": "1985-06-15",
          "nationality": "USA",
          "taxIdType": "SSN",
          "taxIdNumber": "123-45-6789",
          "taxIdCountry": "USA",
          "roles": ["CONTROLLING_PERSON"],
          "ownershipPercent": 100,
          "documentIds": [
            "doc_034A1PiBrEXy0p2EpiUfBc",
            "doc_034A1PiBrJ7mWq5nT2kLdA",
            "doc_034A1PiBrK2xVb8cR4pHsE"
          ]
        }
      ]
    },
    "certification": {
      "termsAndConditions": true,
      "consentToElectronicSignatures": true
    }
  }'

The key difference from standard onboarding is ownership.persons[i].documentIds. The attestation PDF and the ID images attach there. The top-level documentIds carries business-entity documents only, such as registration and license. Response:

{
  "id": "app_034A1PiBr8wb1FGaXD0qTJ",
  "type": "customer_onboarding",
  "status": "processing",
  "reviewStage": "automated",
  "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, and the original ID is attached, 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[]`
Missing original ID document for a declared person	Upload the front of the government ID, and the back if it has one, and include each document ID in that person’s `documentIds[]`

When an attestation is rejected or mismatched, the application routes to operator review: a human reviewer looks at it, and you still receive 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. Read resubmittable on that webhook before you retry: when it is true, submit a new application with corrected documents; when it is false, the decision is final and a new submission reaches the same outcome. Do not call cancel on a rejected application. Cancel accepts only applications still in review. It returns 409 on an approved or rejected one, and 200 with the application unchanged on a cancelled one.

Getting Started

How Conduit Works

Concepts

How-To Guides

Webhooks

Onboard with KYC Reliance

What KYC reliance is

Prerequisites

What changes vs standard onboarding

What the attestation must contain

The original ID document

How to export from your provider

Integration walkthrough

Step 1 — Upload each person’s attestation and ID

Step 2 — Submit the onboarding application

Step 3 — Listen for the outcome

Acceptance and rejection expectations

​What KYC reliance is

​Prerequisites

​What changes vs standard onboarding

​What the attestation must contain

​The original ID document

​How to export from your provider

​Integration walkthrough

​Step 1 — Upload each person’s attestation and ID

​Step 2 — Submit the onboarding application

​Step 3 — Listen for the outcome

​Acceptance and rejection expectations

What KYC reliance is

Prerequisites

What changes vs standard onboarding

What the attestation must contain

The original ID document

How to export from your provider

Integration walkthrough

Step 1 — Upload each person’s attestation and ID

Step 2 — Submit the onboarding application

Step 3 — Listen for the outcome

Acceptance and rejection expectations