Platform Counterparty Types
What this screen is for
A counterparty type is a label for the kind of organization a tenant exchanges with: a card network, a processor, a regulator, a correspondent bank. This screen is the platform half of that catalog. What you publish here is visible to every tenant, and every tenant sees it beside the types it defines for itself.
It is the one entry under Governance & Policy that holds no configuration value. There is nothing here to tune: the screen administers records with a lifecycle of their own, and the count badge the other two cards carry is deliberately absent from this one.
The platform ships none of these. Every row on this screen is an explicit decision somebody made.
This leaf is also where the old top-level Counterparty Types page went. A bookmark or a deep link to the retired address is redirected here, so an old link still lands on the right screen and the catalog has one home rather than two.
What must exist first
Every call behind this screen re-checks that your token carries the platform tenant before it checks anything else, and refuses with a bare Forbidden if it does not. Opening the screen while you are working inside a tenant sends you to that tenant's dashboard instead. Beyond that:
- The permission to list platform counterparty types. It is what puts the card in the governance group at all, and what fetches the rows. Without it the screen states which permission is missing rather than showing an empty catalog.
- Separate permissions to create, to update and to delete. Reading is not writing: without create, the New Platform Type button is absent; without update or delete, each row's two buttons are present and disabled.
- Platform configuration read is not one of these, and holding it does not carry them. The reverse also holds — the list permission alone is enough to reach this screen, even with no access to the settings catalogue.
Decisions you make here
What a type is, and what it is not
A type has a code, a display name and an optional description, and nothing else. A tenant chooses it for an external counterparty at an endpoint of a cryptographic exchange, and that is the only thing the platform does with it. Nothing is authorized, routed or restricted by a counterparty type; it is a classification for your own governance. Its one mechanical consequence is that a type an exchange names on an endpoint cannot be deleted.
Publishing a type
New Platform Type asks for three fields. The code is upper-case letters, digits and underscores, one to 64 characters, and the field upper-cases what you type. The display name is required, up to 128 characters. The description is optional, up to 4000. The code is permanent: once the row is saved the code is never editable again, here or anywhere else, so it is the one field worth deciding before you click Create.
One code namespace, across the whole platform
A code is unique across the catalog as a whole. Your types may not collide with each other, and they may not collide with a code any tenant already holds locally — either collision is refused with a conflict rather than silently accepted.
The second refusal is deliberately narrow about what it tells you: the code is taken by one or more tenants, and no tenant is named. A tenant's own catalog is not enumerable from this screen. Two different tenants may hold the same local code between them; what the platform prevents is one code being both platform-global and tenant-local, so that a code in a tenant's list is never ambiguous.
Editing and retiring a type
Editing changes the display name and the description. The code field is shown, disabled, so you can read it while you edit the rest.
Deleting removes the type from the platform catalog and from every tenant's view at once, and it is refused when any tenant's cryptographic exchange names it on an endpoint. An exchange keeps its endpoints for good, revoked or discarded, so such a type stays in the catalog. The refusal counts the exchanges and their tenants and carries the ids of those tenants, capped at 100 while the count in the message is not, so a heavily used type counts more tenants than it lists.
When the list cannot be read
A failed read replaces the table rather than appearing beside it. An empty table asserts that nothing is configured, and on a failed read that is a false statement about the deployment. The card header and the New Platform Type button stay live, so a failed list does not lock you out of the screen.
How it relates to other screens
This leaf is the third card of the governance group, and it is reached through Platform Settings like every other entry there:
What a tenant does with a type you publish here is decided on the tenant's own screens. A tenant sees your types marked Platform and cannot edit or delete them, and it chooses one for an external endpoint in the exchange editor: