Maker-Checker Security Testing: Prove Approval Survives State Changes

Maker-checker security is a relationship, not two buttons

The maker-checker process separates the person who prepares an instruction from the person who approves it. In a banking application, that separation is only meaningful if the system preserves the relationship between the actors, the instruction version and the eventual operation. Two different screens or role labels do not prove that the backend enforces the intended rule. Security testing should follow the instruction through its lifecycle.

This guide explains how to design authorised maker-checker tests using synthetic transactions and explicit business expectations. It focuses on state changes, delegation, concurrent actions and evidence. It does not describe a real bank compromise or authorise testing against any institution. The examples assume that settlement is disabled or otherwise controlled through an owner-verified arrangement and that all relevant participants have approved the test boundary.

Our bank penetration testing service examines the controls behind financial workflows. For the broader application context, see the banking app session and transaction matrix. This article goes deeper into one specific control: how to demonstrate that an instruction was approved by the right independent authority and that the executed result still corresponds to that approval.

Write the business rule in a form that can fail

Ask the process owner to describe who may create, modify, approve, cancel and execute an instruction. Identify whether independence is defined by user account, person, organisational role or another business relationship. A person holding two accounts may satisfy a simplistic account inequality check while violating the intended separation. The assessment needs the bank’s actual rule before it can judge the implementation.

Define which changes invalidate an existing approval. Amount, beneficiary, source account and execution date may have different significance in different products. Do not assume that every field behaves identically. The owner should identify material fields, permitted post-approval amendments and the required reapproval path. These decisions create the expected outcomes for the test matrix.

State the final business effect that approval permits. Does approval authorise submission to a separate payment engine, immediate execution or only a later operational review? The maker-checker boundary may span several services. A correct approval screen does not establish that a downstream component receives the approved version or applies the intended limits.

Prepare identities that expose the separation boundary

Use designated synthetic identities for a maker, an independent checker, a read-only user and an unrelated customer. Add a dual-role or delegated identity only where that is part of the real product model and explicitly in scope. Record the effective permissions and the relationships between these identities. A role name alone is insufficient when inherited permissions or customer-level delegation changes what the user can do.

Confirm that separate authentication contexts can be used without violating operational restrictions. Shared devices, telephone numbers or approval applications can make it difficult to distinguish actors. Resolve those constraints before testing. If the environment cannot represent the intended separation, record the coverage limitation rather than treating two browser tabs using the same authority as an adequate substitute.

Include lifecycle transitions if relevant: an approver whose role is removed, a delegation that expires or a maker who changes customer association. These cases help determine whether the process evaluates current authority at the appropriate point. The expected timing and propagation behaviour must be agreed; the test should not invent a policy that the bank has never intended to enforce.

Keep identity setup separate from the test evidence. The bank may supply accounts and permissions, while the testing team observes how the application uses them. Record that distinction. It prevents a later report from implying that testers independently acquired privileges that were actually provisioned for a controlled boundary check.

Model the instruction as a state machine

List the meaningful states and permitted transitions. A simple example might include draft, pending approval, approved, submitted, executed, rejected and cancelled. Real products may contain additional review or scheduling states. For each transition, identify the actor, preconditions, relevant version and expected side effects. This exposes paths that a screen-by-screen assessment may miss.

Identify the authoritative state store and the services that read or change it. A user interface may display an older state, a queue may contain a previously approved version and a downstream processor may apply its own interpretation. The test plan should clarify which observations can establish the final outcome and which are only intermediate signals.

Prepare synthetic instructions in the required states through supported setup procedures. Avoid directly altering backend records unless that action is explicitly part of the agreed preparation and its effect is understood. Artificial states can be useful for a focused test, but they may not represent a reachable production path. Label them accurately so the report does not overstate exploitability.

Use a small number of carefully chosen instructions with stable references. One instruction can support a clear sequence of state checks, but repeated mutations may make the history confusing. Where necessary, create a fresh synthetic instruction for each significant case. Preserve the initial condition and the expected final state so reconciliation remains straightforward.

Test what happens when an approved instruction changes

The central question is whether approval remains attached to the intended instruction details. Establish a legitimate approved synthetic instruction, then exercise an authorised change path according to the agreed test plan. Observe whether the application rejects the change, returns the instruction for approval or follows another documented rule. The result should be assessed against the business expectation, not against a generic preference.

Check both visible and indirect change routes. A product may allow changes through an edit screen, an import process, an API or a support operation. The scope should identify materially different enforcement paths. If all routes share a service, that is useful context, but the team should verify the relevant behaviour rather than assuming that the interface architecture guarantees consistency.

