Exchange Contexts
What this screen is for
An exchange context models one governed business relationship in which cryptographic work happens: card embossing with a card brand, collections with an outsourcing provider, reporting to a regulator, or an internal pipeline. It records the application that owns the relationship, the counterparty, the direction the data flows and the business purpose.
Capability grants can be scoped to a context, so the same actor can be authorized differently in different relationships, and one action on the context stops or resumes all of that work at once. Operations performed in a context carry its counterparty and direction into the audit trail.
What must exist first
This screen is for tenants that compose authorization by hand. It is not offered to SIMPLE tenants: a SIMPLE tenant uses Internal Use Cases, which create the exchange context each use case needs.
Before you work here:
- An application to own the context. The application choice is filled with your permission to list applications; without it the list is empty and no context can be created.
- The permission to list exchange contexts, which is what shows this screen. Creating, editing, suspending, reactivating, closing and deleting a context are further permissions, each held separately.
Decisions you make here
Creating a context
With the permission to create exchange contexts, New Exchange Context asks for:
- Parent Application, required: the application that owns the relationship.
- Name, required and unique within that application.
- Direction, required:
OUTBOUNDwhen you send data to the counterparty,INBOUNDwhen you receive it,BIDIRECTIONALfor both, orINTERNALwhen the flow stays inside your tenant. - Sensitivity: the classification of the data exchanged,
PUBLIC,INTERNAL,RESTRICTEDorCONFIDENTIAL, withINTERNALas the default. It is recorded for your own governance; the platform does not restrict operations by it. - Counterparty, an optional Counterparty Type from your tenant's catalog, a Display Name and a Business Purpose.
The context is active as soon as it is created. Its application, name and direction cannot be changed afterwards, so settle them before you create it.
Editing a context
With the permission to update exchange contexts, the Edit tab of a context's detail changes its display name, description, counterparty, business purpose and sensitivity. Emptying a field there keeps its previous value rather than clearing it.
Suspending and reactivating
With the permission to suspend exchange contexts, Suspend on the Lifecycle tab stops the relationship at once: every operation bound to the context is refused, whichever grant would otherwise authorize it. You must give a Reason for suspension, which is recorded in the audit trail against your account.
Nothing is revoked by a suspension. With the permission to resume exchange contexts, Reactivate returns a suspended context to active, and the same grants authorize again.
Closing a context
With the permission to close exchange contexts, Close (terminal) ends the relationship permanently, whether the context is active or suspended. A closed context can never be reactivated. Grants scoped to it are not revoked; they stop authorizing anything, and they stay listed until you revoke them.
Suspend when the relationship will resume. Close when it has ended.
Deleting a context
With the permission to delete exchange contexts, Delete (permanent) is offered only for a closed context, and you confirm it by typing the context's name. The deletion is refused while active capability grants or cryptographic exchanges still reference the context, so revoke those first. A deleted context cannot be restored.
How it relates to other screens
Grants are scoped to a context when they are created, and a grant's actor is what performs the operations inside it:
Every context belongs to an application, and deleting that application closes its contexts:
Cryptographic exchanges also reference contexts, and one that has not ended blocks the context's deletion.