What is LLM evaluation in banking?

LLM evaluation in banking is the structured assessment of a large language model's outputs and behaviour against defined requirements for a banking use case. It checks whether responses are accurate, grounded in approved information and consistent with policy, while examining risks such as exposing sensitive data or giving unsupported financial guidance. Evaluation should cover the model and the surrounding application, including prompts, retrieval sources and connected tools.

What LLM evaluation in banking covers

A bank should define what the system is allowed to do before evaluating it. A customer-support assistant that explains a fee schedule has different acceptance criteria from an internal assistant that summarises procedures or a model that helps staff review loan applications. The intended users, available data, permitted actions and consequences of an incorrect answer shape the test scope.

Evaluation cases can assess factual accuracy, whether an answer is supported by retrieved material, compliance with approved wording, appropriate refusal and correct handling of ambiguity. For systems that call APIs or other tools, tests should check the chosen tool, arguments, permissions and use of the returned result. Response quality alone cannot confirm that a banking workflow completed correctly.

The evaluation also depends on the surrounding system. A change to a prompt, retrieval index, model version, account data, API or access control can alter behaviour. Record those dependencies with the results so a passing run can be reproduced and compared with later runs.

How to evaluate a banking LLM

Start with a representative, risk-based test set. Include routine requests, incomplete or conflicting information, unusual wording, requests outside the system's authority and attempts to elicit restricted information. Use approved test data or suitably controlled synthetic data. For each case, specify the expected behaviour and the evidence needed to judge it. Some answers have a fixed expected value; others need a rubric that reviewers apply consistently.

Run the cases against the configured application, not just a bare model, where retrieval, prompts or tools affect the answer. Automated checks can verify exact values, required phrases, valid tool calls and whether an answer cites an approved source. Human review is useful for contextual judgement, such as whether an explanation is misleading despite containing correct facts. Record disagreements and refine the rubric rather than treating a model-generated score as ground truth.

Set acceptance criteria for each material risk. A high average quality score can conceal a serious failure on a particular class of request. Check results by scenario and failure type, and decide how the system should behave when it cannot answer safely. Protect evaluation data and restrict access to outputs that may contain customer information.

Practical example: explaining a bank fee

Suppose a customer assistant answers questions using an approved fee schedule. A test case asks which fee applies to a specified transaction. The fixture contains the relevant transaction details and the current schedule entry. The expected result is that the assistant gives the applicable fee accurately and grounds the answer in that entry. A related case omits a detail needed to choose between two entries; the expected behaviour is to ask for clarification or explain what information is missing.

Run both cases after changes to the model, prompt or retrieval index. Check the answer and its source, then review any failure to find whether the cause was retrieval, interpretation or response generation. A correct-looking answer with no supporting source should fail if the application requires grounded answers.

Evaluation, testing and model validation

LLM evaluation provides evidence about behaviour for a defined task and test set. It is one part of banking software testing, which also covers interfaces, access controls, data flows, resilience and end-to-end business processes. Model validation is a broader assessment of whether a model is suitable for its intended use and how its limitations and controls are understood. The terms can overlap in practice, so teams should state what evidence each activity produces.

Evaluation cannot prove that a model will behave safely on every possible input. Test sets may miss real-world wording, and automated judges can share the same blind spots as the model under test. Use evaluation alongside security and privacy testing, operational controls, human oversight where required, and monitoring of deployed behaviour. Investigate failures before release and rerun relevant cases when a dependent component changes.