Guides
Onboard a customer
From a submitted CDD form to an approved, risk-rated relationship.
Written for: Relationship and front-office users
Written from docs/adr/0024, api/openapi/openapi.yaml
Onboarding is one call and one transaction. It creates the party with its names, identifiers and attributes; the customer relationship and its tier; and the submitted CDD answers stored verbatim against the form version in force.
The sequencePermalink to this section
- 1
Fetch the form in force
GET /v1/cdd-forms returns the questions and their keys for the tier you are onboarding into.
- 2
Submit the customer
POST /v1/customers carries the party, the relationship, the tier and the answers together. Splitting them would permit a party with no customer, or a customer with no captured CDD.
- 3
Attach evidence
Identity and address evidence is uploaded against the customer. Each identifier records whether it was authoritatively verified, format-checked, or supplied unverified.
- 4
Let risk score
Factors from the content pack produce a band, and categorical triggers fire independently of it.
- 5
Send for approval
Approval is maker-checker: the approver is a different person from the submitter.
What blocks approvalPermalink to this section
- A required CDD answer that was never captured.
- A tier whose evidence requirements are unmet.
- A tier requiring authoritative identifier verification, where no verification adapter is configured — see the note on the parties and customers page.