How to Build Verifiable AI for Financial Services: The 3-Pillar Deterministic Substrate Framework (2026)

Verdict: You cannot use a large language model alone to produce trustworthy financial work product. LLMs are probability machines — they predict the next token, they do not compute deterministic answers. The solution is to augment them with a deterministic substrate: a layer of code, databases, and verification pipelines that handles every numerical operation while the model handles reasoning, planning, and interpretation. The three pillars that make this work are atomic provenance, scope determinism, and derivation chains. Together, they let you produce DCFs, investment memos, and financial models where every figure clicks through to its exact filing, page, and line item — and the same query always returns the same number.

This framework is not theoretical. It was validated in production by a startup that indexed 26 million SEC filings, 50 million additional public documents, and 1 million private documents across 14,000 companies and 27 global markets in under three months — achieving 94% accuracy on financial line-item extraction versus 38–46% for frontier models working alone (Anthropic, April 2026).

Last verified: 2026-07-31

• LLMs cannot do math reliably; route all computation to deterministic code
• Atomic provenance = the model never writes a number, only a reference to where the number lives
• Scope determinism = the model decides what to compute, never how to compute it
• Derivation chains = every calculated metric (ratios, multiples, EBITDA adjustments) has a replayable chain of steps
• The SEC's 2026 examination priorities explicitly require firms to supervise AI and substantiate AI capability claims
• This pattern generalizes beyond finance: law, drug discovery, any domain where a hallucinated fact has consequences

Why Can't You Just Use an LLM for Financial Analysis?

LLMs are next-token predictors — probability machines that generate the statistically likely next word. This makes them extraordinary at interpreting freeform questions, decomposing multi-step problems, and reasoning about which data points are needed. But it makes them fundamentally unsuitable for producing the numbers themselves.

The core insight is this: AI has made producing work product nearly free, but it has turned everything into a reading problem. Writing a DCF, an investment memo, or a fairness opinion is no longer the bottleneck — verifying that every number in it is correct is the bottleneck. In finance, a wrong number is wrong even if it is right 94% of the time, because the 6% of cases where it fails can destroy a trade, trigger a regulatory violation, or mislead an investment committee.

Here is why standard LLM approaches fail in financial services:

Approach	What it does	Why it fails in finance
Raw LLM output	Model reads a filing and writes a number	The number is a token prediction, not a computation — it can hallucinate
RAG + citations	Model retrieves documents and cites them	Citation is an after-the-fact audit, not a deterministic proof the number was extracted correctly
Fine-tuned extraction model	Train a model to extract financial line items	Even 94% accuracy means 1 in 17 numbers may be wrong — unacceptable for regulated work
LLM-as-a-judge (evals)	Use one model to check another's output	You cannot take a non-deterministic system and eval your way to determinism — both are probabilistic

The last point bears emphasis. A growing industry practice is to use one LLM to evaluate another LLM's output — "LLM-as-a-judge." This can be useful for subjective quality scoring. But it cannot produce the mathematical certainty that finance requires. Two probability machines checking each other's work still leaves you with a probabilistic answer, not a deterministic one. The broader problem of AI agent sprawl becoming the new shadow IT starts here: if you cannot verify what your AI systems produce, you cannot govern them.

What Is a Deterministic Substrate?

A deterministic substrate is a layer of code, databases, and pipelines that handles every operation requiring numerical accuracy — while the LLM handles only reasoning, interpretation, and planning. Think of it as giving the model a set of tools: the model decides which tool to use and when, but the tool does the actual work.

The analogy is a portfolio manager at a hedge fund. A PM does not manually compute every ratio in their head — they use Excel, a Bloomberg terminal, and databases. The PM's job is to decide what to look at and how to interpret it. The tools' job is to compute the numbers accurately. You would not ask a PM to mentally calculate enterprise value across a complex capital structure with preferred shares, convertibles, and minority interests. You should not ask an LLM to do it either. This is the same principle behind managing AI like a team member rather than a tool: you delegate the reasoning to the AI and the execution to deterministic systems.

This separation has three immediate benefits:

