A party is anyone or anything a matter involves: a client, a counterparty, a company, a regulator. The stakeholder registry is the single place those records live and the place their relationships are drawn. It is where you keep a person’s details current, see how parties relate to one another (a director of a company, a shareholder, a beneficial owner), and hold the “know your client” standing that regulated work depends on. Because every matter, document, and form reads parties from here, the registry is the one source of truth for who is who across the whole workspace.
What it does
One record per person or company. Add a party and you get a governed record with its core identity (display name and the fields that distinguish it) that you can read back, keep current, and reference from anywhere. A party is created once and reused everywhere a matter needs it, so a client’s details are captured a single time and not re-keyed into every new piece of work. Identity facets are deduped on creation: the same identifier always hashes to the same value and the unique index fires, so the registry pushes back against the same person being entered twice.
Relationships between parties. Parties do not sit in isolation: the registry records how they relate. A party relationship carries a role (director, shareholder, beneficial owner, secretary), a share percentage where it applies, a status, the dates a position was appointed and resigned, and whether the holder is a nominee. This is what makes the registry a set of company registers, not just an address book: read a company’s relationships and you get its directors, shareholders, UBOs, and secretaries, each with the standing detail you need. When someone resigns, the relationship is marked inactive with a resignation date rather than deleted, so the history of who held what role and when stays on the record.
KYC standing, derived not stored. Each party carries its “know your client” standing: the KYC status, risk level, PEP flag, sanctions-match flag, nationality, when it was verified, and when it expires. A KYC review rewrites the standing fields and, on a verified outcome, derives the expiry date from the verification date plus the configured validity period, so a verified party never lands without an expiry. The firm-wide KYC-expiry register is then a filter over that derived standing: who has expired, who is expiring soon, and the earliest expiry on the books, computed on read rather than read off a status field that could drift out of date.
Typed facets for the sensitive detail. Beyond the core record, a party can carry typed facets: KYC detail, corporate detail, equity detail, and a portal-principal facet. KYC facets hold regulated personal data, the most sensitive material in the product, so they are encrypted before they are written and never read back in the clear. A KYC review is deliberately a partial update: it touches only the supplied standing fields and leaves every encrypted facet column byte-for-byte untouched, so re-verifying a party never disturbs the protected detail underneath.
A consolidated profile read. Ask for a party’s profile and you get its standing in one read: the core record, a summary of its relationship edges (counts by status, not the full graph), and its KYC standing (status, risk, flags, dates, nationality). No decrypted personal data ever crosses this read, the encrypted facet columns are deliberately not selected, so a profile, a list, or a register view never leaks the regulated detail held in the sensitive facets.
Lifecycle, kept honest. Parties have a managed lifecycle rather than a delete button. An administrator can suspend a party, reactivate a suspended one back to active with a reason, archive a record so it stops being the active path while its history is kept, or merge duplicates into a single record. Reactivation refuses on an archived party because archive is terminal, and the lifecycle moves are status changes on the record, never inferred from a stray timestamp.
How you use it
Add and maintain a party. Create the person or company once, then keep the core fields current as they change. The registry is the canonical record, so a correction made here is the correction everywhere a matter references that party.
Read who relates to whom. Pull a party’s relationships to see the company registers: directors, shareholders, beneficial owners, and secretaries, each with role, share percentage, status, and the appointed and resigned dates. Filter by role, by status, or by a single party to answer a specific question about a position.
Record a change of position. When a director resigns, a shareholding changes, or a status moves, update the relationship: set the resignation date, the new share percentage, or the new status. The relationship stays on the record as inactive rather than vanishing, so the register reads true both now and as history.
Run and refresh a KYC review. Open a party’s KYC standing and run a review to rewrite the status, risk level, and the rest. On a verified outcome the expiry date is set for you. The encrypted personal detail is preserved through the review, so re-verification never asks you to re-enter the sensitive material.
Watch the KYC-expiry register. List parties filtered on derived KYC standing to see, firm-wide, who has lapsed, who is approaching expiry, and the earliest expiry coming up, so renewals are handled before they become a compliance gap.
Read a consolidated profile. Open a party’s profile for the core record, a relationship summary, and its KYC standing in one place. The read returns standing only: the sensitive facet detail stays encrypted and is never surfaced here.
Clean up and steer the lifecycle. Merge duplicates into one record, suspend a party that should be paused, reactivate it later with a reason, or archive a record to retire it while keeping its history. These are administrator actions and each one is permission-checked and audited.
The kernel verbs behind it
Each goes through the one front door: permission-checked and audited before it runs. These are the verbs most specific to the stakeholder registry.
Parties:
party.create- add a new person or company to the registry.party.get- read one party’s record.party.list- list parties by type, status, or feed; filter on derived KYC standing for the firm-wide expiry register.party.update- edit a party’s core fields (display name).party.profile- read the consolidated standing: core record, relationship summary, and KYC standing in one call.
Relationships:
link.create- record a party relationship (a director, shareholder, or other position).link.query- read the relationship links.link.update- set the resignation date, share percentage, or status on a relationship (resignation marks it inactive, not deleted).party.relationship.list- read the company registers (directors, shareholders, UBOs, secretaries) with role, share percentage, status, and appointed and resigned dates.
KYC and facets:
party.facet.set- write a typed facet (KYC, corporate, equity, or portal-principal); KYC facets are encrypted before write.party.kyc.review- the partial KYC re-verify: rewrite only the supplied standing fields, derive the expiry on a verified outcome, and preserve every encrypted facet.
Lifecycle:
party.merge- fold duplicate records into one.party.suspend- pause a party.party.reactivate- flip a suspended party back to active, with a reason (refused on an archived, terminal record).party.archive- retire a record while keeping its history.
See the full set in the party verb reference.