How to test banking maker-checker workflows

Banking maker-checker workflow testing verifies that a banking operation follows its configured preparation, review and authorisation rules. It checks that the maker can create or amend an item, an eligible checker can review it, and the workflow blocks unauthorised approval or execution. Tests also confirm that state changes, permissions and audit records remain consistent across the systems involved.

Define the workflow and its controls

Start with the operation under test, such as a corporate payment, customer-detail change or lending decision. Record its permitted states, transitions, approval conditions and outcome. A typical payment may move from draft to submitted, pending approval, approved and then released, though the actual states depend on the bank's design.

Identify the roles and rules that govern each transition. These can include maker-checker separation, approval limits, account or entity scope, number of required approvals, delegation and whether a checker must hold a particular entitlement. Role-based access control (RBAC) testing checks access by role; workflow testing checks that access is applied correctly at each point in the process.

Confirm preconditions before execution. Use test users with known entitlements, a controlled test account and data that meets the workflow's validation rules. Check that the test environment has the relevant approval configuration, calendars and downstream services. Configuration differences between environments can produce misleading results.

Test the main path and rejected actions

Exercise the complete path from creation to the defined business outcome. Verify the submitted values, approval status and any downstream action, such as payment release or ledger posting, according to the system's design. Where systems exchange events or API messages, check that the receiving system processes the correct item once and reports its status accurately.

Test prohibited actions as deliberately as permitted ones. A maker should be unable to approve their own item if separation of duties is required. A user without the correct role, account scope or approval limit should be unable to approve it. Check direct URLs, user-interface controls and relevant application programming interface (API) requests where these are part of the system boundary. Hiding an approval button alone does not prove that the action is protected.

Test changes to an item after submission or approval. The expected behaviour may be to invalidate the approval, return the item for review or prevent amendment. Confirm the configured behaviour, including which fields trigger reapproval. Also test cancellation, rejection, resubmission and expired or withdrawn approval, where those states exist.

Check audit records and cross-system outcomes

For each action, verify that the audit record identifies the actor, action, affected item, time and outcome, and preserves the relevant before-and-after values where required by the design. Confirm that rejected attempts and failed transitions are recorded consistently with the audit requirements. Link evidence to the test case and use controlled, non-production data.

Follow the item into dependent systems when approval triggers another process. Check that retries, timeouts or duplicate messages do not create duplicate execution. If a downstream service is unavailable, verify the configured pending, retry or failure state and confirm that the item cannot appear successfully completed while its outcome remains unresolved.

Practical example: corporate payment approval

Assume the configured rule requires a second user to approve a submitted payment, and the maker cannot approve their own payment. Create a payment for £12,500 using a maker account, then submit it.

Verify that its status becomes pending approval and that no release occurs at submission. Attempt approval as the maker and confirm that it is denied, with no status change. Sign in as an eligible checker and approve the payment. Confirm that the workflow records the checker and approval time, then verify the configured release outcome in the payment service or downstream system.

Repeat with a checker whose limit is below the payment amount, and with a payment value at the configured limit boundary. Assert the exact expected result for each rule. If the maker edits a field that requires renewed review, confirm that the previous approval is invalidated and the payment returns to the expected state.

Make results dependable

Use separate user identities for maker and checker; shared accounts cannot prove separation of duties. Reset workflow state and test data between runs, and avoid relying on a previous test's approval. For automation, assert business state and audit data through stable interfaces where available, rather than treating a screen message as proof of completion.

Record the rule under test, user entitlements, input data, observed state transitions and downstream result. When a test fails, compare the workflow configuration, identity permissions, environment version and integration responses before attributing the defect to application logic. This helps distinguish a genuine control failure from environment drift or test-data setup errors.