AI in Banking: Use Cases, Risks, and a Safer Voice AI Blueprint

AI in banking is the use of predictive models, generative models, and conversational agents to improve decisions and workflows across a financial institution. Common applications include fraud detection, credit analysis, document processing, employee assistance, and customer service.

The safest systems give AI a bounded job. A model may classify a transaction, summarize a case, retrieve approved information, or collect a customer's intent. Bank-controlled services should still authenticate the customer, enforce entitlements and limits, make regulated decisions, execute payments, write the ledger, and preserve the official record.

That separation matters most when an AI system can call tools. A fluent response is not proof that an action is permitted, and a conversational confirmation is not sufficient authority to move money.

What AI in banking includes

The phrase "AI in banking" covers several technologies with different failure modes.

One application may use all three. A service agent might use a language model to understand a caller, a predictive model to surface a risk signal, and a deterministic bank API to return an account status. Treating that stack as one undifferentiated "AI" system makes it harder to assign ownership and test failures.

Seven practical AI use cases in banking

1. Fraud and anomaly detection

Predictive systems can compare a transaction with account history, device information, merchant behavior, and broader patterns. The model can prioritize a case or request more verification.

The model's score should be an input to a documented control, not an unexplained final answer. Banks need thresholds, investigation paths, false-positive monitoring, customer remediation, and an audit trail for how the signal was used.

2. Credit decision support

AI can extract application data, detect missing information, summarize documents, and support risk models. It can shorten manual review without removing the institution's obligations.

For covered U.S. credit decisions, Regulation B's notification rule requires specific reasons for adverse action or disclosure of the applicant's right to receive them. A system that cannot preserve the actual decision factors is a poor fit for this workflow, regardless of its benchmark accuracy.

3. Customer service

Voice and chat agents can answer balance and transaction-status questions, explain product terms from an approved knowledge base, collect information, schedule appointments, and route calls.

The strongest first deployments are narrow and reversible. A customer should be able to reach a person for disputes, suspected fraud, financial hardship, complaints, accessibility needs, or any request the agent cannot resolve. CFPB research on financial chatbots documented problems when automation gave inaccurate answers, trapped customers in loops, or blocked timely human help.

Bank of America provides a useful example of a bounded assistant at scale. The bank reported that Erica had passed three billion client interactions in August 2025. The useful lesson is the scope, not the number: a financial assistant can help customers complete defined tasks while the bank's systems continue to own accounts and transactions.

4. Customer identification and document operations

AI can classify identity documents, extract fields, compare records, and route exceptions. It can also assist anti-money-laundering teams by organizing alerts and case material.

These tools do not replace the institution's customer identification, verification, recordkeeping, or investigation process. The FFIEC BSA/AML manual describes customer identification as a bank compliance program. If a third party performs part of the process, the bank still needs the required oversight and controls.

5. Employee assistance

An internal assistant can retrieve approved policies, summarize a customer history, draft a case note, or guide an employee through a procedure. This is often easier to control than an autonomous customer-facing workflow because a trained employee reviews the result before acting.

Ground the assistant in versioned source material. Show citations or source passages to the employee. Log which policy version was used, and do not let the model invent an exception to a bank rule.

6. Personalization and financial insights

AI can categorize spending, identify recurring payments, explain cash-flow changes, or suggest relevant educational content. The bank should distinguish a factual account insight from advice, an offer, or a regulated decision.

Customers also need a way to correct bad data or opt out where required. Measure whether the insight is accurate and useful, not only whether the customer clicked it.

7. Payments and money movement

A conversational agent can collect the source account, recipient, amount, timing, and customer intent. It can retrieve permitted information and present a review summary.

It should not decide that the customer is authenticated, bypass transaction limits, approve a sanctions or fraud exception, or write directly to the ledger. Those decisions belong to bank-owned services with deterministic rules, step-up authentication, idempotency, and complete transaction records.

Benefits worth measuring

AI can create value in banking, but the metric should match the use case.

• Faster handling: Measure time to resolve a defined request, not a generic productivity score.
• More service capacity: Track containment for requests the agent is authorized to solve, plus successful handoff for everything else.
• Consistent information retrieval: Measure answer accuracy against the current approved policy, including how quickly updates propagate.
• Broader signal analysis: For fraud or risk models, monitor detection, false positives, missed cases, and impact across customer groups.
• Less repetitive work: Measure the manual steps removed while tracking rework, overrides, and new review burden.

A lower average handling time is not a win if disputes go unresolved. A high automation rate is not a win if customers cannot reach a person. Include customer outcomes, error cost, and control performance in the same scorecard as speed and volume.

AI risks banks need to control

Requirements vary by institution, product, and jurisdiction. The controls below are an engineering and risk-management starting point, not legal advice.

Wrong or fabricated answers

