Banking & insurance customer assistant (transactional)

Banks and insurers handle huge volumes of repetitive requests: lost card, standing order, address change, claim status, policy certificate. A transactional assistant combines an LLM dialogue layer with authenticated access to core systems, so the customer finishes the task in the conversation. Unlike a FAQ bot (CONV-001), it acts on money and contracts, so it needs deterministic transaction controls, strong customer authentication and clear hand-over to people.

Problem & value

• Today: customers use app menus, hotlines and branches. Contact centres are expensive, queues form on card loss, claims and contract changes, and rule-based bots from 2016-2022 fail on free-form language.
• AI value: natural-language access to the existing self-service functions, 24/7 availability, shorter handling of simple requests, relief for agents who receive pre-structured cases, and a conversational entry point for claims first notice of loss (FNOL).
• Evidence of scale: Bank of America reports its assistant Erica has served nearly 50 million users and passed 3 billion interactions, and that an internal Erica version halved IT service-desk calls [1]. This is a US, mostly pre-generative-AI system, so treat it as proof of adoption rather than an EU benchmark. Do not expect transferable percentage savings without a pilot in your own channels.

Variants

• Retail banking: balances, transaction search ("what was the 80 EUR debit on Friday?"), card block/limit, SEPA transfer drafts, standing orders, spending insights.
• Insurance: FNOL for motor/home/travel, claim status, document upload, policy changes, certificate and invoice requests, broker-facing assistant. Photo-based damage assessment is a separate component (VIS-023); full claims automation is AGENT-014.
• Voice channel: the same agent behind a phone line (CONV-002) with voice-based authentication alternatives.
• Out of scope here: credit decisions and risk-based insurance pricing (PRED-009, PRED-010), which are high-risk uses.

How it works

customer message (app / web / WhatsApp / voice)
  -> guardrails (PII masking, prompt-injection and off-topic filters)
  -> intent + slot routing (small classifier / LLM)
  -> read path: RAG over product terms and FAQ  |  account-data tools (read-only APIs)
  -> write path: proposed action -> strong customer authentication (SCA) -> explicit confirmation card
       -> deterministic transaction API (limits, four-eyes rules, idempotency)
  -> answer generation with citations; compliance wording from templates
  -> escalation to human with summary, authenticated context and transcript
  -> audit log (prompt, tool calls, confirmations)

• LLM as orchestrator, not as authority: the model chooses tools and fills parameters; amounts, limits, eligibility and wording of binding statements come from deterministic services and approved templates. A model never moves money on its own text output.
• Authentication: the session is bound to the logged-in app user; payment-relevant actions trigger the bank's existing SCA flow (PSD2) in the app, outside the chat. Never pass credentials or full card numbers through the LLM context.
• Human-in-the-loop: escalation on low confidence, complaints, vulnerability signals (bereavement, financial distress, fraud suspicion), advice requests, and any regulated advice or credit topic.

Data preparation

The assistant needs two kinds of data. First, knowledge: product terms, tariffs, FAQ and claims process descriptions, which typically sit in a DMS, on intranet pages, in PDFs and in the heads of service agents. Second, transactional access: customer, account, policy and claims data in core systems, reached only through authenticated APIs, never by copying data into the model.

Typical gaps: outdated or contradictory tariff documents, scanned legacy terms, several versions of the same FAQ, no clear owner per product, and core systems without clean APIs. Customer data must not be indexed; only the session-scoped API result is shown.

Preparation steps: inventory the sources and assign owners (PREP-001, PREP-004), curate one authoritative knowledge base with review cycles (PREP-013, PREP-017), build an evaluation set from real, anonymised customer requests with service experts (PREP-018, PREP-022), define intents and hand-over categories (PREP-019), and expose core functions as narrow, audited API tools (PREP-005). Also check the legal basis for reusing chat logs (PREP-025). Tools: document converters and OCR, a vector database, API gateway, log pseudonymisation. Rough share of effort: about 30 to 40 percent, mostly API enablement and knowledge curation.

Implementation paths

Which path for whom

• Enterprise (banks, insurers): Path B, because the assistant must call core banking or policy systems through own APIs with strong authentication and an audit trail, and a shared internal AI platform keeps transaction controls under your own governance.
• Developer (integrators, fintech/insurtech vendors): Path B, because cloud APIs in EU regions let you build the dialogue and tool layer quickly while the deterministic transaction logic stays in your own code.

