Britain Is Rewriting Its Payments Rulebook For Agents And Tokens - And The Consultation Closes On 6 October. What UK Engineering Teams Should Say, And Build

Most consultations are about tidying. This one is about who writes the rules for how money moves in Britain for the next decade. HM Treasury's proposal, published on 14 July with responses due by 6 October, would shift the technical and firm-facing detail of payments regulation from the Payment Services Regulations into FCA rules - a more agile framework that can change without primary legislation - while keeping core consumer protections and the regulatory perimeter in statute. It asks whether existing provisions need updating to reflect tokenised and agentic payments. And it reforms Open Banking: a new right of access for variable recurring payments, and the ability for banks and third parties to agree fair commercial pricing.

It does not stand alone. The FCA's Mills Review, published 6 July, concluded the existing framework - Consumer Duty, the Senior Managers Regime - remains fit for purpose and recommended no AI-specific rulebook, but set seven priorities including monitoring the transition to autonomous models, scaling the FCA's AI Lab, enabling the foundations for agentic finance and building an AI-enabled agentic supervisory model. The Treasury's 14 July AI adoption plan for financial services called for agentic payments readiness and legal clarity. And this week, as OpenAI launched Dots - agents that run continuously on their own cloud computers and act across thousands of apps - the UK was on the list of places they do not yet ship. That is not a failure; it is a window. The UK gets to write the rules before the agents arrive at scale.

What Engineering Teams Should Tell The Treasury

1. 01Define the agent as a party. An agentic payment has three parties, not two: the payer, the payee and the agent acting under a mandate. Rules should require the agent to be identified in the payment - who operates it, on whose behalf, under which mandate - so liability and disputes have something to attach to.
2. 02Make the mandate the regulated object. Variable recurring payments already give the UK a consented, parameterised authority to pay. Extend that model: an agent mandate with scope, limits, duration and revocation, held by the payer's bank, enforced at authorisation time.
3. 03Put limits where they can be enforced. Per-transaction, per-period and per-payee caps must be enforced by the payer's account-servicing provider, not promised by the agent platform. The rules should say so.
4. 04Keep strong customer authentication for consequential actions. New payees, limit changes and mandate creation need the human; payments inside a live mandate should not re-prompt, or agents become useless.
5. 05Set a liability default. If an agent pays outside its mandate, the party that enforced - or failed to enforce - the mandate bears the loss. Clarity here is what will let banks say yes.
6. 06Require machine-readable dispute evidence. Mandate, agent identity, the instruction the agent received and the authorisation decision should be retrievable for every agentic payment.

The Model We Would Build To

The good news is that the engineering already exists in pieces. VRP consent objects, payment-initiation APIs, confirmation of payee and step-up authentication are all in production in the UK. The agent mandate is a composition of them, plus identity for the agent. Below is the shape we use in agentic-payment work, written so that a regulator could read it as easily as an engineer.

export interface AgentIdentity {
  operator: string;          // regulated entity operating the agent, e.g. "urn:fca:frn:123456"
  agentId: string;           // stable id of this agent instance
  onBehalfOf: string;        // payer's customer id at the ASPSP
}

export interface AgentMandate {
  id: string;
  payerAccount: string;
  agent: AgentIdentity;
  purpose: string;                        // shown to the payer at consent
  payees: { id: string; copVerified: boolean }[];   // existing, CoP-verified payees only
  limits: { perTxnMinor: number; perPeriodMinor: number; period: "day" | "week" | "month" };
  validFrom: string; validTo: string;
  requiresHumanFor: ("new_payee" | "limit_change" | "above_threshold")[];
  status: "active" | "revoked" | "expired";
  consentEvidence: string;                // reference to the SCA event that created it
}

export interface AgentPaymentInstruction {
  mandateId: string;
  agent: AgentIdentity;
  payeeId: string;
  amountMinor: number;
  reference: string;
  intent: string;                         // the agent's stated reason, stored for disputes
  idempotencyKey: string;
}

type Decision = { ok: true } | { ok: false; reason: string; needsHuman?: boolean };

