Build auditable oversight for AI payment agents
Start with the rail you cannot reverse, write the policy before you ship the agent, and let the ledger be the record of record. Explore Formance Ledger on GitHub or book a demo with our team to see how it fits your AI agent oversight stack.
Human-in-the-loop (HITL) and human-on-the-loop (HOTL) are the two oversight models for AI agents that move money.
HITL requires a named human to approve each agent action before it executes, blocking the agent from releasing an irrevocable payment until a reviewer signs off. HOTL lets the agent execute autonomously inside a pre-set policy (spending limits, caps, or allow-lists), with a human monitoring the stream and intervening only on exceptions or breaches.
Engineering, finance, and compliance teams need to decide how humans will oversee AI payment agents. Teams wire AI agents to initiate supplier payouts, refunds, treasury sweeps, and card authorization holds.
The oversight decision often lands on the engineering team that wired the agent in. But compliance requests to put a human in the loop. The engineers open the core ledger schema and find no state for "an agent proposed this, nobody has approved it yet."
Formance Ledger, an open-source programmable core ledger purpose-built for money movement, represents that pending state natively through held accounts and transaction metadata, but most general-purpose schemas do not.
The pending amount either double-counts against the operating balance or vanishes until settlement, and the balance sheet drifts either way.
Implement the wrong oversight model and the agent either stalls at approval or runs unmonitored on a rail that cannot be undone. The sections below cover both oversight models, how to choose between them per transaction, and how to encode both and a hybrid option in the ledger.
Human-in-the-loop (HITL) blocks execution until a named human authorizes the action. HITL trades latency and reviewer load for a pre-finality catch, assuming the agent's next step could be wrong in a way the rail will not undo.
The agent drafts the payment, which the core ledger records as a proposed posting into a held account. The posting releases to the rail only after the approver signs off synchronously, so the issue is caught before settlement finality.
While the approval is open, the approver reads the pending amount from that held account.
Use HITL for transactions where applicable rules make reversal difficult or impossible. Examples include wires and instant payments, first-time payees, above-threshold principal, and treasury sweeps above threshold.
HITL also suits an ambiguous policy match and any payload with no labeled precedent. Payment-execution tasks are higher-risk agent work when a model has not demonstrated reliable completion.
For a payload with no labeled precedent, a blocking approval is worth the delay.
HITL puts a named human in the accountability chain for every in-scope action, so "who authorized this?" has a person as its answer.
HITL has limitations such as synchronous approval, which works at low volume but becomes a bottleneck once an agent executes actions by the thousands per hour.
The HITL approval gate can also miss errors if it isn't configured for the specific error class it is meant to catch.
Human-on-the-loop (HOTL) lets the agent execute inside pre-set constraints while a human monitors and can pause, escalate, or reverse the payment. HOTL trades a rehearsed intervention path for throughput.
The agent works under a policy written up front: budgets, per-rail caps, counterparty allow-lists, and escalation thresholds. The agent posts directly to the rail inside those limits.
Anomalies and breaches surface to a monitoring queue, where the human works exceptions and owns a rehearsed reversal path. The human can halt the agent at any time.
Use HOTL for reversible internal postings and high-frequency reconciliation-driven postings. Card authorization holds, such as pre-auth amounts placed on a cardholder's account before capture, also suit HOTL.
Use HOTL for Automated Clearing House (ACH) transfers only where the applicable rules and provider give you a usable return window. HOTL also suits treasury rebalancing between two declared thresholds and refunds under a limit.
This oversight model suits patterns the agent has labeled examples of, and volume that would turn synchronous review into a queue.
HOTL buys throughput because it reviews and tracks exceptions rather than transactions, so volume can grow without a proportional headcount ask. Human attention lands on outliers where a catch is most likely, and the agent isn't blocked waiting for sign-off on every action.
HOTL has limitations such as complacency when the monitoring queue runs quiet, and missing the point at which the agent should be halted (the "kill threshold") can lead to runaway execution on an irrevocable rail.
Reversal and halt procedures must be rehearsed before an incident, or they will not work when it matters.
HITL and HOTL differ across four dimensions: execution control, human role, primary risks, and financial use cases.
| Dimension | Human-in-the-Loop | Human-on-the-Loop |
| Execution control | Blocks before the posting releases | Executes inside pre-set policy; human intervenes after |
| Human role | Named authorizer on every in-scope action | Monitor with pause, escalate, and reverse rights |
| Primary risks | Queue bottleneck, reviewer fatigue, and rubber-stamping | Complacency, missed kill threshold, and runaway execution on irrevocable rails |
| Financial use cases | Wires, instant payments, first-time payees, and above-threshold principal | Reversible internal postings, card holds, ACH and Single Euro Payments Area (SEPA) transfers within return windows, treasury within cap, and refunds under a limit |
HITL is not automatically safer. A blocking approval only catches the error class it was configured to catch, and at thousands of actions per hour, reviewers rubber-stamp requests they no longer read.
HOTL does not hold up without a rehearsed kill path either: monitoring that no one acts on is the same as no monitoring.
The right mode depends on the rail and the payload.
Pick HITL for rails past settlement finality where a wrong payment cannot be undone, and choose HOTL for reversible postings where synchronous approval would turn into a queue. A hybrid default also exists when a single agent handles both kinds of traffic, letting a policy file route each transaction to the right mode.
Whichever mode fires must show up in the ledger as a posting shape an examiner can read. A pending-approval account for HITL, policy metadata on every posting for HOTL, or an oversight_mode tag that records which path fired under hybrid. Without that posting shape, the policy is unenforceable in audit.
Use HITL when the approval gate has to catch a wrong payment before it reaches an irrevocable rail. Place it before the posting releases and configure it for the error class it must catch. Multiple approvals alone do not provide that protection.
HITL needs a pending-approval state that a two-state ledger (posted and not posted) cannot represent. Leaving funds in operating double-counts them against the next budget check.
Recording nothing until approval hides the queue from compliance and pushes the approver to trust a screen instead of the system of record.
Give the pending proposal its own account. Model the proposal as a state machine you encode in account paths and metadata: five forward states (proposed, pending approval, authorized, posted, and settled) and two exits (denied and expired)
The first transition posts from operating into a held account keyed to the approval, preserving the double-entry invariant. Approval moves the balance from held to the rail's outgoing account, while denial is a compensating posting back to operating.
Ledger immutability keeps the proposal, the denial, and the denier's identity in the history. Expired approvals take the same path with a different reason code.
In a core ledger, an agent proposing a $250,000.00 supplier wire uses three accounts: @platform:treasury:operating, @platform:payouts:wire:approval:7f3a2c:pending, and @platform:rails:wire:outgoing.
The proposal writes the hold in Numscript, Formance's language for financial transactions:
// WIRE_PAYOUT_PROPOSAL
// Event: hold a $250,000.00 supplier wire payout pending approval
send [USD/2 25000000] (
source = @platform:treasury:operating
destination = @platform:payouts:wire:approval:7f3a2c:pending
)
set_tx_meta("event_type", "wire_payout_proposal")
set_tx_meta("payout_id", "7f3a2c")
set_tx_meta("oversight_mode", "hitl")
The destination path encodes the rail (wire) and the approval identifier (7f3a2c) in separate segments, with the state (pending) in the trailing segment so that you can aggregate balances under the platform:payouts:wire: prefix to see every pending wire.
Approval posts the same amount to @platform:rails:wire:outgoing; denial posts it back to @platform:treasury:operating.
Use HOTL when the rail gives you a usable reversal window, and volume would turn synchronous approval into a queue.
Encode the policy as budgets, per-rail caps, counterparty allow-lists, and escalation thresholds. Route breaches to a monitoring queue, and define a hard kill threshold that halts the agent without a meeting.
On May 2, 2022, a Citigroup trader entered a $444 billion basket sell order. Hard blocks caught part of it, but $189 billion was passed to the execution algorithm after the trader clicked through a pop-up warning that buried individual alerts under an "OK" button.
Real-time monitoring was too slow to escalate, so $1.4 billion of equities hit European exchanges before the trader canceled, and UK regulators later fined Citi £61.6 million. Monitoring existed, but the intervention did not. That is the failure mode HOTL has to be designed against.
HOTL has no pending state to hold. The agent posts directly from operating to the rail's outgoing account, and the ledger carries the policy context (oversight_mode, budget_bucket, rail_cap_id, and counterparty_allowlist_entry) as transaction metadata that the monitoring queue reads to flag exceptions.
A card authorization hold under HOTL runs straight through, with the policy identifiers recorded alongside the amount:
// CARD_AUTH_HOLD
// Event: card authorization hold executed under HOTL policy
send [USD/2 4200] (
source = @platform:treasury:operating
destination = @platform:rails:card:holds:9b1e4d
)
set_tx_meta("event_type", "card_auth_hold")
set_tx_meta("oversight_mode", "hotl")
set_tx_meta("policy_version", "2026-03-14")
set_tx_meta("budget_bucket", "card:holds:daily")
set_tx_meta("rail_cap_id", "card:holds:per-txn:500usd")
set_tx_meta("counterparty_allowlist_entry", "merchant:a4f7c2")Breaches post the same way, but the metadata flags them for the monitoring queue. The posting record is what the kill-switch decision is reconstructed against after the fact.
Use hybrid whenever a single agent handles traffic across both reversible and irrevocable rails. Run the same agent in both modes: HOTL by default, with HITL as a declared exception written into policy.
The implementation enforces that exception per rail and counterparty according to the applicable threshold. The policy file names which transactions cross the exception line, and reviewer discretion does not. When a wire above cap to a new payee shows up, the policy determines whether approval is required.
We hold one position on agent oversight: on the loop by policy, in the loop by exception, with the exception decision recorded through ledger postings. Metadata compliance can inspect directly, instead of relying on a runbook an approver may or may not follow.
The ledger has to record which path fired so compliance can audit the policy's behavior, not just its intent. Put oversight_mode on every posting.
For HITL, add approver_identity and approval_decision.
For HOTL, add policy_version, budget_bucket, and the matched rail_cap_id or counterparty_allowlist_entry.
Neither human-in-the-loop nor human-on-the-loop oversight for AI payment agents holds up without a ledger built for it. Approval gates, pending ledger states, policy metadata on every posting, and the immutable audit trail an examiner can reconstruct are all ledger primitives.
If your core ledger cannot represent a pending state or attach queryable metadata to every transaction, the oversight model lives in a runbook instead of a system of record.