Path A - Buy (for commodity front-ends and smaller institutions)

• Conversational AI platforms with finance references: Kore.ai, Cognigy (NiCE), Parloa (EU, voice-focused), Sprinklr, Salesforce Agentforce for Financial Services, Microsoft Copilot Studio with Dynamics, Google Customer Engagement Suite, Amazon Connect with Bedrock agents. EU-based or EU-hostable: Cognigy (DE), Parloa (DE), Rasa (DE/US, on-prem capable).
• Choose A when: you lack an in-house conversational team and need pre-built connectors, audit, analytics and agent-desk integration. Verify EU data residency, sub-processors, and whether the vendor logs prompts for training.

Path B - Build on cloud APIs

• Models: Mistral (EU) via La Plateforme or private deployment; Anthropic Claude, OpenAI GPT and Google Gemini through EU-region offerings (Azure OpenAI EU Data Zone, Vertex AI EU, AWS Bedrock Frankfurt/Paris/Ireland). Use tool calling with strict JSON schemas.
• Orchestration: LangGraph, Semantic Kernel or a plain state machine; MCP tools only behind an API gateway with scoped tokens.
• Guardrails: Azure Prompt Shields, Llama Guard-class classifiers, Presidio for PII.

Path C - Self-host (open source)

• Models: open-weight models such as Mistral Small/Medium-class, Llama, Qwen3 or gpt-oss families served with vLLM; embeddings such as BGE-M3 or multilingual-e5; reranker from the BGE family.
• Stack: Rasa (open-source framework with deterministic flows plus LLM understanding), Haystack or LlamaIndex for retrieval, Presidio for PII, Keycloak for identity, Langfuse for tracing.
• Hardware: HW3 for a ~70-120B-class model with concurrency; smaller routing models run on HW2. Many institutions choose this for data-sovereignty and DORA third-party-risk reasons.

Path D - Custom training

Fine-tune a small model for intent classification and banking jargon using several thousand anonymised labelled conversations. Not for facts; use retrieval and tools.

State of the art (2026)

• Agentic tool use with schema-constrained calls is production-grade; the hard part moved to safe action design: confirmation steps, idempotent APIs, limits and replay protection.
• Hybrid design (deterministic transaction flows, LLM for understanding and generation) is what risk teams accept; free-form agents with write access remain rare.
• Limits and failure modes: hallucinated product terms or coverage statements (a binding-statement risk, especially in insurance), wrong account or claim context, prompt injection through claim attachments, inconsistent answers across languages, over-confident handling of vulnerable customers, and latency in core-system calls.

Shared resources & combinations

• Same stack as CONV-001 (RAG, guardrails, channel gateway), CONV-002 (voice), CONV-007 (agent assist shares knowledge base and case summary), CONV-026 (embedded copilot in the banking app) and KNOW-002.
• Downstream and neighbouring: DOC-003 (claim and loan forms), AGENT-014 (claims workflow), AGENT-015 (KYC), VIS-023 (photo damage assessment), ANOM-009 (fraud signals that should trigger step-up or block).
• Not to mix without separate assessment: PRED-009 and PRED-010. If the assistant collects data used for credit scoring or life/health pricing, that component becomes a separate high-risk system.

Effort, cost & KPIs

• Path A: 2-4 months for a first scope (3-10 intents) including core connector and security review; licence typically per conversation or resolution.
• Path B: 4-9 months for a production-grade transactional bot incl. SCA integration, testing and compliance sign-off; run cost dominated by integration and operations, model tokens are secondary.
• Path C: 6-12 months and a platform team.
• KPIs: containment/completion rate by intent (completed, not merely answered), hand-over quality (no repeated questions), CSAT, first-contact resolution, wrong-action rate (target near zero), escalation rate for vulnerable customers, complaint rate, FNOL completeness, and cost per resolved contact.

People & change

Start with management, the department lead for customer service and IT, then add IT security, the DPO and legal/compliance before any design is frozen, since transactions, strong customer authentication and sector rules (e.g. BaFin requirements) shape the architecture. A DPIA is very likely (customer data at scale, new technology) and every vendor needs an AVV (Art. 28 GDPR).

