Onboarding is the institution's first compliance artefact.
Not a signup form. Five gates, each producing evidence a risk function can hand to a supervisor.
Example data for a fictional UK challenger bank. No account is created here.
Bind the tenant to a legal entity, not to an email address.
Register institution
- Work email
- t.whitlock@example-bank.co.uk
Domain must match entity
- Registered entity
- Example Challenger Bank plc
- Company number
- 09482771
- LEI
- 213800EXAMPLE0000LEI
- FCA firm reference
- 774310
- Regulatory status
- UK authorised — deposit taking
- The tenant is bound to a company number and FCA firm reference, not a self-declared name.
- Every downstream identity claim resolves back to this record.
- At design-partner stage, each applicant is approved by a human at IAP.
Entity attestation
type: entity_attestation entity: Example Challenger Bank plc companies_house: 09482771 fca_frn: 774310 reviewer: manual / IAP compliance status: awaiting_approval
Tamper-evident, attributable, and included in the closing attestation pack.
Two rules the sequence never breaks.
Nothing is skippable, everything is resumable
Institutional onboarding runs across weeks and across departments. The flow holds state, shows exactly which gate is blocking and who is holding it, and never asks a bank to complete it in one sitting.
It ends with something a supervisor can read
The final step emits an attestation pack: entity record, accountability record, signed mandate, dry-run manifest and counterparty attestation, in one document. That pack is the reason a CRO signs off.
The full onboarding specification is in the data room.
Including the attestation pack format, the supervised-mode release criteria and the design-partner deployment sequence.