Why Every Banking Chatbot Tested Failed Security

When researchers at TELUS Digital configured 24 leading AI models from OpenAI, Anthropic, and Google as banking customer-service assistants, the result was unanimous failure. Every single model proved exploitable, with attack success rates ranging from 1% to over 64%, according to adversarial testing designed to probe chatbot defenses the way a real attacker would.

The most troubling finding wasn't the raw exploitability—it was the failure pattern. Chatbots would say "I cannot help with that," then immediately disclose sensitive information anyway. This "refusal but engagement" behavior reveals the core problem: model-level guardrails are cosmetic, not structural. As the researchers concluded, these weaknesses are architectural, not rare edge cases, and simple conversational techniques succeeded against every model tested.

The industry's response so far has been spending, not security. Trust, security, and compliance is the top spending category at 78% of financial institutions, yet 69% have rolled back an AI chatbot at least once due to governance failure—most often customer data exposure (27%) or hallucinations (21%). Meanwhile, 76% of organizations still prioritize speed to market over security validation.

That speed-first instinct is about to become expensive. The EU AI Act imposes an August 2, 2026 deadline for high-risk AI systems in the financial sector, with penalties up to €35 million or 7% of worldwide turnover. The Colorado AI Act follows on June 30, 2026. Deploying an exploitable chatbot under these deadlines isn't a competitive risk—it's a regulatory liability.

The failure modes cluster into three recurring categories:

• Inaccurate or incomplete guidance that misleads customers on financial matters
• Sensitive data leakage through basic prompt manipulation
• Operational opacity—missing logging, escalation paths, and audit trails

What this means for vendor evaluation is straightforward: organizations that rely on the underlying AI provider's guardrails and refusal messages as their primary control "will be left explaining failures after the fact." Security has to live in the architecture—deterministic controls, validation layers, and human-in-the-loop escalation—not in the model's good intentions.

This is why the vendor capability matrix in this article scores providers on architectural safeguards rather than marketing claims. Vendors like AIQ Labs, which builds systems with configurable guardrails, full audit trails, and human-in-the-loop controls by design, represent the architectural approach the testing data demands. Every vendor in the matrix gets evaluated against the same question the adversarial research raises: does security survive a determined conversation, or only a polite one?

The Seven-Dimension Matrix That Replaces Feature Lists

Feature checklists are seductive — and nearly useless for evaluating AI chatbots in banking. A vendor can tick "encryption" and "SSO" boxes all day without ever demonstrating how its model decides what to say to a customer about their money.

The problem is that standard third-party risk questionnaires were built for software, not systems that reason across customer data, generate novel responses about financial products, and take actions in backend systems. As one banking trade analysis puts it, conventional due diligence fails to assess how AI makes decisions, how errors are detected, or how quickly a bank can intervene when a model misbehaves — and if a vendor can't document decision logic or assign clear accountability, the regulatory risk lands on the bank, not the vendor. Former Acting Comptroller of the Currency Mike Hsu argues the goal shouldn't be perfect interpretability but actionability: the ability to observe, explain, diagnose, and remediate AI-driven decisions.

A more useful structure replaces the feature list with a seven-dimension compliance matrix, drawn from a framework developed for evaluating AI agents in financial services:

• Foundational security certifications
• AI-specific governance certifications (such as ISO 42001, held by very few customer service AI vendors)
• Financial-services regulatory alignment
• Hallucination control methodology
• Audit trails and operational transparency
• Data handling and privacy architecture
• Deterministic controls for compliance-sensitive workflows

Two practical criteria deserve equal weight alongside those seven. The first is integration depth — the single strongest switching driver in the market. Financial institutions that cite a lack of AI integrations are 2.4x more likely to evaluate a new provider, and 83% are already in active or exploratory conversations with alternatives, according to recent industry survey data. A vendor's answer should specify real, two-way connections to CRMs, financial systems, and payment platforms — the kind of MCP-based integrations (HubSpot, Salesforce, QuickBooks, Xero, Stripe) that builders like AIQ Labs publish openly — not a list of one-way data exports.

The second is data ownership. Regulator-informed evaluation guidance treats data ownership — who trains on the bank's data, who owns outputs, and what happens at contract termination — as a top-four question, noting that standard liability caps are inadequate when AI handles customer data. Vendors that transfer full ownership of code, agents, and data answer this question cleanly; most SaaS chatbot providers cannot.

Why does the matrix matter more than the checklist? Because the failure modes it targets are proven, not hypothetical. Adversarial testing of 24 leading AI models configured as banking chatbots found every single one exploitable, with attack success rates from 1% to over 64% — and a recurring "refusal but engagement" pattern in which chatbots said "I cannot help with that" and then disclosed sensitive information anyway. Hallucinations alone caused 21% of AI chatbot rollbacks, and 69% of financial institutions have pulled back a chatbot at least once due to governance failure.

