Codiste Portfolio · Fintech · Voice AI
Say it.
The bank does it.
“What if you could just tell your bank what to do - and it did it?”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.
Discuss your requirementMoney movement always passes a read-back gate.
The brief
Finance that answers is table stakes.
Finance that acts is the product.
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, not just look one up.
Where voice banking stops
Read-only assistants
Most banking voice features are lookups wearing a microphone. They will read you a balance. Anything that changes state - a transfer, a frozen card, a disputed charge - hands you back to the touchscreen and six taps of navigation.
Where we took it
An assistant with hands
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.
The Challenge
Four walls between
a user and a simple task.
None of them are about speech recognition. They are about what happens after the sentence is understood.
Routine tasks cost more effort than they are worth
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.
Money makes mistakes expensive
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.
Support was absorbing repetitive, answerable questions
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.
One month, inside a live product
The voice layer had to be designed, built, and hardened in four weeks - and had to sit inside an existing production app without destabilising the flows already shipping around it.
The difference
Five steps, or one sentence.
The clearest way to describe what the voice layer changes is to count the interactions it removes.
Checking a balance - before
- 01Open the app, wait for cold start~6s
- 02Authenticate - biometric, or PIN on retry~9s
- 03Navigate to the accounts section~7s
- 04Select the right account from the list~5s
- 05Read the balance~3s
Checking a balance - with voice
- 01“What is my balance?”~3s
One utterance. Authentication is inherited from the active session and tiered by action risk, so a read-only query does not re-prompt. The answer is spoken back while the app is still on screen.
A support question - before
- 01Search the FAQ, phrased differently than you asked~2m
- 02Give up, open a support chat~30s
- 03Wait in queue for an available agent~6m
- 04Explain the issue, then explain it again on handoff~4m
A support question - with voice
- 01“Why was I charged twice on Tuesday?”~8s
The agent already holds account context, so it answers from the actual transaction rather than a generic article. When it cannot resolve something, it escalates with the full transcript attached - the user never repeats themselves.
Codiste’s Solution
Four things it can do
the moment you speak.
Scope was deliberately narrow and deliberately deep. Every capability shipped with its own risk tier, confirmation rule, and fallback path.
01
Account queries, answered from live data
Balances, recent transactions, spend by category, pending items, card status. Responses are grounded in the account record at query time - never inferred, never approximated by the model.
02
Actions, not just answers
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 where they can do it themselves.
03
A confirmation gate on everything that moves money
Before execution, the assistant reads back amount, recipient, and source account in full and waits for an explicit affirmative. Nothing state-changing happens on a single utterance. Ambiguity escalates to a question, never to a guess.
04
Support conversations that actually resolve
Charge explanations, duplicate transactions, disputes, limits, onboarding questions - handled in conversation against real account context. Anything outside scope escalates to a human with the transcript and resolved entities attached.
Technical Implementation
The model proposes.
The banking core disposes.
The central design decision: 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.
Step 01
Streaming STT
Partial transcripts stream as the user speaks, so response drafting starts before the sentence ends.
Step 02
Intent + entities
“Send Mom fifty” resolves to payee, amount, currency, and source account - with a clarifying question when any slot is ambiguous.
Step 03
Action schema
Output is a typed, validated object. Malformed or out-of-scope actions are rejected before they reach any financial system.
ValidatedStep 04
Confirmation gate
State-changing actions are read back in full and held until an explicit affirmative is received.
BlockingStep 05
Execute + speak
The banking core executes; low-latency TTS confirms the outcome with a reference the user can quote.
Scope
Allowlisted actions only
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.
Auth
Assurance tiered by risk
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.
Audit
Every session is reconstructable
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.
Latency
Conversational, not transactional
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.
Recovery
Barge-in and cancel
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.
Grounding
No invented balances
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.
Technology Stack
The tools under the hood.
Value & Impact
The numbers behind it.
Modelled against the manual flows the voice layer replaces, and measured in internal testing ahead of public launch.
~90%
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.
<1.2s
Median response latency
Streaming recognition and streaming synthesis keep replies inside conversational rhythm rather than arriving after it.
~85%
Tier-one queries resolved
The majority of routine support questions are answered in conversation, against real account context, in seconds rather than minutes.
100%
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.
Delivery
How Codiste shipped it
in four weeks.
A narrow scope, defined on day one, is what made a one-month build possible without cutting the safety work.
Week 01
Action taxonomy & risk tiering
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
Voice pipeline
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
Execution & guardrails
The action schema, permission allowlist, confirmation state machine, cancel and barge-in handling, and the per-session audit log.
Week 04
Hardening & handover
Latency tuning, adversarial testing against misheard entities and ambiguous payees, accent and noise robustness passes, then rollout behind a feature flag.
Looking to put a voice layer inside your product? Codiste can build it.
The app stopped being something you operate.
It became something you talk to.