Core concepts

Five ideas explain most of the platform's behaviour. Once you know how tenants, applications, pairs, and intake labels relate, and why two things are frozen, the rest of this documentation follows the same model.

Tenant

Your organisation. Every record belongs to exactly one tenant, and tenants are fully isolated from one another. If the same person applies to two tenants, they are two separate identities with no shared data.

Application

Also called a case. One counterparty's onboarding record: their answers, documents, related parties, screening results, risk rating, decisions, and audit history.

Pair

An intake is a pair: a form, meaning the questions, bound to a risk engine, meaning how the answers score. They are validated together, so a risk engine can never reference a question the form does not ask. You can run several pairs at once, for example one for corporate counterparties and one for strategic partners.

Intake label

The pointer that makes a pair live and selectable. A pair is inert until a label points at it. This is what lets you build and revise an intake without any in-flight applicant seeing the change.

Applications are provisioned against a label, not against a pair directly. That matters when you integrate: the optional labelId on the Onboarding API selects which intake a new application uses.

Freezing

Two snapshots protect the integrity of a rating.

Where these appear

• Roles and access: who can configure pairs and labels, and who can only work cases.
• Onboarding lifecycle: how an application moves from creation to a decision.
• Risk rating: what the risk engine half of a pair actually does.
• Glossary and quick reference: every term in one place.