How to let an AI agent execute routine payments within bounds

Define "routine" so tightly that the agent has nothing to judge: a verified payee paid before, an amount matching an obligation a person already approved, inside per-payment and daily limits, on the usual rail. The agent executes those at depth 4 once certified. Anything new, changed, larger or unmatched is held for a named approver, and every payment is filed.

What counts as a routine payment, and who owns the process?

Payments sit at depth 4: they move money, and on many rails they cannot be recalled without the receiving bank's cooperation. An agent earns that depth for a narrow slice of payments, not for "payments" in general. Our guide to autonomy in regulated industries explains why reversal sets the line.

A routine payment, for this playbook, meets every one of these:

• The payee is on the verified master list and has been paid before to the same details.
• The details have not changed within a set cooling period.
• The amount matches an obligation a person approved: an invoice, a payroll file, a standing schedule.
• The amount is within the per-payment limit, and the day's total stays within the daily limit.
• The rail, currency and timing are the usual ones for that payee.

The head of payments operations owns the definition. The finance controller owns the limits. Approval of the underlying obligation stays with whoever approves it today.

How do you set it up, step by step?

1. Person, head of payments: writes the routine definition. Use the list above, adjusted to your business. Evidence: a versioned definition.
2. Person, finance controller: sets limits. Per payment, per payee per month, per day. Evidence: limits recorded as bounds.
3. Person, approver: approves the obligation. The invoice, the payroll, the schedule. The agent does not approve what it pays; for invoice approval within limits, see how to let an AI agent approve invoices in your AP tool. Evidence: approval in the source system.
4. Agent, depth 2: prepares the payment run. Matches each approved obligation to a payee, checks for duplicates against recent payments, and flags anything outside the definition. Evidence: a prepared run with a reason per line.
5. Platform, at each line: checks the minimum chain. Payee source is signed, amount matches the obligation, limits hold, certificate is in date. Evidence: a verdict per payment.
6. Agent, depth 4: executes allowed lines. Only lines that pass every check. Evidence: allowed verdicts with the payment reference.
7. Person, named approver: decides held lines. New payee, changed details, mismatch, over limit. Evidence: held verdict, decision and approver.
8. Agent, depth 2: drafts the run report. What was paid, what was held, what was refused. A person signs it off. Evidence: signed report.

Which controls matter, and what evidence does each leave?

Separation of approving and paying. The agent never pays an obligation it approved. Evidence: different identities on approval and execution.

Payee source must be signed. A payee detail that came from an email or an uploaded document is not good enough. Evidence: source class on each verdict.

Duplicate check across runs. Same payee, same amount, close dates. Evidence: duplicate flags and outcomes.

Running totals. Daily limits must reflect payments already made that day, including by people. Evidence: the running total recorded on each verdict.

Cut-off awareness. A payment held after the day's cut-off goes next day. The agent should say so rather than push. Evidence: timing on held items.

Recall procedure. For each rail, a written and tested procedure for recalling a payment sent in error. Evidence: procedure and test date. The reasoning for letting reversible work run and making irreversible work wait applies here with force: most payments sit on the irreversible side.

What should you measure?

• Held lines per run, by reason. If a single reason dominates, fix the upstream data.
• Duplicates caught before payment.
• Recalls needed after payment. Every one is reviewed.
• Payments executed without a linked approved obligation. Must be zero.
• Time from approval to payment, compared with the process before the agent.

Where does it usually go wrong?

"Routine" drifts. A payee paid twice becomes "known"; a variance tolerance grows to absorb rounding, then to absorb more. Keep the definition versioned and review changes.

Limits ignore human payments. The agent pays up to the daily limit while a person also pays, and the business exceeds what it meant to.

Changed details slip through. The vendor master is updated from an email without verification, then the agent pays the new details as routine. Changes to payee details must be verified out of band and trigger the cooling period.

The run report is skipped. Without a signed report nobody looks at what the agent did.

Payments are treated like case closures. Closing a case can be undone by reopening it; letting an agent close low-risk cases is a different decision with a different ceiling.

Where Pryme fits

In Pryme, executing a payment is a depth 4 capability, earned on your own cases and capped by the role's ceiling. Every payment is checked against the minimum chain at the moment of action, including your limits and the source class of the payee details. An external claim cannot authorise a payment, and some actions, such as reversing a settled payment on our own rail, are withheld for every agent.