Works council: depends. If service agents get hand-over cases, quality scoring or conversation analytics, the system is objectively suited to monitor performance, so co-determination under §87(1) no. 6 BetrVG applies; §90(1) no. 3 requires timely information about AI-supported work processes, and §80(3) allows an expert. Agree a works agreement on analytics early.

AI literacy: support staff and agents with training (AI Act Art. 4; see GUIDE-006). Communicate openly that the assistant relieves repetitive tasks and that agents take over complex and emotional cases. Pilot with one product line and a volunteer agent group, with a visible "talk to a person" option. Typical concern: job loss and wrong transactions; address with confirmation steps, limits per transaction and human approval for risky actions. See GUIDE-004, GUIDE-008 and GUIDE-009.

Risks, regulation & compliance

• EU AI Act: a customer-facing assistant is mainly limited risk (Art. 50: users must be told they are talking to an AI unless obvious). It becomes high-risk if it performs or materially feeds creditworthiness assessment of natural persons, or risk assessment and pricing for life and health insurance (Annex III) [2]. Fraud detection is carved out of the credit-scoring category. No Art. 5 prohibition applies to normal service use, but avoid emotion inference to manipulate customers, exploiting vulnerability, or subliminal nudging towards products. AI literacy (Art. 4) applies to staff. The EBA's 2025 mapping found limited friction between the AI Act and banking rules, and EIOPA's August 2025 Opinion applies existing Solvency II and IDD governance to AI in insurance [3][4].
• GDPR: processing of account and claims data (health data in claims is Art. 9); legal basis, DPIA, retention, data subject rights over logs. Decisions with legal or similarly significant effect cannot be solely automated without safeguards (Art. 22) [5], so refusals of claims or product changes need human review.
• Financial regulation: PSD2 SCA for payment actions, MiFID II/IDD rules (the bot must not give unsuitable advice or unfair sales pressure), complaint handling, record-keeping. DORA requires ICT third-party risk management, incident reporting and exit plans for LLM providers [6]. National supervisors (BaFin, ACPR, DNB, FMA) expect governance and outsourcing control.
• Typical risks and mitigations: wrong binding statements (answer only from versioned approved content, show source); account takeover (SCA outside the chat, step-up on anomalies); prompt injection (tool permission scoping, treat uploads as untrusted); data leakage to vendors (EU region, no-training contract terms, masking).

Getting started

1. Pick 3-5 high-volume, low-risk intents (card block, claim status, address change) from contact-centre data.
2. Map each to an existing API and its authentication requirement; design confirmation steps and limits before writing prompts.
3. Build a 200-500 case test set from anonymised real conversations, including attacks and vulnerable-customer cases.
4. Run a shadow-mode pilot (bot suggests, agent decides), then an internal-staff beta, then a small customer cohort.
5. Complete DPIA, AI Act classification note, DORA outsourcing assessment and a human hand-over SLA before launch.

Sources

1. Bank of America - Erica surpasses 3 billion interactions (Aug 2025) - https://newsroom.bankofamerica.com/content/newsroom/press-releases/2025/08/a-decade-of-ai-innovation--bofa-s-virtual-assistant-erica-surpas.html
2. Regulation (EU) 2024/1689 (AI Act), Art. 50 and Annex III - https://eur-lex.europa.eu/eli/reg/2024/1689/oj
3. EBA - Chair letter on outcome of the AI Act mapping exercise (Nov 2025) - https://www.eba.europa.eu/sites/default/files/2025-11/2019d1b5-59f8-4149-ad3b-23cfcd4388a1/EBA%20Chair%20letter%20to%20Mr%20Berrigan%20and%20Mr%20Viola%20on%20outcome%20of%20EBA%E2%80%99s%20AI%20Act%20mapping%20exercise.pdf
4. EIOPA - Opinion on AI governance and risk management (6 Aug 2025) - https://www.eiopa.europa.eu/publications/opinion-artificial-intelligence-governance-and-risk-management_en
5. Regulation (EU) 2016/679 (GDPR), Art. 9 and 22 - https://eur-lex.europa.eu/eli/reg/2016/679/oj
6. Regulation (EU) 2022/2554 (DORA) - https://eur-lex.europa.eu/eli/reg/2022/2554/oj
7. Rasa open-source conversational AI framework - https://github.com/RasaHQ/rasa
8. Microsoft Presidio (PII detection) - https://github.com/microsoft/presidio