AI Agents in Banking: How to Let Agents Act on Financial Mandates Without Losing Control

For most of their short history, AI agents in banking have talked. They answered questions, summarized statements and drafted messages. That phase is ending.

Agents are starting to act. They pay suppliers, schedule transfers, move balances between accounts, initiate payments through Pix and Open Finance, and manage routine treasury on behalf of companies and individuals. The technology to let an agent move money already exists. What doesn't yet exist, in most institutions, is the infrastructure to let it do so safely.

The question is no longer can this agent act? It is: should this agent take this specific action, right now, under these conditions, and can the institution prove afterward that it was authorized?

That question can't be answered by the agent, and it can't be answered by the institution's existing controls. It needs a new unit of control: the mandate.

Why existing controls don't fit agents

Financial institutions have spent decades building controls around one assumption: that a human is present at the moment of the transaction.

• Authentication verifies a person, not a delegation. Biometrics, device binding, one-time passwords and step-up challenges all confirm that the right human is holding the device. An agent acting on that person's behalf can't pass them, and shouldn't be able to. The result is a dead end: either the institution blocks the agent and loses the value of automation, or the customer shares credentials with the agent and the institution loses all visibility into who is actually acting.

  
  

  Credential sharing is the worst of both outcomes. The institution sees a transaction that looks like the customer. It is not. It has no record of the delegation, no limits on it, and no way to tell the agent's actions from the customer's.

• Consent defines access, not authority. Open Finance consent and API permissions define what an application may access or initiate. They don't define whether a specific action makes sense at a specific moment. A consent to initiate payments says nothing about whether this payment, to this counterparty, for this amount, should go through.

• Fraud controls look for anomalies, not mandates. Transaction monitoring is built to detect behavior that deviates from a human's usual pattern. An agent's behavior is different by design: more frequent, more regular, at any hour. It will either trigger constant false alarms or be whitelisted into a blind spot.

None of these controls is wrong. They were simply designed for a world where the actor and the account holder were the same person.

The mandate as the unit of control

When a person delegates authority to an agent, the institution needs that delegation to be explicit, bounded and verifiable. That is a mandate.

A well-formed mandate defines seven things:

1. The principal. Who is delegating authority, and on behalf of which account or entity.

2. The agent. A distinct, identifiable actor, not a borrowed set of credentials.

3. The scope. Which actions are allowed: reading data, initiating payments, executing transfers, and for which purposes.

4. The limits. Amounts per transaction and per period, frequency, permitted counterparties, time windows.

5. The conditions. The evidence each action requires before it can proceed, such as a matching invoice, a registered supplier or a confirmed balance.

6. The escalation rules. When the agent must stop and ask a human, and which human.

7. Expiry and revocation. When the mandate ends, and how it can be withdrawn immediately.

One property deserves special attention: chained delegation. In practice, agents increasingly act through other agents. A company's finance agent may delegate supplier payments to a specialized payment agent, which was authorized by the finance agent, which was authorized by the CFO. Each link must be recorded, and no agent should be able to delegate more authority than it holds. Chained delegation is hard to add to a system that wasn't designed for it, so it needs to be part of the mandate structure from the start.

Every action is a decision

With a mandate in place, each action the agent attempts becomes a decision, evaluated before anything happens. The outcome is not a gradient but one of four defined types:

• Execute. The action is within the mandate, meets every condition and is supported by sufficient evidence.

• Condition. The action can proceed only once an additional requirement is met: human confirmation, step-up authentication or further evidence.

• Escalate. The action exceeds the agent's authority, reaches a defined threshold or requires human judgment.

• Block. The action conflicts with a policy, limit or authority boundary, or required evidence is missing. It does not proceed, and the reason is recorded.

This is where the authentication dead end gets resolved. Instead of forcing the agent through controls designed for humans, the institution evaluates the agent's actions against a mandate the human approved. Step-up authentication doesn't disappear. It becomes one of the conditions the mandate can require, applied when it adds real protection rather than on every transaction.

An illustrative example

The following scenario is illustrative.

A small manufacturing company authorizes a treasury agent to pay its suppliers through Pix. The CFO approves a mandate with these terms:

