Agentic banking: AI that actually moves money.

Agentic banking is the use of AI agents that plan, reason, and execute real financial transactions on behalf of customers, inside the bank's own systems and under its control. Unlike a chatbot that answers questions or hands off to a human, an agentic system moves money, opens accounts and resolves issues, with every action validated against policy and written to an audit trail.

Manual money-movement operations, back-office reconciliation, and the account changes that currently route through customer support. What it does not replace is the judgement call: a credit decision, an exception outside policy, or anything a regulator expects a named person to have signed. If a vendor tells you it replaces those too, that is the answer to end the meeting on.

A chatbot can talk about banking; an agent can do banking. Chatbots retrieve and answer. Agentic systems compose a multi-step transaction, check it against bank policy and the customer's real account state, execute it, and confirm the result. The difference is execution, and execution is what changes your risk profile.

One process, picked for shape rather than visibility: high volume, rule-governed at the core, currently capped by a small share of messy exceptions. Wrap the existing system rather than replacing it, put the reasoning step only where exceptions fall out, and keep everything either side deterministic. That sequences value before architecture. Programmes that start with a platform decision tend to spend their first two quarters in procurement.

It sits on top of it rather than replacing it. Your existing bots keep doing the deterministic work they do well, and a reasoning layer handles the exceptions that currently fall out to a queue. That protects the investment and makes the business case easier, because the comparison is incremental lift on a known baseline rather than a rip-and-replace.

FIS, Fiserv, Jack Henry, Temenos, Mambu and Thought Machine. Integration is typically through the core's own APIs where they exist and a service layer where they do not, with the agent never holding core credentials directly. The pattern matters more than the vendor: the agent calls named, permission-scoped tools, so swapping a core changes the adapter rather than the agent.

Three layers, and none of them is the model. A policy layer the model cannot override decides which tools exist for this customer and channel. Per-action authentication ties a state-changing step to a verified human. Everything is written to a tamper-evident log, and the bank holds a kill switch. The agent is also grounded in your systems of record, so it cannot invent an account, a balance or a payee.

With an evaluation harness, run against a graded set of cases including the ones designed to make it fail: adversarial inputs, questions your data cannot answer, and edge cases pulled from your own exception queue. It runs before and after every change, scoring groundedness, citation precision and refusal behaviour. The harness is a deliverable you keep, not a tool we hold. Methodology is on /proof.

Steps are idempotent, so a retry produces the same result rather than a duplicate payment, and partial execution rolls back to a known state rather than leaving a half-finished instruction in the ledger. The reasoning trail replays deterministically for investigation. This is ordinary payments engineering rather than anything novel about AI, and it is the part most AI-first vendors have not built.

The bank, exactly as it is for any automated system today. The useful question is whether your accountability framework extends to this, and usually it mostly does: model risk, change management and outsourcing governance already cover automated decisioning. What typically has to be built is enforcement at the point of action, and an identity for the agent itself so the log says which agent acted under whose authority rather than just naming a service account.

They approve what they can inspect. The artefacts that get a programme through are a model inventory with owner and risk tier, a risk classification per use case rather than per system, documented human-oversight design, and retained logs proving accuracy was measured against a stated baseline. We produce those as part of delivery rather than reconstructing them when review is scheduled. Governance mapping is on /services/ai-security-governance.

No. Deployment is inside your own VPC, using your IAM, your secrets management and your observability. We do not train on your data. Where a third-party model is in the chain, it is named in the architecture document and we will route around any provider your counsel will not accept.

Systems we have built have been reviewed by the OCC, the CFPB and state DFS as part of standard examinations. What examiners consistently want is the same short list: show which decisions the system made, on what evidence, under whose approval, and demonstrate a human could have intervened. A system designed to answer those three questions tends to pass; one designed to demonstrate capability tends not to.

Delivery supports the institution's KYC, BSA and AML obligations and runs under SOC 2 Type II controls, with the attestation issued against your deployment and your auditor of record rather than held by us at company level. Data is isolated per institution, and custody, licence and funds stay with the regulated entity.

Straight-through processing rate, not automation rate. The exception queue is what caps return, so the number that moves the case is the share of cases completing with no human touch, measured before and after on your own volumes. Pair it with the cost of the manual handling it removes. We have shipped this pattern into production: 1M+ transactions automated on QuickCard, and real-time payments at scale for RYVYL (NASDAQ: RVYL). Both case studies are linked from this page.