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. Under standard reliance, the default level, everything else in onboarding is identical: business-entity fields, KYB documents, compliance screening and the review decision work the same way. Under full reliance, fewer checks hold a business application, and it can be approved with no operator review. See Full reliance. 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. When it is on, your organization has one of two levels: standard reliance, the default, or full reliance. No API field shows the level. Confirm it with your Conduit account manager.

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	Standard reliance: on mismatch, unrecognized provider, or non-valid classification. Full reliance: only for the checks in Full reliance

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.
A selfie does not count as the ID. A face photo does not satisfy identity_verification.

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. Each file must be a PDF, JPEG or PNG of at most 10 MiB (10,485,760 bytes). Another file type returns 400 UNSUPPORTED_FILE_TYPE; a larger file returns 413 FILE_TOO_LARGE.

curl https://api.conduit.financial/v2/documents \
  -X POST \
  -H "x-api-key: YOUR_API_KEY" \
  -F "file=@aiko-tanaka-verification.pdf" \
  -F "name=IDV Attestation - Aiko Tanaka" \
  -F "purpose=kyc"

Response:

{
  "id": "doc_034A1PiBrEXy0p2EpiUfBc",
  "name": "IDV Attestation - Aiko Tanaka",
  "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[]. The body below is abridged: it leaves out most businessActivity and regulatoryHistory fields to show what reliance changes. For a complete body that passes validation, see Step 2 of the sandbox quickstart, and take the fields from your discovery response.

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",
      "businessEntityId": "0123456789"
    },
    "companyClassification": {
      "legalStructure": "C-Corporation",
      "primaryIndustry": "manufacturing",
      "incorporationDate": "2020-01-15"
    },
    "businessActivity": {
      "hasRegulatedOrRestrictedActivities": false,
      "businessActivitiesDescription": "Designs and sells warehouse robots to logistics companies."
    },
    "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",
          "phoneNumber": "+14155550100",
          "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": {
      "consentToElectronicSignatures": true,
      "termsAndConditions": {
        "accepted": true,
        "acceptedAt": "2026-01-15T09:30:00.000Z",
        "acceptedByName": "Aiko Tanaka",
        "isAuthenticated": 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, Conduit clears the identity requirement with no operator intervention. Under standard reliance, a Conduit reviewer then decides the business application. Under full reliance, the application can be approved with no operator review (see Full reliance). Sandbox follows the same rules. To test a screen that finds a match, use the test names in Customer KYC.

Full reliance

Under full reliance, Conduit relies on your own KYB and KYC checks for your business customers. Standard reliance is the default. Confirm your level with your Conduit account manager.

What still holds a business application

A full-reliance business application is approved with no operator review unless one of these holds it:

Compliance screening of the business or of a control person has not cleared.
Enhanced due diligence applies to the business.
Conduit cannot confirm that the business is eligible for its services, or no banking partner can serve it.
The submission is missing a field or a person that the customer record needs.

While one of these holds it, the application stays processing with reviewStage: operator, and a Conduit reviewer decides it. application.approved does not mean that every document passed review. Send complete, current documents anyway: a banking partner can still need them before it opens an account.

Documents a USD virtual account still needs

The banking partner that opens a USD virtual account checks the customer’s documents itself, for example a business registration and a tax certificate. A document counts when Conduit identifies it as that type and it is not out of date. Attach these documents to the onboarding submission, in the top-level documentIds[], so the account can open without delay. To see what the banking partners still need for a customer:

curl 'https://api.conduit.financial/v2/customers/{customerId}/features/requirements?type=virtual_account&asset=USD' \
  -H "x-api-key: YOUR_API_KEY"

When a document is missing, the virtual account does not activate:

The Virtual Account stays pending_activation, and virtual_account.activated does not fire.
About one hour later, Conduit sends a request for information to your organization’s users: rfi.published fires, and GET /v2/rfis/{id} lists the missing items. An organization with no users gets no request, so do not wait for one: read the missing documents from the features/requirements call above.
Upload each missing document with POST /v2/documents, then send the document ids with POST /v2/customers/{customerId}/updates.
Conduit reviews the update. When it is approved, the account opening continues, the request for information resolves, and virtual_account.activated fires.

See Add Virtual Accounts for the request flow. If you verified a control person with Sumsub or Persona, you can share that verification instead of uploading the report and the ID. Conduit redeems the share and keeps the result as the person’s identity check. The person then owes no identity documents, and an individual customer owes no identityDocumentExpiryDate. The person still owes each other document that individualRequirements[].documents[] lists for their role, for example a proof of address under enhanced due diligence. Send industry to GET /v2/onboarding/requirements to see them. This uses the same KYC reliance setting from Prerequisites above — there is no separate setting to enable. A token works one time.

Link your Sumsub account to Conduit

This is for production. In sandbox, Conduit answers a SUMSUB share itself: you need no link, no client ID and no Sumsub token (see the note below). Conduit can redeem your Sumsub share tokens only after your Sumsub account and Conduit’s Sumsub account are linked as sharing partners. Do this before your first Sumsub share.

Ask your account manager for Conduit’s partner token.
In your Sumsub Dashboard, open the Partners tab, select Add recipient and paste the token.

You do this one time. Until the link exists, each shared check is not usable. The person you submit must have the same name as the person on the shared verification, middle names and initials included. Case and accents do not count. Sumsub Conduit runs its own liveness and face-match check on the shared applicant.

Ask your account manager for Conduit’s Sumsub client ID.
Right before you submit, mint a share token for the person’s Sumsub applicant with POST /resources/accessTokens/shareToken. Set forClientId to Conduit’s client ID and give the token a lifetime of at least 10 minutes.
Send { "provider": "SUMSUB", "token": "<share token>" }.

Persona Conduit keeps a copy of the person’s inquiry and its verifications, and reads their results and dates. The inquiry needs a passed government ID verification and a passed selfie verification with liveness and face match. A verification older than 365 days does not count.

Ask your account manager for Conduit’s Persona organization ID. Create a Connection to that organization one time, and wait until Conduit activates it.
Right before you submit, and with the person’s consent, create a share token for the person’s inquiry with POST /connect/share-tokens on your Persona API key.
Send { "provider": "PERSONA", "token": "<share token ID>" }. Use a token from Persona Production. In sandbox, see the note below.

Send the token on the person, in place of documentIds:

{
  "ownership": {
    "persons": [
      {
        "firstName": "Emily",
        "lastName": "Parker",
        "identityShare": { "provider": "SUMSUB", "token": "<share token>" }
      }
    ]
  }
}

The token is write-only: no response, webhook or read returns it. A person without identityShare still owes both identity documents. You can share some persons and upload for others in one application; each person still owes their other documents.

Outcome of the shared check	What happens
Approved	The identity requirement of the person clears.
Rejected, for example because the person is a duplicate of another applicant	The application routes to operator review.
Not usable, for example because the shared profile misses a step Conduit needs	The person owes the report and the ID document again. The application stays `processing`, and the application read does not show this outcome. A Conduit reviewer can ask you for the documents with a request for information (`rfi.published`). To send them yourself, cancel the application with `POST /v2/applications/{applicationId}/cancel`, then submit a new application with the documents, a new `Idempotency-Key` and the same `clientReferenceId`. An individual customer also sends `identityDocumentExpiryDate`, which the share had waived; without it the submit returns `422` `ONBOARDING_NOT_READY`. A new submit while the first application is `processing` returns `409` `ONBOARDING_ALREADY_SUBMITTED`.
Did not finish	The application routes to operator review and stays `processing`. Conduit keeps reading the check, and a later approval clears it. The application is not cancelled for this check.

The operator-review outcomes in this table apply under standard reliance. Under full reliance, only the checks in Full reliance hold the application. If identity sharing is not enabled for your organization or for the provider, submit returns 403 IDENTITY_SHARE_NOT_ENABLED and creates no application. Omit identityShare and upload the documents instead.

In sandbox, a PERSONA token is a share token from your Persona Sandbox account. Create the Connection to Conduit’s Persona organization in your Persona Sandbox account, and wait until Conduit activates it.For SUMSUB, sandbox answers the share itself, so you need no link and no Sumsub account. Send one of the identity share test tokens to get each outcome. A token that is not in the table is not usable. share-did-not-finish does not finish in sandbox: decide the application with simulate/decision.

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[]`

Under standard reliance, 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. Under full reliance, only the checks in Full reliance hold the application.

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

Full reliance

What still holds a business application

Documents a USD virtual account still needs

Link your Sumsub account to Conduit

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

​Full reliance

​What still holds a business application

​Documents a USD virtual account still needs

​Share from your identity provider

​Link your Sumsub account to Conduit

​Share a person’s verification

​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

Full reliance

What still holds a business application

Documents a USD virtual account still needs

Share from your identity provider

Link your Sumsub account to Conduit

Share a person’s verification

Acceptance and rejection expectations