1. Zero number hallucination. The model never touches raw numerals, so it cannot invent a figure. A deterministic tool extracts, stores, and returns the number.
2. Radical cost reduction. Running 1 + 1 through a multi-billion parameter model wastes compute. A single CPU cycle in a deterministic function does the same job — faster, cheaper, and provably correct.
3. Reproducibility. The same query returns the same number every time. This is a regulatory requirement, not a nice-to-have.

The 3-Pillar Framework for Verifiable AI in Finance

Pillar 1: Atomic Provenance

What it means: The LLM never writes or manipulates a number directly. When it encounters a financial figure — say, revenue from a 10-K — it writes a reference to where that number lives (a specific filing, page, and line item). A deterministic tool then extracts and persists the actual value in a database. A verification step checks that the extracted number matches the source independently. If it cannot be verified, the number is stripped — it never reaches the user.

Why it matters: In finance, "this came from a 10-K" is not sufficient validation. The validation is the deterministic, repeatable process that proves the extraction was correct — the filing, the page, the line item, and the exact value. A provenance ledger records every extraction event so it can be replayed and audited.

How to implement it:

1. Parse structured filings first. SEC filings are available in XBRL (eXtensible Business Reporting Language), which is machine-readable structured data. Extracting from XBRL is deterministic — you are querying a tagged structure, not OCR-ing a PDF. Always prefer XBRL over PDF parsing.
2. Model writes a reference, not a value. When the LLM identifies that it needs "net revenue for fiscal year 2024," it outputs a structured query: {filing: "10-K", company: "ACME", year: 2024, field: "RevenueFromContractWithCustomerExcludingAssessedTax"}. This is a pointer, not a number.
3. Deterministic extraction. A separate code module executes the query against the XBRL-parsed database and returns the value. The LLM never sees or touches the raw numeral.
4. Independent verification. A second pass cross-checks the extracted value against the source document — same filing, same field, same value. If the check fails, the value is discarded.
5. Provenance ledger. Every extraction event is logged: what was extracted, from where, when, by which pipeline step. This creates an immutable audit trail.

Pillar 2: Scope Determinism

What it means: The model is scoped to operate only within its competence — reasoning, planning, and interpretation. Every deterministic task (math, data extraction, formula computation, fiscal period resolution) is routed to deterministic code. The model decides what to compute; it never performs the computation itself.

Why it matters: This is the most controversial principle and the most important. The model is brilliant at understanding that a user asking for "inventory days outstanding over the last eight quarters" needs COGS, inventory levels, and the correct fiscal periods. But it should not be the entity running the formula ((Inventory / COGS) × DaysInPeriod) — that is code, and code is what handles it.

This also dramatically reduces cost. Instead of routing every step through a frontier model, you use the model for what it is good at and let a CPU cycle handle the rest. The cost difference between a multi-billion parameter inference call and a Python function execution is orders of magnitude.

How to implement it:

1. Build a proprietary ontology. Map every financial concept your firm uses (EBITDA, gross margin, enterprise value, inventory days) to a precise formula and a set of source fields. This ontology is your dictionary — the model references it, the deterministic engine executes it.
2. Enforce hard boundaries on model scope. The model can: interpret a question, decompose it into steps, identify which data points are needed, and plan the execution sequence. The model cannot: perform arithmetic, extract numbers from documents, or produce a final calculated value.
3. Route computation to deterministic functions. Once the model produces an execution plan (e.g., "fetch inventory for periods Q1 2024 through Q4 2025, fetch COGS for the same periods, compute days outstanding for each"), a deterministic engine executes it and returns the results.
4. Make skills idempotent. The same input should always produce the same output. Running the same query twice must return the same number. This is a prerequisite for regulatory reproducibility.

Pillar 3: Derivation Chains

What it means: When a requested metric does not exist directly in a filing — a ratio, a multiple, an EBITDA adjustment — the system constructs a chain of steps that produced it. Each link in the chain records: what data point was used, where it came from, what transformation was applied, and what the result was. The chain can be replayed and rewound, just like an analyst's work paper.

Why it matters: Everyone calculates ratios and multiples differently. Gross margin, enterprise value, EBITDA adjustments — these are not standardized. One firm's "recurring revenue" is another firm's "one-time gain." The derivation chain captures your firm's specific definitions and makes them auditable. When a regulator asks "how did you arrive at this number?", you can show the exact chain of steps — every number, every formula, every source.

