An AI-powered voice banking experience built for a US neo-bank.
Discuss your project
“What if you could just tell your bank what to do,”
We built a voice layer inside a US neo-bank app that does not stop at answering questions. It checks balances, explains charges, resolves support issues, and moves money on a spoken instruction, with a confirmation gate in front of every transaction.
The client is a US-based, AI-native neo-bank building a payment layer that behaves less like an app and more like something that runs itself. They had the account infrastructure. What they wanted was an interface you could talk to, one that could carry out an instruction rather than just look one up.
Where voice banking stops
Most banking voice features are lookups wearing a microphone. They will read you a balance. Anything that changes state, whether a transfer, a frozen card, or a disputed charge, hands you back to the touchscreen and six taps of navigation.
Where we took it
We built voice as an execution surface. Intent is parsed into a validated action object, checked against a permission scope, read back to the user in full, and only then executed against the banking core. The model never touches the ledger directly.
None of them are about speech recognition. They are about what happens after the sentence is understood.
Checking a balance means opening the app, authenticating, finding the right account, and reading a number. Five interactions for one fact. Users do it several times a week, and the friction is entirely navigational.
A misheard word in a search box costs nothing. A misheard word in a transfer costs real money and real trust. Any voice feature that moves funds needs disambiguation, an explicit confirmation gate, and a full audit trail before it needs anything else.
Users hunt through FAQ pages that do not match how they phrased the question, then queue for an agent who may not have the account context to answer quickly. The majority of that volume is tier-one and mechanically resolvable.
The voice layer had to be designed, built, and hardened in four weeks, and it had to sit inside an existing production app without destabilising the flows already shipping around it.
Two people want the same number. One taps for it, one asks for it. Scroll to run the clock forward.
Tapping through the app
five screens to reach one number
Opening the app
cold start
Authenticating
biometric, or a PIN on retry
Finding the accounts screen
two taps deep
Picking the right account
four of them look alike
Reading the balance
finally
Just asking for it
one sentence, answered out loud
“What is my balance?”
one utterance
$2,140.50
answered, spoken back, done
The same holds for support. A charge you do not recognise is roughly twelve minutes of FAQ, chat queue and re-explaining yourself on handoff. Asked out loud it is about eight seconds, because the assistant already holds the account context and answers from the actual transaction. We did not put that one on a clock you have to sit through.
Scope was deliberately narrow and deliberately deep. Every capability shipped with its own risk tier, confirmation rule, and fallback path.
Balances, recent transactions, spend by category, pending items, card status. Responses are grounded in the account record at query time, never inferred and never approximated by the model.
Transfers between accounts and to saved payees, card freeze and unfreeze, limit changes, payee management. The assistant carries out the instruction rather than deep-linking the user to the screen.
Before execution the assistant reads back amount, recipient and source account in full, and waits for an explicit affirmative. Ambiguity escalates to a question, never to a guess.
Charge explanations, duplicate transactions, disputes, limits and onboarding questions, all handled against real account context. Anything outside scope escalates to a human with the transcript attached.
The language model never executes anything. It emits a structured, validated action object, and a deterministic layer decides whether that object is allowed to run.
The invariant
Nothing reaches the banking core that the core has not itself validated.
01
Streaming STT
Partial transcripts stream as the user speaks, so response drafting starts before the sentence ends.
02
Intent + entities
“Send Mom fifty” resolves to payee, amount, currency, and source account, with a clarifying question when any slot is ambiguous.
03
Action schema
Output is a typed, validated object. Malformed or out-of-scope actions are rejected before they reach any financial system.
Validated04
Confirmation gate
State-changing actions are read back in full and held until an explicit affirmative is received.
Blocking05
Execute + speak
The banking core executes; low-latency TTS confirms the outcome with a reference the user can quote.
Six constraints, written before the pipeline was, and enforced by the deterministic layer rather than requested of the model.
The assistant can invoke exactly the actions it has been granted, and nothing more. Unrecognised intent does not improvise. It routes to support, or asks a clarifying question.
Read-only queries inherit the active session. Money movement requires a higher assurance level and a fresh explicit confirmation, so convenience never leaks into the transactional path.
Full transcript, resolved entities, the emitted action object, the confirmation event, and the execution result are logged per session, so any transaction can be traced back to the exact sentence that caused it.
Streaming recognition and streaming speech synthesis run concurrently with intent resolution. The target was a reply that lands inside the rhythm of a conversation rather than after it.
Users can interrupt mid-response, correct a misheard entity, or abandon a pending action at any point before confirmation. A pending action that is not confirmed expires rather than lingering.
Every figure the assistant speaks is retrieved from the account record within the turn. The model is responsible for phrasing and intent, never for the numbers themselves.
Modelled against the manual flows the voice layer replaces, and measured in internal testing ahead of public launch.
~%
Less time on routine tasks
A balance check drops from five interactions and roughly thirty seconds to a single spoken sentence answered in about three.
<s
Median response latency
Streaming recognition and streaming synthesis keep replies inside conversational rhythm rather than arriving after it.
~%
Tier-one queries resolved
The majority of routine support questions are answered in conversation, against real account context, in seconds rather than minutes.
%
Actions confirmed before execution
Not a performance figure but an architectural guarantee: no money-movement action can execute without an explicit read-back and affirmative.
A note on these figures. The platform is pre-launch and operating a waitlist, so the first three are modelled from the manual journeys they replace and from internal testing, not from production traffic at scale. The fourth is a property of the architecture rather than a measurement. We will publish observed figures once the product is live.
A narrow scope, defined on day one, is what made a one-month build possible without cutting the safety work.
Week 01
Every candidate intent mapped, sorted into read-only or state-changing, and assigned a confirmation rule and assurance level before a line of pipeline code was written.
Week 02
Streaming recognition, intent and entity resolution, and speech synthesis wired end to end inside the existing app shell, with account data grounded per turn.
Week 03
The action schema, permission allowlist, confirmation state machine, cancel and barge-in handling, and the per-session audit log.
Week 04
Latency tuning, adversarial testing against misheard entities and ambiguous payees, accent and noise robustness passes, then rollout behind a feature flag.
The app stopped being something you operate.
It became something you talk to.
