Voice banking: adding voice commands to a banking app

Voice earns its place where a task takes many taps and the intent is expressible in one sentence. In retail banking that is a short and predictable list.

• Repeat transfers. Sending a familiar amount to a known beneficiary is a five-screen flow that compresses to a sentence.
• Bill payment and top-up. Recurring, low-value, high-frequency — the profile where navigation cost dominates.
• Statements and history. Narrowing by date or merchant in speech is far quicker than through filters.

Where voice does not help: anything requiring careful review of numbers on screen, first setup of a beneficiary, or any flow with legal text the customer must read.

Coverage is not a count of languages. It is whether the system understands the language your customers actually speak, which in these markets is usually not the textbook form.

Three problems recur. Regional dialect can differ enough from the standard form to defeat a model trained only on the latter — Gulf, Levantine and Egyptian Arabic are not interchangeable. Code-switching is normal: an Urdu or Arabic sentence carrying English words for amounts, banks and product names is the common case, not an edge case. And numbers are spoken in more than one way in most of these languages, so a system that handles only one form will fail on amounts, which is the part that matters most.

The test worth running before committing is not a benchmark. It is a recording of your own customers, in their own dialects, saying the amounts they actually send.

This is the part that decides whether voice banking is a feature or a liability. A spoken command is not an authorisation. Speech is observable, recordable and reproducible, and synthesis has made voice alone insufficient as a sole factor for moving money.

The design that holds up separates the two concerns. Voice carries the intent: what the customer wants to do. A separate, non-voice step carries the authorisation: proof that the person entitled to the account approves this specific instruction.

In practice that means a passkey step-up before anything moves. The customer speaks the command, the app shows the parsed instruction — beneficiary, amount, currency — and the customer approves it with a face or fingerprint. The signature covers the transaction detail on screen, so what was approved and what executes cannot diverge.

Voice biometrics has a place alongside this as a continuous signal: it can confirm that the speaker matches the enrolled customer, and flag when it does not. It is a useful additional factor and a poor sole one.

Voice is often framed as a convenience. In these markets it is frequently an access question.

Customers with low literacy can navigate a screen-based banking app only by memorising positions, which breaks with every redesign. Speaking an instruction removes that barrier entirely. Customers with visual impairments get a path that does not depend on a screen reader having been tested against your particular layout. Older customers who find dense interfaces difficult get a route that matches how they already ask for things at a branch counter.

Designing for these customers rather than treating them as a secondary case changes specific decisions: confirmations should be spoken as well as displayed, timeouts need to be generous, and the system must handle a hesitant, self-correcting sentence rather than requiring a clean single utterance.

Voice sits on top of the transaction capability you already have. It does not need its own payment path, and building one would be a mistake — you would end up with two code paths with different limits and controls.

• Capture in the app. An SDK in the existing iOS, Android or web app handles capture and streaming; no separate application to install or maintain.
• Process in region. Speech is customer data. Processing it inside the bank’s own region — never cross-border — is both the residency answer and usually the latency answer.
• Resolve to an intent, then reuse your own APIs. The voice layer produces a structured instruction. Your existing transfer API executes it, with the same limits, sanctions screening and fraud checks that already apply.
• Step up before execution. The passkey approval sits between intent and execution, so the authorisation path is identical to your in-app one.

On 3G and 4G, where a meaningful share of these customers are, the design constraint is responsiveness under variable latency: stream rather than batch, show the parsed intent as it forms, and never leave the customer waiting on a silent screen.

The metric that matters is not recognition accuracy in isolation. It is whether the customer got what they asked for without falling back to tapping.

• First-try resolution — the share of commands completed without a repeat or correction.
• Abandonment point — where in the flow customers give up, which usually localises the problem precisely.
• Fallback rate to the tap flow, segmented by language and dialect.
• Step-up completion — whether customers finish the authorisation once they have spoken the command.

For reference, FortVoice resolves 96% of actions on the first try, measured in production at a partner bank.

FortVoice adds spoken commands to an existing banking app through an SDK for iOS, Android and web, resolving speech to a structured instruction your own APIs execute. Speech is processed in the bank’s region rather than crossing borders, and every money-moving action requires a FortAuth passkey step-up bound to the instruction shown on screen.