How to implement it:

1. Record every transformation. When the system computes gross_margin = (revenue - COGS) / revenue, it logs: the revenue value, its source filing, the COGS value, its source filing, the formula used, and the result. This is the derivation chain.
2. Make the chain replayable. An auditor should be able to click any number in a financial model and see the full derivation: which filings it came from, what formulas were applied, and what intermediate values were computed. This is the "work product as proof" principle — the document itself is the audit trail.
3. Reconcile against internal documents. When your firm has proprietary definitions (e.g., a specific set of EBITDA adjustments), codify them in the ontology. The derivation chain should reflect your firm's philosophy, not a generic standard.
4. Handle restatements and period changes. Filings get restated. Fiscal periods change. The derivation chain must track which version of a filing was used and flag when a newer restatement is available.

Comparison: Citation vs. Verification

The distinction between citation and verification is the crux of the entire framework. Most current AI tools — from ChatGPT to Claude to Perplexity — cite sources. None of them verify that the numbers they extract are correct.

Dimension	Citation (current AI tools)	Verification (deterministic substrate)
What it proves	Where the model says it got the information	That the number was deterministically extracted from that source
When it happens	After generation (post-hoc audit)	During generation (in-pipeline proof)
Can the model hallucinate?	Yes — it can cite a real source but extract the wrong number	No — the model never writes numbers, so it cannot invent them
Reproducible?	No — re-running the same query may produce different numbers	Yes — same input, same output, every time
Regulator-ready?	No — "the AI said so" is not an auditable defense	Yes — every number has a replayable chain to its source
Source quality control	None — the model may cite a Substack or Reddit post	Enforced — the system only extracts from approved, structured filings

What Does the SEC Require for AI in Financial Services?

The SEC's Division of Examinations released its Fiscal Year 2026 examination priorities, and AI is explicitly in scope. Section VII.B of the priorities directs examiners to assess "whether firms have implemented adequate policies and procedures to monitor and/or supervise their use of AI technologies" and to "review for accuracy registrant representations regarding their AI capabilities" (SEC, October 2025).

This creates two concrete obligations:

1. AI supervision. Firms must document which AI tools they deploy and be able to explain how AI-driven decisions are reached. When an AI system produces a number that drives a trading or investment decision, examiners will want to understand the logic behind it.
2. Substantiation of AI claims. If a firm markets an "AI-powered" investment strategy or research tool, they must be able to substantiate those claims during an examination. This directly addresses "AI-washing" — making exaggerated or misleading claims about AI capabilities.

The deterministic substrate framework directly satisfies both requirements. Every number is traceable to its source (supervision). Every decision step is replayable (explainability). And the system does what it claims — it produces verified numbers, not probabilistic guesses.

The OCC, Fed, and FDIC have also stated that existing model risk management guidance (SR 11-7) applies to AI models, including generative AI. If your LLM is used in decision-making, risk assessment, or compliance, it falls under validation, governance, and ongoing monitoring requirements.

How to Build This: A Step-by-Step Implementation Guide

If you are a fintech founder, a quant team lead, or a CTO evaluating AI for financial research, here is a practical implementation sequence.

Step 1: Index Structured Filings

Start with SEC EDGAR, which provides filings in XBRL format. XBRL is tagged, structured data — extraction is deterministic, not probabilistic. You can download the full SEC filing corpus via EDGAR's bulk data feeds. A financial platform that did this indexed 26 million SEC filings across 14,000 companies in under three months using AWS, Rust, and Python (Anthropic, April 2026).

Do not start with PDF parsing. PDFs are unstructured — extracting a number from a PDF page is a probabilistic task. XBRL gives you the same data in a machine-readable format where the extraction is a database query, not an inference call.

Step 2: Build the Extraction Layer

Create a deterministic extraction pipeline that:

• Parses XBRL filings into a structured database (company, fiscal period, line item, value). -Tags every value with its source: filing type (10-K, 10-Q, 8-K), filing date, page (if available), and XBRL tag.
• Makes the database queryable by the LLM via structured queries (not freeform prompts).

