Model cards that actually help finance governance

A useful model card answers one question for whoever reviews the model: can I approve this, and what am I approving? It states what the model decides, what data it learned from, how it was measured, where it fails, and who answers when it does. The test is whether a validator who has never met the team can act on it alone.

Most model cards fail that test. They read like a data-sheet crossed with a press release: architecture diagrams, an accuracy number with no denominator, a paragraph about how the model was built with care. A reviewer cannot do anything with that. They cannot tell whether the training data leaked information the model would not have at inference, whether the reported metric came from a held-out set or the training set, or what happens at quarter-end when volumes spike. The card looks thorough and tells you nothing you could challenge.

Start from the decision, not the architecture

The first thing on the card is what the model is allowed to decide. A label like “transaction monitoring model” is useless here. The card needs the operating boundary: this model scores wire transfers for a sanctions review queue, it does not block payments, and a human clears every alert before release. That sentence sets the entire risk profile. A model that ranks cases for human review carries very different exposure than one wired into straight-through processing, and a reviewer needs to know which they are looking at before they read another line.

Alongside the decision, name the population. A credit model built and tuned on prime borrowers behaves unpredictably on thin-file applicants, and the card should say so plainly rather than leave the reader to discover it in production. We put three things here:

• The intended use and the intended population, in one paragraph each.
• The out-of-scope uses, stated as prohibitions, because someone will eventually try to reuse the model for something it was never measured on.
• The decision owner, meaning the person in the business who answers for the outcome, not the team that trained it.

That last line matters more than it looks. When a model produces a bad outcome, the question is who owned the decision. If the card cannot name them, the governance around the model is already broken.

Data provenance is where the honest work shows

This is the section that separates a card written for a reviewer from one written to look complete. A reviewer of a finance model does not trust a metric until they trust the data behind it, and most of the ways these models go wrong are data problems wearing a modeling costume.

Point-in-time correctness comes first. For any feature derived from a time series, the card states the timestamp the feature was computed as-of, and confirms that no value from after the label date entered training. Lookahead leakage is the most common defect we find in finance models and the most flattering, because it makes offline metrics look excellent right up until the model meets live data. If the card cannot demonstrate point-in-time construction, the eval numbers below it are not worth reading.

Then lineage. Each feature should trace to a source system and a transformation, ideally through a feature store rather than a notebook nobody can rerun. We list, per feature group, where it came from, how it was reconciled against the system of record, and what entity resolution rule joined records across sources. Entity resolution deserves its own line because a join that silently drops or duplicates entities will bias a model in ways no aggregate metric surfaces. The card should also record which fields were reconciled and which were taken on faith, since a figure that three upstream systems report three different ways is a figure the reviewer will want to ask about.

• Source system and extraction date for each feature group.
• The as-of logic proving point-in-time correctness.
• Entity resolution and reconciliation rules, including known gaps.
• Label definition, plus how labels were verified rather than merely pulled.

Metrics a reviewer can argue with

An accuracy number without a denominator is not evidence. The metrics section names the eval set, its size, its time range, and how it was held out, then reports performance in the units the business cares about. For an alerting model that means the false-positive budget: at the operating threshold, how many alerts per thousand transactions, how many of those are cleared as noise, and what analyst load that implies. A reviewer signing off on a monitoring model is signing off on that workload as much as on the detection rate.

One aggregate number hides too much. Slice by the segments that matter in finance: product, channel, geography, customer tenure, transaction size. A model that is strong overall and weak on new customers carries a specific, nameable risk, and the card should put that risk on its face rather than let a validator find it three months in. We also state the threshold and the reasoning behind it. A threshold is a policy choice about the false-positive budget rather than a technical constant, and it belongs in front of the person who owns the tradeoff.

Failure modes, drift, and the audit trail

The last section is the one teams most want to skip and reviewers most want to read. Write down how the model fails, in concrete terms. Which inputs push it out of distribution, what it does when a feature is missing or stale, and what the fallback is when it cannot score at all. State the drift signals you monitor and the thresholds that trigger a review, so the card describes a living control rather than a one-time snapshot. A model card that never mentions drift is describing a model on the day it was born, not the one running now.

Finally, the audit trail: the version of the model this card describes, the training data snapshot, the code commit, and the approval record. A card that cannot be tied to a specific deployed version is decoration. Version the card with the artifact, so that when someone asks in a year what was running last quarter-end and why it was approved, the answer is a document, not an archaeology project.