How to validate LLM output schemas in banking

Banking LLM output schema validation checks that a large language model (LLM) response conforms to an agreed data structure and field constraints before a banking application consumes it. It helps prevent malformed or unexpected values from reaching downstream services. It does not establish that a response is factually correct, permitted by policy or safe to act on; those outcomes need separate checks.

How banking LLM output schema validation works

A schema defines the expected fields, data types, required values, permitted ranges and handling of unknown fields. For a response encoded as JavaScript Object Notation (JSON), a validator parses the complete response and checks it against a versioned JSON Schema or an equivalent application contract.

For a banking workflow, define the contract from the consumer's needs. A statement-extraction service might require a transaction date, a GBP amount and a classification from an approved list. Specify whether additional fields are rejected, whether fields may be null, and how missing or uncertain values are represented. These choices affect the calling application and should be agreed before testing.

Here is a deliberately narrow JSON Schema for extracting GBP transactions. It treats amounts as strings so the application can parse them using its defined decimal rules. The pattern assumes GBP amounts with two decimal places; other currencies need suitable precision rules.

{
  "type": "object",
  "properties": {
    "transaction_date": { "type": "string", "format": "date" },
    "amount_gbp": { "type": "string", "pattern": "^-?(0|[1-9][0-9]*)\\.[0-9]{2}$" },
    "classification": {
      "type": "string",
      "enum": ["credit", "debit", "fee", "unknown"]
    }
  },
  "required": ["transaction_date", "amount_gbp", "classification"],
  "additionalProperties": false
}

The validator must enforce the date format, as some JSON Schema implementations treat format as an annotation unless format checking is enabled. A structurally valid result could be:

{
  "transaction_date": "2026-10-03",
  "amount_gbp": "-12.50",
  "classification": "debit"
}

A result containing classification: "purchase" fails the enum check. A result with an extra customer_name field fails because the schema rejects additional properties.

How to test the contract

Pin the schema version used by the application and validate every complete model response at the service boundary. Test representative valid outputs, then mutate them to check failure handling. Include missing required fields, incorrect types, invalid dates, amounts with excessive precision, unsupported enum values, extra properties, malformed JSON, empty output and responses that contain prose outside the JSON object.

Check that a failed validation cannot trigger a payment, account update, case closure or other consequential action. The application should return a controlled error or route the response for review. If it retries generation, test a bounded retry policy and confirm that repeated invalid output reaches the intended fallback. Avoid silently dropping fields or coercing values into a valid shape, since either behaviour can conceal a model or integration defect.

Schema validation covers structure and declared constraints. Add domain-level assertions for banking meaning and policy. For example, validate that a classification agrees with the transaction context where that is required, that amounts use the expected sign convention, and that an extracted account identifier belongs to the authorised test data. Keep these checks separate so failures show whether the issue lies in the response contract or in business logic.

What to verify in a banking test pipeline

Run the validator in the same service path that consumes model output, rather than relying only on prompt-level instructions. Test with controlled inputs and record the prompt or template version, model configuration, schema version, validation result and failure category. Handle logs according to the data classification rules; test evidence should avoid exposing real customer information.

Model settings, prompts and upstream retrieval content can change response shape over time. Include schema validation in regression tests for those changes, and check compatibility whenever a schema evolves. Constrained output modes offered by a model provider can reduce formatting errors, but they do not replace validation at the application boundary. The application still needs to reject invalid output and apply its own banking rules.