Generative models can respond confidently when the source is missing, ambiguous, or outdated. Use an approved knowledge base, require the model to stay within scope, test refusal behavior, and transfer the customer when the answer cannot be supported. A prompt that says "be accurate" is not a control.

Bias and unexplained decisions

Training data, proxy variables, thresholds, and feedback loops can produce different outcomes across groups. Define the decision owner, validation method, fairness tests, explanation requirements, override process, and remediation path before deployment.

The Federal Reserve, FDIC, and OCC issued revised model-risk guidance on April 17, 2026, replacing SR 11-7. The guidance covers traditional quantitative and non-generative AI models. It expressly says that generative and agentic AI are outside its scope, while noting that a banking organization's governance practices should determine appropriate controls for systems not covered by the document. Do not cite traditional model guidance as if it fully governs a voice agent or large language model.

Privacy and data leakage

Map every data element that enters prompts, tool requests, transcripts, recordings, logs, and analytics. Minimize sensitive data, redact it where possible, define who can access each copy, and verify retention and deletion behavior. Review model providers, speech providers, telephony providers, support systems, and subprocessors rather than assessing only the application customers see.

Tool abuse and prompt injection

An attacker may ask the model to reveal data, ignore policy, call a tool with altered parameters, or repeat a write operation. Treat model output as untrusted input. Every bank API must authenticate the calling service, authorize the requested operation, validate each field, enforce account-level permissions and limits, and return only the minimum data the agent needs.

Third-party and concentration risk

AI stacks can depend on several providers for models, speech, telephony, hosting, and observability. The interagency guidance on third-party relationships describes a continuous lifecycle of planning, due diligence, contracting, monitoring, and termination. For an AI workflow, that means knowing which provider sees which data, how changes are communicated, how incidents are handled, and how the bank will continue or exit if a service fails.

Weak human escalation

Define the conditions for transfer before launch. These should include an explicit request for a person, uncertainty about identity, a disputed transaction, a complaint, a suspected scam, a high-risk or out-of-policy request, repeated misunderstanding, and any tool result the system cannot interpret safely.

Drift and silent failure

Model, prompt, policy, provider, and data changes can alter behavior. Version the complete system, run regression tests before changes, monitor errors and overrides, and maintain a practiced disable-and-rollback process.

The NIST AI Risk Management Framework is a useful voluntary structure: govern the program, map the context and impact, measure performance and risk, and manage the results throughout the lifecycle.

A seven-step implementation framework

1. Define the intended use and prohibited actions

Write a one-sentence job for the system. Then list actions it must never perform. "Answer authenticated customers' questions about posted transactions" is testable. "Handle banking" is not.

2. Map data, decisions, and obligations

Document the data entering and leaving the system, the authoritative source for each fact, applicable policies, affected customers, and the owner of every decision. Include prompts, retrieved documents, transcripts, recordings, logs, vendor support access, and model training settings.

3. Choose an automation tier

Use increasing levels of control:

1. Retrieve: answer from approved information.
2. Recommend: prepare a draft, score, or next step for a person.
3. Prepare: collect inputs and create a reviewable transaction proposal.
4. Execute: request a bank-controlled action after independent authorization.

Start at the lowest tier that creates value. Raise the tier only after the earlier controls and evidence are working.

4. Separate the AI from authoritative services

The model should not hold master credentials or write to a ledger. Put a bank-owned service between the agent and core systems. That service should enforce identity, entitlements, limits, fraud rules, sanctions controls, policy, idempotency, and audit records on every request.

5. Test outcomes and abuse cases

Build a test set from real workflows and known failures. Include accents, background noise, ambiguous amounts, similar recipient names, interruptions, corrections, repeated requests, prompt injection, tool timeouts, stale data, compromised accounts, and customers asking for a person.

Measure task success, unsupported answers, unauthorized action attempts, tool failures, handoff success, latency, and outcomes across relevant customer groups.

6. Pilot with monitoring and human override

Limit the pilot by customer group, task, channel, amount, and operating window. Give operations staff a clear kill switch. Review failures quickly and preserve the evidence needed to reconstruct what happened.

7. Reassess the full supply chain

Review model and vendor changes, test results, incidents, complaints, security evidence, subprocessors, concentration, and exit plans on a defined schedule. A system that passed once is not permanently approved.

A safer voice AI blueprint for money transfers

The legacy version of this article demonstrated a conversational transfer with local demo data. A production bank flow needs a different architecture.

Recommended flow