The LLM's job at this stage is to interpret the user's question and produce a structured query. The database's job is to return the value. Neither touches the other's domain.

Step 3: Build the Computation Layer

For any metric that is not a raw filing value (ratios, multiples, adjustments), build deterministic functions:

• Each function takes structured inputs (company, period, formula).
• Each function returns a result with a full derivation chain (inputs, formula, intermediate values, result).
• Each function is idempotent — same input, same output.

Common functions to build first: gross margin, operating margin, net margin, inventory days outstanding, enterprise value, EBITDA (with customizable adjustment sets), P/E ratio, debt-to-equity.

Step 4: Build the Provenance Ledger

Every extraction and computation event writes to an immutable log:

• What was extracted/computed.
• From what source (filing, page, line item).
• By which pipeline step.
• At what timestamp.
• With what result.

This log is your audit trail. When a regulator asks to see how a number was derived, you replay the chain.

Step 5: Integrate the LLM as the Reasoning Layer

Only now do you introduce the LLM. Its role:

• Interpret the user's natural-language question.
• Decompose it into a structured execution plan (which data points to fetch, which formulas to apply).
• Resolve ambiguity by asking the user clarifying questions (e.g., "Do you mean GAAP or non-GAAP EBITDA?").
• Synthesize the deterministic results into a human-readable answer.

The model should never write a number. It should always reference the deterministic layer's output. If a model is tempted to write "the company's revenue was $4.2 billion," it should instead write a reference that the presentation layer uses to pull the verified value from the database.

Step 6: Build the Verification Layer

After the deterministic layer produces its output, run an independent verification pass:

• Re-extract the value from the source filing independently.
• Compare the two results.
• If they match, the value is confident. If they do not, strip the value and flag the discrepancy.

This is not the same as "having two models check each other." This is two deterministic extractions compared against each other — a checksum, not an opinion.

Step 7: Build the Presentation Layer

The final output (a financial model, a DCF, a research memo) should be assembled from the deterministic layer's verified results. Every number in the output should be clickable — clicking it takes the user to the exact filing, page, and line item it came from. This is the "work product as proof" principle: the document itself is the audit trail.

What Are the Limitations of This Approach?

This framework is powerful, but it is not a silver bullet. Honest limitations:

1. It requires structured data. The deterministic substrate works only when the source data is machine-readable. XBRL filings are ideal. Hand-typed PDFs, scanned documents, and earnings call transcripts are harder — extraction from these is inherently probabilistic, even if the downstream computation is deterministic.
2. It requires codified financial definitions. Every ratio, multiple, and adjustment must be explicitly defined in your ontology. Firms that have never formalized their EBITDA adjustments or enterprise value calculations will need to do so. This is significant organizational work.
3. It does not solve for source quality. If the underlying filing contains an error, the deterministic substrate will faithfully extract the wrong number and verify it against the wrong source. Garbage in, garbage out — but at least it is auditable garbage.
4. It does not replace analysts. The framework automates the extraction and computation layers. The interpretation, judgment, and decision-making still require human analysts. What it does is give those analysts their time back — the hours spent manually keying numbers from 10-Ks into Excel models.

What Does This Mean for You?

If you are a fintech founder or CTO: The deterministic substrate is the architecture that will let you build AI products that financial institutions will actually buy. The barrier is not model capability — it is trust. Firms will not deploy AI that cannot be audited. Building provenance from day one is not a feature; it is the product. This is the same reason 95% of enterprise AI pilots fail to reach production: the bottleneck is process understanding and trust, not model intelligence.

If you are a quant or portfolio manager: You can start demanding this architecture from your AI vendors. If a tool produces a number and cannot show you the exact filing, page, and line item it came from — with a replayable derivation chain — it is not verifiable. It is a citation tool, not a verification tool.

If you are a compliance officer: The SEC's 2026 examination priorities mean you need to audit your firm's AI usage now. The framework above gives you a checklist: can your AI tools trace every number to a source? Can they reproduce the same output for the same input? Can they explain every step in a computation? If not, you have regulatory exposure. The same logic applies to managing unverified AI-generated code and content: without a verification layer, you are shipping work product you cannot defend.

