← All Projects

Bank of the Future: Voice Banking Agent

Customers pay bills, add payees and dispute charges by voice, while 14 written policy rules decide what the agent may do and hold likely scams.

Bank of the Future: Voice Banking Agent

Voice banking for customers in Singapore and Malaysia. Customers speak to it to check balances, pay bills, add payees, freeze a card or dispute a charge. Every action the agent proposes goes through 14 written policy rules before anything happens. Large or unusual payments need a passkey, likely scams are put on hold, and every step is written to a tamper-evident audit log that operations staff can watch live.

Banks want customers to be able to talk to their bank, but a voice agent that can move money is also a new way to lose it. The brief was a voice assistant that could carry out real transactions while meeting Singapore and Malaysian expectations on authentication, scam protection and record keeping.

The build covers the customer app, a real-time voice agent, a ledger, and a policy engine with 14 rules covering limits, new payees, unusual amounts and scam patterns. The agent can only propose an action. The policy engine decides whether it is allowed, needs a passkey, or must be held. Customers can ask for a person at any point, and the human desk receives a summary so nobody has to repeat themselves.

The system ran 318 scripted and adversarial scenarios with no wrong actions and no successful prompt injections, plus full spoken runs of eight demo scenes. Median voice response time was 0.6 to 0.7 seconds. A full evaluation run costs about US$5 in model fees, which is what makes testing before every change practical.

Status
Working system
Client
Confidential

Built to the Governed Cognitive Layer: the model reads and drafts, deterministic checks decide what it may do, and a named person approves anything that commits the business.

Mid-market takeaway

Make testing cheap enough to run before every change. Here a full run of 318 scenarios costs about US$5 in model fees, so a change to the agent or the rules is tested before a customer hears it. A finance team of any size can keep a small set of hard cases, scam scripts included, and rerun it whenever anything changes.

Working system

Concept paper, C-suite deck and live demo

The concept paper, the C-suite deck and the working demo are available on request. I take executives through the scam-hold scene live.

●Live demo (on request) →

The same design rules behind this build, applied to your business in half a day.

Book the WorkshopDiscuss a build like this

Screens from the system

Customer app showing an S$8,000 payment placed on hold with the reasons listed
The customer sees why a payment is on hold. A passkey cannot release it.
Operations console showing the held payment with its reasons, latency and cost per turn, and the audit chain with verify and tamper buttons
Every action is written to a tamper-evident audit chain, with latency and cost per turn.
Customer care desk showing a handoff summary, the frozen card and the last ten turns of conversation
When the customer asks for a person, the human desk gets the full picture.

Demo data throughout. Customer names, accounts and payees are fictional.

Terence Kok
Before You Go

Early on, the agent refused a scam payment by itself. That sounds like a win, but it is the wrong design: the model was making a decision that belongs to the bank's rules. I rewrote it so the policy engine decides and the agent explains. The other lesson came from a test transcript where the caller said the scammer "said it quiet". My scam check missed it. I widened the check and added the phrase to the test set. Scam language changes faster than any rulebook, so the test set has to grow with it.

Terence Kok