A human clicked approve. That is not a control

Ask a finance team how it controls its treasury agent. The answer comes fast: a person approves anything above a threshold.

That sounds like a control. Usually it is not.

A click proves a button was pressed. It does not prove what the person saw, what they could refuse, or who pays if the approval was wrong.

What an approval used to carry #

An approval has never been just a click. It sits on a stack companies built over decades.

A delegation of authority says who may commit how much. A purchase order fixes what was promised. A document set gives the approver something to check. Segregation of duties stops the person who created a payment from releasing it.

Behind all of it sits a balance sheet. When a person commits the company to a payment, the company carries the loss. Authority and exposure sit in the same place.

The click is the last step. The control is everything underneath it.

What agents quietly remove #

Agents do not remove the click. They remove the stack, and they pull authority away from exposure.

A treasury agent proposes the transfer. A payroll agent assembles the run. A freight agent books the shipment and commits the spend. In each case the approver is reviewing a summary produced by the system being approved.

That leaves three questions hard to answer. What was in front of the approver? The screen has moved on, and the data may have changed. What was the agent allowed to do without asking? If nobody fixed that before the run, there is no line to point at later. And if this goes wrong, whose capital is already behind it?

The first two can be closed with better tooling. The third cannot.

Where this shows up #

A weak approval is invisible until something goes wrong. Then it surfaces in four places.

• The audit. The team can show an approval happened. It cannot show what the approval was based on.
• The dispute. Both sides have a version of events, neither can be checked, and the loss stays where it landed.
• The incident review. People argue about whether the agent exceeded its mandate, with no agreed record of what the mandate was.
• The next rollout. Legal and risk have seen how thin the control was, and the second workflow does not get approved.

The last one is the expensive one, and the most common.

What a control actually looks like #

A control has three parts.

• Task terms, set before the run. What the agent may do on its own, what it must escalate, and what counts as done.
• The decision and its basis. Whether the action proceeded, was held, or was refused, and what the approver saw at that moment rather than reconstructed afterwards.
• The funding. Capital committed to the task before it runs, with a defined payout path if the terms are not met.

The first two make an approval reviewable. The third makes it answerable.

Capital before execution #

A record does real work on its own: a held action, a clean audit trail, a version of events another party can check. What it cannot do is settle. When a payroll run goes out wrong, the reconstruction can be exact and the loss still sits with whoever was holding it.

That is what the funding is for, and the timing is the point. Capital found after a failure is a negotiation. Capital committed before the run is a control.

It also changes what the click means. The approver is not waving through a summary. They are releasing a task whose failure path is already defined and already funded. That is what makes a rollout approvable: legal and risk are not asking for a better dashboard, they are asking what happens if this goes wrong, and who carries it. The terms and the record answer the first; the funding answers the second.

Where Reineira sits #

Reineira is an accountability layer for financial agents. It runs in a sandbox; the code is unaudited. It sits at the point where a task is defined and funded, before the agent runs it.

You define each run’s terms: the mandate, the controls, and the success conditions. You choose the funding: your own capital committed to the task, or a funding provider’s under separate terms, once formed. You define the failure terms and the payout path.

Reineira is software. It does not custody funds, does not provide or arrange insurance, does not recommend capital, and does not become your client’s counterparty. The operator remains the counterparty for the service.

The short version #

A click is not a control. A control is terms fixed before the run, a record of what happened, and capital standing behind it. For a person that stack was built over decades. For an agent it does not exist unless someone puts it there.

Before handing an agent a payroll run, a supplier, or a treasury line, a finance team should be able to answer two questions. What was this allowed to do? And if it got that wrong, whose capital was already behind it?

If the honest answer to the second is nobody’s, the approval was never a control.