Your customer's agent is at the door: what the Personal Agent Protocol means for consumer financial services

On 6 October Meta and Sierra announced the Personal Agent Protocol, or PAP (its authors call it “Poppy”). Draft 0.1 of the specification followed on 9 October, and the specification site now carries draft 0.2. The launch partners were Walmart, Shopify, Stripe, Genesys and Rocket. On 9 October Sierra added 35 design partners, and the list reads like a roll-call of consumer finance: Bank of America, Wells Fargo, BBVA, Chime, Synchrony, Visa, Mastercard, PayPal, Venmo, Plaid, Adyen, GEICO and Liberty Mutual, alongside OpenAI, Okta and 1Password. The problem it addresses is simple. Personal AI agents currently deal with businesses the way a person would: they load web pages, click through forms and, when that fails, sit on hold with the contact centre. PAP proposes a direct, authorised connection instead.

Most commentary has treated it as a retail story. I think the bigger consequences are in consumer financial services, where every interaction is about identity, consent and money. Here is what the draft does, what it leaves open, and what I would ask a bank’s board to decide now.

What the draft actually does

The mechanics are sensible and built on established standards.

• Discovery. A business publishes a file at a fixed address on its website (/.well-known/poppy.json) saying how agents can reach it: through its website, its APIs (via MCP or OpenAPI), or its own customer-service agent.
• Agent identity. Each personal agent identifies itself with a URL pointing to its metadata and public keys, so the business knows which agent product is calling.
• Sign-in. The customer authorises the agent through OAuth, either on the business’s own sign-in page or by a device code. The session tokens are short-lived and bound to the agent’s keys, so a stolen token is of little use on its own.
• Permissions. Two default scopes: read and write. Businesses can add their own, narrower scopes.
• Revocation. Access ends when the customer signs out, disconnects the agent in their account settings, or the business revokes it.
• Payments. Outside the core. Sierra describes Poppy as complementary to Google and Shopify’s Universal Commerce Protocol, which handles shopping, and has said payment extensions may follow.

For a retailer, that is most of what is needed. A customer’s agent can check an order, change a delivery address or start a return, and the retailer can see that an agent is acting and on whose behalf.

Why financial services is different

UK banking has already been through this argument once. Before open banking, aggregators collected customers’ banking passwords and logged in as them, a practice known as screen scraping. Open banking replaced it with regulated, consent-based APIs: the third party is identified and authorised, the customer gives specific consent, and the customer never hands their password to anyone else.

PAP, in its first draft, is open banking’s consent model applied to everything else: insurance policies, mortgage accounts, pensions, loyalty schemes, utilities. That is a real opportunity, because most of those products sit outside open banking today. But four gaps matter far more in finance than in retail.

1. Read and write are too coarse. In a bank account, “write” covers everything from changing a marketing preference to adding a new payee. Those are not the same risk. A useful permission model for finance needs at least four levels: unauthenticated questions, signed-in viewing, reversible changes, and irreversible actions such as payments, transfers, new payees and changes of address. The last level should stay closed, or require the customer’s own step-up confirmation, until the regulatory questions below are answered.

2. One sign-in route is a step backwards. Alongside the two OAuth routes, the draft defines a “mediated” route in which the agent submits the customer’s own username and password to the business. For a bank, that is screen scraping in a new form. It conflicts with most banks’ terms and conditions, and it blurs the line between an authorised and an unauthorised transaction. No regulated firm should accept it.

3. The regulated questions are untouched. Under the Payment Services Regulations, a firm must be able to show that its customer authorised a payment, and strong customer authentication assumes a person is present. If an agent initiates a payment, is the agent’s provider performing a regulated payment initiation service? Who carries the loss if the agent was mistaken, manipulated or impersonated? How does a firm meet the Consumer Duty, and its obligations to vulnerable customers, when it is talking to software? PAP does not attempt these questions, and it is right not to. They belong to regulators and to the reform of the payments regime that HM Treasury has already begun. But it means a bank cannot treat PAP as a complete answer.

4. Whose interests does the agent serve? The consumer’s agent is built by a company with its own commercial interests. A financial firm has a duty to deliver good outcomes for its customer. It should be able to tell which agent it is dealing with, apply its own controls, and refuse an agent that behaves badly. PAP’s agent identity gives firms the first of those; the rest is up to them.

What changes for banks, lenders and insurers

The front door moves. If a customer’s agent can compare, switch and cancel on their behalf in seconds, inertia stops being a business model. Pricing that relies on customers not shopping around, already under pressure from the Consumer Duty, gets harder to defend.

Customer service becomes agent to agent. The draft lets a business route an agent to its own agent for conversational tasks such as a claim or a complaint. Firms that have invested in good service agents, with proper controls and records, will handle this well. Firms still relying on web forms and call queues will be the ones whose customers’ agents give up and go elsewhere.

Data access arrives through the side door. A read scope on an insurance or mortgage account is, in effect, open finance delivered voluntarily, years ahead of any mandated scheme. Firms that design that access deliberately will set the terms. Firms that ignore it will find agents working around them.

Fraud gets new targets. Agents can be impersonated, and customers can be tricked into authorising a malicious one. Key-bound tokens and agent identity help, but firms will need to monitor agent behaviour the same way they monitor device and payment behaviour today.

What I would ask a board to decide now

None of this needs a build programme yet. The specification is still a draft that can change before a stable version, and Google, Amazon and Anthropic are not among the named partners. But four decisions can be taken now, and they hold whichever standard wins.

1. Choose the door. Decide whether external agents will reach you through your website, your APIs or your own agent, and for which tasks.
2. Write the permission matrix. Map every customer action to the four levels above. Keep irreversible actions closed to agents until you have a regulatory position.
3. Refuse credential sharing. State now that you will not accept agents signing in with customers’ passwords, whatever protocol they use.
4. Build scoped APIs. OAuth-scoped APIs that match the permission matrix are useful for PAP, for Visa’s Trusted Agent Protocol, for Google and Shopify’s Universal Commerce Protocol, and for whatever comes next.

The bigger point

I have argued on this site that a company’s lasting asset in the AI era is its context and memory: what it knows about its customers and how it uses that knowledge. PAP is the other side of the same coin. The customer’s agent will build its own memory of every bank, lender and insurer it deals with: how fast they respond, how fairly they treat the customer, how easy they are to leave. Firms will be judged by software that never forgets. The ones that prepare for that now, carefully and within the rules, will win the customers’ agents and, through them, the customers.

Sources: Sierra: Introducing the Personal Agent Protocol (6 October 2026); Sierra: Poppy draft and design partners (9 October 2026); Personal Agent Protocol specification (draft); UCP Checker: PAP v0.1 explained; Addleshaw Goddard: agentic AI considerations for payment service providers.