Your product has a custody provider, an internal operations team and an approval policy. A user requests a transfer. The release question is concrete: which combinations of people and permissions can make that transfer happen?
Testing those combinations gives the team something more useful than a screenshot of the settings page. It creates repeatable evidence about the behavior the product depends on.
Start with one business action
Choose one action, such as withdrawing an approved asset to an approved destination. Write down who may initiate it, who may approve it and what must block it.
Consider a fictional rule that requires an operator and an independent approver. The same person holding both roles should not satisfy the intended separation of duties. Whether a chosen provider enforces that exact distinction must be checked against its configuration and identity model.
Zodia describes white-label custody infrastructure for financial institutions. Tangany describes custody services for clients including banks, brokers and asset managers. These products establish the relevance of the integration boundary; they do not imply that either provider lacks controls. Zodia Solutions, Tangany overview.
Turn permissions into cases
For the chosen action, create a compact matrix of expected results. An eligible request with independent approval may proceed. A request with an unapproved destination must stop. A request with a revoked approver must be re-evaluated according to the selected system's semantics.
Each case needs the policy version, participating identities and expected decision. A failure should explain which condition was unmet.
Provider rule semantics matter. Fireblocks documents ordered policy evaluation. A broad earlier rule can change how later rules apply, so testing the policy as a whole is more informative than reviewing each rule in isolation. Fireblocks policies.
Check the alternative paths
The application may have several ways to initiate an operation: a customer workflow, an internal dashboard, an integration worker or a recovery procedure. A control review should identify all of them.
For example, an API handler may reject a withdrawal while an administrative route permits a similar operation. That can be intentional, but it needs explicit authorization, ownership and evidence. The test suite should reflect the design the institution actually approved.
Also decide what happens when policy or identity data is unavailable. A cached approval from yesterday may be inappropriate for today's request. The correct behavior depends on the chosen risk policy and implementation.
A small lab with a clear question
We built Permission Lab to compare a valid two-person approval with self-approval and an unapproved destination. It uses fictional identities and a simplified rule model. Each scenario shows ALLOW or BLOCK alongside the reason.
The simulation covers independent approval and destination eligibility. Real custody configuration, the provider's complete policy engine and security certification require separate review. It handles no keys, assets or customer information.
The production opportunity is the surrounding integration work: translate approved controls into tests, connect the provider, cover administrative paths and make failures understandable to operators.
Bring a workflow and its policy
dOrg can review a narrowly defined custody integration and assess the engineering needed to make its permission boundaries testable. The institution and custody provider retain their own responsibilities, and production access requires the appropriate review.
Sources checked September 8, 2026. All examples use fictional test cases; provider-specific behavior requires validation.