Counterparty Types
What this screen is for
A counterparty type is a label for the kind of organization you exchange with: a card network, a processor, a regulator, a correspondent bank. This screen is the catalog those labels come from. It shows two kinds of row side by side: Platform types, defined by the platform administrator and visible to every tenant, and Custom types, which belong to your tenant alone. A type has a code, a display name and an optional description, and nothing else.
A type is chosen for an external counterparty at an endpoint of a cryptographic exchange, and that is the only thing it is used for. The platform does not authorize, restrict or route anything by it; it is a classification for your own governance, and its one consequence in the platform is that a type an exchange names on an endpoint cannot be deleted.
What must exist first
This screen is for tenants that compose authorization by hand. It is not offered to SIMPLE tenants, and the server refuses a SIMPLE tenant's changes to the catalog even when the request reaches it.
Before you work here:
- The permission to list counterparty types, which is what shows the catalog. Without it the screen says so and shows nothing.
- The permissions to create, update and delete counterparty types, each held separately. Without the create permission New counterparty type is shown disabled and names the permission to ask for; without the other two the row's edit and delete controls are disabled. On a RAPIDAPI tenant the create control is not shown at all.
Nothing needs to exist before a type. It is the exchange's endpoint that takes the type, not the other way round.
Decisions you make here
Creating a type
New counterparty type asks for three things:
- Code, required: uppercase letters, digits and underscores, 1 to 64 characters. The field uppercases what you type. The code is permanent once saved.
- Display Name, required, up to 128 bytes of text. It is what the exchange editor shows beside the code when a type is chosen.
- Description, optional, up to 4,000 bytes of text (fewer characters in scripts that need several bytes per character).
The code must be unique within your catalog. Creation is refused when your tenant already holds the code or when a Platform type carries it, because a custom type with a Platform type's code would shadow it in your list. Another tenant using the same code is not a conflict and is never consulted.
Editing a type
The pencil on a Custom row changes its display name and description. The code is shown read-only and cannot be changed by any means: a request that carries it is refused. The display name cannot be left blank. Emptying the description clears it.
A Platform row cannot be edited from this screen: its controls are disabled with the note Managed by platform, and the server refuses the change regardless. Platform types are maintained by the platform administrator in the platform settings.
Deleting a type
The bin on a Custom row removes the type permanently after you confirm. The deletion is refused when any cryptographic exchange of your tenant names the type on an endpoint, and the refusal says how many exchanges do. An exchange keeps its endpoints for good, revoked or discarded, so a type an exchange has named cannot be deleted.
A Platform type cannot be deleted here.
Choosing a type is a one-time decision
The type is picked in the Endpoints step of the exchange editor, from this catalog, for an endpoint that is an external counterparty, and it is optional. Once the exchange is active its endpoints are read-only: to change one, clone the exchange. The exchange list shows the counterparty's free-text name, not its type; the topology shows the type's code under that name.
How it relates to other screens
A type exists to be chosen on an exchange's external endpoint, in the exchange editor:
The counterparty an endpoint names is free text, separate from its type. The exchange list filters by that text, and the topology draws one card per counterparty name and type: