For payments, treasury and transaction-banking leaders

When software starts buying

Agents are becoming buyers of the inputs software runs on: a fraud signal, a data record, a compute burst. Each purchase is worth a fraction of a penny; each agent makes thousands an hour. The question every payments leader will be asked is the same: can we support this without losing control of authority, cost or evidence?

Three design positions

Concept level here; the working demonstration carries the detail.

The instruction carries its authority

In machine-to-machine commerce there is no authenticated session to trust. The instruction, or a verifiable envelope travelling with it, must carry who the accountable principal is, what limits apply, which mandate legitimises the action and what evidence must exist. A central round-trip to a human approver does not scale to machine-speed payments; the boundary has to verify authority on the spot.

Meter, account, settle

A usage event, an economic obligation, a ledger posting and an external settlement are four different objects. Record every priced unit; accumulate and net the payables; settle when a threshold or time window is reached. Micro-pricing survives; micro-settlement becomes a policy choice rather than a reflex.

Rails are a policy decision

Depending on the case, settlement might run over a stablecoin, a tokenised deposit, an instant account-to-account payment, a card rail, an internal ledger transfer or a periodic net position. The agent's contract specifies the economic outcome; a settlement policy selects the rail on cost, finality, liquidity, jurisdiction and protection.

Sub-cent value is not sub-cent risk

At machine speed a tiny defect compounds fast: an agent can generate millions of individually valid but collectively harmful transactions before a human notices. The controls that matter are core banking discipline under new stress: idempotency on every command, double-entry invariants, cumulative and velocity limits per agent and per mandate rather than per customer, fail-closed authorisation, concentration controls, and an event log that can be replayed to reconstruct any position.

Where multiple rules apply, the calculation can be automated. The precedence rule cannot be wished away. It is a firm policy decision: which rule wins, who approved that posture, what risks were accepted and what evidence must be retained. The engine executes the rule; the decision record governs the rule's legitimacy.

The emerging standard, and the layer beneath it

HM Treasury's Financial Services AI Adoption Plan (July 2026) calls for a trust framework for agentic payments on three pillars. We support it, and we complete it: knowing the agent is necessary, but knowing the decision it acted on is what makes accountability real.

Legal and liability

Liability follows control. A bank that correctly executes a validly mandated instruction should not carry the loss for an agent failure it could neither see nor prevent. The decision record is what makes that allocation provable rather than argued after the loss.

Know Your Agent

Verifiable identity and status for a non-human actor, derivable from the authorising party. The natural substrate is the Data (Use and Access) Act digital verification trust framework, extended from people and legal entities to agents.

Authentication and governance

A durable, machine-readable mandate the counterparty can verify, carried by reference in the payment message. The message references the mandate; it does not execute it. Enforcement stays with the ledger and the rules layer.

Beneath all three sits the Agent Contract. Know Your Agent verifies the identity; the Agent Contract governs everything after it: identity and owner, mandate, permissions, decision authority and execution authority, evidence requirements, operating boundary, revocation, accountability and audit trail. It is machine-readable, inspectable and revocable. This is the layer the plan gestures at and stops short of defining.

What exists today

The authority, metering and settlement-policy model is built into our working demonstration on synthetic data: usage recorded individually, obligations aggregated and netted, authority checked per action, and settlement switchable between rails under one policy. Live rail execution at scale is designed, not yet built, and we say so plainly.