A loan risk model in 2026 is not a credit-score lookup with a threshold on it. It is a real-time read of how money actually moves through someone's account, turned into a decision in minutes, that you then have to be able to explain. I have built the systems behind this, and the part people underestimate is never the model. It is everything around it.
Here is the plain version first. Open banking lets a borrower connect their bank account, with consent, so the lender sees the real picture: income landing, rent and Direct Debits going out, what is essential and what is discretionary. From that you compute affordability, the money genuinely left over to service a new repayment, and you decide on the borrower's actual behaviour rather than a thin bureau file that might say very little. It is faster and it reaches people a traditional score misses. It is also a money-moving system that has to be correct, auditable, and defensible, which is where the build gets real.
Vadim building a full-stack loan platform. Watch on Loom if the player does not load.
What the model actually reads now
The shift is what the decision is built from. Instead of asking a bureau for a number, you read the cashflow directly through an aggregator like Plaid or TrueLayer: salary credits and their regularity, rent and loan Direct Debits, the pattern of spending across a few months. From that you derive the numbers that matter, disposable income after committed outflows, how stable the income is, whether the account already runs tight at the end of every month. That is affordability, and affordability is a far better predictor of whether someone repays a small loan than a score built mostly on past borrowing they may not have.
The honest tradeoff is that you have traded a clean, cached number for a live, messy data feed you do not control. Bank connections drop. Category labels are wrong as often as they are right. Two months of data looks different from six. None of that shows up in a demo, and all of it shows up in production, so the ingestion and the categorisation are where the real engineering time goes, not the scoring formula on top.
The match usually comes before the decision
Most borrowers do not arrive at one lender, they arrive at a funnel. The pattern that runs underneath a modern lending marketplace is a soft search first: an eligibility check that does not touch the borrower's credit file and so leaves no footprint, run against a panel of lenders' criteria, returning the offers they are actually likely to get. Only when they pick one does a hard check happen. I have built the real-time matching layer for a high-volume lending marketplace, and the lesson is that this routing is its own product. You are ranking lenders per applicant on who is most likely to approve and fund, under rules that change constantly, and the whole thing has to answer in the time it takes a page to load.
Keep the soft-search and hard-check stages strictly separate in the architecture, because confusing the two is how you accidentally leave a credit-file footprint you promised the borrower you would not, which is both a trust problem and a compliance one.
The decision is a state machine, not a number
This is the part teams underestimate, and it is the part I lead with now. A loan is not approved or declined, it moves through states: applied, matched, decisioned, approved or declined, funded, repaying, then closed, settled, or in arrears, with side branches for appeal, reschedule, and forbearance. A regulated onboarding and lending flow has more state branches than most entire applications, and if that graph lives implicitly inside your application code it becomes unmaintainable the first time a borrower asks to reschedule a payment mid-loan. I have built a lending platform around an explicit apply-to-repay state machine for exactly this reason. The state graph matters more than the scoring model, because the model is a function you can swap and the state machine is the thing that has to never lose a loan.
Two rules hold it together. A decision, once made, is a record you keep, not a value you overwrite, so you can always reconstruct what data the model saw and why it decided what it did. And every money event, the disbursement that funds the loan and each repayment that comes back, runs through the same webhook discipline as any payment system, so a retried or duplicated event never funds a borrower twice or double-collects a repayment. That disbursement and repayment correctness is its own discipline, and we take it apart in the reconciliation piece.
You will have to explain the decline
An open-banking model that approves people quickly is only half a system. The other half is that when you decline someone, you have to be able to say why, in terms a regulator and the borrower can both follow. That means the decision record has to carry the factors that drove it, not just the outcome, so an adverse-action explanation is a query rather than a guess. Build the model as an opaque box that emits yes or no and you have built something you cannot defend the first time someone asks you to justify a no, and in regulated lending someone always does.
This is also where you have to be careful with the marketing claims. Reading real cashflow genuinely reaches borrowers a thin bureau file misses, and that is a real strength worth building toward. It is not a magic key that makes anyone creditworthy, and it does not remove the lender's obligation to lend responsibly. The engineering supports a better decision. It does not replace the judgement and the compliance around it. The rules that shape all of this, on both sides of the Atlantic, are their own topic in the loan-app guide.
Where the build actually gets hard
If you take one thing from this, make it the order of difficulty. The risk model is the part everyone focuses on and the part that is least likely to sink you. What sinks lending products is the state machine that loses track of a loan, the duplicated disbursement, the bank feed that silently went stale and quietly degraded every decision after it, and the decline you cannot explain. Get those right and you can change the model whenever a better one comes along. Get them wrong and the best model in the world is sitting on a system you cannot trust.
What 2muchcoffee covers
We build lending products end to end, the open-banking ingestion, the real-time matching, the decision engine and its audit trail, and the money-movement correctness underneath disbursement and repayment. If you are building underwriting on cashflow data and the hard questions are starting to be about the state machine and the audit trail rather than the model, that is the right time and the conversation we have. The plain way in is the engineering work we do.
