Credit risk reporting that survives the questions after it
A regulator, a funder and an auditor each ask a different question about the same number. What it takes to answer all three without a spreadsheet in the middle.
There is a moment in every funder diligence process where someone asks how a number was produced. Not whether it is right — how it was produced. Which system it came from, what was excluded, who checked it, and whether the same query run today would give the same answer.
If the honest reply involves a spreadsheet, an export and a person who is on leave, the conversation changes. Not because the number is wrong, but because it is now unverifiable, and unverifiable is treated as wrong by anyone with a fiduciary duty.
This piece is about what it takes for the answer to be boring.
Three audiences, three questions#
The same reported figure gets interrogated three different ways, and reporting built for only one of them fails the other two.
The regulator asks whether it is consistent. Does this month's definition match last month's? If a number moved, did the business move or did the definition? Consistency over time matters more to a supervisor than precision at a point in time.
The funder asks whether it is comparable. Does your ninety-days-past-due mean what it means at the other lenders in their portfolio? Can they compare your vintage curves to somebody else's without adjusting? They will build their own view from your raw tape regardless — the reporting exists to tell them whether to trust the tape.
The auditor asks whether it is traceable. Can you get from this figure back to the underlying records, through every transformation, without a manual step? Reproducibility is the whole question.
One reporting stack can serve all three, but only if it is built with traceability as the primary requirement rather than as documentation added afterwards.
Lineage is a build decision, not a document#
Most lineage documentation is written after the fact by someone reading the code. It is accurate on the day it is written and drifts from then on.
Lineage that holds up has four properties, and each one is a choice you make while building rather than something you can bolt on:
Every figure is reproducible from an immutable source. Land raw source data unchanged and keep it. Never transform in place. If you overwrite yesterday's extract with today's, you have lost the ability to reproduce yesterday's report, and every downstream explanation becomes a story rather than a demonstration.
Every transformation is in version control. Not in a stored procedure that someone edits directly on the server. Not in a Power Query step inside a workbook. In a repository, with a commit history that shows who changed what and when.
Every reported figure names its definition. The dashboard should be able to tell you which version of the "default" definition it is using and when that definition last changed. This sounds fussy until a supervisor asks why a figure moved eleven percent and the answer is that the definition changed in March.
Every run is logged. Which pipeline ran, over which input, producing which output, at what time, with what row counts. When a figure is queried nine months later, the run log is what turns "I think so" into "yes, here it is".
None of this is exotic. All of it is much cheaper to do from the start than to retrofit.
The reconciliation nobody wants to build#
Between your risk reporting and your general ledger there is a gap. There is always a gap. Timing differences, write-off treatment, foreign exchange, interest accruals, provisions posted at a different grain.
The instinct is to explain the gap when asked. The better approach is to report it every month, as a standing line item, with each component named.
A monthly reconciliation that says the gap is 0.4 percent and consists of four known components is a control. The same gap, unreported until someone finds it, is a finding.
Building it is unglamorous and takes a few weeks. It is the single highest-return thing we have built for lending clients, measured by how much easier it makes every subsequent conversation with a funder or auditor.
Monitoring the scorecard, not just the outcome#
Portfolio performance tells you what happened. Scorecard monitoring tells you what is about to happen, and it is routinely the weakest part of a lender's reporting.
The minimum set:
- Population stability index on the score distribution, month on month, and on each significant input feature. A PSI above 0.25 on the overall distribution is a stop-and-look; on an individual feature it usually means a source system changed.
- Characteristic analysis — for each feature, the shift in distribution and the resulting shift in average score. This is what tells you why the PSI moved.
- Back-testing — predicted bad rate against actual bad rate by score band, for each cohort with enough seasoning.
- Override tracking — how often manual decisions overrule the model, in which direction, by which team, and how those cases performed. Unmonitored override rates are where good models quietly stop being used.
- Reject inference sanity checks — some view of what happened to applicants you declined, where you can get it.
The mistake we see most often is monitoring these annually, in a model validation document, rather than monthly on a dashboard. A scorecard degrades continuously. Annual validation finds out about it up to eleven months late.
Segregate the environments, properly#
Regulated data reporting has a boring operational requirement that is easy to get wrong and expensive to fix.
Lower environments should not contain live personal data. Not masked-on-read, not "only the test subset" — genuinely pseudonymised or synthetic. The moment a developer needs production data to reproduce a bug, you have a process problem and a data protection problem at the same time.
The practical version: pseudonymise on the way in, keep the mapping in a separate controlled store that almost nobody can reach, and make sure your synthetic data preserves the distributions your logic depends on. Synthetic data that is uniformly random will pass your tests and hide every bug that matters.
What good looks like#
A lender with credit risk reporting that survives scrutiny can do these things without warning:
- Reproduce any reported figure from any prior month, from source, without manual intervention
- Show which version of which definition produced it
- Explain the gap to the general ledger, by component
- Show the scorecard's stability over the last twelve months
- Name the person who signed off each reported figure and when
None of these are analytics achievements. They are engineering and governance achievements that happen to be delivered through analytics. That is usually why they do not get built — they sit between two teams, and neither team's roadmap has them on it.
They are also, almost without exception, the things that decide how a diligence process goes.
Reporting held together by one person and a macro?
The Risk & Regulatory Pod rebuilds credit risk, collections and supervisory reporting with lineage behind every figure. Gap assessment inside ten days.