• up to R$50,000 per day;

• only to suppliers already registered in the company's system;

• only against an invoice that matches the amount;

• payments above R$20,000 require the CFO's confirmation;

• the mandate expires in twelve months.

During one day, the agent attempts five payments:

Request	Evaluation	Decision
R$12,000 to a registered supplier, invoice matches	Within limits, conditions met	Execute
R$26,000 to a registered supplier, invoice matches	Above the R$20,000 confirmation threshold	Condition: CFO confirmation
R$8,000 to a registered supplier, no invoice found	Required evidence missing	Block, with the reason recorded
R$15,000 to a supplier not in the registry	Outside the mandate's counterparties	Escalate to the CFO
R$9,000 after R$47,000 has already been executed	Would exceed the daily limit	Block

The agent did most of the routine work on its own. Every exception reached the right person, for the right reason. And every decision, including the blocked ones, is on record with the mandate version, the evidence checked and the outcome.

Decide here, execute there

One architectural principle matters more than any other in agentic finance: the decision must be separate from the execution.

The decision layer evaluates the action against the mandate and issues a typed decision with a unique identifier. Execution happens elsewhere: in the institution's payment systems, or with the custodian the customer has chosen, who applies its own controls and signs the transaction.

This separation has three consequences.

• The decision layer never holds keys or funds. It can authorize; it cannot move money. Compromising it doesn't give an attacker access to accounts.

• Every execution carries the ID of the decision that authorized it. Any transaction can be traced back to the mandate, the evidence and the policy behind it. An execution without an authorizing decision is, by definition, an anomaly.

• Failure is handled safely. Execution must be idempotent, so a retried request never pays twice. When the state of an execution is uncertain, the system resolves it by stopping, not by guessing. And the path to reverse or compensate an action is defined before the action exists in production.

Proof, not just logs

When an agent moves money, disputes are inevitable. A customer says they never authorized a payment. A supplier says it never arrived. A regulator asks how the institution controls agent activity.

A log, written by the same system that made the decision, is a weak answer. What institutions need is proof: a signed record of each decision, showing that a specific action was evaluated against a specific mandate version, with specific evidence, at a specific moment. When the action settles on a shared ledger or crosses institutional boundaries, a fingerprint of that record can be anchored to the transaction itself, so any party can verify it independently, without exposing the underlying data.

With proof, a dispute stops being one party's word against another's. It becomes a verification.

What institutions should require before letting agents act

Whether an institution builds or buys, these questions separate controlled agent activity from automation with a blind spot:

1. Is every agent a distinct, identifiable actor, or does it act through the customer's credentials?

2. Is the mandate explicit, with scope, limits, conditions, escalation rules and expiry?

3. Can the mandate be revoked immediately, with effect on the next action?

4. Is chained delegation recorded, and is each agent limited to the authority it received?

5. Is every action evaluated before execution, with a typed outcome?

6. Is the decision layer separate from execution, and does it never hold keys or funds?

7. Does every execution carry the ID of the decision that authorized it?

8. Can the institution prove, to a customer or a regulator, that any specific action was authorized?

Why this matters now in Brazil

Brazil has built some of the most advanced payment and data-sharing infrastructure in the world. Pix made instant payments universal. Open Finance made it possible for authorized third parties to access data and initiate payments. Together, they make Brazil one of the first markets where agents can act on financial rails at scale.

That is an opportunity and a responsibility. The same infrastructure that lets an agent pay a supplier in seconds lets a poorly governed agent make a mistake in seconds, repeated thousands of times. Institutions that define how agents act on their rails, through explicit mandates, typed decisions and verifiable proof, will be the ones customers trust to let agents act at all.

Autonomy is an institutional parameter

The debate about AI agents in banking is often framed as a choice between autonomy and control. It is a false choice.

With a mandate, autonomy becomes a parameter the institution sets: how much an agent may do, under which conditions, and when it must ask. That parameter can be widened as trust is earned and narrowed when risk rises, without re-engineering anything.

Autonomy without governance is risk. Autonomy with trustworthy decision infrastructure is institutional capability.

Want to see how agent mandates can work on your institution's payment rails? Talk to our team →