1. Disclose the automated interaction and recording state. Give the customer a direct path to a person.
2. Capture intent. Collect the requested source account alias, recipient, amount, currency, and timing without asking the customer to speak passwords, one-time codes, full account numbers, or other secrets.
3. Retrieve permitted data. Call a bank-owned read service that returns only accounts and recipients available to the already authenticated session.
4. Prepare the transfer. The bank service checks entitlements, balance, limits, recipient status, fraud signals, sanctions controls, and policy. It returns a short-lived review ID and a customer-readable summary, not a completed transaction.
5. Confirm the summary. Read back the amount, recipient, source account alias, fees, and timing. A verbal "yes" confirms intent but does not complete authentication.
6. Require bank-controlled step-up authentication. Use an approved out-of-band or cryptographic method tied to the exact transaction. NIST's current authentication guidance states that a biometric is not an authenticator by itself. Voice matching alone should not authorize the transfer.
7. Execute once. The bank backend exchanges the approved review ID and authorization result for a transaction. It enforces an idempotency key so retries cannot create duplicate transfers.
8. Return the authoritative result. The agent reads the bank's status and reference number. An unknown or timed-out result must be described as pending verification, never guessed as success or failure.
9. Record and escalate. Store the bank's transaction audit record separately from the conversational transcript. Transfer disputes, warnings, uncertainty, and policy exceptions to a trained person.

Responsibility boundary

The conversational tool should prepare a request rather than accept arbitrary instructions. A conceptual response from a bank-owned prepare_transfer service might look like this:

{
  "reviewId": "trv_7f31...",
  "status": "requires_step_up",
  "summary": {
    "sourceAccountAlias": "Checking ending 4821",
    "recipientAlias": "Jordan Lee",
    "amount": "250.00",
    "currency": "USD",
    "delivery": "Next business day"
  },
  "expiresAt": "2026-08-12T16:05:00Z"
}

The agent can read this summary. It cannot turn requires_step_up into approval. Only the bank service should issue and consume the authorization needed for execution.

Where Dasha fits in a banking voice workflow

Dasha provides a managed runtime for voice AI agents. In the current product model, an agent manages the conversation, tools call customer-owned APIs, webhooks report lifecycle events, and call transfers route customers to people or other systems.

For the transfer blueprint, Dasha can:

• handle the voice conversation and corrections;
• request bank-owned read and prepare operations through typed tools;
• present the bank's returned summary and status;
• route sensitive or unresolved requests to a human; and
• support testing and diagnosis through the Call Inspector and activity logs.

The bank must continue to own identity, entitlements, transaction policy, fraud and financial-crime controls, step-up authentication, the ledger, dispute handling, compliance, and production acceptance. A Dasha tool call is a request to the bank's service, not permission to move money.

Two current Dasha behaviors need explicit design review for banking data:

1. Tool webhooks can retry. Every write operation must be idempotent, and a fallback must never look like a successful transfer.
2. Dasha's current API reference says the call-recording endpoint is publicly accessible without authentication. Treat a recording URL as a sensitive capability link. Disable recording unless the use is approved, do not expose recording IDs, and put customer-facing access behind a bank-controlled authenticated service.

Deleting an agent preserves historical call records. Before production, agree on transcript and recording retention, deletion, legal holds, encryption, data location, support access, incident response, and subprocessors. Public Dasha documentation does not establish bank-specific certifications, data residency, customer-managed encryption keys, or private networking, so confirm every required assurance directly and contractually rather than inferring it.

Banking AI vendor and launch checklist

Use this checklist for Dasha or any other AI provider:

• Scope: Is the intended use narrow, testable, and separated from prohibited actions?
• Data: Which customer, account, call, transaction, and employee data enters each provider and log?
• Access: How are users, services, support staff, recordings, transcripts, and tools authenticated and authorized?
• Retention: Can every data copy be retained, exported, deleted, or placed on legal hold as required?
• Models: Which models and providers are used, how are changes announced, and how is regression testing triggered?
• Actions: Does the bank revalidate every tool request and use idempotency for every write?
• People: Can customers reach a person, and does the operator receive enough verified context to help?
• Testing: Are accuracy, bias, privacy, abuse, latency, failure, and recovery tested with realistic cases?
• Monitoring: Can teams reconstruct a decision or action without exposing unnecessary sensitive data?
• Resilience: Is there a kill switch, rollback plan, provider outage path, and tested exit plan?
• Third parties: Are contracts, subprocessors, concentration, security evidence, incidents, and termination addressed throughout the relationship?
• Approval: Have security, risk, compliance, legal, operations, accessibility, and the business owner accepted the residual risk?

Start with a bounded banking workflow

The first AI workflow in a bank should prove control, not autonomy. Account-status questions, branch or specialist scheduling, approved policy retrieval, and transaction preparation are better starting points than autonomous credit or money movement.

For technical teams building a voice layer around bank-owned controls, start by testing one end-to-end path: authenticated session, Dasha conversation, read-only bank tool, verified response, human transfer, monitoring, and rollback. Add write authority only after the bank can prove that authentication, authorization, idempotency, data handling, and exception management work under real failure conditions.

Review Dasha's current documentation to evaluate the conversation, tool, transfer, and monitoring layers against your institution's requirements.