The Data Layer: Attributes, and Why Yours Don’t Match Theirs | HL Hunt
The Data Layer: Attributes, and Why Yours Don't Match Theirs
Models don't consume credit reports. They consume attributes — counts, balances, ratios, and intervals computed from the raw data by somebody who made a series of decisions about what to include. Which account types count. Whether closed accounts do. What window applies. What value comes back when there's nothing to count. Two attributes with the same name from two sources routinely encode different answers to all four, which is why a model that performed well on one feed can degrade on another that looks identical. This is the layer beneath everything else, and it's the one nobody documents.
What you'll learn
What an attribute is
A value computed from raw report data. "Number of accounts 30 or more days past due in the last 24 months" is an attribute; the underlying tradelines are the raw data.
Every attribute embeds decisions, and the name conveys none of them:
- Which account types count — revolving, instalment, mortgage, collections, all of them?
- Whether closed accounts are included.
- Whether disputed accounts are included, excluded, or flagged.
- What lookback window applies, and from what reference date.
- How to treat authorized user accounts.
- What value to return when there's nothing to count.
- How to handle ambiguous or conflicting underlying records.
Each decision is defensible; each produces a different number. Which means a model is only as reproducible as its attribute definitions, and per our validation analysis, a validation that can't obtain them can't complete the variable review.
Where definitions diverge
Take an attribute two sources both call something like "delinquent accounts." Ways they can differ:
| Decision | Source A | Source B |
|---|---|---|
| Closed accounts | Included | Excluded |
| Currently vs ever | Ever delinquent in window | Currently delinquent |
| Window | 24 months | 12 months |
| Disputed accounts | Included | Excluded |
| Authorized user | Counted | Not counted |
| No accounts at all | Returns 0 | Returns a sentinel |
Two of these six can reverse the sign of a relationship. "Ever delinquent" and "currently delinquent" measure different things about a person, and a model trained on one and scored on the other will misrank systematically.
The last row is the most damaging and gets its own section below.
The operational rule: obtain the written definition of every attribute you use, and don't infer it from the name. Where a vendor won't supply definitions, per our vendor analysis you're being asked to accept obligations you can't discharge — and here the obligation is being able to explain a decision that turned on a number you can't define.
The blank value problem
The single most consequential attribute-layer failure, and it connects directly to our missing data analysis.
What does an attribute return when there's nothing to compute? "Months since most recent delinquency" for someone who has never been delinquent has no natural value. Sources handle it differently:
- A sentinel value like 999 or −1, meaning "not applicable."
- Zero, which is catastrophically wrong here — zero months since a delinquency means one just happened.
- A null, requiring downstream handling.
- A different sentinel for "no data" than for "not applicable", which is the correct approach and the least common.
If a sentinel is treated as a number, the model learns from a value that doesn't mean what it appears to. Someone with no delinquencies coded as 999 will be treated as extremely low risk on that dimension — which happens to be right by accident — while someone coded as 0 will be treated as extremely high risk, which is catastrophically wrong for a person with a clean file.
What to do:
- Obtain the sentinel convention for every attribute.
- Distinguish "not applicable" from "no data" — these are different states and per our missing data analysis they carry different information.
- Never let a sentinel enter a model as a number.
- Add missing indicators rather than substituting values.
- Check reason codes trace to observed values, per our explainability analysis — a reason code derived from a sentinel describes a fact the applicant never had.
Silent changes
The most common data problem in production, and the reason distribution monitoring exists.
A source changes something and the attribute keeps arriving with the same name. What changes:
- A definition is revised — a window, an inclusion rule.
- Coverage shifts as furnishers are added or stop reporting.
- Encoding changes — a new sentinel, a different null convention.
- Upstream reporting practice changes, which alters what's in the raw data.
- A regulatory change alters what may be reported, which per our reporting analysis can remove a category entirely.
- A vendor migrates infrastructure and something subtly differs.
Why these are dangerous: model performance degrades slowly while the distribution shifts immediately. An operation monitoring only outcomes discovers the problem in loss numbers months later, by which point every decision in between was made on corrupted input.
Which is the argument for the checks below and for the input monitoring in our monitoring guide. Inputs are the early warning; outcomes are the post-mortem.
Checks that catch it
Run on every batch, automatically:
- Missing rate per attribute against its historical level. A jump is the most reliable signal a feed has changed, and it's trivial to compute.
- Distribution comparison — mean, percentiles, and shape against a baseline.
- Range checks. Values outside plausible bounds indicate an encoding change.
- Sentinel frequency, watching for new sentinel values appearing.
- Cross-attribute consistency. Attributes that should agree — total accounts against the sum of account types — catch construction errors nothing else does.
- Record-level completeness, since a partial file can produce plausible-looking but wrong attributes.
- Population stability on the score, which aggregates everything upstream.
- Alerting with thresholds, since a check nobody looks at is not a check.
The cross-attribute consistency check is underused and unusually powerful. Internal contradictions in a record are impossible under correct construction, so any occurrence is a definite fault rather than a statistical anomaly — no judgment required about whether a shift is meaningful.
And a check worth running once per source: pull the same records from two sources and compare like-named attributes. The differences are informative and most teams have never looked.
How current the data is
Systematically overestimated, with consequences for any decision sensitive to recent change.
The lags:
- Furnishers report on cycles, so an event waits for the next report.
- Balances reflect statement dates, not the present — per our score guide, a paid-down balance may not show for weeks.
- Processing and availability add further delay.
- Your own refresh cadence adds more, on anything not pulled fresh.
Consequences worth designing around:
- "Current balance" means recent past balance, at varying ages per account.
- Recent events may be absent. An applicant who defaulted three weeks ago may show clean.
- Attributes counting recent inquiries may miss the most recent — which matters for detecting a shopping spree across lenders.
- Portfolio refresh cadence determines how stale account review data is, which per our line management analysis affects decisions made on it.
Establish the actual lag for your sources and attributes rather than assuming currency, and let it inform which decisions can rely on the data. A decision requiring genuine currency needs a different input, not a faster pull of the same one.
Trended attributes
Attributes summarizing behaviour over time rather than at a point — the direction of a balance, payment patterns, utilization trajectory.
Why they're valuable: a point-in-time balance can't distinguish someone paying down from someone building up. Two identical utilization figures moving in opposite directions carry different information, and only trended data sees it.
What to check before relying on them:
- History depth, and what happens when a file has less than the window requires.
- Coverage — not all furnishers supply the underlying history, so a trended attribute may be computed on a subset.
- How gaps are handled when a month is missing.
- Whether the attribute is stable across the period, since underlying reporting practice changed over the same years.
- Thin-file behaviour, since trended attributes are least available exactly where per our thin-file analysis extra information would help most.
That last point is worth weighing. Trended attributes add most to files that already have plenty of data and least to files that don't — so they improve discrimination in the population you already assess well, which is a real gain and not the one usually claimed for them.
Versioning and governance
The discipline that makes the layer manageable:
- Maintain a dictionary — every attribute, its definition, source, sentinel convention, and where it's used.
- Version definitions alongside models, so a model is reproducible only if the inputs are pinned too.
- Record which model version used which attribute version.
- Treat a definition change as a model change, requiring the same review — this is the governance gap most operations have, since attribute changes arrive through a vendor relationship rather than through model risk.
- Contract for notice of definition and coverage changes.
- Retain historical attribute values, since you can't reconstruct what a model saw without them.
- Include the attribute layer in validation, per our validation analysis.
- Review annually, including attributes nobody uses any more.
Item four carries the most risk reduction. An operation with rigorous model governance and no attribute governance has controlled the visible layer and left the one underneath it uncontrolled — and changes to that layer alter every model's behaviour simultaneously, without triggering any review.
Know what every number in the decision means
HL Hunt AI Underwriting maintains versioned attribute definitions with documented sentinel conventions, runs distribution and consistency checks on every batch, and traces reason codes to observed values rather than substituted ones.
Frequently asked questions
A value computed from raw report data — a count, balance, ratio, or interval. Models consume attributes rather than reports, so every model rests on somebody's summarization decisions.
The name describes intent, not construction. Closed accounts, windows, disputed accounts, and blank handling all vary, and each choice produces a different number.
A feed changing silently. Performance degrades slowly while distributions shift immediately, so monitoring inputs catches it and monitoring outcomes doesn't.
Less than assumed — reporting cycles, statement dates, and refresh cadence mean an attribute describes the recent past at varying ages per account.
Key takeaways
- Attributes embed decisions the name doesn't convey, so obtain written definitions rather than inferring from labels.
- Sentinel values entering a model as numbers is the most damaging failure in this layer, and reason codes inherit it.
- Distinguish "not applicable" from "no data" — they're different states carrying different information.
- Monitor input distributions and missing rates; performance degrades slowly while distributions shift immediately.
- Cross-attribute consistency checks catch definite faults rather than statistical anomalies, requiring no judgment.
- Treat a definition change as a model change — attribute governance is the gap in otherwise rigorous model risk programs.
Governed inputs, not just governed models
Get started with HL Hunt AI Underwriting for a versioned attribute dictionary, automated data quality checks on every batch, and full traceability from decision to source value.
This guide is educational and does not constitute legal or compliance advice. Attribute definitions, sentinel conventions, coverage, and refresh timing vary by bureau and vendor and change over time; the examples here are illustrative rather than descriptions of any particular source. Permissible use, accuracy obligations, and model risk requirements apply to the data layer as fully as to models. Consult qualified counsel and your data providers.