A practical guide / Fonix.AI
Banking voice workflows: a practical implementation guide
A worked scenario, illustrated decision review and a practical pilot worksheet.
A banking voice bot needs an allowed-action catalogue
A banking voice bot should operate within a defined account-service scope, with verified access and an authorised next step. Public product information, protected account details and consequential account actions require different controls. Fluent speech does not establish authority to move money, approve credit or interpret financial obligations.
Evaluate Fonix.AI around a narrow service task approved by the institution. This guide is a scoping and acceptance framework, not a regulatory certification or a claim of universal core-banking integration. Loan reminder outreach has its own EMI workflow guide.
Classify each question before choosing a tool
Create an action inventory: public information, verified read, service-request intake and human-only action. Specify the authoritative data source and required verification for each. Enforce those rules in the server-side tool layer rather than relying on the agent's conversation instructions alone.
Return only the minimum approved information. A mobile number can be shared or forwarded; possession of it is not proof of account authority. Use the institution's approved identity flow, and avoid putting authentication secrets in transcripts or general case notes.
Worked example: a caller asks to change an account detail
A fictional caller passes the verification needed for a status enquiry, then asks to change a registered contact detail. Read-only verification should not automatically authorise a sensitive write. The agent must use the stronger approved process or create an appropriately restricted service request.
| Request class | Required authority | Valid outcome |
|---|---|---|
| Public branch information | Public source | Approved answer |
| Protected status | Verified account-scoped read | Minimum permitted response |
| Service request | Approved intake permissions | Accepted reference |
| Sensitive account change | Institution-specific authorisation | Authorised process or human handoff |
Preserve what was requested and what actually happened
Keep caller statements, verification state, tool decisions and final business results separate. “Request accepted” must not become “account changed” before the authoritative system confirms it. A timeout requires reconciliation, not repeated consequential writes.
Pass an auditable, minimal brief to the receiving team. Define what happens when verification fails, the account tool is unavailable or the caller reports an urgent issue. Those routes should come from the institution's operating policy, not model-generated advice.
An institution-owned action-authority matrix
Start with synthetic accounts and one institution-approved low-risk workflow. The bank should define identity requirements, permitted responses and escalation for each action. Test the intended restricted tools rather than demonstrating with administrator access.
| Pilot case | Required behaviour |
|---|---|
| A verified status caller requests a contact-detail change | Require the stronger institution-approved authority or route to the authorised process. |
| An unverified caller knows the account holder's name | Avoid protected disclosure and offer only the permitted general route. |
| The account system times out during a request | Preserve unknown state and an owned next step without claiming the change completed. |
Count correct permitted responses, denied unauthorised reads/writes and accurately owned service requests. Keep false denials visible too. Efficiency should be assessed only inside the approved action boundary, not by rewarding fewer security checks.
Does a banking use case imply a compliance approval?
No. This is a workflow design guide. The institution must review the actual controls, policies, deployment and obligations through its authorised teams. No certification, regulatory approval or suitability for every banking operation is claimed here.
Test denied paths and disclosure boundaries
Include a shared number, failed verification, a mid-call account switch and a request outside the allowed catalogue. Inspect both spoken output and tool audit events. Treat unauthorised disclosure and actions as explicit failures even when the call otherwise completes.
Review a bounded banking voice pilot with your action catalogue and approved identity process. Caller verification, access-control logs and private-cloud architecture cover the supporting controls.