How to test groundedness in banking LLMs

Banking LLM groundedness testing checks whether a large language model (LLM) supports each material statement in its response with the evidence supplied to it, such as approved product documents or retrieved records. It also checks whether the model stays within that evidence when information is missing. The aim is to detect unsupported claims, misread evidence and answers that exceed the system's authorised scope.

What groundedness testing checks

Groundedness concerns the relationship between an answer and its supporting context. It differs from factual accuracy: a response may happen to be true while having no support in the context provided. Citation accuracy is a related check that asks whether a cited passage actually supports the claim beside it. These checks can overlap, but they measure different failure modes.

For a banking assistant using retrieval-augmented generation (RAG), test the path from source document to answer. Verify that the correct document was retrieved, that the answer reflects its content, and that citations point to relevant passages when citations are part of the interface. For an LLM that receives data from an application programming interface (API) or another tool, check that its statements match the returned values and tool results.

Use controlled, approved test sources. Include relevant product terms, fee schedules, account help content or policy documents, with their effective dates and version identifiers. Keep customer or account data synthetic where possible. Confirm that the test account, retrieval index, model, system prompt and application configuration match the versions recorded in the test run. Environment drift or an unnoticed source update can make a result difficult to reproduce.

Design groundedness test cases

Build cases around the evidence available to the model, then define the expected support for each material claim. Include questions with a clear answer in the source, questions where only part of the answer is supported, and questions for which the supplied evidence gives no answer. Add cases with outdated or contradictory material if the application is expected to detect those conditions.

For each case, record the input, permitted source set, expected answer boundaries and expected behaviour. Assertions can check that required facts appear, prohibited claims do not appear, and any citation identifies supporting text. Avoid relying on exact response wording when several phrasings could express the same supported answer. Where a claim depends on a number, date, eligibility condition or fee, compare it with the source value explicitly.

Worked example

Suppose a test fixture contains an approved savings product document stating a variable rate of 2.4% AER, effective from 1 June, and a separate older document showing a previous rate. The customer asks, “What rate applies to this account?” The test should confirm that the current document is retrieved and that the response gives the current rate with its effective date. It should fail if the response uses the older figure, adds an unsupported condition, or presents the rate as fixed when the source describes it as variable. If the fixture lacks account-specific information, the model should explain that the documents do not establish which rate applies to that account.

Measure and investigate failures

A practical evaluation records whether each material claim is supported, whether each citation supports its claim, and whether the response handles missing evidence correctly. Teams can report these results by case, source type or risk category. Set acceptance thresholds from the use case and risk assessment; no single score establishes that a banking assistant is safe for every purpose.

Automated evaluators, including LLM-based judges, can help review large response sets, but their verdicts need validation. Compare them with human-reviewed examples, inspect disagreements and retain the input, retrieved passages, model output and evaluator result as test evidence. Re-run the same suite after changes to prompts, models, retrieval settings, source content or application code. Use repeated runs where responses can vary, and investigate failures rather than averaging away a serious unsupported claim.

Groundedness results do not replace checks for access control, privacy, policy compliance or transaction correctness. A response can be supported by a document and still disclose information to the wrong user or imply an action the system cannot perform. Combine groundedness cases with permission and workflow tests where the assistant handles account-specific questions or interacts with banking systems.