A financial platform must demonstrate segregation of duties. What is the concrete test, and where does it usually fail?

The concrete test

Can any single credential — including a database administrator, a root cloud account, a deployment pipeline or an on-call engineer — both initiate and approve a movement of value?

If yes, the segregation exists on paper. The answer is frequently uncomfortable, and it is the question that distinguishes a real control from a documented one.

Where it usually fails

• Database access. An administrator who can update a row can approve a payment regardless of what the application enforces — which is why the enforcement must be at a boundary the database cannot bypass, such as a signing service or an external approval record the payment path validates.
• The deployment pipeline, which can change the code that enforces the approval. A pipeline with production write access is a path around every application control, and it is rarely counted in the segregation analysis.
• Break-glass access, granted for incidents and standing rather than just-in-time, exercisable without an approval or a record.
• Approvals sharing an identity provider account, so one compromise satisfies both — segregation that shares an identity is not segregation.
• Support tooling, which is broad by necessity and least covered by customer-facing controls.

What makes it real

• Policy enforced outside the application, at a signing boundary or in an approval service the payment path must consult.
• Genuinely separate credentials, devices and people for multi-party approval above a threshold.
• Just-in-time elevation with an expiry, an approval and a recorded justification, rather than standing broad access.
• Immutable audit of every privileged action, exported outside the platform's own trust boundary so detection does not depend on the system being investigated.
• Thresholds on bulk operations, since mass action is the highest-damage capability available and requires confirmation above a proportion.

The framing that gets it prioritised

Assume the platform will be compromised and design so the compromise is bounded and detectable. For a platform handling value, the ability to describe what an attacker with any single credential could and could not do is itself a product requirement — and increasingly what enterprise customers audit.