Record which fields changed and which version was later consumed by the execution step. A successful response to an edit does not prove that the changed values reached the payment engine. Conversely, a rejected interface action may not prove that an asynchronous record remained unchanged. Use the agreed authoritative evidence to establish the actual effect.

The OWASP Transaction Authorization guidance provides useful background on binding authorisation to transaction details. The bank-specific test adds the actual role, version and execution semantics. Keep the technical finding precise: identify the violated rule and observed effect without implying a regulatory conclusion that the assessment did not establish.

Check self-approval and delegated authority as separate questions

Self-approval can arise through more than one account submitting both actions. A user may hold multiple roles, operate through a delegated identity or act through a service account. Determine which combinations are legitimate and which should be prevented. Test those combinations with the owner’s knowledge and synthetic records rather than assuming that every dual-role configuration is inherently wrong.

Delegation introduces its own boundaries. Who may grant it, what operations does it cover, which customer or account does it apply to, and when does it expire? An approver may legitimately act for another person while remaining subject to limits. The assessment should verify those limits and the audit representation of the action. A log that records only the delegated identity may obscure the person who actually acted.

Check whether authority is evaluated when the approval task is opened, when the approval is submitted or when the downstream action occurs. A task created before a role removal may retain stale assumptions. The expected behaviour depends on the product design, but the bank should know where the decision is made and how changes are reflected.

Include a positive control for legitimate delegation. A fix that disables every delegated approval may remove a security path while breaking a required operational process. Useful acceptance evidence shows both that the permitted delegation works and that the disallowed boundary is enforced. This keeps the assessment aligned with reliable banking operations rather than restriction for its own sake.

Use a maker-checker test matrix with observable outcomes

The matrix should identify prerequisites, actor relationships, instruction state, action and expected result. Add the evidence source and cleanup requirement. Keep it concise enough that owners can review the business meaning without reading low-level requests. The detailed technical procedure can remain in the testing team’s controlled records.

Do not treat this list as permission to exercise every case in production. Some transitions may require a sandbox, a supervised window or a separate risk decision. Mark cases that are not safe or available and agree an alternative. A transparent coverage limit is preferable to improvising around a fragile financial process.

For each completed case, retain enough context to explain why the result is meaningful. An error message without the initial state and actor relationship is weak evidence. A final-state check tied to the exact synthetic instruction makes the conclusion much stronger and easier for developers to reproduce.

Plan concurrency checks as controlled consistency tests

Distributed workflows can receive overlapping approvals, edits or cancellations. A bounded concurrency case can help assess whether the application preserves its business invariants. It must be planned with the owner because even a small number of requests can produce unintended state changes. Set the maximum attempts, synthetic objects, observation method and stop condition before execution.

Define the invariant in ordinary language. For example, one synthetic instruction should not create more than one intended business effect, or a cancelled instruction should not proceed through a later unauthorised transition. The test need not assume a particular locking or database design. It observes whether the agreed outcome holds under the specific controlled overlap.

Correlate all responses with the final state. Two apparent successes may refer to one idempotent operation, while one apparent failure may occur after a backend action has already committed. The owner’s authoritative view is important. Record the request references and timing without presenting a small sample as proof of correctness under every possible race or infrastructure failure.

If the test reveals ambiguity rather than a clear defect, report that accurately. Additional instrumentation or a targeted engineering test may be needed. A penetration test can identify a concern and demonstrate a specific outcome; it should not invent an implementation cause or claim exhaustive distributed-systems verification from limited external observation.

Check limits and exception routes without creating real exposure

Approval requirements may vary by amount, account type, customer mandate or other business conditions. Identify the relevant boundaries and prepare synthetic cases around them. The purpose is to verify the intended transition in authority, not to move funds or probe arbitrary production limits. Use approved test values and confirm how the environment prevents external effects.

Consider aggregation rules where they are part of the scope. A product may apply limits per instruction, per period or per actor. The bank should explain which rule is intended before testing. Do not assume that splitting synthetic instructions is a defect unless it violates the agreed business requirement. The assessment needs evidence of the actual rule and observed behaviour.

Exception and emergency routes deserve explicit treatment. An authorised override may be necessary for operations, but it should have a defined role, rationale and audit trail. Ask who can invoke it, what constraints remain and how the action is reviewed. The existence of an override is not automatically a finding; uncontrolled or misleading use of it may be.

Keep technical and governance conclusions distinct. A test may show that an override is available and logged, while a separate process review determines whether its use is reviewed appropriately. Combining those observations can be valuable, but the report should identify which evidence supports each conclusion and which part of the process was not assessed.

Verify that the audit trail explains who approved what

A useful audit trail identifies the acting identity, any delegated relationship, instruction reference, relevant version, action, time and outcome. The precise fields depend on the system, but a reviewer should be able to distinguish preparation, modification, approval and execution. A sequence of generic “success” events may not support that reconstruction.

