Conversational Banking: From Customer Questions to Authorized Actions

A customer opens their banking app and types:

“I don't recognize the €84 payment from yesterday. What is it, and should I block my card?”

For the customer, this is one question. For the bank, it crosses several systems and several levels of risk. The assistant needs to understand what the customer means, identify the right transaction, retrieve trusted information, explain what it found, and potentially move from answering a question to taking action.

Conversational banking connects these customer requests to bank-controlled services. The model interprets the message and requests the relevant operation. Banking services verify permissions, apply the required controls, and execute the action.

Following this example from transaction lookup to card freeze and specialist handoff shows how those responsibilities fit together, and what the bank needs to control at each step.

Start with the customer's intention

The assistant first needs to establish what the customer is referring to. Because the conversation happens inside an authenticated banking channel, it can work with the customer's session and identity context. It does not need the customer's entire financial history in its prompt.

The model interprets “the €84 payment from yesterday” and requests the relevant transaction data through a controlled banking capability. The transaction itself still comes from the bank's systems of record. The model may explain the result, but it is not the source of the amount, merchant, date, or card information.

That separation matters, because banking systems remain responsible for truth, while the model handles language, interpretation, and orchestration. For consequential information, the system retrieves authoritative values rather than relying on what a model happens to know or generate.

The assistant can now respond:

“I found one €84 card payment to ACME Digital yesterday, made with your Visa ending in 7734. Do you recognize this merchant?”

At this point, the assistant has identified the transaction and answered using details retrieved from the bank’s systems.

When conversation becomes action

The customer answers:

“No. Freeze the card.”

With the customer's reply, the nature of the interaction has changed. Reading a transaction and changing the state of a payment card should not be treated as the same operation.

The model can recognize the new intent and request the freeze_card capability. It should not decide on its own that the customer is authorized to use it, nor should it directly modify a banking database. The request passes through a controlled tool and policy layer that evaluates the authenticated user, channel, capability, risk level, parameters, and required confirmation before the banking service is invoked.

This creates the most important boundary in the architecture: AI can reason about what should happen next, while deterministic systems decide what is actually permitted and execute the operation.

This division of responsibilities also applies to other banking services. A conversational assistant might find a transaction, retrieve a statement, explain a fee, or prepare a transfer. The controls depend on the requested operation and its potential financial or security impact. Moving money, for example, may require additional authentication and explicit customer confirmation before execution.

Build a banking harness, not a generic agent

This is where domain-specific harness engineering becomes important.

Instead of placing a general-purpose AI agent in front of banking APIs, the bank builds a harness specifically around banking processes. The harness defines which capabilities exist, how workflows progress, which context is available, when clarification is required, where deterministic policies apply, and when control must move to another system or a human.

The model operates inside this environment rather than inventing the process itself.

A sovereign model can become part of that architecture. For example, a bank may operate an open-weight model within infrastructure and governance boundaries it controls, then fine-tune it on approved banking processes, terminology, tool-use patterns, clarification behavior, and representative conversation traces. Fine-tuning is useful for teaching the model how the bank works, not for storing changing customer balances, current product conditions, or other financial facts. Those remain in authoritative systems.

The result is more than just a more knowledgeable chatbot. It's a model that has learned how to operate inside a specific banking harness: when to retrieve information, which capability to request, what information is missing, when to ask the customer, and when not to proceed.

The model is a component, not the compliance strategy

A model trained for banking workflows does not need to handle every interaction. Different tasks may call for different models.

A smaller sovereign model may handle intent recognition, entity extraction, routing, predictable tool calls, and many routine conversations. More capable models can be used when conversations become ambiguous or require deeper reasoning.

A model gateway keeps this decision separate from the banking application. It can route between sovereign models and approved external models while applying provider policies, PII controls, logging, fallbacks, and cost limits. Models can then change as quality, economics, or requirements evolve.

But neither a sovereign model nor fine-tuning makes the resulting system compliant by itself.

Compliance emerges from the complete system: how data is handled, which capabilities the model can access, how customers are authenticated, how actions are authorized, how third parties are governed, when confirmation is required, and whether decisions and actions can later be reconstructed.

The architecture matters at least as much as the model. To assess whether those controls work as intended, the bank needs visibility into the complete interaction, from the customer’s request to the final banking action.

Our Custom & Private Models offering covers model evaluation, fine-tuning, and deployment options for teams with specific data, security, and operational requirements.

Observe the complete journey

After the card is frozen, the assistant tells the customer what happened. But the customer-facing response is only one part of the record.

The bank should be able to reconstruct the journey from the initial message to the final state: which context was provided, which model and policy version were active, what tool the model requested, what parameters it supplied, what the policy layer decided, what the banking backend returned, and what the customer was ultimately told.

That level of observability is especially important for agentic systems. The complete interaction chain should be reconstructable, subject to appropriate privacy and retention controls.

Monitoring therefore goes beyond uptime, token consumption, or GPU utilization. We also need to check that the assistant selected the correct tool, asked for clarification when needed, and followed confirmation requirements. That includes checking responses against retrieved information, identifying policy violations, and assessing how well the interaction resolved the customer’s request.

The important operational question becomes less “Did the model respond?” and more “Did the complete system produce the correct and permitted outcome?”

Know when AI should hand the case to a specialist

Our customer continues:

“There are three more payments I don't recognize. I want my money back.”

The assistant retrieves the transactions and connects them to the current case. But the problem has now moved beyond a simple card-control operation. A fraud investigation and potential reimbursement may require a specialized workflow or a human expert.

Instead of trying to automate beyond its mandate, the harness recognizes when a case requires a specialist and hands it over.

The customer does not have to start again. The specialist receives the authenticated customer context, affected card, disputed transactions, actions already completed, and reason for escalation. The conversation becomes part of the case, and the human continues where the AI stopped.

Then something unexpected happens

The immediate story ends well. The card is frozen, the suspicious transactions are collected, and the fraud specialist takes over without asking the customer to repeat everything.

Additionally, the recorded interaction can inform later evaluation and improvement.

Because the complete interaction is observable, the bank can see that the assistant correctly identified the transaction, selected the right capabilities, asked the right questions, respected the authorization boundary, and handed the case over at exactly the point where human judgment became necessary.

After review and appropriate data preparation, successful interactions like this can become evaluation cases and, where suitable, training examples for the sovereign model. The model can become better at the bank's actual processes without learning private customer facts.

Thanks to this the next customer with a similar problem may receive a faster and more precise experience.

Banks can apply this architecture to other services, too. The domain-specific harness can gradually gain new controlled capabilities for payments, cards, financing, savings, service requests, and financial guidance. Each new capability extends what customers can accomplish through conversation without giving the model unrestricted control over the bank.

A customer asking about an unfamiliar payment may need several things: an explanation, a card freeze, and a way to dispute the transaction. Building a conversational service means connecting those steps so the customer can move through them with the right checks and assistance along the way.

For banking product and technology teams, the next step is to choose one customer workflow and map it from the opening question to a confirmed outcome. Define the information the assistant needs, the actions it can request, the checks required before execution, and the point at which a specialist should take over.

Test that workflow with ambiguous requests and failed actions as well as successful conversations. Use the findings to decide what needs improving and when the service is ready to cover more customer needs.

Before extending the workflow, check that your banking app’s delivery foundations can support it. Read Why Banking App Modernization Stalls Before It Ships for a closer look at testing, observability, release coordination, and ownership across teams.