The records a lender fails to keep at launch cannot be rebuilt later, so decisions, offers, declines and repayment events should be stored exactly as they happened from the first loan.
In short
A credit model can only learn from what a lender recorded at the time. The cheapest moment to capture it is the first day.
A credit model learns from history, and a lender’s history cannot be recreated after the fact. Teams that start building a model often find that key fields were overwritten, were never stored or cannot be linked to repayment outcomes.
The cost of capturing the right records at launch is small. The cost of discovering a year later that the first 5,000 loans cannot be used is much larger, because those early loans often carry the most useful signal about how a new product behaves.
Data capture is part of credit strategy, not just an IT task. It decides how quickly a lender can move from a generic score to a model built around its own customers.
Think of each decision as a record that could be replayed. For every application, some data to consider capturing include:
With this in place, a lender can later ask what a new model would have done on the same applicants, and trust the answer.
Many systems keep one current value for each field and overwrite it when something changes. That is convenient for operations and damaging for modeling.
Take a customer whose income field is updated after they stop repaying. A model trained on the updated value will appear to “see” something the lender could not have known at decision time. This is known as leakage. It inflates accuracy in testing and disappoints in production.
The fix is simple in principle. Append new records instead of overwriting old ones, and timestamp everything. A lender can always build the latest view from a history. It cannot rebuild a history from the latest view.
Declined applicants never produce repayment outcomes, so they are easy to ignore. They are still valuable. Recording them lets a lender measure approval rates over time, test a second-look strategy in shadow mode, and estimate how many good borrowers its policy may be turning away. Lenders should be careful, though. Methods that infer the outcomes of declined applicants are approximate, so they support exploration rather than certainty. Our guide to introducing a new risk signal without breaking governance explains how shadow testing works.
Offers matter for a similar reason. For every offer, record the amount, term, price and fees, and whether the customer accepted. Without records of what customers declined, a lender cannot learn how sensitive its borrowers are to price and limit. That sensitivity is the input to offer optimization, which we discuss in risk-based pricing vs limits.
A lender can only use data it has permission to use, and it must be able to prove it. For every data source, record what consent was given, when, in which version of the consent wording, and which uses it covers, such as underwriting, monitoring and model development.
Record whether data can be shared with partners and how long it can be kept. Without this, a lender may hold years of data that it cannot legally or contractually use to train a model. Partners and regulators will also ask for it, as we cover in our article on preparing lending operations for AI integration.
These steps are not glamorous, but they can help decide how much time a modeling team spends on analysis and how much on cleaning.
If a lender has already launched without this, you can still start now what matters most: decision snapshots, offers, repayment events and consent records. Audit what already exists, backfill where it is reliable, and be honest about which periods cannot be used.
A new lender will not have many outcomes yet. In the meantime, a standardized score such as Cashflow Score, which is based only on account and transaction data, can give a risk signal before the lender’s own history builds up. As outcomes accumulate, a custom Credit Risk Model can learn from the lender’s own data. It can use any appropriate combination of transaction, bureau, application and internal performance data, and no single source is required. Once there is a probability of default and acceptance data, the Credit Offer Engine can use them to recommend how much to lend and at what price within the lender’s policy limits.
The quickest test is to ask whether you could replay last quarter’s decisions and link each one to its outcome. If the answer is partly or not yet, the next step is to decide what to capture and what the current data can already support.
If you want to talk through what your existing data could support and what to start capturing now, book a call with the Carrington Labs team.
