CAP 138
| Category: | Identity & access |
| Business Goal: | BG-001 — Frictionless digital onboarding; BG-011 — License the platform |
| System Domain: | SD02 — KYC Platform |
| Satisfying Module: | MOD-096 Multi-entity party graph manager (module in design) |
| Architecture: | Customer, party and user schema |
Description¶
A single user login can see and operate across all parties, accounts, and operating contexts to which that user has been granted access — their own personal accounts, their sole trader business, their rental properties, their Ltd companies as director, and organisations (charities, clubs) where they hold a governance role such as treasurer.
The user experience is a unified "financial universe" view. The underlying model is a party graph with explicit role relationships and access grants — not a flat customer-with-flags model. This is the difference that makes DCS, AML/CFT, and CRS compliance structurally correct rather than approximate.
What a user sees¶
A single authenticated session surfaces:
| Context type | Example | Legal basis |
|---|---|---|
| Personal banking | Savings, transaction, wallet accounts | Account holder |
| Sole trader activity | "My Consulting" income/expense view | Same legal person, different operating context |
| Rental properties | "12 Smith St" P&L, ring-fencing position | Asset owner's operating context |
| Ltd company | Acme Holdings Ltd accounts | Director + authorised signatory |
| Charitable/NGO | Wellington Community Trust accounts | Treasurer role + access grant |
| Family account | Joint account with partner | Joint account holder |
Key design rules¶
- One user_id, one person party_id. The user_id never changes across role changes or new entity additions.
- Access ≠ ownership. Having access to the charity's accounts does not make the user the depositor. Regulatory views (DCS, CRS) use the account_party_relationship model, not the access_grant model.
- Roles are explicit relationships. TREASURER, DIRECTOR, BENEFICIAL_OWNER are rows in Party_Role — not UI labels or permission flags.
- Context switching, not account switching. The user navigates contexts within one session, not between separate logins.
Regulatory correctness¶
The DCS Single Depositor View for this user's personal accounts is computed independently from the charity's SDV. The user's personal deposits and the charity's deposits are never aggregated. The AML/CFT customer graph for the Ltd company includes the user as beneficial owner and director — not as a "customer of the account."
Onboarding implications¶
Adding a new entity to a user's view (e.g. becoming treasurer of a new charity) requires: - Party creation or lookup for the charity - Party_Role creation (TREASURER) - Access_Grant creation with appropriate permissions - The charity goes through its own KYC/CDD workflow independent of the user's personal relationship
This is additive — it does not re-trigger the user's personal KYC.