A finance-operations AI glossary: the terms that actually matter

Most of these terms circle one problem: getting the correct value to a decision at the moment it has to be made, then being able to prove afterward how it got there. Finance work fails on inputs and lineage far more often than on model choice. Below are the words that carry weight in production, defined by how they behave rather than by the textbook.

The data terms that decide whether anything works

Before a model matters, the data around it has to be honest about time. Almost every silent failure in a finance model traces back to one of these.

• Point-in-time correctness. The guarantee that every feature value used to train or score reflects only what was knowable at that timestamp. A borrower’s revised revenue figure filed in March must not appear in a January decision. Get this wrong and your backtest lies to you.
• Lookahead, or leakage. Any path by which future information sneaks into a feature. The classic case is joining a customer’s lifetime default flag onto historical transactions. The model learns the answer, scores beautifully offline, then behaves like a coin flip on live traffic.
• Feature store. A system that computes a feature once and serves the identical logic to both training and real-time scoring. Storage is the least of what it does. The point is to stop the training-serving skew that creeps in when a batch SQL job and a streaming service each compute “average balance over 30 days” in slightly different ways.
• Lineage. The recorded chain from a source record to the value that fed a decision. When a regulator or an internal reviewer asks why an account was flagged in April, lineage is the difference between a two-minute answer and a two-week reconstruction.
• Reconciliation. Confirming that the same quantity reported by two or more systems agrees, and explaining it when it does not. Ledgers, warehouses, and vendor feeds disagree constantly. A model that consumes an unreconciled figure inherits the discrepancy without knowing it exists.

Identity, matching, and the messiness of real feeds

Finance data arrives as fragments about the same people and companies from a dozen sources that never agreed on a format.

• Entity resolution. Deciding that “ACME Corp”, “Acme Corporation Ltd”, and a SWIFT counterparty string all refer to one legal entity. It is the load-bearing step under KYC, exposure aggregation, and sanctions screening. Do it too loosely and you merge distinct entities; too tightly and you fragment one customer into five, understating concentration risk.
• Blocking and matching. Blocking narrows billions of possible pairs to plausible candidates; matching scores each candidate pair. The trade-off is explicit. Aggressive blocking is fast but drops true matches, which shows up later as duplicate accounts and missed links between related parties.
• Golden record. The single resolved view of an entity, assembled from the winning matches. It holds up only as well as the survivorship rules that decide which source wins each field, so those rules belong in review, not buried in code.

Decisions, controls, and what happens when they drift

This is where models meet policy, and where the auditors live.

• Straight-through processing (STP). A transaction or case that flows from intake to completion with no human touch. The rate of straight-through processing is the number most operations leaders actually care about, because it maps directly to cost and turnaround. The engineering task is raising it without letting bad cases through the gap.
• Decision engine versus rule engine. A rule engine executes conditions someone wrote down. A decision engine combines rules, model scores, and policy into a single governed outcome with an explanation attached. Most finance teams need the second wrapped around the first, so a model score never becomes an action without a rule and a reason recorded beside it.
• Champion/challenger. Running the current production model (champion) alongside one or more candidates (challengers) on live or shadow traffic, then promoting a challenger only when it beats the champion on agreed metrics. It is how you change a model in a regulated environment without betting the quarter on a hunch.
• Model drift. The gradual divergence between the world the model was trained on and the world it now scores. Data drift is a shift in the inputs; concept drift is a shift in the relationship between inputs and outcome. Fraud patterns move on purpose, so drift monitoring is not optional there.
• Eval set. A held-back, labeled dataset that stands in for the decisions you care about, used to measure a model or an LLM pipeline before and after every change. Without a stable eval set, “the model got better” is an opinion.
• False-positive budget. The volume of wrong alerts a team can absorb per period. In alert triage this governs everything, because recall you cannot staff is not recall.
• Human-in-the-loop. A design where a person reviews, approves, or overrides model output at defined points. In finance the loop is usually mandated for adverse actions and for suspicious-activity decisions, and the interface has to give the reviewer the evidence, not just the verdict.
• SAR. A Suspicious Activity Report, the filing an institution submits to its financial intelligence unit (FinCEN in the United States) when a case warrants it. Automation can assemble and rank the case; the decision to file, and the narrative, stay with a qualified human.
• Audit trail. The immutable record of who or what decided, on which inputs, under which model and policy version, at what time. Treat it as a product feature from day one. Retrofitting it after an examiner asks is the expensive path.

The pattern here rarely changes. The hard engineering is almost never the model itself; it sits in the plumbing underneath. That plumbing keeps time honest and holds identity stable across feeds. It also leaves a defensible record behind every decision the system made on your behalf, which is usually what an examiner asks about first.