Check whether failed and rejected actions are represented appropriately for the agreed use case. An investigation may need to understand an attempted self-approval or a rejected change after approval. The assessment should not demand unlimited logging of sensitive content; it should identify the context needed to explain the security decision without exposing unnecessary data.

Compare the application’s user-facing history with the authoritative operational record. They may serve different audiences, but material discrepancies should be understood. If a delegated action appears to have been performed directly by another person, the bank may struggle to reconstruct responsibility. Record the observed representation and its practical consequence rather than simply labelling all differences as defects.

Preserve evidence integrity in the test record. Keep source timestamps and note any clock adjustment used in the consolidated timeline. Redact secrets and unnecessary personal details in the report. Where evidence cannot be collected, state the limitation and identify the owner who can perform the follow-up check. Missing visibility should not silently become an assumption that the audit trail is complete.

Report the business invariant, not a dramatic exploit story

Describe a finding through the expected invariant and the observed deviation. For example, approval remained associated with a synthetic instruction after a material change that the owner said should require reapproval. State the actor relationship, initial state, changed field and final effect. That is more useful than a vague claim that the payment process was “fully bypassed.”

Explain the impact proportionately. If settlement was disabled, say that the test demonstrated an unauthorised state transition or prepared instruction rather than an actual transfer of customer funds. If downstream execution was outside scope, do not imply it was achieved. Clear limitations strengthen the finding because the reader can trust the boundary of the evidence.

Include remediation direction at the level of the control. The engineering team may need to bind approval to an immutable version, re-evaluate authority or centralise transition checks, depending on the demonstrated mechanism. Avoid prescribing a specific implementation without understanding the architecture. State the required security outcome and suggest verification cases that can prove it.

Group related observations carefully. Several endpoints may expose the same missing state check, while similar-looking failures may have different causes. The report should help owners prioritise and assign work without hiding affected paths. Preserve the evidence references for each relevant route so a later retest can verify the actual coverage.

Retest the invariant across the relevant paths

A meaningful retest repeats the demonstrated case with the corrected implementation and confirms that the legitimate workflow still operates. If the issue involved a material instruction change, verify the expected reapproval or rejection behaviour and the final downstream state within scope. Do not close the issue solely because the original request format now returns an error.

Check relevant adjacent paths identified in the original assessment. A correction in the web controller may not affect an import job or a separate API service. The retest should remain bounded, but its rationale should follow the violated business rule. Agree the paths with the owner and state any that remain unverified.

Record the tested version, data setup and acceptance result. If the owner provides implementation evidence without an observed retest, label that distinction. Risk acceptance, planned remediation and verified correction are different states. Keeping them separate helps the bank avoid reporting a technical closure when the actual decision was administrative.

Use the resulting cases as regression candidates for the development team. A stable synthetic workflow with explicit expected transitions is useful beyond the pentest. It can help protect the maker-checker boundary as the application evolves. The security assessment should leave the team with a clearer model of the control, not only a PDF describing a problem.

Include approval continuity when workflows are migrated

A migration or product release may move pending instructions between services or change the role model. If that situation is relevant to the assessment, ask how existing approvals are represented after the change. The bank should know whether an old approval remains valid, requires renewed confirmation or is deliberately cancelled. The test should use a controlled synthetic instruction and the owner’s documented migration rule.

Preserve the before-and-after references and inspect the final authority relationship. A migrated record may retain a visible approval label while losing the version or actor context needed to interpret it. Conversely, an intentionally invalidated approval may be a correct safety decision rather than a defect. The assessment should establish the expected behaviour and observe it. This focused case can be especially useful when a team changes payment engines, consolidates customer roles or introduces a new mobile approval channel during the same release.

Prepare a focused maker-checker assessment

For an initial discussion, provide the instruction types, roles, customer model, approval thresholds, supported channels and relevant state transitions. Identify whether delegation, imports, scheduling and emergency overrides are used. Explain the available test environment and how external effects will be prevented. These details allow the scope to target the actual approval boundary rather than a generic application checklist.

Use the bank pentest scoping brief or contact Atlant Security to discuss the workflow. Do not send real customer instructions, credentials or sensitive logs through an initial enquiry. Agree the NDA and secure exchange arrangements before sharing detailed evidence. The proposal should describe the necessary test inputs, coverage limits and acceptance evidence.

This guide was reviewed on 25 October 2026. It provides practical testing recommendations and does not establish compliance with every banking or payment obligation. The maker-checker principle is valuable when the implementation preserves independent authority, the approved instruction and the final effect. A useful test makes those relationships observable and reports precisely where they held, failed or remained unverified.