// Runs at the payer's bank (ASPSP). The agent platform cannot change any input.
export async function authoriseAgentPayment(i: AgentPaymentInstruction, store: MandateStore): Promise<Decision> {
  const m = await store.get(i.mandateId);
  if (!m || m.status !== "active") return { ok: false, reason: "mandate not active" };
  if (m.agent.agentId !== i.agent.agentId || m.agent.operator !== i.agent.operator)
    return { ok: false, reason: "agent identity does not match mandate" };
  const now = new Date().toISOString();
  if (now < m.validFrom || now > m.validTo) return { ok: false, reason: "mandate outside validity" };
  const payee = m.payees.find((p) => p.id === i.payeeId);
  if (!payee) return { ok: false, reason: "payee not in mandate", needsHuman: true };
  if (!payee.copVerified) return { ok: false, reason: "payee not CoP-verified", needsHuman: true };
  if (i.amountMinor > m.limits.perTxnMinor) return { ok: false, reason: "per-transaction limit", needsHuman: true };
  const used = await store.usedInPeriod(m.id, m.limits.period);
  if (used + i.amountMinor > m.limits.perPeriodMinor) return { ok: false, reason: "period limit" };
  await store.recordAuthorisation(m.id, i);      // mandate, agent, intent, decision: dispute evidence
  return { ok: true };
}

Note what the code makes true by construction. The agent can only pay payees the human already verified; limits live at the bank; a mismatch between the agent and the mandate is a hard refusal; and every authorisation records the mandate, agent and stated intent. Those four properties are what a liability default can rest on - and they are what the Treasury should require, not merely permit.

“Open Banking taught the UK how to let a third party move money with consent. Agentic payments are the same lesson with a new party in the room. Britain already has the grammar; the consultation is about writing the sentence.”

What To Do Before 6 October

• Respond. Engineering voices are under-represented in payments consultations, and the questions on agentic and tokenised payments are open. Say what the mandate model must support.
• Map your VRP and payment-initiation stack against the mandate shape above; most of it is already there.
• Decide your agent-identity scheme now. Whatever the rules settle on, you will need to know which agent, run by whom, initiated a payment.
• Watch the Mills Review follow-through. An agentic supervisory model implies machine-readable reporting; design your audit records to be exportable.

The Bottom Line

HM Treasury's overhaul - FCA-led technical rules, statutory protections, explicit questions on tokenised and agentic payments and a new VRP right of access - closes for responses on 6 October, alongside the Mills Review's call to lay the foundations for agentic finance and in a week when always-on agents launched everywhere but here. We think Britain should use the window to write the first workable rules for agents that pay: the agent as an identified party, the mandate as the regulated object, limits enforced at the bank, SCA reserved for consequential changes, a liability default and machine-readable dispute evidence. The engineering is largely built; what is needed is the rule that makes it mandatory. As an AI and payments engineering firm in London, that is the response we are filing, and the model we build to.

References & Further Reading

• Global Regulation Tomorrow (Norton Rose Fulbright) - HMT consults on modernising payment services regulation. regulationtomorrow.com/2026/07/hmt-consults-on-modernising-payment-services-regulation
• Skadden - HM Treasury proposes major overhaul of UK payments regulation. skadden.com/insights/publications/2026/07/hm-treasury-proposes-major-overhaul
• A&O Shearman - Modernising UK payments: HM Treasury's proposed overhaul of the payment services regime. aoshearman.com/en/insights/ao-shearman-on-fintech-and-digital-assets/modernising-uk-payments-hm-treasurys-proposed-overhaul-of-the-payment-services-regime
• Bratby Law - Agentic payments: HM Treasury's July 2026 consultation and the accountability gap. bratby.law/agentic-payments-accountability-gap
• FCA - AI and the future of retail financial services (the Mills Review). fca.org.uk/publications/corporate-documents/mills-review
• Osborne Clarke - Regulatory outlook September 2026: fintech, digital assets, payments and consumer credit. osborneclarke.com/insights/regulatory-outlook-september-2026-fintech-digital-assets-payments-consumer-credit
• TechCrunch - OpenAI launches Dots (29 September 2026). techcrunch.com/2026/09/29/openai-launches-dots-its-bubbly-agentic-avatar

Code in this guide is illustrative and supplied without warranty. Review and test it before production use. Nothing here is investment advice. Important information