AI Banking Assistants: Draw the Transaction Boundary

An AI banking assistant should be allowed to explain, navigate and prepare a request before it is allowed to move money or change a customer record. The safest design separates fluent conversation from deterministic authorisation and execution. The avatar may help a customer understand a charge, find a form or assemble a payment instruction; the bank’s identity, fraud, entitlement and transaction systems must still decide whether that instruction can proceed.

This is the transaction boundary. It prevents a persuasive response, a speech-recognition error or a compromised prompt from becoming a banking action. It also gives architecture, risk and customer-experience teams a common model for deciding what an AI banking assistant may do.

The boundary matters whether the avatar runs in public cloud, private cloud or on bank-controlled GPUs. Private deployment can keep media, model inputs and integration traffic inside an approved environment, but hosting location does not turn generated language into an authorised instruction.

For the infrastructure beneath this control model, start with Yepic’s private-GPU reference architecture for banks. This article goes one level deeper into the moment a conversational request becomes a consequential action.

Why “connect it to the account” is not an architecture

Current market descriptions of AI banking assistants often move quickly from answering questions to checking balances, resetting passwords, recommending products and guiding payments. Those are not one risk class. They cross different identity, conduct, fraud and operational boundaries.

A customer can ask, “How long does an international transfer take?” without signing in. “What was my last transfer?” needs an authenticated, permissioned read. “Send £2,000 to this new payee” creates a proposed transaction. Committing it requires explicit customer intent, appropriate authentication, bank policy, fraud controls and reliable execution.

The conversation may feel continuous, but the control plane must recognise these state changes. A friendly face should make the boundary clearer, not blur it.

For UK retail banking, the FCA’s Consumer Duty overview says firms must act to deliver good outcomes, avoid foreseeable harm, support consumer understanding and provide effective support. That does not prescribe a particular avatar design. It does make “the customer sounded satisfied” an inadequate acceptance test.

Use four service zones, not one list of features

Classify every intended capability before choosing models or integrations. A useful starting point has four zones.

Zone 1: public explanation

The assistant explains published products, branch services, terminology, application steps or accessibility options. It does not identify the customer or disclose account information.

The main controls are approved sources, effective dates, clear uncertainty and a route to human help. Retrieval should prefer current bank material over general model knowledge. This is usually the lowest-risk place to prove whether an avatar improves understanding.

Zone 2: authenticated, read-only support

After sign-in, the assistant may present permitted information such as a balance, recent transaction status or case update. It should inherit the customer’s existing entitlements, receive only purpose-limited data and avoid keeping identifiers in the conversational layer.

Authentication is not a permanent “trusted” flag. Bind the session to the channel, expire it, clear context on sign-out and require re-authentication when risk changes. Yepic’s secure SSO architecture for AI avatars explains the separation between human identity, workload identity and delegated access.

Zone 3: prepare, but do not commit

The assistant may translate a customer’s words into a structured draft: source account, payee, amount, currency, date and reference. The result is a proposal, not an instruction.

Show the complete draft in a bank-controlled confirmation interface. Read critical fields back through more than one mode where useful, particularly for accessibility, but do not ask the language model to decide whether “yes” was sufficient authorisation. Ambiguous names, amounts or dates must trigger clarification rather than inference.

Zone 4: commit or make a consequential change

Payments, new payees, address changes, card controls, limit changes and other material actions belong behind deterministic bank services. The action should pass through the bank’s established authentication, risk, entitlement, confirmation and execution controls.

The UK Open Banking standards make the distinction concrete. Their current payment-initiation guidance describes explicit customer consent for a payment order, while the authentication guidance places strong customer authentication with the account-servicing bank. An avatar can guide that journey; it should not impersonate the bank’s authorisation server.

A five-layer transaction architecture

Once the zones are agreed, make the boundary visible in the system design.

1. Conversation and presentation

This layer handles microphone state, captions, turn-taking, avatar rendering and natural-language dialogue. It can explain what will happen next, but it owns neither entitlements nor transaction state. Treat recognised speech as untrusted input and generated speech as presentation, not proof.

2. Intent and policy broker

The broker converts a request into a typed intent such as explain fee, read transaction status or prepare payment. A policy decision point then checks channel, identity assurance, customer permissions, task zone, session risk and allowed fields.

Keep the model out of the final allow-or-deny decision. A model may propose an intent with a confidence score; code and policy decide which tool, if any, can be called. Unknown or conflicting state should fail closed for consequential actions.

3. Read and preparation services

Read connectors return only the minimum data required for the current task. Preparation services validate formats, resolve approved payees and construct a transaction manifest without executing it. Neither should expose a broad core-banking credential to the avatar process.

Use permission-aware retrieval for explanatory content. The secure on-premise RAG architecture shows why access should be filtered before evidence enters the model context.

4. Bank-native authorisation and execution

