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.

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.