5 min

AI Gateway

Financial Guardrails & Number Validation

Why Financial AI Needs an Orchestration Layer

In a general-purpose chatbot, a wrong answer is annoying. In a financial AI system, a wrong number can drive real decisions — portfolio rebalancing, earnings estimates, competitive positioning. The AI gateway is the safety layer that prevents bad outputs from reaching analysts.

This module builds the gateway as a LangGraph.js state graph — a directed graph where each safety check is a visible, debuggable node. The graph architecture means you can trace exactly why a particular number was flagged or a disclaimer was added.

The Financial Gateway Graph

classify_query → check_cache → [hit] → return_cached
                             → [miss] → apply_guardrails
                                       → check_freshness
                                       → route_model
                                       → call_llm
                                       → validate_numbers
                                       → add_disclaimers
                                       → track_usage

Each node is a pure function: it reads the current state, performs its check, and returns updated state. Edges between nodes can be conditional — the graph takes different paths based on query classification.

Financial-Specific Nodes

Query Classification

Financial queries fall into distinct categories that require different handling:

Query Type	Example	Model Needed	Special Handling
Factual lookup	"NVDA Q3 revenue?"	Fast (Haiku)	Exact number verification
Comparison	"Compare NVDA vs AMD margins"	Capable (Sonnet)	Multi-company context assembly
Trend analysis	"Revenue growth last 4 quarters"	Capable (Sonnet)	Temporal ordering, calculation
Forecast/opinion	"Will margins improve next quarter?"	Strongest (Opus)	Heavy disclaimers required
Screening	"Which companies have P/E < 20?"	Fast (Haiku)	Structured data filters

The classifier extracts: query_type, tickers_mentioned, metrics_requested, time_period, and complexity_level. This metadata drives every downstream decision.

Number Validation

The most critical financial node. After the LLM generates a response, this node:

Extracts all numbers from the response using regex patterns: $X.XM, XX.X%, X.XX, dollar amounts, percentages, ratios

Matches each number against the source chunks in the retrieved context

Classifies each number as:

Verified — exact match found in source data

Derived — result of a calculation from verified source numbers (e.g., margin = profit / revenue)

Unverified — number not found in any source chunk

Contradicted — number conflicts with source data

Generates confidence score:

High (0.9+): All numbers verified or correctly derived

Medium (0.6-0.9): Most numbers verified, some derived

Low (<0.6): Multiple unverified numbers or contradictions

If any number is contradicted, the node can either flag it in the response or trigger a re-generation with explicit instructions to use only source data.

Freshness Checking

Financial data has strict freshness requirements:

Data Type	Acceptable Age	Action When Stale
Market data	< 1 hour	Flag with "as of [timestamp]"
Earnings transcripts	< 90 days	Acceptable for current quarter
SEC filings (10-Q)	< 100 days	Flag if newer filing expected
SEC filings (10-K)	< 1 year	Flag with "annual data from [date]"
Analyst notes	< 30 days	Flag if older than most recent note

The freshness node checks the data_date metadata of all retrieved chunks against these thresholds. If the data is stale for the query type, it adds a freshness warning: "Note: This analysis is based on Q2 2024 data. Q3 2024 10-Q has not been filed yet."

Disclaimer Management

Financial AI must never provide investment advice. The disclaimer node adds context-appropriate notices:

Always: "This analysis is based on publicly available data and should not be construed as investment advice."

When data is stale: "Based on data through [latest date]. More recent filings may be available."

When numbers are unverified: "Some figures could not be verified against source documents. Please cross-reference with original filings."

For forecast queries: "Forward-looking statements reflect management guidance and analyst estimates, which may not materialize."

Caching with Financial TTLs

Not all financial data ages at the same rate. The cache node uses source-type-aware TTLs:

Market data queries: 15-minute TTL (prices change continuously)

Filing-based queries: 24-hour TTL (filings don't change after publication)

Analyst note queries: 1-hour TTL (new notes may be published)

Mixed queries: Use the shortest TTL from any source type involved

Cache keys include the query embedding, ticker filter, and period filter. Two queries that are semantically identical but for different tickers must be separate cache entries.

Cost Controls

Financial analysis queries can be expensive — complex comparisons may use 10,000+ tokens of context. The gateway enforces:

Per-user daily budget: Configurable token limit per user per day

Query cost estimation: Before calling the LLM, estimate the token count and warn if it will consume a large portion of the budget

Budget alerts: Notify at 80% utilization, reject at 100%

Model routing optimization: Simple lookups go to cheaper models, saving budget for complex analysis

LangGraph Benefits

Building this as a LangGraph state graph instead of nested if/else provides:

Traceability — Log which nodes executed, what state they modified, and what decisions they made. Critical for compliance audits.

Composability — Add a new guardrail by adding a new node and edge. No spaghetti code.

Debuggability — When a number is wrong, trace back through the graph to see if retrieval, validation, or generation was the failure point.

Testability — Each node is a pure function that can be unit tested independently.

This is chapter 4 of AI Finance Analyst.

Get the full hands-on course for $100 and build the complete system. Your projects become your portfolio.

View course details

Ch. 3: Retrieval System

Ch. 5: Finance App