Most SME lending declines that I have looked at closely were not risk decisions. They were data decisions wearing a risk decision's clothes.
A business applies. The bureau record is thin, because the company is young, or small, or has never borrowed, or operates in a market where bureau coverage is patchy. The model does what it was trained to do with missing inputs, the score lands below the cut, and the application is declined. Nothing in that sequence involved anyone forming a view about whether the business is good.
A design put to a consumer and SME banking group operating across several European markets addresses this directly. Among three lending use cases in a board workshop deliverable, one covers enhanced underwriting for complex cases, and its content is an assembly instruction: analyse alternative, non-traditional data for thin-file clients, integrate the bank's own data, bureau feeds and public information, and pre-populate the credit memo for underwriter review.
Nothing here had been built when the document was written. The autonomy level and the stated outcomes are design commitments in a proposal, and should be read that way.
What a thin file actually is
The phrase makes it sound like a degraded version of a normal file. It is not. It is a file that has never been written, and the distinction matters because it determines what a model can legitimately conclude.
A business with a poor bureau record has demonstrated something. Missed payments, defaults, judgments: the record is evidence, and pricing it is what credit risk is for. A business with no bureau record has demonstrated nothing at all, and a scorecard that maps that emptiness onto the same output as bad history is not measuring risk. It is measuring how long the applicant has been visible to a particular reporting infrastructure.
Across the markets this group operates in, that visibility varies a great deal by country and by company age, which means the population being systematically declined is not randomly distributed. It skews young and it skews toward the smaller end. That is a commercial problem before it is anything else.
A thin file is not a bad file. It is an empty one, and a model that treats absence of evidence as evidence of risk will decline a profitable book it never learns anything about.
Why four sources rather than a better model
The instinct when a model performs badly on a segment is to improve the model. For thin files that instinct is wrong, because no amount of modelling recovers information that is not in the inputs. The design's answer is to change what the model can see.
The bank's own data is the source most often left out, which is the strange part. An SME applicant is frequently already a customer with an operating account, and that account records payment behaviour, cash flow seasonality, counterparty concentration and balance discipline in far more detail than a bureau summary. The bank is sitting on a richer record than the one it is declining people against.
Bureau feeds stay in. This is not a proposal to replace credit reference data. Where the record exists it is the strongest single signal and it is doing real work.
Public information covers filings, registrations, and the ordinary registry footprint of a trading company. Thin on its own, useful as corroboration, and it establishes that the business is what it says it is.
Non-traditional data is the loosest of the four and the one that needs the most governance. It is also where the genuinely new signal for a young company lives, since a business with two years of trading and no borrowing history has left traces somewhere other than a bureau.
The assembly is the point. Any one of these, alone, is a worse basis for a decision than the bureau record. Together they describe a business that the bureau record does not describe at all.
Inclusion written next to efficiency
The strategic framing in the deck puts two things side by side: a reduction in manual data entry, and serving thin-file SMEs effectively. The first is the usual argument. The second is the one worth noticing, because it changes what the business case is.
An efficiency case says you will do the same lending with fewer people. It is easy to write, easy to approve, and its ceiling is your current cost base. An inclusion case says you will do lending you are not doing now, to businesses you are currently turning away for reasons unrelated to their quality. Its ceiling is the size of the segment.
Those are different investments with different risk profiles, and putting them on one page is honest in a way that pure-efficiency automation cases usually are not. It also creates an obligation the deck does not follow through on: if the argument for the programme is that a new population gets served, then the number that proves it is approvals in that population, tracked separately, with their performance followed long enough to know whether the lending was any good. An efficiency metric will not show it, and an aggregate approval rate will hide it.
Where this gets dangerous
Two risks, and they run in opposite directions.
The obvious one is fairness. Alternative data can encode things a credit decision must not turn on, and it does so without anyone choosing it. Any assembly of this kind needs the decisions it produces tested on the way out, not just the inputs vetted on the way in. The same programme instruments its approval gate for exactly this reason, with an override ceiling and a fairness ratio computed on what the gate lets through, and that work is described in How to Put an Override Rate on the Approval Gate So an Auditor Can Test It.
The less obvious one is that you now have no baseline. If the segment was previously declined near-automatically, you have almost no performance history for it. You are lending into a population your models have never observed repaying, and early performance will look better than the truth because the first cohort through a new channel is usually not representative. Size the initial exposure on the assumption that you are wrong, and get a full cycle of performance before you scale.
What I would ask
How much of your decline volume is thin file. If nobody can answer, that is the first piece of work, and it is a query rather than a programme.
Does your scorecard distinguish absent from adverse. Many do not, and it is worth knowing before you build anything on top.
Which of the four sources do you already hold. The bank's own account data usually needs no acquisition, only permission and plumbing, and it is the strongest of the three that are not the bureau.
How will approvals in this population be tracked separately. If the answer is that they roll into the aggregate, the inclusion half of the case cannot be proven and will quietly become an efficiency programme.
The pattern generalises past lending. Wherever a decision system has been trained on a population, the people it cannot see are not being assessed and rejected. They are being skipped, and the system reports that as a clean run.
Drawn from one slide of a board-level AI transformation deliverable for a consumer and SME banking group operating across several European markets, covering three lending and SME use cases at a stated autonomy level. Nothing described had been built when the document was written: the stated outcomes and the autonomy level are design commitments rather than results, and no approval or performance figure is claimed here. The approval-gate instrumentation from the same programme is a separate published piece, linked above. The reading of a thin file as an absence problem rather than a risk problem, and everything said about baselines and tracking, is ours.
“A thin file is not a bad file. It is an empty one, and a model that treats absence of evidence as evidence of risk will decline a profitable book it never learns anything about.”
Get in touch
Put RealAI’s applied-AI team on your hardest data problem.
We help enterprises move from pilots to production: sovereign models, governed data, and agents you can audit. Start with a value-first assessment.