Conversational Banking

Chat, voice and assisted digital servicing

A conversation connected to the service

Conversational banking uses chat or voice to provide information, support or permitted actions. It can use scripted flows, intent classification, generative models or human agents. The customer needs accurate information and an effective way to resolve the task, regardless of the technology answering.

Define supported activities and their limits. Retrieving a payment status differs from giving a product explanation, making a personal recommendation or executing a payment. Decide which activities can be completed automatically and which need an authorised specialist or another controlled journey.

Ground information in appropriate records

Use authoritative business sources for balances, transaction states and account restrictions. Approved product information should have a version and scope. If a source is unavailable or ambiguous, explain uncertainty and provide the appropriate next step instead of inventing a reassuring answer.

Retrieval can improve grounding but does not guarantee truth. Test stale content, conflicting records and unsupported answers. Customer messages, documents and retrieved text must not be able to expand a model's tool permissions or disclose another customer's information.

Authentication and bounded actions

Verify identity and action authority through the bank's accepted process. Do not ask customers to reveal full passwords, one-time authentication codes or secret credentials in free-text chat. A voice resemblance or stated account number alone is not sufficient proof of every banking right.

For actions, use approved APIs with server-enforced permissions and business references. Show necessary details and obtain the appropriate confirmation. If a tool call times out, establish its original outcome before retrying a consequential effect. The bot should not promise a refund before the authorised refund decision exists.

A hand-off that preserves context

Carry relevant intent, transcript, transaction or case reference and last known status to the receiving team. Minimise sensitive content and make hand-off ownership clear. Preserve the original case history and applicable clocks rather than starting again with each transfer.

Recognise requests involving urgent fraud, hardship, complaints or other consequential matters using suitable escalation controls. Intent classification can be wrong, so provide a direct route to assistance and monitor missed escalations. A low transfer rate is not success if unresolved customers stop asking.

Worked example: a returned payment

In this fictional chat, a customer asks why rent did not arrive. The service retrieves an original instruction and a later return. It distinguishes the submitted payment from the return and explains the recorded reason only to the extent supported by evidence.

An unclear return explanation becomes an owned investigation with the original reference. The bot does not infer that the landlord rejected the customer, create a duplicate transfer or guarantee immediate recovery. The agent inherits the transaction history and the question already asked.

Operation and assurance

Test language variations, accessibility, adversarial prompts, wrong-customer retrieval, unavailable tools and ambiguous states. Monitor completed tasks, repeat contact, incorrect answers, escalation quality and unauthorised action attempts. Human review should sample high-risk errors as well as apparently successful sessions.

The CFPB's 2023 chatbot report identifies risks including inaccurate information and barriers to human support. It is a research report, not a universal rule that all financial conversations require a human.

Takeaway

A useful conversational channel combines factual grounding, bounded authority and an effective hand-off. Fluent wording cannot substitute for the financial record or the responsible team's decision.

Continue to Personal Financial Management.