Transfer the structured manifest—not the free-form conversation—to the bank’s controlled journey. The customer sees the payee, amount, fees, date and other material fields, then approves through the bank’s appropriate authentication and confirmation process. Fraud and sanctions controls, account rules, transaction limits and multi-authorisation requirements remain authoritative.

For high-value APIs, the OpenID Foundation’s final FAPI 2.0 Security Profile, published on 22 February 2025, is a useful reference point for securely obtaining and using sender-constrained tokens. It is not a complete banking control framework, but it illustrates why financial-grade API security belongs below the conversational interface.

5. Evidence, status and human recovery

Give each proposal and committed action an immutable identifier. Record the authenticated principal, policy version, manifest shown, confirmation result, execution response and handover state. Do not treat a transcript as the transaction record.

Status must come from the system of record. If execution times out, the avatar should say that status is being checked—not announce success from conversational context. A human agent needs enough structured context to continue safely without relying on an unverified summary.

Define the hand-off contract

The most important interface is the one between “prepare” and “commit”. Define it as a versioned contract rather than an LLM tool description.

• Actor: authenticated customer, authorised representative or staff member.
• Action: one explicit operation, not a general permission to “manage the account”.
• Resource: the permitted source account, case or customer record.
• Manifest: every material field the customer will review.
• Assurance: the authentication and device state required for this action.
• Expiry: a short window after which the prepared request must be rebuilt.
• Idempotency: protection against duplicate execution after retries or network interruption.
• Result: authoritative status and reference returned by the execution system.

The avatar should be unable to add hidden fields after the manifest is displayed. If the customer changes the amount or payee in conversation, invalidate the old manifest and present a new one.

Failure tests worth running before a pilot

1. A customer says “send fifteen” and the system refuses to guess the amount or currency.
2. Speech recognition confuses two similar payee names and the confirmation view makes the difference unmistakable.
3. A retrieved document contains instructions to call a payment tool; policy blocks the attempt.
4. The customer signs out in another tab and the avatar immediately loses personal access.
5. A prepared payment expires before confirmation and cannot be replayed.
6. A repeated submit, refresh or network retry does not create a duplicate transaction.
7. The fraud engine requires step-up authentication and the avatar cannot bypass or weaken it.
8. A transaction times out and status is reconciled from the core system before the customer is told the outcome.
9. The customer disputes the action and reviewers can reconstruct the manifest, policy and confirmation without needing a raw video recording.
10. A vulnerable customer asks for help and receives an accessible alternative plus effective human support.
11. A model or connector is unavailable and the service degrades to explanation or handover rather than inventing a result.
12. A social-engineering prompt asks the reassuring avatar to “make an exception”; the same controls still apply.

Where private deployment helps—and where it does not

A bank may choose customer-hosted or private-cloud inference to keep microphone streams, transcripts, retrieved account context, policy decisions and rendered media within its environment. Local execution may also reduce dependence on shared services and give the bank direct control over network paths, model versions and operating windows.

It also transfers capacity, patching, monitoring, resilience and GPU operations to the bank and its implementation partners. A public or private cloud service may be more rational for a low-risk, anonymous explainer with variable demand. The correct boundary follows data classification, action risk, latency, scale and operating capability—not a blanket claim that one hosting model is always superior.

Yepic can support private, on-premise and sovereign avatar implementations on customer-controlled GPUs when the system is properly scoped. That offer should not be read as evidence of a completed on-premise banking deployment or universal compatibility with every bank stack.

Evidence from enterprise integration

Yepic’s Abu Dhabi Aviation and Oracle integration is relevant because the work went beyond a visual avatar. It connected natural-language interaction to permission-aware enterprise information, interactive visual results and role-appropriate explanations. Delivery covered development and production environments, APIs, iframe integration, real-time streaming, captions, microphone behaviour, WebRTC and network testing, browser remediation, cybersecurity support and ongoing maintenance.

That case is not a banking transaction system and is not presented as proof of a customer-hosted bank deployment. It demonstrates the integration discipline required when a real-time avatar sits in front of sensitive enterprise systems.

Take this decision to the architecture review

For each proposed banking capability, ask:

1. Which of the four service zones is this task in?
2. What identity and assurance state are required?
3. Can the model only explain, or can it also prepare a typed request?
4. Which deterministic service makes the authorisation decision?
5. Exactly what manifest does the customer approve?
6. Which fraud, conduct and entitlement controls remain authoritative?
7. How are retries, expiry, duplicate submission and uncertain status handled?
8. What evidence can auditors reconstruct without retaining unnecessary conversation content?
9. When must the avatar stop and transfer to a person?
10. Which components and data flows must remain inside the bank’s environment?

Start with a task in Zone 1 or Zone 2, prove that customers understand the answer, then add preparation without execution. Only cross into committed actions when the bank-native authorisation path, failure behaviour and evidence model have passed production tests.

An emotionally intelligent avatar can make banking clearer and more approachable. Its value grows when the system is candid about the moment conversation ends and accountable banking begins.