What is banking segregation of duties testing?

Banking segregation of duties testing checks whether access permissions and workflows prevent one person from completing incompatible actions in a financial process. It verifies that role combinations, user assignments and application controls enforce the bank's defined separation rules, such as requiring a second authorised user to approve a payment prepared by another user. It also checks that violations are detected and recorded where preventive controls cannot apply.

What the testing covers

Segregation of duties (SoD) rules identify activities that should be separated to reduce the risk of error, misuse or unauthorised transactions. A rule might prohibit the same user from creating a beneficiary and approving a payment to that beneficiary. Another might separate loan application approval from loan disbursement.

Testing uses the bank's control rules, role definitions and process requirements as expected results. It checks role-based access control (RBAC), where permissions are assigned through roles, alongside workflow rules and enforcement in connected systems. A user may have no conflicting permissions in one application yet receive them through a second role, an inherited group or access granted in another application. Testing should account for those combinations where they fall within scope.

Controls can prevent a user from performing a restricted action, or detect a conflict for review. Tests should verify the intended behaviour for each control. For preventive controls, an unauthorised action should be denied. For detective controls, the conflict should generate the required alert or report, with enough detail for investigation.

How to test segregation of duties

Start with an approved SoD ruleset or risk and control matrix. Confirm which systems, roles, user types and processes are in scope, and define the expected result for each conflicting permission or action. Prepare test accounts with known role assignments and representative data. Include combinations such as a single role, multiple roles, inherited access and a recently changed entitlement.

Test both access and transaction behaviour. Check that restricted functions are unavailable or rejected at the application programming interface (API) as well as in the user interface. Then exercise the full workflow, including approval, rejection, cancellation and any permitted exception path. Review audit records and monitoring outputs to confirm that denied attempts and detected conflicts are captured as required.

A useful test set includes valid combinations, prohibited combinations and boundary cases. Examples include a user whose access has just been removed, a payment that crosses an approval threshold, or two actions performed by the same identity through different channels. Verify that the application uses the correct user identity and current permissions throughout the workflow.

Practical example: payment approval

Assume policy states that the user who prepares a corporate payment must not approve that payment. Set up two test users: one with payment preparation permission and one with approval permission.

1. User A prepares a payment. Confirm that the payment enters the pending approval state and records User A as its preparer.
2. User A attempts to approve it. The system should reject the action and record the denial.
3. User B approves the same payment. Confirm that approval succeeds and the audit trail identifies User B as the approver.
4. Assign approval permission to User A as well, then repeat the test. Confirm that the system enforces the conflict even when both permissions are available to the same identity.

The expected result depends on the bank's documented control design. A failure includes a restricted action succeeding, an invalid identity being recorded, or a required alert or audit record being absent.

Common failure modes and limits

Tests can miss conflicts when they check role definitions in isolation and omit effective access assembled from multiple sources. Other risks include enforcement in the interface only, stale permissions after role changes, inconsistent rules across channels, and test environments whose configuration differs from production. Validate that test data and access assignments reflect the target configuration, and investigate environment drift before treating a result as evidence.

A passing test supports confidence in the controls that were exercised. It does not establish that every access path, role combination or applicable compliance obligation has been covered. Keep test results traceable to the approved SoD rules and record any exclusions or compensating controls.