Before AI agents touch money: ten questions for banks, fintechs and exchanges

October 2026 forced a decision on every platform where money moves. Customers are bringing AI agents, some with their passwords. Large banks have responded by blocking or restricting them. Others are exploring ways to let them in safely.

Whichever way you lean, the same questions come up. We have collected ten, each grounded in a published source, so a security, fraud or product team can work through them in one sitting.

Part 1: Know what is happening

1. Do you know when an agent is in a session?

Most platforms cannot tell today, because an agent using a customer's password looks like the customer. The six-bank paper Building Trust in Agentic Commerce makes knowing this its first principle: parties should be aware “when an AI agent is helping to make or facilitate a transaction, and on whose behalf.” Start by measuring: how many of your sessions show signs of automation at all?

2. Which of your actions are sensitive?

Write the list down. For a bank: transfers, payee changes, limit changes, contact-detail changes, credential resets. For an exchange: withdrawals and new withdrawal addresses. For a payments company: payouts and beneficiary changes. For an AI product: the moment a person approves what an agent will do. Every later question applies to this list, not to the whole site.

3. Could you reconstruct what happened yesterday?

In Salt Security's 2H 2026 survey, more than 60% of respondents said reconstructing an agent's previous-day activity would take hours or days, and only 12.5% could consistently trace it end to end, Campus Technology reported. That was for agents organisations run themselves. For customers' agents, the trace has to be built on your side, at your actions.

Part 2: Decide your policy

4. What may agents read, and what may they do?

The emerging default is read-only through approved channels, with no money movement. If you go further, decide which actions an agent may take alone, which need the customer's approval, and which are off limits. The draft Personal Agent Protocol models this as scopes, with a tier for actions taken only with the user's approval.

5. Who carries the loss when an agent gets it wrong?

Wells Fargo's answer, from 24 November 2026, is the customer, wherever the law allows (section 15). The six banks' paper prefers liability that reflects “where risks and errors are introduced.” And the CFPB has said that when a consumer is fraudulently induced to share access information, resulting transfers are unauthorised under Regulation E. Your terms, your regulators and your customers' expectations may not agree. Decide before the first dispute.

6. How will customers see and revoke what they granted?

Principle 2.2 of the bank paper: consumers should be able to “view and manage delegations.” If an agent got in with a password, there is nothing to revoke except the password. If it got in with a scoped grant, there is.

Part 3: Put controls at the action

7. Can an agent complete a sensitive action alone?

This is the most important question on the list. Brave's research on agentic browsers recommended that “security and privacy sensitive actions should require user interaction”, because agents can be redirected by content they read. OWASP's agentic Top 10 lists goal hijack, privilege abuse and rogue agents among the top risks. If the answer to this question is yes, every one of those risks reaches your customers' money.

8. Does your approval step prove a person approved?

A confirm button the agent can click is not an approval. An email code the agent can read is not either. The approval step needs to be tied to this action and to show that a person, not the software already in the session, is in control. Passkeys and presence checks do this; screens that only ask “are you sure?” do not.

9. When the evidence is weak, what happens?

Blocking every uncertain session hurts real customers. NIST's session guidance points to a better default: when monitoring suggests possible fraud, the relying party should “reauthenticate, terminate the session” or involve support staff. In product terms, step up: ask for a passkey, a one-time code on another device or a second approver. A person completes it in seconds. An agent alone can't.

10. Can you prove it later?

Principle 3.2 of the bank paper asks for “auditable records to evidence consumer instructions, authentication, intent, and transaction decisions and outcomes.” For each sensitive action, you want a record of what was decided, why, and whether a person was in control when it happened. That record is your answer to the customer, the regulator and the court.

A sensible order of work

1. Answer questions 2 and 4: list the sensitive actions and decide your policy for each.
2. Add a check at each sensitive action in observe mode first: see what it would decide on real traffic, without blocking anyone.
3. Agree what step-up means for your customers (question 9).
4. Enforce on the highest-risk action first, then widen.
5. Review the decision records weekly for the first month.

HEIP was built for steps 2 to 5. At each sensitive action, your server asks whether a person is at the controls and gets ALLOW, STEP_UP or DENY with reasons, starting in observe mode, without adding a puzzle and without learning who the person is. If you would like to work through this list with us for your own platform, get in touch.