Banking four-eyes approval testing verifies that a banking transaction or sensitive change requires approval by a second, separately authorised user before it can proceed. It checks the configured approval rules, separation between the person who creates or changes an item and the person who approves it, and the evidence recorded throughout the workflow.
How four-eyes approval works
A four-eyes workflow, also called maker-checker, assigns separate actions to different users. A maker enters a payment, changes a beneficiary or prepares another controlled item. A checker reviews and approves it. The application should enforce the bank's configured policy at the relevant points in the workflow.
The policy may define which actions need approval, who can approve them, whether approval depends on value or account type, and what happens when an item is amended, rejected or cancelled. Requirements vary by product and bank. Tests should use the documented policy and configuration as their expected results.
Approval depends on identity and entitlement data. The maker and checker need distinct user identities, and the checker must have the required permissions for the action and account. This is where four-eyes approval testing overlaps with [role-based access control testing] and [segregation of duties testing]. It also depends on reliable workflow state, transaction data and audit logging.
What to verify
Test the permitted workflow alongside attempts that should be blocked. Confirm that a maker cannot approve their own item, an unauthorised user cannot approve it, and a transaction cannot be released while approval is pending. Check that approval applies to the exact item reviewed, including its amount, beneficiary and other controlled fields.
Exercise relevant state changes. For example, test whether editing an approved payment returns it to a state requiring approval, and whether rejection prevents release. Check behaviour for repeated approval requests, duplicate submissions, expired or disabled users, and concurrent actions where these cases are covered by the requirements.
Verify enforcement at each access path. A disabled or hidden approval button is insufficient if an application programming interface (API) or another channel can still approve the item. Check that the server rejects unauthorised requests and that unsuccessful attempts leave the payment in the correct state.
Inspect the audit record as well as the screen result. Evidence should identify the action, the relevant users, the item and its state change, with timestamps or other fields required by the system's audit requirements. Confirm that rejected attempts and amendments are recorded where specified.
Practical example
Suppose policy requires a second user to approve a business payment above a configured threshold. Prepare test data with separate maker and checker accounts, plus a user who has no approval entitlement. Submit a payment above the threshold and verify that it remains pending and cannot be released. Approve it as the authorised checker, then confirm the resulting state and audit record.
Repeat with the maker attempting approval and with the unauthorised user. Both requests should be denied. Amend the beneficiary after approval and verify the documented reapproval rule. Include a payment below the threshold to check the boundary between approval paths, using the configured threshold value and its specified inclusive or exclusive rule.
Run these checks through the user interface and, where available, the API or downstream release interface. Use controlled test accounts and isolated test transactions so that verification cannot trigger real payment processing. Record the policy configuration, test identities, transaction values, observed state transitions and audit evidence. This makes failures easier to reproduce when a workflow, permission or environment configuration changes.
Common failure modes
A workflow can appear correct in the interface while a backend path accepts an approval from the maker. Other defects include stale approval remaining valid after a material edit, an incorrect threshold comparison, inconsistent permissions between channels, or an audit record that omits who approved which version of an item.
Testing every policy combination can become expensive when approval rules vary by amount, product, account or user group. Use decision tables to identify meaningful combinations, then prioritise high-risk paths and boundary values. Keep role assignments and policy configuration explicit in test data; environment drift can otherwise make the same scenario pass in one environment and fail in another.
Frequently asked questions
Is four-eyes approval the same as multi-factor authentication?
No. Multi-factor authentication verifies a user's identity with more than one authentication factor, while four-eyes approval requires a separate authorised user to review or approve an action.
Can a bank allow a user to approve their own transaction in an exception case?
That depends on the bank's documented policy. If an exception is permitted, test its eligibility, scope, duration, required approvals and audit evidence as explicit policy rules.
How should automated tests represent maker and checker users?
Use separate test identities with explicit, controlled entitlements for each role. Avoid switching roles within one shared account, because that can conceal identity and permission defects.
When should approval-policy changes trigger regression testing?
Run regression tests when changes affect approval thresholds, role mappings, workflow transitions, transaction fields or release integrations. Include existing approval paths and relevant boundary cases.