.svg)
On 14 November 2024 the Financial Stability Board, the body in Basel that coordinates financial regulators across 24 jurisdictions, published a stocktake of how AI is actually being used in finance. Firms had concentrated it on internal operations and regulatory compliance. Revenue-generating uses were limited. Lending decisions are revenue generation, and that's the part of the bank where AI still mostly hasn't landed, for reasons that sit underneath the model rather than inside it, in what the digital lending platform records about the loans it already services.
The attrition rate is documented. MIT's 2025 work on custom enterprise AI tools found that 60% of organisations evaluated them, 20% ran a pilot and 5% reached production. Deloitte's 2026 Banking and Capital Markets Outlook puts the stall inside banks down to fragmented data foundations, ageing core systems and governance built for a different kind of model. Neither finding is about mathematics.
What a credit model needs isn't mysterious: a large number of labelled outcomes, at fine grain, from borrowers the lender actually served. A conventional scorecard reads a few dozen variables, most of them derived from a credit bureau file, which is the summary of a borrower's repayment history that bureaus compile and sell to lenders. A machine learning model can read thousands, and the ones that add predictive value tend to be behavioural, drawn from how borrowers repaid rather than from what a bureau summarised about them. Lenders built around models from the start accumulate that history with every loan they write, and the effect compounds. A bank that has been lending for thirty years holds far more borrower history than any of them, and usually can't use it, because of how it was stored: monthly balance snapshots rather than events, core systems migrated twice over where the reason for a reschedule lives in a free-text comment, bureau reports discarded once the decision was made.
Your digital lending platform is the training set
A model learns from what happened, at the grain it was recorded. Take a USD 15,000 personal loan over 36 months. Recorded well, it leaves 36 scheduled instalments, each with a due date, a received date, an amount and a channel, plus the two partial payments, the fee a branch manager waived in month nine, the reschedule in month fourteen and the reason given for it, the days past due at every point, and the recovery that landed 20 months after the loan was written off. Recorded the way many core systems record it, that same loan leaves one row: closed, paid in full. Only the first version teaches a model anything.
This is loan account management doing double duty. Repayment scheduling, interest accrual, fee calculation, rescheduling and collections activity all generate events, and those events are the labels a model trains on. Institutions that keep them at event level, with reason codes attached, end up holding a dataset no vendor can sell them, because it describes their own borrowers under their own policies.
Write the decision down as you make it
Almost every consumer credit regime requires a lender to tell a declined applicant why, in terms specific enough to act on. In the US it takes the form of an adverse action notice setting out the principal reasons. In Europe it comes through data protection rules governing decisions made by automated means. Regulators across Asia and the Gulf have issued their own versions, and supervisors everywhere have said in some form that a model nobody can explain doesn't discharge the duty.
Meeting it is a matter of persisting a handful of fields while the decision is being made. Automated credit decisioning should store, against the application record, the model version that scored it, the feature values as they stood at that timestamp, the bureau report and the time it was pulled, the score, the ranked reason codes, the policy rules that fired, and any human override with its stated justification. Institutions that treat this as an analytics problem, exported to a warehouse and reassembled by a data team a quarter later, can't answer a question about one applicant from February without opening a project.
The same record does the prudential work. Model risk expectations across the major supervisory regimes come down to three things: documented development, independent validation by someone who didn't build the model, and ongoing monitoring once it's live. All three need production decisions logged with the inputs they saw, rather than a development notebook and a summary deck. A lender operating in several markets gets more out of this than a single-market lender, since one decision record answers whichever local duty applies.
Overrides are the most valuable data you hold
Underwriters stay in the loop for years after a first model goes live, which makes the override a recurring event worth capturing properly: what the model said, what the underwriter did instead, the reason they gave, and how that loan performed afterwards. Run through email and case notes, that judgement never becomes training data, and the second model gets built on the same thin history as the first.
Start where the returns are already provable
Document extraction pays quickly because it sits beside work that's still manual: statements, payslips and trade licences parsed into structured fields on the online loan application, with income verified from transaction narratives rather than typed in twice. Collections and recovery is the other near-term case, ranking accounts by predicted responsiveness and timing contact accordingly instead of running one reminder cadence across the whole book. Both produce savings inside a quarter, and both generate labelled data the underwriting model will want later: which documents parsed cleanly, which nudge preceded a payment, which borrower answered on the second attempt. Fair treatment duties cover how a lender handles a borrower in arrears as well as how it decides an application, so those treatment decisions want logging on the same terms as a decline.
Production means you can change the model on a Tuesday
A model in production needs a retraining cadence, a champion and a challenger running side by side, and a shadow mode where the new version scores live applications without deciding them, so both outputs can be compared against real outcomes. Deploying a new version should be a configuration change. Where it needs a release cycle on the core system, the model ages in place and its accuracy decays with the market it was trained on.
Latency belongs in the same conversation. Real-time decisioning needs features computed from current balances, so a lender scoring an applicant against last night's batch is approving a limit against money that has already been spent.
The question, when it comes, will be about one applicant on one day: what the model saw, which version scored it, which reasons went on the notice, who overrode it and why. None of that can be reconstructed two years later if nobody wrote it down while the loan was being serviced.
