Developer · 5 min read

The four-eyes illusion: why ERP dual authorization does not stop push payment fraud

Tobias Lindqvist-RaoTechnical Deep-Diver

Dual authorization is the control every finance organisation points to first. It works against the threat it was designed for — a single dishonest employee — and it is structurally silent about the threats that actually produce losses now.

Why doesn't ERP dual authorization stop push payment fraud?

Because both approvals are rows in the same database, written by the same application. A stolen session, an insider with table access, or a field edit after approval produces a payment that every control believes was authorised twice. Independence is the property you want; a second click is not it.

Key takeaways

An ERP approval is a state transition written by the ERP. It records that an account approved, not that a human reviewed specific content.
Three failure modes defeat it without defeating the ERP: session theft, post-approval mutation, and approval of content the approver never saw rendered.
Binding both approvals to a canonical statement of the payment closes all three without changing the workflow.

Part of Payment release authorization

What maker-checker was designed against

Maker-checker assumes two independent judgements. It records two writes.

Segregation of duties in payments addresses a specific, historically dominant threat: one person creating and releasing a payment to themselves. Requiring two people raises the bar to collusion, which is materially harder and much more detectable.

It works. Internal fraud by a single actor in an organisation with functioning maker-checker is genuinely rare, and the control deserves credit for that.

What it does not address is a threat where both humans act honestly and the payment is still fraudulent.

Failure mode one: session theft

An approver's session token is exfiltrated by infostealer malware or captured by an adversary-in-the-middle proxy. The attacker replays the session and approves.

From the ERP's perspective nothing unusual occurred. The session was valid, the user had the role, and the approval was recorded. Multi-factor authentication was not bypassed because no login took place — the attacker inherited an authenticated session.

The approval row is identical to one produced by the human.

Failure mode two: post-approval mutation

An approval is recorded against a payment record. The payment record contains the beneficiary details. Those are separate fields in a database.

An actor with database access — an administrator, a compromised service account, an application defect — can alter the beneficiary account after approval without altering the approval status. The system has no cryptographic relationship between the two, so nothing is invalidated.

What is recorded	What it is bound to
Approval status	A payment record identifier
Approver identity	A session
Approval timestamp	Server clock
Beneficiary account	Nothing — an independent mutable field
Amount	Nothing — an independent mutable field

Failure mode three: unrendered content

The subtlest one, and the most common. An approver reviews a payment batch in a list view showing vendor name, amount and reference. The beneficiary account number is on a detail screen they do not open, or is truncated for display.

They approve honestly, having reviewed what the interface showed them. The field that was altered is the one the interface did not render.

This is not an attack on the ERP. It is the interface behaving as designed, and it is why account masking in approval screens is actively harmful rather than merely unhelpful.

What SOX testing actually examines

Under PCAOB AS 2201, an auditor tests whether the control operated effectively. For dual authorization, that typically means selecting a sample of payments and verifying that two distinct approvers are recorded and that they were appropriately authorised.

All three failure modes above pass that test. Two distinct approvers are recorded. They were authorised. The control operated exactly as documented, and the payment was still fraudulent.

The integration that closes it

The change is at the approval step and does not require ERP modification in most architectures — a hook at approval, an API call, a receipt stored alongside the payment record.

On approval, construct a canonical statement containing the payment's material terms: amount, currency, beneficiary legal name, full account number, full routing or SWIFT code, beneficiary bank, and reference.
Render that statement to the approver in full. No truncation, no masking, no hidden detail screens.
Obtain a hardware-backed assertion with user verification required over the canonical statement.
Repeat for the second approver, with distinct-credential and distinct-authenticator constraints so one person cannot produce both.
Before release, verify both signatures against the payment as it stands at release time. Any field altered since approval fails verification and the payment does not go.

Step five is the one that closes post-approval mutation. Verification happens at release, against current state, rather than trusting a status flag set earlier.

What it costs

Two device gestures per payment above the threshold, each roughly the time it takes to unlock a phone. The approvers already open the payment; the additional step is the confirmation.

The implementation cost is a hook at one workflow step. The organisational cost is deciding the threshold and accepting that the approval screen must render everything, which some ERP configurations make harder than it should be.

What independence actually requires

Three properties, and which the ERP provides
Property	Maker-checker in an ERP	Signed dual approval
Two distinct humans	Asserted by account	Distinct credentials, attestable as separate hardware
Two distinct judgements	Same screen, same data	Same, unless rendering differs — this is not solved by cryptography
Immune to a single compromise	No — one adversary-in-the-middle kit holds both sessions	Yes — two devices, two gestures
Survives post-approval edit	No	Yes — digest mismatch refuses

Note the second row. Cryptography does not make two approvers think independently; only workflow design does. What it does fix is the first, third and fourth.

Objections and honest limits

“Segregation of duties is enforced in the role model.” At the role level. It says nothing about whether the two sessions were held by two people, or about a change made after the second approval.

“We have an immutable audit log.” Immutability means the record cannot be altered later. It does not mean the record described two independent human decisions.

Making dual approval independent

Bind each approval to a distinct credential. With attestation, so you can show two separate authenticators.
Bind both to the same payload digest. So an edit between the two invalidates the first.
Recompute at execution. A change after the second approval refuses rather than executes.
Render independently for the second approver. Different framing, so the second reviewer is not simply confirming the first.

Terms used here

Maker-checker: A control where one person enters a transaction and another approves it. Its value depends entirely on their independence.
Adversary in the middle: A phishing technique that proxies a real session, capable of holding two approvers' sessions at once.
Distinctness attestation: Evidence that two signatures came from two separate authenticators rather than two credentials in one person's hands.

Frequently asked questions

Does this require replacing our ERP? No. It is a hook at the approval step plus verification before release. The ERP remains the system of record for the payment.

Will this break straight-through processing? Payments below your threshold are unaffected. Recurring payments to established beneficiaries can run under a pre-signed authorisation with amount and payee constraints.

How do we set the threshold? From your own payment value distribution. Most populations are heavily skewed, so a threshold capturing most of the value touches a small share of transactions.

Does an auditor care about this? They test whether the control operated as documented. A control that additionally produces verifiable evidence is easier to test, which is worth raising at the walkthrough.

Isn't segregation of duties enough? It operates on roles. It does not establish that two sessions were held by two people, nor that nothing changed after the second approval.

Does cryptography make approvers think independently? No. It establishes distinct humans and distinct devices, and refuses post-approval edits. Independence of judgement is a workflow design problem.

What breaks dual approval fastest? A single adversary-in-the-middle kit holding both sessions, which collapses the control to one.

Where this fits in Manav

Manav renders the full payment or change details, binds the approver's signature to that exact payload, and produces a receipt an insurer, an auditor or a court can verify without calling anyone.

See payment gating →