AI Banking Chatbot

Design a Secure Conversational Assistant for Retail Banking

Design a retail bank's chat assistant that answers account questions, moves money between the customer's own accounts and takes dispute reports, without letting the language model invent a number or move money on its own.

Overview

A banking assistant sits inside the bank's app and website. A customer types 'how much did I spend at the grocery store last month?' or 'move $300 to savings', and the assistant answers or acts. Large banks already run these at scale: the CFPB found that about 37% of the US population used a bank chatbot in 2022, and that all of the ten largest commercial banks deploy one.

The hard part is not the chat. It is that a language model (an LLM) predicts plausible text, and in banking a plausible but wrong balance, a transfer the customer did not mean, or a dispute the bot failed to notice all cause real harm. The CFPB's 2023 report on chatbots lists exactly these failures: wrong answers, disputes not recognized unless the customer used certain words, and 'doom loops' with no way to reach a person. The design below answers each one with a mechanism, not a prompt.

Questions to ask first

Which channels? — The bank's mobile app and website, where the customer is already signed in
Can the assistant move money? — Yes, between the customer's own accounts only, after a confirmation on the device
Payments to other people? — Out of scope; they carry fraud risk that needs its own flow
Advice on investments or credit? — No; the assistant hands those to a licensed person
Can the model provider see customer data? — Only the minimum, under contract, with card numbers and SSNs removed first
How many users? — 10 million customers who use chat, 500,000 sessions a day

What you will be able to do

Explain why the model may read and phrase but never decide a number or move money.
Design a transfer as draft, confirm, execute, with SQL that cannot move the same money twice.
Keep card numbers and other sensitive data away from the model and the logs.
Recognize a dispute however the customer words it, and meet the Regulation E clock.
Size the service and say what happens when the model provider is down.

Key concepts

Tool calling with an allow-list
Step-up authentication
Draft, confirm, execute
Grounded answers
PII redaction
Prompt injection
Reg E disputes
Human handoff
Append-only audit log

Functional requirements

Answer balance, transaction and pending-item questions from the core banking system
Draft a transfer between the customer's own accounts and execute it only after a confirmation on the device
Answer product, fee and branch questions from approved bank documents, with the source
Recognize a reported error or unauthorized charge and open a dispute case
Hand off to a human agent at any time, with a short summary of the conversation
Record every action in an audit log

Non-functional requirements

Never show an amount that did not come from a bank system in this turn
Never move money without an explicit, device-bound confirmation
First words of a reply within 1.5 seconds at p95 (a target we chose)
Keep working without the model: menus, account facts and handoff still function
Card numbers and SSNs never reach the model provider or the logs

Interview questions

How do you stop the model from moving money the customer did not intend?
How do you defend against prompt injection?
Where do the numbers in an answer come from, and how do you know they are right?
How does the chatbot handle a dispute, and what does regulation require?
What data do you send to the model provider?
What happens when the model provider is down?
How do you size it, and what is the expensive part?
How do you know a new prompt or model version is safe to release?