Counterparty types
A counterparty type is a kind of party you hold on the book — a person, a company, a trust. Your organisation decides what the list holds. Adding a new kind is something you do on this screen, not something that waits for a release.
Every counterparty you register is one of these types, and the type decides what you capture about it and what roles it can hold.
What a counterparty type carries
| Field | What it is |
|---|---|
| Name | The stable identity everything else refers to. Fixed once you create it. |
| Label | What people read on screen. Rename it whenever the wording should change. |
| Plural name | The label’s plural, used in headings and lists. |
| Numbering scheme | How new counterparties of this type are numbered. |
| Allowed roles | The roles a counterparty of this type may hold. Leave empty to allow every role. |
| Requires a role | Whether a counterparty must hold at least one role. |
| Requires identification | Whether a counterparty must hold at least one identification. |
| Suspendable | Whether a counterparty of this type can be suspended. |
| Active | Whether the type is offered when someone registers a counterparty. |
The name is fixed once you create the type, because your other settings refer to it by that name. The label is not fixed — nothing refers to it.
Adding a counterparty type
- Go to Settings, then Counterparty Types.
- Select New Counterparty Type.
- Enter a Name, such as
PublicCompany. - Enter a Label, such as “Public Company”.
- Set the roles, numbering and switches you need.
- Select Create.
The new type is offered straight away wherever a counterparty is registered.
The property schema
Open a type to see its Property Types. Each property is a field you capture on every counterparty of that type — a registration number, a date, a reference to another record.
Add, edit and remove properties on that panel. Two things about a property are fixed once it exists: its Kind and its purpose roles. Both feed the counterparty’s display name and search, so they are set when you add the property and read-only afterwards. Everything else — the label, whether it is required — you can change.
Marking a property required warns you how many existing counterparties of this type do not carry it yet, so you know what you are asking for before you publish.
Staging and publishing
Changes here are staged, not live. Edit a type, add a property, deactivate one — the change sits in a draft until you submit it for approval from the bar at the top of the screen. Nothing you change takes effect until the draft is published.
Retiring a counterparty type
flowchart LR
A[Counterparty type in use] -->|Deactivate| B[Hidden from register<br/>existing counterparties unchanged]
A -->|Remove| C{Any type or relationship<br/>names it?}
C -->|Yes| D[Refused]
C -->|No| E[Gone]Deactivate is the everyday choice. Clear Active on the type. It disappears from the register screen, so nobody creates a new counterparty of it. Counterparties already registered as that type keep working exactly as before.
Remove deletes the type. It is refused while another type is based on it, or a relationship type hosts or includes it. The refusal names what still uses it.
What your organisation configures
Everything on this screen. The platform ships no counterparty types of its own — the list you see is the one your organisation set up, and you can add to it at any time.
The roles a type may hold come from your role types, and the relationships it can take part in from your relationship types.