A stranger hands you their bank account. Salary landing, rent going out, the subscriptions they forgot about, all of it, in exchange for an answer in minutes: yes or no, and how much. Months later a regulator can ask why that answer was no, and "the model said so" is not an accepted reply. That is what a loan risk model is in 2026. Not a credit-score lookup with a threshold on it, but a real-time read of how money actually moves through someone's account, turned into a decision you have to be able to defend. I have built the systems behind this, and the part people underestimate is never the model. It is everything around it, and by the end of this piece you will see why the model is the part least likely to sink you.
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.
The model now reads the account, not the score
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 what matters, 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 it predicts whether someone repays a small loan far better than a score built mostly on past borrowing they may not have.
The evidence has caught up with the intuition. FinRegLab's July 2025 study found its two strongest machine-learning models on cashflow data approved about 4 percent more borrowers than similar models on simpler analytics, without approving more people who went on to struggle: at mainstream cutoffs, roughly two million more credit card accounts and 152,000 mortgages a year. The buy side voted too. Chase picked Nova Credit's Cash Atlas in September 2025, FICO and Plaid announced a Cash Flow UltraFICO Score that November, and by April 2026 Fannie Mae, Freddie Mac, and FHA were accepting the FHFA-validated VantageScore 4.0. Underwriting on the account has stopped being experimental.
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 ingestion and categorisation are where the real engineering time goes, not the scoring formula on top.
That feed is also no longer free. In June 2025 JPMorgan began charging data aggregators for API access to consumer accounts, and by November its paid contracts covered more than 95 percent of its open-banking data requests, with CNBC estimating Plaid's bill alone could reach some 300 million dollars a year. The input you do not control now carries a unit cost as well as a correctness burden.
The match usually comes before the decision
Most borrowers do not arrive at one lender, they arrive at a funnel. Underneath a modern lending marketplace is a soft search first: an eligibility check that never touches the borrower's credit file, 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. Credit decisioning is a system, not a score. 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. That correctness is its own discipline, and we take it apart in the reconciliation piece.
A decision, once made, is a record you keep, not a value you overwrite.
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 say why, in terms a regulator and the borrower can both follow. So the decision record has to carry the factors that drove it, not just the outcome, which makes an adverse-action explanation a query rather than a guess. Build the model as an opaque box that emits yes or no and you have something you cannot defend the first time someone asks you to justify a no, and in regulated lending someone always does.
The regulator has already answered the obvious objection. The CFPB's Circular 2022-03 says plainly that using a complex, black-box algorithm does not excuse a lender from giving specific, accurate reasons for an adverse action. Explainability is not a courtesy layered on top of the model. It is a legal property the decision record has to carry, designed in from the first schema.
Be careful with the marketing claims here. Reading real cashflow does reach borrowers a thin bureau file misses, but it makes nobody creditworthy and it removes none of the lender's obligation to lend responsibly. The engineering supports a better decision; it does not replace the judgement 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.
That first decision is only half the relationship. How a lender scores behaviour across repeat loans, and the event model that keeps that number explainable, is covered in alternative credit scoring, explained.
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 under disbursement and repayment. If your hard questions have become the state machine and the audit trail rather than the model, that is the conversation we have. The plain way in is the engineering work we do.
One concrete action
Pull one real decline from last quarter and try to write its adverse-action explanation from your stored decision record alone: the data the model saw, the factors that drove the no, in words the borrower and a regulator can both follow. If you can do it as a query, your decision layer is sound. If you find yourself re-running the model to guess at why, you have found the gap to close first, and it is far cheaper to close now than the first time someone asks.
