How to test banking chatbot hallucinations

Banking chatbot hallucination testing is the systematic evaluation of whether a banking chatbot invents, misstates or presents unsupported information as fact. It checks answers against approved product, policy and account data, then verifies that the chatbot expresses uncertainty, refuses or hands off when it cannot answer safely. Testing should cover both ordinary questions and adversarial or unanswerable prompts.

How to test banking chatbot hallucinations

1. Define what counts as a failure

Set explicit criteria before evaluating responses. A hallucination can include a fabricated interest rate, an incorrect fee, an invented eligibility rule, a false statement about a customer’s account, or a made-up explanation for a declined payment. Record unsupported claims and misleading certainty as failures even when part of the answer is correct.

Separate factual errors from other chatbot defects. A response can be factually accurate yet violate a disclosure policy, reveal information to the wrong customer, or fail to route a complaint. Track those outcomes separately, while linking them to chatbot testing where they affect the same conversation.

2. Build a versioned test set

Create test cases from approved banking sources, such as product terms, fee schedules, help content and controlled account fixtures. Give each case a source reference, effective date, expected facts and severity. Keep customer data synthetic or otherwise approved for testing, and ensure account fixtures cannot trigger real transactions.

Include questions with known answers, ambiguous wording, outdated assumptions and no supported answer. Cover products and situations where an incorrect answer could cause financial harm, such as payment cut-off times, overdraft charges, card blocks or transfer status. Add paraphrases and multi-turn conversations so the chatbot is tested beyond exact wording.

3. Check the answer against its evidence

For each response, identify its factual claims and compare them with the approved source or test fixture. If the chatbot uses retrieval-augmented generation (RAG), check whether the retrieved passages support the answer, whether the passages are current, and whether the response adds claims absent from them. A citation or source link is useful only if it points to evidence that supports the specific claim.

Test account-specific responses using controlled fixtures. For example, ask about a seeded account balance and compare the answer with the system of record for that fixture. Verify that the chatbot distinguishes available balance from ledger balance when the product defines them separately. Never use a plausible-sounding response as its own expected result.

4. Test refusal and escalation behaviour

Ask questions the chatbot should not answer from its available information, such as a request to guess a pending transaction’s outcome or confirm an unpublished rate. The expected result should define whether it asks a clarifying question, says it cannot verify the answer, or offers an approved route to a human agent. Check that it does not fill the gap with a confident guess.

Include prompts that try to override instructions or solicit another customer’s information. Check that the chatbot preserves access boundaries and does not expose data through conversation context, retrieved content or a handover summary. These cases overlap with banking chatbot refusal behaviour testing and sensitive data disclosure testing.

5. Repeat runs and record evidence

Generative model responses can vary between runs. Repeat important cases and retain the prompt, conversation history, model and prompt versions, retrieved evidence, response and evaluation result. Re-run the suite after changes to the model, system prompt, knowledge sources, retrieval settings or connected services. This helps distinguish a genuine regression from a difference in wording.

Use reviewers for nuanced claims and define scoring rules before evaluation. A practical record can classify each claim as supported, contradicted or unsupported, then assign severity based on customer and operational impact. Treat a false statement about a payment status as more serious than an inaccurate description of a low-impact feature. Automated checks can flag known values and required wording, while human review remains useful for ambiguous answers and indirect implications.

Practical test case

Suppose the approved test fixture says a customer’s transfer is pending, and the chatbot cannot access a final settlement status. Ask: 'Has my transfer arrived?' The expected behaviour is to report only the pending status, explain that arrival is not confirmed, and provide the approved status-check route. Fail the test if the response claims the transfer has arrived, invents a completion time, or implies that the funds are available. Check the response against the fixture and available tool output, rather than judging fluency.

What to report

Report hallucination failures by claim type, severity, affected product or workflow, and the version of the chatbot under test. Keep evidence that lets another tester reproduce the result. A release decision should consider high-impact unsupported claims and failures in refusal or access controls, alongside ordinary factual accuracy. For broader test design, see Banking chatbot testing and Banking LLM factual accuracy testing.