Update Customer Identification Data
Partial update for a person customer’s existing KYC record. Only non-null fields are applied. Patches the customer’s existing KYC record directly — does not trigger re-verification, so an already-approved customer keeps their status. Useful for backfilling a tax identification number (DAC8/CARF) on customers who onboarded before TIN collection existed.
Authorizations
API Key
Headers
Optional sub-partner UUID, if provided, the identification data will be updated for the sub-partner's customer
Selects the API version for this request, as an ISO date (YYYY-MM-DD). Omit to use the default version (2025-03-13). Supported versions: 2025-03-13, 2026-07-01, 2026-08-01.
Path Parameters
the ID of the Customer whose identification data will be updated
Body
The identification data to update
Update Identification Data Params
Partial update for a person customer's existing KYC record. Only non-null fields are applied; today only the tax identification number is supported.
Tax identification number (e.g. SSN for US, national TIN for EEA residents). Patched directly onto the customer's existing KYC record — does not trigger re-verification, so an already-approved customer's status is unaffected.
ISO 3166-1 alpha-2 country of tax residence. Required whenever
tax_identification_number is set — TIN format is validated against
this specific country, and it can genuinely differ from the
customer's physical residence or nationality (the reason DAC8/CARF
asks for it separately).
Response
PATCH Customer Identification Data Succeeded
Identification
The entity wrapping our KYC/KYB process and underlying providers
Rails (e.g. "ach", "sepa_thirdparty") the synchronous rule-engine
preflight gate definitively ruled out at creation time, keyed to a
partner-safe reason. Only set on an outsourced Person/Business
identification (empty otherwise) — see
controllers::identifications::create_person_customer_outsourced_identification /
create_business_customer_outsourced_identification_v2.
The Process status of the identification
The various state transitions an identification can go through.
Pending, Processed, PendingReview, Approved, Declined, Expired, Archived Absent on a referral partner's identification (partner-keyed record)
The owning partner for partner-keyed (referral) records
Curated, partner-safe summary of the async preflight pipeline
(document/selfie analysis + workflow predictor) — backfilled onto an
identification once the shadow worker finishes (see
controllers::identification_preflight_shadow). Deliberately narrower than
ApiIdentificationPreflightResult/PreflightShadowDetails: no internal
level names, trace/correlation ids, or per-check evaluation names — those
stay internal/backoffice-only.
ISO 3166-1 alpha-2 (2 letter) country code of the verified residence address; only set on the customer's most recent identification while it is approved
- BusinessIdentificationStepStatus
- PersonIdentificationStepStatus