Custody risk concerns holding and safeguarding the token or reserve relationship, while payment workflow risk concerns who can initiate, approve, and encode transfers. Banks can have strong custody practices and still fail at payment governance if APIs, smart contracts, or delegated service access are not tightly controlled.
Custody Risk Is About Safeguarding the Asset Relationship
Custody risk is the risk that the token, reserve, or the control of the underlying asset relationship is lost, corrupted, misappropriated, or left insufficiently segregated. The focus is on safekeeping, legal and operational control, reconciliation, and whether the custodian can actually preserve value and entitlement under stress.
That means custody risk can exist even when payment operations are well designed. A strong custody model should answer basic questions about who holds assets, how holdings are segregated, how backing is evidenced, and how loss, freeze, or insolvency would be handled.
Payment Workflow Risk Is About Who Can Move Value
Payment workflow risk is the risk that transfer initiation, approval, encoding, routing, or execution can be abused, bypassed, or misrouted. The subject is not whether the asset exists, but whether the workflow that converts intent into a transfer is tightly controlled and auditable.
This is where PCI DSS v4.0 becomes relevant for payment environments, because it reinforces least-privilege access and control over system and application accounts that can initiate or interact with payment functions. If APIs, service access, or delegated approvals are weak, the workflow can be abused even when custody itself remains intact.
Why the Difference Matters in Practice
The two risks fail differently. Custody failures usually threaten asset loss, reserve mismatch, commingling, or inability to honor claims. Payment workflow failures usually threaten unauthorized transfers, duplicate sends, fraudulent approvals, replayed instructions, or faulty straight-through processing.
That distinction matters because the controls are not interchangeable. Custody controls center on asset segregation, reconciliation, proof of reserves, and resilience of the holding relationship, while workflow controls center on authorization, transaction integrity, privileged access, API governance, and separation of duties. A system can be excellent at one and weak at the other.
For transfer paths that rely on software interfaces, workflow integrity is often the more fragile layer. If a smart contract, treasury API, or delegated service account can be used to create or approve transfers, the risk is not just technical compromise, but unauthorized business action with direct financial impact.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and PCI DSS v4.0 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| PCI DSS v4.0 | 7.2 — Restrict Access to System Components and Cardholder Data by Business Need to Know | Payment workflows depend on tightly limiting who can initiate or modify transfers. |
| 8.6 — Use of System and Application Accounts and Authentication Factors | Service and application accounts can directly drive payment execution and approval paths. | |
| Recommendation — Restrict transfer-related access to the minimum roles needed for payment operations. Control and monitor application accounts that can initiate or approve payment actions. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Separates payment initiation authority from custody and administrative access. |
| IA-5 — Authenticator Management | Workflow risk increases when credentials or tokens used for transfer actions are weakly managed. | |
| Recommendation — Apply least privilege to every role that can create, approve, or route transfers. Rotate and protect authenticators used by payment automation and delegated services. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | APIs that can initiate or approve transfers must enforce function-level authorization. |
| Recommendation — Verify every transfer API enforces explicit function-level authorization. | ||
Practitioner Guidance
What to prioritise: Treat custody and payment workflow as separate control domains with different owners, evidence, and failure modes. If the question is “can the institution still prove and protect the asset,” you are in custody territory; if it is “can someone cause a transfer,” you are in workflow territory.
What to verify: Confirm that transfer initiation, approval, and execution are independently restricted, logged, and reviewable, especially where delegated credentials, APIs, or smart contracts can trigger movement. Do not assume that custody controls compensate for weak payment authorisation.
Common mistake: Teams often focus on reserve safekeeping and overlook the operational path that actually moves funds. That gap is where many real losses begin, because the asset can be safely held while the payment function is quietly abused.
Practitioner takeaway: Strong custody reduces the chance of losing the asset relationship, but strong payment governance is what prevents legitimate holdings from being turned into unauthorized transfers.
Related resources from NHI Mgmt Group
- What is the difference between attack surface management and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between human IAM controls and NHI governance?