Banking conversation data for virtual assistants: beyond Banking77

What Banking77 covers, and where it stops

Banking77 answers the question "which of 77 intents is this sentence?" and nothing after that. The PolyAI release from 2020 pairs short customer queries with fine-grained intents such as a lost card or a failed top-up, and it was designed to test few-shot intent detection; check the dataset card for current counts and license terms. It remains useful for routing-model regression tests and for seeding an intent taxonomy.

It cannot teach a model what a bank agent does next. There are no second turns, no identity-verification prompts, no tool calls, no hold or transfer, and no record of whether the customer's problem was fixed. Research on task-oriented dialogue made the same point years ago: the Action-Based Conversations Dataset (ABCD) argued that slot-value datasets miss the actions agents take under company guidelines, and paired dialogues with those actions [1]. For banking, the gap is wider because the actions move money and are regulated.

How banking agents are now evaluated

Banking assistants are increasingly judged on policy compliance and end state, not intent accuracy. The tau-bench framework tests agents that talk to simulated users, call APIs and must follow domain policy documents, and it grades the final database state against an annotated goal [2]. The maintained tau2-bench framework has since added a knowledge-intensive banking domain that requires retrieval over documents [3].

That shift changes what training and eval data must contain. A transcript is only gradeable if it carries the policy that applied, the actions the agent took in the core banking or card system, and the resulting state. See our guide to policy-following service agent data for how to pair conversations with policies and back-office actions, and voice agent evaluation sets for building held-out call scenarios.

Fields a banking servicing conversation record should carry

A usable record ties every turn to the authentication state, the action executed and the final outcome. Specify these fields in your request rather than accepting "transcripts with intents":

• Channel and source system: chat, IVR, live voice, secure message; speaker roles separated into customer, bot, macro and human agent (see separating bot, macro and human turns).
• Authentication flow: method (OTP, knowledge-based questions, voice or app push), pass, fail or step-up, and the turn where access was granted.
• Intents and sub-intents: mapped to your taxonomy, with Banking77-style labels as an optional crosswalk.
• Backend actions: card freeze or replacement, transfer, payment reschedule, fee reversal, dispute or chargeback intake, address change, with action outcome codes.
• Disclosures: which scripted disclosures were read and at which turn.
• Escalation and resolution: transfer target, complaint flag, resolution code, repeat-contact within a window, and CSAT or survey score where captured.

Illustrative example: invented to show structure; it does not describe an available dataset.

{
  "conversation_id": "c-000184",
  "channel": "voice",
  "turns": [
    {"t": 1, "role": "customer", "text": "My card was stolen this morning."},
    {"t": 2, "role": "agent", "text": "I can help. I've sent a code to the phone on file."},
    {"t": 3, "role": "customer", "text": "It's [OTP_REDACTED]."},
    {"t": 4, "role": "agent", "action": {"name": "card_block", "card_ref": "[CARD_TOKEN_1]", "result": "success"}}
  ],
  "auth": {"method": "sms_otp", "status": "passed", "granted_at_turn": 3},
  "intents": ["card_lost_or_stolen"],
  "disclosures_read": ["replacement_card_fee_notice"],
  "escalated": false,
  "resolution_code": "card_blocked_replacement_ordered",
  "csat": 5,
  "redaction": {"method": "pattern_plus_ner", "pan_audio_muted": true}
}

For field-level transport, see our delivery schema for chat and conversation transcripts.

Why public call-center corpora rarely work commercially

Most public conversational corpora that look like banking servicing data carry research-only terms. CallCenterEN, a large public call-center transcript set, is released under CC BY-NC 4.0, which excludes commercial use [4]. Synthetic banking dialogues avoid licensing friction but tend to miss the messy parts that break production agents: failed verification, partial account numbers spoken twice, disputes that span several contacts.

Commercial buyers therefore need data licensed directly from the operators that hold it: banks, credit unions, card program managers and the outsourcers that run their contact centers. Our guide to user-assistant conversation logs covers how existing chatbot logs differ from human-agent servicing data.

Redaction and regulatory checks specific to banking

Banking conversations need card-data, financial-privacy and recording-consent checks before any license is signed. The checklist below is buyer-side diligence, not a substitute for counsel.

• Card data (PCI DSS): primary account numbers and sensitive authentication data such as CVV are frequently spoken or typed. PCI DSS restricts storing sensitive authentication data after authorization, and call recordings and transcripts count as storage. Require audio muting or bleeping of card digits, not only transcript masking, and test for numbers split across turns.
• GLBA and Regulation P: customer conversations contain nonpublic personal information. Regulation P limits how a nonaffiliated recipient of that information from a financial institution may reuse and redisclose it [5], so ask how the supplier's privacy notice and exceptions cover the transfer, or whether the data is de-identified before it leaves.
• Recording consent: California requires all-party consent to record confidential communications [6], and separately for calls involving cellular or cordless phones [7]. Confirm the "this call may be recorded" notice was played on every inbound and outbound path, including callbacks.
• Voice biometrics: raw call audio can support voiceprint derivation. As of October 2026, class actions filed in May 2026 allege that voiceprints used to train AI fall under Illinois BIPA, though none has been decided on the merits [8]. Texas treats voiceprints as biometric identifiers requiring notice and consent for commercial capture [9]. Decide whether you need audio at all, or transcripts plus prosody features.

This page is general information, not legal advice. Confirm requirements with counsel for your jurisdiction and use case.

Choosing between intent sets, transcripts and audio

The right data shape depends on which model component you are training. Use this decision table when scoping a request.

Illustrative example: invented to show structure; it does not describe an available dataset.

Related industry pages cover adjacent regulated servicing flows, including debt collection conversation data and mortgage servicing and loss-mitigation records. The industry-specific operational data hub lists the rest.

How SourceX approaches banking conversation requests

SourceX sources operational datasets, including support histories, from US companies on request; it does not hold banking transcripts in stock, and a request does not guarantee a match. Buyers describe the data they need, and SourceX looks for US businesses that hold it; every release is approved by the supplying company. Each dataset is rights-reviewed for ownership and consents and delivered under a license that defines records, uses, term and delivery.

Before delivery, personal details such as names, emails, phone numbers and account numbers are removed or replaced, the method is recorded and a sample is checked, though no method is perfect. Delivery runs through private, access-controlled workflows only after an executed agreement and supplier approval. Finance-sector buyers can also review buyers by industry: finance, call center audio datasets, customer support AI training data and voice agent training data, or describe your banking data requirements.

Request banking chatbot training data

SourceX serves AI teams wherever they are based and manages the process from finding a supplier through assessment, licensing and ongoing purchases. Nothing is contracted until a supplier agrees, and terms are set per deal. Start by describing the channels, actions and annotations you need at sourcex.si/buyers.