Onboarding is the institution's first compliance artefact.
Not a signup form. Five gates to join, each producing evidence a risk function can hand to a supervisor. Once through, the same six checks run before every trade settles.
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.
Nothing here changes your stack.
The agent stays as built — IAP runs as a sidecar beside it, mediates the handshake and holds nothing. Your keys stay in your infrastructure, your model is never touched, and every check runs inside controls your risk team defines.