Voice AI for Banking

Voice agent integrated with the core banking API to handle inbound balance and recent transaction enquiries end-to-end. Authentication uses a spoken four-digit PIN matched against the CRM record, with a fallback to a security question for unrecognised numbers. For institutions with voice biometric infrastructure, the authentication layer connects to the existing biometric service rather than building a separate credential store.

Account data is pulled in real time via the core banking REST or SOAP API. The agent reads the current balance, available balance, and pending transactions in natural language. If the caller asks about a specific transaction, the agent filters by date, merchant, or amount and reads back the matching result. Response latency runs at 380 to 450ms on a properly provisioned infrastructure, which keeps the interaction conversational. The agent handles the full call lifecycle, greeting, authentication, data retrieval, response, and close, and logs the interaction to the audit trail with a timestamp, authentication outcome, and data accessed. Calls that request account actions the agent is not authorised to complete are transferred to a human agent with the authentication context passed through so the customer does not re-authenticate. PCI-DSS aware data handling governs how account data is used within the call session and what is retained in call logs.

Outbound voice agent triggered automatically when a fraud rule fires in the transaction monitoring system or card processor. The agent calls the cardholder's registered number, identifies the bank by name, and describes the flagged transaction, merchant name, amount, and timestamp, in plain language without reading a card number or full account number over the call.

The caller confirms or disputes the transaction verbally. The agent captures the response, logs the outcome with a timestamp and the caller's authentication status, and updates the fraud case system via webhook. If the customer confirms the transaction as legitimate, the agent closes the call and the case is marked confirmed. If the customer reports the transaction as unauthorised, the agent escalates immediately to the fraud team via case system alert and, where configured, initiates an automated card block before the escalation completes. The agent does not request card numbers, PINs, or full account numbers during the confirmation call. All call recordings are encrypted and retained to the institution's configured retention policy for AML and FCA, PSD2, or FinCEN audit requirements. DTMF fallback allows customers who prefer keypad input to confirm or dispute without speaking, covering accessibility requirements and environments where voice input is impractical.

Inbound voice agent integrated with the loan origination system to handle application status enquiries. The caller authenticates, the agent queries the origination system by application reference or customer identifier, and reads back the current stage, the last action completed, the next required action from the applicant, and the expected timeline to the next stage.

Where the origination system returns a status that requires explanation, for example, a request for additional income documentation, the agent reads the specific document required and the submission instructions, and offers to send an SMS summary to the customer's registered number so they have the detail in writing. For applications that have reached a decision, the agent reads the outcome and transfers to a human specialist if the customer has questions about the decision that fall outside the agent's authorised scope. The agent does not communicate a credit decision reason or offer to override an underwriting outcome, those interactions route to a trained human. All status calls are logged to the origination system audit trail. AML and KYC status flags on the application record are checked before the agent reads back status information, if the application has an open compliance hold, the call routes to a compliance officer rather than an automated response.

Voice-guided account opening flow for retail current accounts and savings products, designed for customers who prefer voice to a web form. The agent collects the applicant's name, date of birth, address, and employment status in a structured conversational flow, confirms each field before proceeding, and submits the completed record to the account opening system via API.

Identity verification connects to the institution's existing KYC provider, Onfido, Jumio, or Alloy, via a handoff that sends the applicant an SMS link to complete document capture and liveness check after the voice intake is complete. This keeps the structured data collection in voice while delegating the document verification step to a purpose-built mobile flow, rather than trying to handle document capture over a phone call. The agent captures explicit verbal consent to the account terms and records the consent event with a timestamp and call reference. AML screening runs automatically when the application record is submitted, the agent does not communicate the AML screening outcome but routes flagged applications to the compliance queue for manual review. The account opening flow is scoped to personal accounts; business account opening with company verification and beneficial owner checks is handled as a separate flow with additional data collection steps.

Inbound voice flow for customers initiating a transaction dispute. The agent authenticates the caller, asks them to describe the transaction they want to dispute, and uses the description to retrieve the matching transaction from the account record via the core banking API. The caller confirms the transaction, states the reason for the dispute, not recognised, wrong amount, duplicate charge, or goods not received, and the agent creates a dispute case in the case management system with the transaction reference, dispute reason, and a transcript of the caller's statement.

Where the institution uses Mastercard Dispute Resolution or Visa Dispute Resolution as the card scheme dispute system, the dispute case is formatted to the scheme's required fields and submitted automatically, reducing the manual step of a human agent translating the customer's verbal description into a structured scheme submission. The caller receives a reference number and an estimated resolution timeframe before the call closes. The dispute transcript is retained as part of the case record, satisfying the evidence requirement for scheme-level disputes. Dispute cases involving potential fraud, where the customer states the card was not in their possession or the PIN was not used by them, are flagged as potential fraud and escalated to the fraud team rather than processed as a standard chargeback dispute.

Voice agent for handling inbound payment instructions, bill payments, peer transfers, and standing order setup, using a structured confirmation flow that reduces the risk of misdirected payments. The agent authenticates the caller, collects the payee name, account details, and amount, reads back the full instruction for verbal confirmation, and submits the payment to the payment rail via the core banking payment API.

Step-up authentication triggers for payments above a configurable threshold, typically the same threshold the digital banking app applies for strong customer authentication (SCA) under PSD2 or Regulation E. For payments above the threshold, the agent sends an OTP to the registered mobile number and requires the caller to read it back before the payment is submitted. Payments are not submitted without explicit verbal confirmation of the full instruction details. The agent does not accept payments to payees not already on the customer's registered payee list without step-up authentication, reducing the risk of authorised push payment (APP) fraud, a specific concern for FCA-regulated institutions under the APP fraud reimbursement rules. Payment instruction calls are logged with the full instruction details, the authentication events, and the payment reference returned by the core, satisfying FCA and PSD2 audit trail requirements.