Deterministic controls — mandatory disclosures, identity verification gates, hard escalation rules — exist precisely because model-level guardrails are not enough. When vendors are scored on observable, remediable decision logic rather than marketing features, the differences between them become impossible to hide.

Scoring the Vendor Landscape Against the Matrix

The vendor landscape for financial institution chatbots splits into three distinct camps, and each fails the compliance test differently. When researchers at TELUS Digital configured 24 leading AI models as banking chatbots, every single one proved exploitable, with attack success rates ranging from 1% to over 64% — a reminder that no vendor category has solved the underlying problem.

The incumbents — Salesforce, Zendesk — carry deep certification portfolios but, as one compliance analysis notes, they "bolt AI onto legacy architectures, creating disjointed audit trails" (fin.ai). For a bank that must document every AI decision under NYDFS Part 500 or the EU AI Act, a fragmented audit trail is a liability, not a feature. The AI-native startups — Ada, Decagon, Sierra — offer modern architectures and fast deployment, but the same analysis argues they lack the compliance certification depth regulators require, and ISO 42001 AI governance certification remains rare among customer service AI vendors.

The third camp is purpose-built bank vendors: Kasisto (deployed at JPMorgan Chase and TD Bank) and Interactions (Citibank), according to the CFPB's chatbots in consumer finance report. These vendors have regulatory track records but operate on closed, subscription-based platforms — the bank never owns the underlying system.

AIQ Labs scores against this matrix differently, though every claim below is self-reported and should be verified during due diligence:

• Audit trails and controls: published architecture includes complete audit logging, validation layers, guardrails, human-in-the-loop escalation, and fallback systems — mapping directly to the seven-dimension compliance framework's transparency and deterministic control criteria.
• Integration depth: MCP-based two-way integrations with HubSpot, Salesforce, QuickBooks, Stripe, and Twilio — significant given that institutions citing a lack of AI integrations are 2.4x more likely to evaluate a new provider.
• Regulated voice AI: the company operates its own compliant collections platform with full compliance tracking, demonstrating voice AI in a financial context rather than promising it.
• Ownership: the Own It Outright model transfers full ownership of code, agents, and data to the client — a direct answer to the data-ownership and exit-rights questions regulators emphasize, which most SaaS vendors cannot match.

The honest caveat: AIQ Labs' SOC 2 and ISO 42001 status is not covered in independent research sources, and certification depth is a core matrix dimension. That gap is exactly why vendor evaluation should include direct verification — which is what the free strategy call at aiqlabs.ai/book is designed for. As former Acting Comptroller Mike Hsu argues, banks should aim for "actionability" — the ability to observe, diagnose, and remediate AI decisions — and no vendor should be scored on claims alone.

How to Run the Evaluation Before You Sign

When TELUS Digital researchers tested 24 leading AI models configured as banking chatbots, every single one proved exploitable, with attack success rates ranging from 1% to over 64%. Yet 76% of organizations still prioritize speed to market over security validation — which means the burden of verification falls squarely on you, the buyer. Here's how to run that verification before you sign anything.

Demand the actual testing methodology, not the claim. Every AI vendor will tell you they test for bias. Almost none will show you the actual testing methodology or results, according to The Financial Brand's regulator-informed evaluation guide. Ask for the test protocol, the adversarial scenarios used, and the failure rates — in writing. A vendor who hesitates is telling you something.

Require deterministic controls, not model-level guardrails. The same research documented a "refusal but engagement" failure mode, where chatbots said "I cannot help with that" and then disclosed sensitive information anyway. Relying on a model's built-in refusals as your primary control leaves you explaining failures after the fact. For compliance-critical workflows — identity verification, mandatory disclosures, escalation — insist on hard-coded, deterministic gates that no prompt can override, backed by human-in-the-loop controls and complete audit trails.

Probe data ownership and exit rights at termination. Who trains on your customer data? Who owns the outputs? What happens to your system when the contract ends? Standard liability caps are inadequate for AI handling customer data, and this question ranks among the top evaluation criteria for informed buyers. It's also why AIQ Labs builds on an ownership model where clients own the code, agents, and data outright — an answer most subscription chatbot vendors structurally cannot give.

Verify integration depth in your own systems. Lack of AI integrations makes financial institutions 2.4x more likely to evaluate a new provider, and 83% are already in active or exploratory conversations with alternatives. Don't accept a demo against sample data — require the vendor to connect to your actual CRM, core systems, and communication platforms before signing.

Check for AI-specific certifications. Infrastructure certifications alone don't cover the risks of systems that reason across customer data and take actions in backend systems. AI-specific governance certifications like ISO 42001 remain rare among customer service AI vendors, which makes them a genuine differentiator — and their absence a legitimate question.

One practical way to run this playbook: the free 30-minute strategy call at AIQ Labs is structured as a working session, not a pitch. An engineer maps your specific bottleneck, shows the verification evidence behind any capability claim — or says plainly if there isn't a clear win for your institution.