A reference architecture for finance AI systems

Every finance AI build we take on ends up with roughly the same six layers: a data layer that guarantees point-in-time correctness, retrieval over documents and records, the model that does the reasoning, guardrails that constrain what it can output, human review where the stakes are high, and an audit trail that lets you reconstruct any decision later. The topology varies. The shape does not.

That consistency is worth saying out loud, because most finance AI projects fail in the same predictable places, and a reference architecture is mostly a list of those places with a defense at each one. What follows is the starting point we sketch on the first whiteboard, before anyone has argued about which model to use.

The data layer decides everything downstream

The number the model reads has to be the number that was true at the moment the decision was made. This sounds obvious and is violated constantly. A model scoring a loan application in the training set sees a borrower’s revenue figure that was restated two quarters later. That restatement leaks backward into the features, the offline eval looks excellent, and the system underperforms the day it meets a borrower whose future you cannot see. Lookahead is the most expensive bug in finance AI and the hardest to notice, because everything about a leaky system looks healthy until it is in production.

So the data layer carries obligations that a general-purpose pipeline does not:

• Point-in-time correctness. Every record answers “what did we know, and when did we know it,” not just “what is true now.”
• Lineage. For any figure the model consumed, you can name the source system, the extraction step, and the transformation that produced it.
• Entity resolution. The same counterparty appears as three different strings across four systems, and you need one identity before you can reason about exposure or covenant history.
• Reconciliation. When two sources report a figure differently, the discrepancy is surfaced and resolved by a rule, not silently averaged away.

Get this layer wrong and no model, retrieval trick, or prompt saves you. Get it right and much of the rest is ordinary engineering.

Retrieval and the model are the interchangeable part

This is the layer people spend the most time debating and the layer that matters least to whether the system works. Retrieval pulls the relevant filings, contract clauses, prior memos, and internal records into context. The model reasons over them. Both are largely swappable; you will replace the model at least once during the life of the system, and the architecture should assume that.

Two things earn attention here. First, retrieval over financial documents is rarely well served by semantic search alone. A query about a specific covenant threshold or a line item in a filing is a lexical match as much as a semantic one, and hybrid retrieval that combines the two consistently beats either in isolation. Numbers, defined terms, and section references are exact by nature, and dense embeddings blur them.

Second, the model needs an eval set that reflects the actual work, not a generic benchmark. For a credit memo assistant, that means real memos with known-correct figures and a grader that checks the numbers, not the prose. For a transaction-monitoring assistant, it means labeled alerts with a defined false-positive budget, because the cost of the system is measured in analyst hours spent clearing noise. Without a domain eval set you are tuning against vibes, and vibes drift.

Guardrails, review, and audit are where finance is different

A general AI product can ship the model’s output straight to the user. A finance system usually cannot, because the output feeds a decision with a regulator, a counterparty, or a balance sheet on the other end. Three layers sit between the model and the consequence.

Guardrails constrain the output space before anyone sees it. A figure the model reports should be traceable to a retrieved source or it does not leave the system; unsupported numbers are the failure mode that matters, and a confident sentence with a wrong number in it is worse than a hedge. Guardrails also enforce the boundaries the model must not cross on its own, such as declining to act where a regulation like ECOA governs how a credit decision may be explained.

Human review is placed by materiality, not uniformly. The design question is which cases go straight through and which stop for a person. Route by the model’s calibrated confidence and the cost of being wrong: low-stakes, high-confidence cases become straight-through processing, and the reviewer’s attention is spent on the ambiguous and the expensive. A review layer that asks a human to check everything is a review layer nobody uses by month three.

The audit trail is not a log file. For any decision the system produced, you should be able to reconstruct the inputs as they stood at the time, the retrieved evidence, the model version, the guardrails that fired, and who reviewed it. This is what SR 11-7 expects of model risk management and what the EU AI Act expects of record-keeping for high-risk systems, and it is also what you will want the first time a quarter-end number is questioned and someone asks how the machine arrived at it.

Where drift and quarter-end live

Two operational realities sit underneath all six layers. Models and data drift, so the eval set is not a launch gate you pass once; it runs on a schedule against fresh data, and a calibration that slips is treated as an incident. And finance has a clock. Quarter-end concentrates volume and raises the cost of every error at exactly the moment throughput demand peaks, so the human-review routing and the guardrails have to hold under load, not just in the demo. The days that decide whether a design works are the ones when the queue is deep and the close is due. A design that only holds when traffic is calm has never met them.