Emil Chetty on Letting Payment Agents Act Within Customer-Approved Boundaries

Have you ever tired of clicking approve for a coding agent or granting an assistant permission repeatedly? Emil Chetty says the industry promised to reduce complexity but often delivered a queue of requests. The result is a customer watching the process instead of having useful work handled.

Chetty leads data and AI product at Wise. He describes the company’s account for individuals, Wise Business for companies, and Wise Platform for financial institutions. Its payments network connects local banks and domestic payment schemes across multiple countries.

Chetty says Wise moved $243 billion across borders in the previous year, served nearly 19 million active customers and held more than 80 licenses. Different countries, currencies and entities impose different requirements; a chatbot does not make those obligations disappear.

Regulators still expect Wise to know what a customer authorized, control the movement of money and explain the outcome. Chetty asks how an agent can have useful autonomy while the financial institution remains accountable for what it does.

Imagine a small business owner asking an agent to handle the week’s approved supplier payments, reconcile the results and report exceptions. The owner wants the job done, not a separate approval for each lookup, document read and status check.

A long chain of approval prompts turns the person into an API. Coding agents have reduced similar friction with permission rules, classifiers and sandboxes, Chetty says. Those controls matter, but a financial transaction poses a more specific authorization question.

For a payment, the question is not merely whether an action looks safe. It is whether this customer authorized payment to this recipient on these terms. Evaluations and an agent harness remain useful, but they cannot substitute for evidence that the customer agreed to the job.

Chetty proposes turning the customer’s intent into an immutable agreement. Trusted software prepares a concrete proposal, the customer reviews and confirms its bounds, and services enforce that confirmed version. The agent can choose how to accomplish the job without changing what was authorized.

The agent may replan when the route changes without affecting agreed payment terms. If the fundamental terms change, the service returns a revised proposal to the customer for a decision. The customer approves the job; the agent selects the steps; trusted software enforces the agreement.

In a hypothetical example, business owner Sarah asks an agent to handle supplier payments. The agent first receives limited read-only access to gather context. Trusted software resolves supplier details, bank information and amounts; this preparation does not itself authorize a transfer.

Sarah sees a draft covering three suppliers and $775 in payments, together with the fee allowance and the decisions the agent may make. Missing or conflicting details must be resolved before confirmation. The example slide shows a $780 ceiling including agreed fees.

Chetty describes two views of the same job: a human-readable promise and a machine-readable record that services can check. Sarah confirms and authenticates a specific version; that version becomes the immutable authorized job rather than an agent’s interpretation of what she might have wanted.

A trusted provisioning service grants only the intersection of the confirmed job, Wise-approved capabilities and Sarah’s current rights. A payment worker can request the permitted payments, while a reconciliation worker can read invoices and results. The agent can adapt its plan but cannot expand its own authority.

Retries should not produce duplicate payments. Chetty describes shared payment state: after a crash or restart, the worker looks up the existing payment job rather than creating a second one. If a quote expires or changes, the agent prepares a replacement but asks Sarah to approve the new terms.

Chetty sketches gateways for provisioning agents, checking the immutable job, routing model access and registering and evidencing tools. A worker checks which tools it can use, calls the payment service and remains subject to the original bounds. He presents this as Wise’s approach and a rough architecture, not proof that every detail is deployed.

Suppose an invoice contains a prompt injection claiming that bank details have changed, and the agent believes it. That belief cannot modify the confirmed job. The downstream payment service rejects an unapproved recipient, while the model cannot rewrite the agreement or grant itself wider access.

The resulting evidence chain should answer who authorized the job, what the agent could do, what happened to the payment, what can be stopped and who is responsible. Chetty’s closing principle is to let customers authorize the job, let agents choose steps and have services enforce the agreement.