Access changes and offboarding
Retire people and integrations while preserving outstanding obligations and evidence.
Retire access without abandoning obligations
When someone leaves, a connection is replaced or an integration is retired, first hand over outstanding payments, approvals and reconciliation work. Removing access does not remove tokens, release locked funds or settle a cash obligation.
The bank's administration and security teams change access. Business and operations owners review remaining balances and obligations and preserve the evidence required by the bank. Deployment closure and custody or ledger changes follow the agreed operator process. The steps below cover the access and connection changes separately.
Decide what is being retired
Removing a team member, replacing a machine client, retiring one integration and closing a bank's deployment are different changes. Record the scope, authorised change owner, effective time, affected workflows and replacement responsibilities. The external API does not provide a whole-bank offboarding or deletion operation.
Access removal does not burn tokens, settle a cash obligation, cancel a lock or erase audit evidence. Coordinate remaining value and pending work separately.
1. Hand over outstanding work
Before revoking the identities used by your adapter, inventory unresolved operations, approvals, automations, webhook deliveries, customer/account balances and known locks. Assign a surviving identity and team to outcome recovery and reconciliation. An access change must not leave a payment or approval without an owner.
For an approver's departure, inspect pending requests/tasks and reassign eligible pending tasks using the documented endpoint. Review approval groups and policy references before removal or deactivation; a policy referencing a deactivated group fails evaluation. The initiator must not approve their own request.
2. Remove or change user access
Use the tenant-scoped team-member API for authorised removal, or change the member's role for a role change. The member record is retained. A user cannot remove themselves or the tenant owner; arrange ownership changes through the operator.
Check the resulting membership and configured access behavior. Revocation of refresh tokens does not guarantee immediate invalidation of an already issued access token; account for configured token lifetime and gateway controls. See Authentication.
3. Replace or revoke machine credentials
A machine client is managed through the assigned identity provider and onboarding process, not created or revoked by a generic token-operation endpoint. Give the replacement only the required permissions, store its credentials in the backend secret manager and test it before cutting over. Revoke the old client through the identity provider and verify that fresh tokens cannot be issued under the old credentials.
Use the deployment's approved rotation and emergency-revocation procedure. Coordinate custody credentials separately with their owner. Do not copy a departing employee's user token into a server application.
4. Retire automation and event connections
Pause automations through ACTIVE-to-INACTIVE before deciding whether to disable them permanently; DISABLED is not the reversible maintenance state. Verify their status history and retain script/version and execution identifiers. An accepted run may remain in flight, and the public API does not provide its final outcome; obtain operator evidence.
For a receiver replacement, register and test the new destination, preserve deduplication across any overlap and compare subscription coverage. Subscription changes do not backfill previously undelivered events. Drain or reconcile the old receiver's work before retiring it. Deleting a webhook registration cancels its queued deliveries, so preserve delivery evidence and plan recovery first. Rotate HMAC secrets when appropriate; never log the returned secret.
5. Resolve resource obligations and retain evidence
Reconcile balances, locked value, confirmed movements and bank cash postings before agreeing resource retirement. Customer deactivation also deactivates ACTIVE accounts; reactivating the customer does not reactivate those accounts. Inactive accounts retain their wallet and readable balances. Deactivation is not balance removal, and references are not released for reuse.
Agree any redemption, migration or deployment closure with the bank's business owner and Quant/operator. There is no customer balance-migration endpoint. Export required activity evidence and retain the bank's instruction journal under its retention rules. Infrastructure destruction and ledger/custody closure belong to the separately authorised operator process.
6. Verify and close the change
Record retired identities and destinations, final resource statuses, remaining obligations, evidence locations and handover owners. Confirm expected access removal and that surviving integrations still receive outcomes. Keep unresolved obligations open in your bank's tracking system rather than treating revocation as settlement.
%%{init: {"theme": "neutral"}}%%
flowchart TB
Scope["Agree retirement scope and owner"] --> Handover["Assign pending obligations"]
Handover --> Access["Change access and credentials"]
Access --> Connections["Retire automations and receivers safely"]
Connections --> Value["Reconcile remaining value and preserve evidence"]
Value --> Verify["Verify access removal and surviving workflows"]
Worked example
Illustrative request and response from the published contract. Replace identifiers and credentials with those assigned to your environment. This example is not a live test result.
GET /api/accounts/ACC-0001 HTTP/1.1
Host: api.qfp.quantnetwork.net
Authorization: Bearer <access token>
API-Version: 1.0.0HTTP/1.1 200 OK
Content-Type: application/json
{
"accountRef": "ACC-0001",
"customerRef": "CUST-0001",
"assetId": "GBP",
"status": "ACTIVE",
"walletAddress": "0x4E55aD154FFfE514D7dEF1658dEbe593907121ae",
"createdAt": "2026-08-03T09:29:10.285Z",
"updatedAt": "2026-08-03T09:29:14.911Z"
}View in API Reference
- Get an account ·
GET
Read the account before deciding its retirement treatment, then read its balances and inspect known locks and unresolved operations. An ACTIVE status or a wallet address says nothing about whether the bank's obligations are cleared.
API Reference
Open an endpoint for request fields, response examples and the interactive API console.
Related pages
Updated 2 days ago