Machines as Customers: Agent to Agent Economy in Banking

Machines as Customers: Agent to Agent Economy in Banking

Banks are not only preparing for AI agents inside their own operations. They are preparing for AI agents on the other side of the counter.

That change sounds abstract until it reaches a real system. A treasury agent requests pricing. A procurement agent initiates payment. A merchant agent disputes a charge. A wealth agent moves liquidity between accounts. A compliance agent asks for evidence. None of these actors is a person using a screen, but each one expects the bank to respond.

The customer has stopped being only human.

I think this is one of the more important shifts in financial services architecture because it attacks a quiet assumption inside most banking platforms: the user is a person, the session is human-paced, and the interface exists to be read.

In an agent to agent economy, none of that holds.

The customer stops being human

Most digital banking systems were built around a human request pattern. A person logs in, views information, makes a choice, and confirms an action. Even the API layer often mirrors that pattern. The system waits for requests that ultimately map back to human intent.

Agent customers behave differently.

They ask more often. They compare faster. They retry without frustration. They negotiate based on policy. They read machine responses, not page layouts. They may transact in smaller amounts and at higher frequency than a human customer ever would.

That creates a different capacity problem, but it also creates a different product problem. A bank cannot assume the primary customer experience is a mobile screen. The primary experience may be whether the agent can discover the bank's capabilities, understand the terms of an action, prove authority, complete the transaction, and retain evidence.

The interface becomes contractual.

That is a harder design task than exposing another API. A normal API lets another system call the bank. An agent-facing surface has to let another system reason about the bank. It needs clear states, explicit permissions, predictable failure modes, and evidence that survives audit.

I do not think most banks are ready for that yet. They have APIs, but they do not have agent-native operating surfaces.

Identity becomes the hard part

The first hard question is not what an agent can do. It is who the agent is acting for.

Human banking identity is already difficult, but the model is familiar. A person is identified, authenticated, authorised, and monitored. With an autonomous agent, the bank has to identify the software actor, the organisation or person behind it, the scope of its authority, and the chain of intent that led to the action.

A password is the wrong abstraction for that world.

An agent needs a cryptographic identity, but cryptography is only the beginning. The bank also needs to know what the credential means. Is this agent allowed to price? To commit? To move funds? To accept liability? To delegate to another agent? To operate only during market hours? To act only below a threshold?

That is not a login problem. It is a policy problem.

The identity layer has to bind machine action back to human or corporate accountability. If an autonomous procurement agent moves money incorrectly, the bank cannot answer the regulator by saying the model did it. The bank needs the evidence chain: which agent acted, under whose authority, against which policy, with which approvals, at what time.

I expect this to become the banking version of Know Your Customer for non-human actors. Know Your Agent will not be a slogan. It will be a control surface.

Compliance has to move at machine speed

The second hard question is whether compliance can operate at the same tempo as the agent.

A human-paced process can tolerate queues. An agent economy cannot. If every machine-initiated action has to wait for manual interpretation, the bank has not built an agent-facing service. It has built a slow exception process with a modern name.

That does not mean removing human accountability. It means placing human judgement where it belongs: in the design of the policy, the approval of the operating boundary, and the review of exceptions that genuinely require judgement.

The routine path has to be encoded.

For banking, that means sanctions checks, transaction limits, authority checks, data access rules, model-use constraints, and audit evidence cannot sit as after-the-fact controls. They have to be part of the execution path.

I prefer to think of this as compliance becoming part of the runtime. The platform should know what an agent is allowed to do before the action happens. It should reject out-of-scope behaviour immediately. It should record the decision in terms a human reviewer can inspect later.

The gap between machine speed and governance speed is where the risk lives. If the agent moves faster than the control environment, the bank is exposed. If the control environment is built into the platform, the agent can move quickly without becoming unaccountable.

That distinction is going to separate serious deployments from demos.

The bank becomes an operating surface

The deeper shift is that the bank becomes a surface for other systems to operate against.

That requires cleaner domain boundaries than many institutions have today. Payments, identity, risk, pricing, onboarding, and evidence management cannot be tangled together behind human workflows. Agent customers will find the ambiguity immediately because ambiguity becomes latency, failed requests, or unsafe execution.

A bank that wants to serve agent customers needs a platform that can state its capabilities clearly and enforce its boundaries technically. It needs event-driven flows for state change, not only request-response endpoints. It needs policy at the edge, not only policy in documents. It needs observability that explains intent, not only infrastructure health.

This is why I do not see the agent to agent economy as a chatbot story. It is an operating model story.

The banks that move first will not be the ones with the most polished assistant. They will be the ones that make their core capabilities usable by software actors without losing control. They will treat agents as counterparties with constrained authority, not as users with faster fingers.

The temptation will be to create a thin agent interface in front of existing systems. That will work for demos. It will fail when the volume rises, when liability appears, or when the regulator asks how the bank knows what happened.

The agent to agent economy does not ask banks to trust machines blindly. It asks them to design systems where machine action is bounded, legible, and accountable.

That is a much more interesting engineering problem than another digital channel.