How to run four-eyes (maker-checker) approval when an AI agent prepares payments: who approves, where to enforce it, thresholds, and audit evidence.
A payments team that lets an AI agent prepare wires and ACH batches has not changed the rule that matters most: one person should not be able to create and release the same payment. What changes is that the "maker" is now software that works at machine speed, so the control has to sit somewhere the agent cannot reach. This post covers how to set that up, where Nacha rules do and do not apply, and what evidence an examiner or auditor will want to see.
The pattern has four steps, and the agent only owns the first. The other three belong to people and to the system that releases the money.
Step | Who does it | What must be true |
|---|---|---|
Prepare | AI agent | Builds the payment from the invoice or instruction, attaches the evidence, and submits it to a queue. Cannot release. |
Review | Approver one (a person) | Sees the exact beneficiary, account details, amount, currency and supporting document, not a summary written by the agent. |
Release | Approver two (a different person) | Has a separate login and role. Releases only the payment version that approver one saw. |
Record | The payment system | Logs the proposal, the evidence, both approvers, timestamps and the final released payment. |
Some teams collapse review and release into one human step for low-value payments, which is a single approval plus a prepared-by-agent record. That is a policy choice. The point is that the agent is never one of the approvers, and that anyone who approves is not the person who changed the payment details.
NIST's security control catalog describes the same idea as separation of duties. Control AC-5 in NIST SP 800-53 Rev. 5 asks organizations to identify and document the duties that need separating and to define system access authorizations that support that separation. An AI agent that prepares payments is a duty holder like any other, and the access you grant it should reflect that.
We checked the Nacha pages that cover origination risk, and none of them prescribes dual approval for ACH payments. Dual control is an internal control and a bank portal setting, not a Nacha mandate that we could verify. Treat anything you read that says otherwise as unconfirmed until you see the rule text.
Two Nacha rule changes do matter for teams that originate ACH with agents in the workflow:
A second approver helps you meet the spirit of the fraud monitoring rule, because a human looking at an unusual payment is a detection step. The rule itself asks for risk-based processes, and a well-run approval queue with clear escalation criteria is one way to show them.
For wires, the controls live in your bank's wire agreement and online banking settings. We did not find a public rule text we could verify for wire dual control, so this post makes no regulatory claim there. Ask your bank which approval modes its portal supports, and what its security procedure says about who may initiate and who may release.
A gate that exists only in the agent's prompt can be talked around, misconfigured or removed in a prompt edit. The enforcement belongs in systems the agent cannot change.
The threshold is a policy decision for finance, treasury and risk. There is no regulator-set dollar figure that we could verify, so the tiers below are an illustration of how teams structure it, not a requirement.
Payment type | Typical approval design |
|---|---|
Low-value, existing beneficiary, matched to an approved invoice | One human approval, agent prepared |
Above the team's set threshold | Two independent human approvals |
New beneficiary | Two approvals plus an out-of-band confirmation of bank details |
Change to an existing beneficiary's bank details | Two approvals, callback to a known contact, and a hold period |
Refunds, manual overrides, or policy exceptions | Two approvals regardless of amount |
Anything the agent flags as unusual | Escalate to a named person with the evidence attached |
Write the thresholds down, version them, and record who approved each change. Revisit them when volumes or fraud patterns shift. A threshold that nobody has reviewed in two years is a finding waiting to happen.
An auditor testing a four-eyes control wants to pick a payment at random and reconstruct what happened. Make that possible without asking an engineer to pull logs from three systems. For each payment, keep:
Also keep the policy: thresholds, role definitions and who may change them. For wider context on what evidence regulated teams assemble, see how to govern AI agents: 12 controls for regulated enterprises and SOC 2 and AI agents.
No, where independence is the point. A second model that reviews the first agent's proposal can catch arithmetic errors and flag odd patterns, but it shares the same inputs and often the same blind spots. It is not an independent person, and it cannot be held accountable the way a named approver can. Use AI review as an extra layer in front of the human checks, for example to rank the queue so approvers see the riskiest payments first.
At Zamp, an AI employee is built to do the preparing and to stop where the approval gate starts. Everything below comes from our published architecture and trust pages. We have no published banking customer case study, so this describes how the mechanism works, not a bank deployment.
The agent's identity cannot release.
Each AI employee has its own identity with least-privilege access. For a payment role, the agent's access would let it read the invoice or instruction, build the payment and submit it to the approval queue. It would not carry the entitlement to release funds. That entitlement sits with named people in your bank portal or treasury system.
The procedure holds the limits.
Every AI employee runs one agent operating procedure (AOP). For this job it would record the approval limits, the sources of truth for beneficiary details, the escalation path, and the actions the agent may never take.
Uncertain cases go to a person.
When a payment hits a tolerance breach, missing data or a pattern the agent has not seen, it assigns the Needs Attention status and routes it to a person with the context already assembled. Before a case closes, the PEV loop checks the agent's own output.
Reasoning lands in your system.
In a biopharma procurement deployment, the agent writes its full reasoning for each decision inside SAP Ariba, so reviewers read it in the system of record. For payments, the equivalent is the ERP or treasury record the approvers already use.
A high review rate at launch is the safety mechanism.
In that same deployment, the agent sent 64% of requests to manual review in week one instead of guessing. As corrections built up, its decision rate rose to 85% and manual review fell to 15%. The case study has the details. Expect the same pattern when you start: most payments reach a human at first.
Corrections become tested changes.
A reviewer's correction is captured on a branch, run against a golden set, reviewed and merged, with no engineering ticket. Regulated teams usually pair this with BYOC or on-prem deployment so logs stay in infrastructure they already audit; see our trust and security page.