If you are building AI agents for other industries: This pattern generalizes. In law, the same architecture can prevent hallucinated case citations by extracting case references deterministically and letting the model reason about the relationships. In drug discovery, compound formulations from NIH white papers can be extracted once and stored deterministically so the model never invents a molecule. Any domain where a hallucinated fact has consequences needs the same separation of reasoning from extraction. The key is verification density, not model capability — more checks per unit of output, not more parameters.

FAQ

Q: What is the difference between RAG and a deterministic substrate?

A: RAG (Retrieval-Augmented Generation) retrieves documents and feeds them to the LLM, which then generates an answer. The model still writes the numbers, which means it can still hallucinate them. A deterministic substrate routes all numerical operations to code — the model never writes a number, only a reference to where the number lives. RAG constrains what the model reads; a deterministic substrate constrains what the model is allowed to produce.

Q: Can fine-tuning an LLM make it accurate enough for financial analysis?

A: No. Fine-tuning can improve extraction accuracy — one team achieved 94% on line-item mapping versus 38–46% for base frontier models (Anthropic, April 2026). But 94% means 1 in 17 numbers may still be wrong. In finance, a single wrong number in an investment memo or regulatory filing can be catastrophic. Fine-tuning improves the odds; a deterministic substrate changes the game.

Q: Why can't you use one LLM to check another LLM's output (LLM-as-a-judge)?

A: Because both systems are probabilistic. A probability machine checking a probability machine gives you a probabilistic answer, not a deterministic one. If the first model hallucinates a number and the second model fails to catch it (which it will, some percentage of the time), you still have a wrong number with a false stamp of approval. Verification must be deterministic — the same check must pass or fail the same way every time.

Q: How does this framework help with SEC compliance?

A: The SEC's 2026 examination priorities require firms to supervise their use of AI and substantiate claims about AI capabilities (SEC, October 2025). The deterministic substrate provides exactly what examiners need: every number is traceable to its source, every computation is replayable, and the system does what it claims. It transforms "the AI said so" into "here is the filing, the page, the line item, and the formula — verify it yourself."

Q: Does this approach work for unstructured data like earnings call transcripts?

A: Partially. The deterministic substrate works best with structured data (XBRL filings, tagged financial databases). For unstructured sources like earnings call transcripts, the extraction step is inherently probabilistic — you are parsing natural language. However, the downstream computation remains deterministic, and the provenance ledger still records exactly where each extracted data point came from. The framework reduces the risk surface area even when it cannot eliminate it entirely.

Q: Is this only relevant to financial services?

A: No. The core pattern — separate reasoning (model) from extraction and computation (deterministic code) — applies to any domain where output must be trusted. In law, it can prevent hallucinated case citations. In drug discovery, it can prevent invented chemical compounds. In healthcare, it can ensure clinical trial data is accurately represented. Finance is simply the most demanding environment because the regulatory and financial consequences of error are highest, which is why the pattern was pioneered there.

Sources

• Anthropic — "How Kepler built verifiable AI for financial services with Claude" (April 30, 2026) — Primary case study; 26M+ SEC filings indexed, 14,000+ companies, 27 global markets; 94% extraction accuracy vs 38–46% for frontier models; founded 2025 by Vinoo Ganesh (CEO) and John McRaven (CTO).
• SEC Division of Examinations — 2026 Examination Priorities (October 2025) — Section VII.B addresses AI supervision and substantiation of AI capability claims.
• NIST AI 600-1 — Generative AI Profile (companion to the AI Risk Management Framework) — Defines "confabulation" (hallucination) and maps mitigation actions across Govern, Map, Measure, and Manage functions.
• BusinessWire — "Anthropic Spotlights Kepler for Verifiable AI in Financial Services" (May 21, 2026) — Press release confirming 94% extraction accuracy and 26M SEC filings indexed.

Updates & Corrections

• 2026-07-31 — Article published. All facts verified against primary sources as of July 31, 2026. SEC 2026 examination priorities confirmed via SEC.gov press release. Kepler statistics confirmed via Anthropic case study and BusinessWire press release.

---