Blog
Why CEOs Should Not Be Their Own Platform Testers
I have sat in enough implementation kickoff calls to recognize a pattern before it becomes a problem. Somewhere around week three, the founder or division head who was supposed to be the point person on the client side starts missing sessions. Not because they stopped caring. Because they are running a business, and the business does not pause for a loan origination software rollout.
The technology is rarely the reason a lending platform implementation stalls. I have watched well-configured systems sit half-finished for months, not because the vendor was slow or the platform was wrong, but because there was no one on the client side who could stay in the weeds of the project long enough to see it through. This is what I have started calling the altitude problem, and once you see it, you notice it in nearly every early-stage lending organization trying to modernize its operations.
The Altitude Problem, Explained
Here is what it looks like in practice. In the morning, the CEO or head of lending is presenting to a board about 2027 financial projections. By midday, that same person is supposed to be testing whether a loan template is configured correctly in the origination platform. By afternoon, they are back in a strategic planning conversation about a new funding source or a regulatory filing. Each of those activities requires a fundamentally different cognitive mode. Strategic thinking is expansive and future-oriented. Configuration testing is granular, detail-obsessed, and requires holding a specification in your head while clicking through screens looking for the place where reality diverges from intention.
Moving between those modes once a day is manageable. Moving between them multiple times a day, for weeks on end, is exhausting in a way that quietly degrades the quality of every activity involved. The board presentation gets a little less sharp. The platform testing gets rushed. The strategic conversation loses the person’s full attention because part of their mind is still wondering whether the underwriting workflow they glanced at an hour ago was actually configured the way they described it to the implementation team.
This is not a discipline problem. It is not that these executives lack rigor. It is that human attention does not switch altitude for free. There is a real cost every time someone moves from thirty-thousand feet to ground level and back, and that cost compounds every time it happens.
What Actually Breaks During Implementation
The consequences of the altitude problem are predictable once you have seen them play out a few times. Testing gets deferred. It is always the item that can wait until tomorrow, and tomorrow has the same conflicts as today, so it keeps sliding. By the time someone finally sits down to test the loan servicing workflow end to end, three other configuration decisions have been built on top of the untested piece, and the rework is far more expensive than it would have been at the start.
Configuration decisions get made quickly, without full consideration of downstream implications. This is one of the more subtle failure modes I see. A busy executive gets asked a question in a working session, something like whether a particular loan product should route through an automated approval path or require manual review above a certain threshold. They answer based on what feels right in the moment, because they do not have the bandwidth to think through how that decision interacts with reporting requirements, servicing workflows, or the audit trail a funder will eventually ask for. Weeks later, that decision surfaces as a problem, and nobody remembers why it was made that way.
Requirements drift. Every lending platform implementation starts with some version of a requirements document, whether formal or informal. As the project evolves, the system that gets built inevitably diverges somewhat from what was originally described. Some of that divergence is healthy, the natural result of learning more as you go. But without someone comparing what is being built against the original specification on a regular basis, the drift accumulates silently. Nobody notices it until go-live, when the system does not quite do what the business needed it to do, and everyone is left arguing about whether that was ever actually a requirement.
And perhaps most damaging, the project starts to feel like it is flying by the seat of its pants. Even if progress is technically happening, the absence of a strategic oversight layer creates a persistent sense that nobody is fully in control of the outcome. That feeling is corrosive to an implementation team’s morale and to the client organization’s confidence in the process.
This Is an Organizational Design Problem
I want to be clear about something. This is not primarily a project management problem, even though it shows up as one. It is an organizational design problem. The implementations that go smoothest, across every specialty lender, CDFI, and commercial lending division I have worked with, share one structural feature. There is a dedicated owner on the client side who is in the weeds alongside the implementation team, catching discrepancies early, making configuration decisions with full context, and maintaining continuity between working sessions.
That person does not need to be a technologist. In fact, some of the best implementation owners I have seen have no technical background at all. What they need is a deep understanding of the lending operation and enough dedicated time to engage with the implementation seriously, week over week, without the competing demands of running the entire organization pulling them away.
For a large bank or a well-capitalized commercial lender, this person usually already exists inside the org chart. It is a project manager, a business analyst, or a head of operations who can be assigned to the implementation as a significant part of their job. They sit in every working session. They keep the requirements document current. They test the workflows as they are built, not weeks later. They are the continuity layer between the vendor’s implementation team and the client’s leadership.
For a startup lending division, a newly formed CDFI, or a specialty finance company being incubated inside a larger organization, that person frequently does not exist. There has not been time to hire for the role, or the organization is lean by design, or the founder assumed they could handle it themselves because they handle everything else. The founder or division head becomes the default owner of the implementation, not because they are the right person for the job, but because there is no one else.
What Actually Works
The practical solutions I have seen work in these situations share a common structural element. They externalize the project oversight function rather than asking the business leader to provide it out of sheer will.
One version of this is engaging a fractional Salesforce implementation partner who understands the lending domain specifically, not just the platform generically. This person or small team plugs into the role that a dedicated internal project owner would otherwise play. They attend the working sessions, they test the configuration as it is built, and they flag when a decision made in isolation is going to create a downstream problem. Because they understand lending operations, they can ask the right clarifying questions without needing the CEO to translate every requirement from business language into technical language.
Another version is a structured managed services engagement with the platform vendor itself. Rather than treating implementation as a one-time project that ends at go-live, the organization treats the first several months of platform use as an ongoing partnership, with the vendor’s team providing continuity that the client organization cannot yet provide internally. This works particularly well for organizations that know they will eventually build out an internal team but are not there yet.
A third version, and one that costs nothing beyond discipline, is a structured project management cadence with weekly accountability against a documented requirements list. Even without a dedicated hire or an external partner, some organizations succeed by treating the requirements document as a living artifact that gets reviewed in the same meeting every week, with someone explicitly assigned to flag drift. This requires more discipline than most fast-growing lending organizations naturally have, which is why it works less consistently than the first two approaches, but I have seen it succeed when the leadership team takes it seriously.
What all three approaches have in common is that they do not depend on the business leader personally absorbing the cognitive cost of switching altitude multiple times a day for the duration of the implementation. They accept that the altitude problem is real and design the project around it, rather than hoping sheer effort will overcome it.
Why This Matters More for CDFIs and Specialty Lenders
I want to spend a moment on why this shows up so consistently among CDFIs and specialty finance companies specifically, because the pattern is not evenly distributed across the lending industry. These organizations tend to be lean by mission and by funding structure. A CDFI launching a new loan program is often doing so with a small team stretched across underwriting, compliance, reporting to multiple funders, and community relationships, in addition to whatever operational modernization is underway. There is rarely a spare business analyst sitting around waiting to be assigned to a software implementation.
At the same time, these organizations often have the most complex configuration requirements relative to their size. A CDFI might need to support several distinct loan products with different underwriting criteria, different reporting obligations to different funders, and different servicing rules, all inside a single platform. That complexity means the cost of requirements drift or rushed configuration decisions is higher, not lower, than it would be for a simpler commercial lending operation. The organizations that most need a dedicated implementation owner are often the ones least likely to have one sitting on staff already.
This is exactly why I think the externalization approach matters so much for this segment of the market. A CDFI does not need to hire a full-time implementation project manager it cannot afford to keep busy after go-live. It needs access to that function for the duration of the project, through a partner who understands both the platform and the specific operational realities of community development lending.
Designing Around the Problem, Not Hoping It Goes Away
The organizations whose implementations finish on time and produce the system they originally envisioned are not the ones with the most talented CEO or the most sophisticated platform. They are the ones that named the altitude problem explicitly, early, and designed around it instead of hoping good intentions would be enough.
If you are heading into a loan origination software implementation right now, the question worth asking in the first planning meeting is not whether the platform can do what you need. It almost certainly can, if it is the right platform for your lending model. The question worth asking is who, specifically, will be in the weeds of this implementation every week, testing configuration, catching drift, and maintaining continuity, while you are doing the other parts of your job that cannot wait. If the honest answer is nobody, that is the problem to solve before the first working session, not the one to discover three months in when the project already feels like it is flying by the seat of its pants.
Digital transformation for lenders succeeds or fails less on the strength of the technology chosen and more on whether the organization built the oversight structure the implementation actually requires. That is a solvable problem, but only if you solve it on purpose.
Blog
Why Cash Flow Underwriting Is Finally Catching On
Ask any credit officer what they look at when they evaluate a borrower, and you will hear some version of the same two ideas. Does this person have a history of paying back what they borrow. And do they have the income and financial capacity to repay right now. Willingness to pay and ability to pay. Those two pillars have anchored lending for as long as lending has existed, and no one in the industry would argue with either of them in principle.
What is strange, once you sit with it, is how lopsided the infrastructure built around those two pillars turned out to be. I have spent a lot of time in underwriting departments over the years, and I have come to appreciate just how much of that imbalance was never really a decision about what mattered. It was a decision about what was possible.
Fifty years of investment went to one side of the ledger
For the better part of five decades, the credit industry poured enormous resources into extracting every possible signal out of willingness-to-pay data. Credit bureaus built national infrastructure around it. FICO and VantageScore refined it into precise, standardized scores. An entire analytics industry grew up around inferring a borrower’s financial stress from things like the number of recent credit inquiries or the age of their oldest account. It is genuinely sophisticated work, built and rebuilt over generations.
The ability-to-pay side of the equation received almost none of that same investment. Cash flow data, meaning the actual pattern of income and expenses moving through a person’s or a business’s accounts, sat mostly untouched by comparison. That is not because it lacked predictive value. Research on cash-flow-based scoring has found it performs on par with traditional credit scores in forecasting loan performance, with area-under-the-curve accuracy in the same range as VantageScore. The two data sets are also measuring something different from each other. The correlation between a traditional credit score and a cash-flow score sits around 0.22, which tells you they are picking up on largely separate signals rather than restating the same information in a different form.
So if cash flow data has been this valuable the whole time, why did the industry build fifty years of infrastructure around the other half of the picture instead?
The 1970s made a practical choice, not a philosophical one
The answer is almost entirely about what was technically feasible at the time the infrastructure was being designed. Credit bureau data in the 1970s was structured, predictable, and low in volume. It updated once a month. It fit neatly into the batch-processing systems of the era. Cash flow data was the opposite of convenient. A single consumer generates thousands of transactions a year, arriving continuously, in no standard format, at a volume that would have overwhelmed the computing capacity available at the time.
Asking a lender in 1975 to build a scoring infrastructure around raw transaction data would have been a bit like asking an automaker in 1910 to build around electric batteries instead of gasoline. Gasoline was the obvious engineering choice given the technology of the moment, and the industrial infrastructure that got built around that choice, refineries, distribution networks, service stations, became so deeply entrenched that it persisted for a century, long after better alternatives were technically possible. Credit bureau infrastructure followed a similar path. It was the right practical choice in 1975, and it became so deeply embedded in underwriting, servicing, securitization, and regulation that it kept shaping decisions long after the original constraint that justified it had started to loosen.
Larry Rosenberger, who ran FICO for years, has said it about as plainly as it can be said. Cash flow data is gold. The only reason it was not used at the start was because it was not widely available. That is a remarkable admission from the person who built much of the willingness-to-pay infrastructure we still rely on today. It was never that the industry decided credit history mattered more than cash flow. It was that credit history was the only one you could actually build a national scoring system around with 1970s technology.
What changed, and why it matters now
The constraint that shaped fifty years of underwriting infrastructure has largely dissolved. Bank transaction data is now accessible programmatically, with consumer permission, in something close to real time. The analytical tooling to turn that transaction stream into a reliable, standardized risk signal exists and is being used in production by lenders today, not as an experiment but as a functioning underwriting input. And the regulatory environment has stopped being neutral on the question. The Consumer Financial Protection Bureau’s open banking rulemaking is deliberately designed to make consumer-permissioned financial data portable across providers, and the Office of the Comptroller of the Currency has been actively encouraging banks to use deposit account data to qualify borrowers who would otherwise be invisible to traditional scoring.
CFPB Director Rohit Chopra has framed the shift in terms that matter directly to lenders serving underserved populations. Bringing a personal financial ledger to a new provider lets that provider evaluate a borrower’s full financial picture instead of relying on a summary compiled by a credit bureau. Individuals without years of credit history, or those who had a rough patch years ago that still shows up on their file, can be evaluated on what their finances actually look like today rather than on a score shaped by events from years past.
This is not a marginal population. An estimated 26 million American adults are completely invisible to the traditional credit system, with no file at any of the three major bureaus. Another 10 million have files too thin to generate a reliable score. Add in the tens of millions more who are technically scorable but sit on thin, brittle files, and you are talking about a meaningful share of the adult population that traditional underwriting infrastructure was never built to see clearly.
Why this lands hardest at CDFIs and community lenders
I think about this population differently after spending time with CDFIs and mission-driven community lenders, because the credit-invisible and thin-file borrowers are not an edge case for them. They are frequently the core of the portfolio. Recent immigrants who have not yet built a domestic credit file. Young adults who have not had the opportunity to establish one. Small business owners whose personal credit history has nothing to do with the financial health of the business they are actually running day to day.
Traditional credit scoring was never designed with these borrowers in mind, because they simply were not part of the population the infrastructure was built to serve in 1975. Cash flow data changes the question entirely. Instead of asking what a bureau file says about a borrower’s history, it asks what is actually happening in their accounts right now. Is income arriving consistently. Are essential obligations being met. Is there a cash flow pattern that indicates capacity to take on and repay new credit, independent of whether that pattern has ever been translated into a bureau score.
The results from early adopters are hard to dismiss. Under the OCC’s Project REACh initiative, banks piloting deposit-account-based underwriting for first-time credit products had established over 110,000 accounts as of late 2023, with credit-invisible borrowers who were approved through this approach reaching an average FICO score of 680 within twelve months. In other words, borrowers who could not have been approved under a traditional model went on to become traditionally creditworthy, because someone was willing to evaluate their actual cash flow rather than the absence of a file.
What this means operationally, not just philosophically
It is one thing to accept the argument that cash flow data is predictive and underused. It is another thing to actually operationalize it inside a lending organization that has spent years, in some cases decades, building processes around credit-bureau-driven underwriting. This is where I think a lot of the conversation about cash flow underwriting stays too abstract. The data being available through open banking connections does not mean an underwriting team can use it well.
Cash flow data is high volume, unstructured relative to a bureau file, and constantly changing. Making it usable in a live underwriting workflow requires an origination system that can ingest transaction-level data, normalize it into something an underwriter or an automated rule can actually evaluate, and route it through the same approval and exception workflow as every other piece of the credit decision. Bolting a cash flow data feed onto a process built around static bureau pulls tends to produce exactly the kind of disconnected, manually reconciled workaround that most lenders are already trying to eliminate elsewhere in their operations. The lenders who get real value out of cash flow underwriting are the ones treating it as a core input to their loan origination software, not as a side lookup that a credit analyst checks manually when a file looks borderline.
This is also where the fair lending questions get real rather than theoretical. Attributes derived from spending categories, like discretionary purchases or timing of recurring payments, have not been tested extensively under the Equal Credit Opportunity Act and Regulation B. Lenders who build cash flow underwriting into their process need the same rigor and documentation discipline they apply to any other underwriting variable, with a clear rationale for why a given signal is being used and evidence that it is not operating as a proxy for a protected characteristic. That is a governance conversation as much as a data conversation, and it belongs inside the underwriting policy framework, not bolted on afterward.
The infrastructure decision in front of lenders today
What strikes me most about this history is how long a purely practical, technology-driven decision from 1975 continued to shape underwriting policy for fifty years afterward. Nobody sat down in 1975 and decided that cash flow data was less valuable than credit history. They decided that credit history was the only one they could actually build a national infrastructure around at the time. That practical constraint calcified into an assumption, and the assumption outlived the constraint by decades.
We are now at the point where the original constraint no longer holds. The data is accessible. The tooling to interpret it exists. The regulatory signal is pointing toward, not away from, its use. What is left is an infrastructure decision, the same kind of decision the industry made in 1975, except this time lenders get to make it deliberately rather than by default.
For CDFIs and community lenders in particular, this is not just a technical upgrade. It is an opportunity to serve the borrowers their mission is built around more accurately than the inherited infrastructure ever allowed. The lenders who understand this history, and who build the operational capability to evaluate ability to pay with the same rigor the industry has spent fifty years applying to willingness to pay, are the ones who will be positioned to serve those borrowers well. The rest will keep operating on infrastructure that was designed for a data problem that no longer exists.
Blog
Why Alternative Lenders Need a Native Scoring Model
There is a moment that almost every scaling merchant cash advance lender reaches in its growth journey. Merchant cash advance, for readers newer to the space, is a short-term business financing product where a company receives capital in exchange for a percentage of future revenue. The moment I am talking about usually happens somewhere between fifty and a few hundred applications a month, and it is the moment when the underwriting process stops being manageable.
I have seen this pattern repeat itself across enough alternative lending operations that I no longer think of it as an edge case. It is closer to a rite of passage. And the shape of the problem is almost always the same.
The calculator that lives outside the platform
Here is what it looks like in practice. The lending operation has a risk scoring model and a pricing calculator. Maybe it started as a spreadsheet someone built years ago when the company was small. Maybe it evolved into something more sophisticated, with tiers and weighted variables and a few hard-won rules baked in from experience. Either way, it lives outside the loan origination system.
When an application clears initial screening and moves to the underwriting team, someone has to take the relevant data points — cash-flow figures, business revenue, time in business, industry classification, existing debt obligations — and manually enter them into the calculator to determine what tier the deal falls into and what pricing to offer. The underwriter then brings that result back into the loan file and continues the process.
The problem is not that the scoring logic is bad. In many cases it is quite good — refined over years of watching deals perform or default. The problem is that every one of those data points already exists in the loan origination system. The underwriter is copying information from one system into another, running a calculation by hand or through a disconnected tool, and then re-entering the result. It is manual. It is slow. And it introduces the possibility of data entry errors in a step that directly determines the price offered to the borrower.
Why this becomes a scaling problem, not just an annoyance
At low volume, this workaround is tolerable. An operation processing a handful of files a week can absorb the inefficiency without much notice. The trouble starts when volume grows, because the constraint scales linearly with headcount and application count in a way that most other parts of the business do not.
Consider the arithmetic. An underwriter who spends fifteen minutes per file on manual data entry and calculator work is an underwriter who could be reviewing twice as many files if that step were automated or eliminated. At a hundred files a month, the impact is a manageable inefficiency — annoying, but not existential. At five hundred files a month, it becomes a significant operational constraint. Lenders in that position often respond by hiring more underwriters rather than fixing the workflow, which solves the volume problem temporarily while making the underlying inefficiency more expensive to carry.
There is also a risk dimension that gets less attention than the efficiency dimension, but probably matters more. Every manual re-entry of financial data is an opportunity for a transcription error. A misplaced decimal point in a revenue figure, a wrong time-in-business value, a stale debt obligation number — any of these can shift a deal into the wrong tier and produce a pricing decision that does not match the actual risk profile of the borrower. In a lending business, pricing errors do not announce themselves immediately. They show up months later in the performance of the portfolio, by which point it is difficult to trace the error back to its source.
The fix is not a better calculator. It is no calculator.
The instinct when facing this problem is often to look for a better external tool — a more robust spreadsheet, a purpose-built scoring application, something that plugs into the loan origination system through an integration. I understand the appeal. It feels like a smaller project than rebuilding the scoring logic inside the platform itself.
But in my experience, that path just relocates the problem rather than solving it. Any external tool, no matter how well built, still requires data to move from the loan origination system into it and a result to move back. Integrations can reduce friction, but they rarely eliminate the underlying issue, which is that the scoring logic and the loan data live in two different places that were never designed to operate as one system.
The fix that actually holds up at scale is a native scoring model built directly inside the lending platform — one that reads the data that is already there rather than requiring it to be re-entered anywhere. When a file reaches the underwriting stage, the system has already applied the scoring logic in the background and surfaced a tier recommendation and pricing range automatically, using the exact data already captured during origination. The underwriter reviews the recommendation, applies judgment to any factors the model cannot fully capture — and there are always a few — and moves to a decision. The data entry step disappears entirely, along with a meaningful share of the risk that came with it.
What it actually takes to build this correctly
Lenders who decide to bring their scoring model natively into their loan origination software sometimes underestimate what the project actually involves. It is not a technical lift so much as an organizational one, and it requires two things in particular.
The first is documenting the underwriting logic in a form precise enough to encode as platform rules. This is often the harder of the two requirements, because risk criteria that exist in the heads of experienced underwriters need to be made explicit. Ask most seasoned underwriters why they priced a deal a certain way and you will get a confident, coherent answer. Ask them to write down the exact decision tree that produced that answer, covering every edge case they have encountered over the years, and the conversation gets a lot longer. That exercise is uncomfortable, but it is also valuable independent of any technology project. It forces an organization to confront where its risk logic is actually consistent and where it has quietly drifted between underwriters, branches, or time periods.
The second requirement is a platform flexible enough to express that logic without requiring custom development every time a parameter changes. Risk models are not static. Industry classifications get added. Weightings shift as portfolio performance data comes in. A tier threshold that made sense two years ago might need adjustment after a wave of defaults in a particular segment. If every one of those changes requires a developer and a release cycle, the scoring model will fall behind the realities of the portfolio, and underwriters will quietly start working around it — which puts the lender right back where it started, just with a more expensive system sitting idle in the background.
This is where the choice of underlying platform matters more than it might initially seem. A loan origination system built on a genuinely configurable foundation allows risk and operations teams to adjust scoring rules themselves, through structured configuration rather than custom code. That difference determines whether the native scoring model stays current with how the business actually operates, or slowly becomes another piece of infrastructure that the team has to work around.
The advantage that goes beyond speed
The most obvious benefit of moving the scoring model natively into the platform is speed. Underwriters stop doing manual data entry, files move faster, and the operation can absorb higher volume without adding headcount at the same rate. That alone justifies the effort for most lenders I talk to.
But the lenders who get this right end up with something more valuable than speed. They end up with a scoring model that is auditable, consistent, and improvable in a way that a spreadsheet living outside the system never was. Every decision the model makes is tied to the actual loan record, with a clear record of which inputs produced which tier and which pricing recommendation. When a pricing decision turns out to be wrong — when a deal that was offered favorable terms defaults earlier than expected, or a deal priced conservatively performs better than anticipated — the organization can go back and understand exactly what inputs drove that decision.
That traceability changes the nature of the conversation after a loss. Instead of a general discussion about whether underwriting standards need to tighten, the team can look at the specific variables that fed into the scoring model for that deal and ask a much sharper question: did the model weight this factor correctly, or was this an underwriter override that deviated from the model’s recommendation. Over time, that kind of specific feedback is what allows a risk model to actually improve rather than simply age.
Why this matters for lending workflow automation broadly
The scoring model problem is really a specific case of a broader pattern I see across alternative lending operations. Workflow automation only delivers its full value when it eliminates the handoffs between systems, not just the manual steps within a single system. An underwriting process that automates document review but still requires a manual jump to an external calculator has only solved part of the problem. The bottleneck simply moves to wherever the next disconnected step lives.
This is why I encourage lending leaders evaluating their loan origination software to think about scoring and pricing logic as a core part of the origination workflow, not as a separate function that gets bolted on afterward. The lenders who treat their scoring model as native infrastructure — built on the same data, governed by the same configuration process, visible in the same file view as everything else in the loan lifecycle — are the ones who scale underwriting capacity without proportionally scaling headcount or risk.
The alternative lending market is only going to get more competitive on speed and pricing accuracy, not less. Lenders still routing deals through an external calculator today are not just carrying an inefficiency. They are carrying a growth ceiling that will become very visible the next time application volume doubles. Fixing it before that happens is far less disruptive than fixing it after.
Blog
How Auto-Decline Waterfalls Help Lenders Scale Underwriting
I was talking recently with the leadership team at a merchant cash advance lender, and one number in that conversation stuck with me. They decline roughly 90 percent of the applications that come through their pipeline. In merchant cash advance, where a business receives a lump sum in exchange for a percentage of its future sales, that is not an unusual figure. Underwriting standards in this space are tight, application volume is high, and a large share of applicants simply do not clear the bar. What made the conversation worth writing about was not the decline rate itself. It was what they had built around it.
Twenty-five percent of their total application volume is now being automatically declined before an underwriter ever opens the file. No manual review, no phone call, no judgment call. The system evaluates stated application data alongside cash-flow signals pulled from their OCR and data parsing vendor, runs that information against a set of underwriting rules configured in Salesforce, and sends a decline notice automatically. The underwriter who would have spent twenty or thirty minutes reviewing that file instead spends that time on an application that actually warrants their experience and discretion. Their stated goal is to keep expanding that percentage, not because they want to decline more people, but because they want their underwriting team spending its limited hours exclusively on the decisions that require a human being to make a judgment call.
The Problem Every Growing Alternative Lender Eventually Hits
If you run underwriting at a specialty or alternative lending shop, you already know the tension. Volume grows because the business is succeeding. Origination is doing its job, marketing is doing its job, and applications are coming in faster than they used to. But underwriting headcount cannot grow at the same rate. Underwriters are expensive to hire, expensive to train, and hard to find with the right combination of risk judgment and product knowledge. So the natural question becomes: how do we process more applications without proportionally growing the underwriting team?
Most lending organizations answer that question the same way at first. They try to make their existing underwriters faster. They build better queues, cleaner document checklists, faster document requests. Those are worthwhile improvements, but they treat every application as if it deserves equal underwriting attention. In a market where 90 percent of applications are ultimately going to be declined, that assumption is expensive. It means your most experienced, highest-paid underwriting talent is spending a meaningful share of its time confirming what the data could have told you automatically.
The lenders who have actually solved this problem did not make their underwriters faster. They changed what reaches an underwriter in the first place. That is the real operational shift behind an auto-decline system: it is not an efficiency tool bolted onto underwriting, it is a triage layer that sits in front of underwriting and decides which applications deserve human time at all.
Why the Instinct to Pull Everything Upfront Is the Wrong One
When most lending operations first consider building automated screening, the instinct is to go big. Pull a comprehensive report on every application the moment it arrives — background check, UCC filing history, a default database search, the full financial picture. It feels thorough. It feels like the safe, complete way to build a screening system. It is also the most expensive way to do it, and at volume, that expense compounds quickly.
The lenders who have engineered this well took a different approach. They built a waterfall. Rather than pulling every available data source on every application, they identified the two or three signals that are most predictive of an automatic decline — a hit in a default database, a specific type of UCC filing that signals prior distress, a cash-flow pattern in the bank data that reliably indicates an inability to repay. Those signals get pulled first, and only those signals. That initial pull might cost fifty cents to a dollar per application. If the application clears that first screen, the system automatically triggers the next layer of data collection. If it does not clear, the application is declined immediately and the more expensive comprehensive report is never purchased at all.
The math is straightforward once you see it laid out. If a lender is processing several thousand applications a month and 60 to 70 percent of those applications would have failed on the first one or two data points anyway, pulling a full report on all of them means paying full price to confirm a decision the cheapest data point already made. Sequencing the pulls so that the most predictive and least expensive signals are checked first means the expensive, comprehensive data only gets purchased on applications that have already demonstrated some baseline viability. Over a year, that difference shows up directly in operating cost. It also shows up in how much underwriting capacity is freed up, because every application that declines on the first data point never enters a queue at all.
The Real Question Is Sequencing, Not Just Data
This is the part of the conversation I think gets missed most often when lending organizations talk about automation. The question is rarely just what data should we use to make a decision. Most experienced underwriting teams already have a good sense of which data points matter. The more important and more overlooked question is in what sequence that data gets used, at what cost, and at what stage of the process each signal gets checked.
Getting the sequence wrong produces one of two bad outcomes. Either the lender pulls everything upfront and pays for a level of diligence that most applications never needed, or the lender pulls too little upfront and lets applications advance further into the process than they should, consuming underwriter time before the disqualifying signal ever surfaces. Getting the sequence right means the cheapest, most predictive signals act as a first filter, the moderately predictive and moderately priced signals act as a second filter, and the expensive comprehensive diligence is reserved for the smaller pool of applications that have already proven themselves worth that expense.
This is also where the value of an auto-decline waterfall extends beyond merchant cash advance. Any alternative lending operation processing meaningful volume against a lean underwriting team faces the same structural problem. Working capital lenders, equipment finance companies, small business lenders, and other specialty finance operations all deal with a similar reality: a sizable share of inbound applications will not qualify, and the cost of determining that should not require the same resources as approving a loan. The specific data points will differ by product and by risk model, but the discipline of identifying which signals are cheapest and most predictive, then sequencing data pulls accordingly, applies broadly.
What This Requires Operationally
None of this works as a one-time project. The lender I spoke with did not build their waterfall once and walk away. They are actively working to expand the percentage of applications that get automatically declined, which means they are continuously testing which signals are the strongest predictors of an eventual decline, and adjusting the rules that govern the automated decision. That requires a few things to be true operationally.
First, the underwriting rules need to live somewhere that is visible and adjustable without engineering intervention every time. If a rule change requires a developer to modify code, the feedback loop between what underwriting is learning and what the system is doing slows down dramatically. Rules configured directly in the lending platform, where risk and underwriting leadership can see and adjust the logic, keep that loop tight.
Second, the data has to actually reach the decision engine in a usable form. This lender’s system is pulling stated application data alongside cash-flow signals from an OCR and data parsing vendor. That only works because the parsing output is structured well enough to feed directly into an underwriting rule rather than requiring someone to read a PDF and manually determine what the cash-flow pattern indicates. A lot of lending operations have the data sources they need but not the integration layer to make that data usable at the moment a decision needs to be made. That gap is often the real obstacle to building an effective waterfall, more so than a lack of underwriting rules or ideas.
Third, the decline communication itself needs to be automatic and immediate. Part of what makes this operationally valuable is not just that the underwriter never touches the file, it is that the applicant gets a fast answer instead of sitting in a queue for days waiting for a human to eventually determine what the data already indicated. Borrower experience and operational efficiency are not competing goals here. A fast, automatic decline is a better experience for an applicant who was never going to qualify than a slow one, and it frees capacity for the applications that deserve real attention.
Where Human Judgment Still Belongs
It is worth being direct about what this approach is not. It is not a system designed to replace underwriter judgment on the applications that matter. It is a system designed to make sure underwriter judgment is spent where it belongs. The lender in this conversation was clear that their underwriting team’s time is now concentrated on the applications that have passed initial screening and actually warrant discretion — the deals where the data is mixed, where context matters, where a person with experience needs to weigh competing signals and make a call that a rule set cannot make on its own.
That distinction matters because it is easy to conflate automated screening with a broader push to remove underwriters from the process. That is not what is happening in the operations that have done this well. The automation is handling the clear-cut cases, the applications that would have been declined regardless, just more slowly and more expensively without it. The judgment calls, the applications that sit in genuine gray areas, are still going to a person. If anything, this approach makes the underwriter’s role more valuable, not less, because it removes the repetitive, low-judgment work and leaves the decisions that actually require their experience.
The Broader Lesson for Scaling Lending Operations
Every alternative lender I talk to is thinking about growth, and almost every one of them is thinking about it in terms of volume, marketing reach, or new products. Fewer of them are thinking about it in terms of the sequencing question this lender had already solved. As application volume increases, the cost of screening every application with the same level of diligence increases right alongside it, and at some point that cost structure becomes the limiting factor on how much growth an underwriting team can actually absorb.
The lenders who are scaling most efficiently right now are not necessarily the ones with the most sophisticated underwriting models. They are the ones who have taken the time to map out their decline reasons, identify which two or three signals catch the majority of those declines, and build the sequence and the systems to check for those signals first, automatically, before anything more expensive or more human gets involved. That is not a flashy operational change. It does not show up in a press release. But it is the kind of decision that determines whether a lending operation can double its volume without doubling its underwriting team, and that is exactly the kind of leverage every growing lender should be looking for.
Blog
Why Cash-Flow Data Beats Credit Scores for CDFI Lenders
I spend a lot of time in rooms with COOs and Heads of Lending at CDFIs and community lenders, and for the last few years one conversation keeps repeating itself. Someone brings up cash-flow underwriting, someone else nods and says it sounds promising, and then the conversation quietly moves on because nobody feels like they have enough evidence to make the case to their board or their funders. That excuse just got a lot harder to use.
FinRegLab, a nonprofit research organization, recently published a study analyzing more than 38,000 small business loans originated by fintech lenders between 2015 and 2024. The research was conducted with faculty from the NYU Stern School of Business, and the findings are about as definitive as empirical lending research gets. Cash-flow variables derived from electronic bank account data are a stronger and more accurate predictor of loan performance than personal credit scores alone. Not marginally stronger. Meaningfully stronger, and especially so for the exact borrower population that CDFIs and community lenders were created to serve.
The Borrowers Traditional Credit Scoring Was Never Built For
Early-stage businesses. Businesses owned by people with limited credit histories. Financially constrained entrepreneurs. These are the categories the study highlights, and if you work in community lending you already know these borrowers well. They are not high-risk. They are underserved by a scoring system that was never designed to evaluate them fairly in the first place.
A low credit score does not mean a business is a bad bet. It might mean the owner is young and has not had time to build a long credit history. It might mean the owner is an immigrant who arrived in this country without an existing credit file. It might mean there was a difficult stretch four or five years ago, medical debt, a divorce, a failed first venture, that has since fully resolved and no longer reflects the person running the business today. Personal credit scores are backward looking by design. They are a historical proxy, and for a huge share of the borrowers community lenders exist to serve, that proxy is simply wrong.
Cash-flow underwriting evaluates something different. It looks at deposits, expenses, revenue patterns, and payment behavior as they exist right now, inside the business, based on actual bank account activity. It answers the question a lender actually needs answered, which is whether this business can service debt today, not whether the owner had good or bad credit years ago. That is not a philosophical argument anymore. It is what the data shows across 38,000 loans and nearly a decade of originations.
This Is No Longer a Theoretical Debate
What makes this study different from the cash-flow underwriting conversations the industry has been having for years is that it is not theoretical. FinRegLab documented real-world implementation pilots at operating lending institutions, including Allies for Community Business, Ascendus, LiftFund, Ponce Bank, and Texas National Bank. These are CDFIs and minority depository institutions that have already put cash-flow underwriting into production and are using it right now to approve borrowers they could not previously serve under a credit-score-first model.
That distinction matters. It is one thing for a research paper to conclude that a methodology is theoretically sound. It is another thing entirely when five different lending organizations, with real portfolios and real regulatory obligations, have implemented it and can point to outcomes. The debate over whether cash-flow underwriting works has effectively closed. The research settled it, and the pilots proved it operationally.
So if the evidence is this strong, and the pilots are already running, the obvious question is why cash-flow underwriting still is not standard practice across the CDFI sector. The FinRegLab report is honest about this, and the answer has nothing to do with skepticism about the methodology. It has to do with infrastructure.
The Real Barrier Is Not Belief. It Is Plumbing.
To underwrite on cash flow, a CDFI needs to securely access bank transaction data through third-party aggregators, bring that data into the underwriting workflow in a usable form, train staff to interpret it consistently across every application, and do all of this while protecting borrower privacy and meeting the compliance obligations that come with handling sensitive financial data. None of that happens by wishing it into existence. It requires a technology platform that can actually support it, and a meaningful number of CDFIs are still running loan origination on a patchwork of spreadsheets, PDFs, email threads, and a core system that was never built to ingest a live bank data feed.
I have sat with underwriting teams who believe completely in cash-flow analysis, who have read the research, who want to move on it, and who are stuck because their current system has no way to pull transaction data into the file where the credit decision actually gets made. So what happens instead is someone downloads a PDF bank statement, someone else manually reviews it line by line, and the process that was supposed to expand access to underserved borrowers ends up being slower and more labor-intensive than traditional underwriting, not faster. The intent is right. The infrastructure is not there to support it, so the benefit never reaches the borrower.
This is the part of the FinRegLab report that deserves the most attention from lending leadership teams, because it is the most actionable. The report specifically points to lending platforms as the mechanism that makes cash-flow underwriting operational rather than aspirational. The CDFIs that have successfully reduced paperwork burdens and cut processing times from months down to weeks are not the ones with the most conviction about cash-flow data. They are the ones that integrated bank data feeds directly into their loan origination and underwriting systems, so the information flows automatically into the workflow instead of being manually assembled by an analyst every single time.
What Automated Data Flow Actually Changes
It is worth being specific about what changes when bank data flows directly into an origination system instead of arriving as a static export. First, consistency improves. When every underwriter is looking at the same structured categorization of deposits, expenses, and revenue trends, you get a repeatable credit decision framework instead of individual analysts each interpreting a bank statement their own way. Second, speed improves, not because anyone is cutting corners, but because the manual transcription and reconciliation step disappears entirely. Third, and this is the one boards and funders care about most, documentation improves. Every cash-flow variable that fed into the decision is captured in the system of record, which matters enormously when a CDFI has to justify its underwriting methodology to a funder, an examiner, or its own risk committee.
None of this requires exotic technology. It requires a loan origination and servicing platform that was built with the flexibility to connect to third-party data sources and route that data into the underwriting workflow where decisions get made and documented, rather than a system that was built purely around static application forms and manual document uploads. This is precisely the operational gap that separates CDFIs that are scaling cash-flow underwriting from CDFIs that are still talking about it in strategy meetings.
What This Means for CDFI and Community Lending Leadership Right Now
If you lead lending operations at a CDFI or a community lender, the research has effectively done its job. You no longer need to build an internal case for why cash-flow underwriting deserves serious consideration. FinRegLab and NYU Stern have built that case for you, with 38,000 loans of evidence and five operating institutions as proof points. The question in front of your leadership team is no longer whether cash-flow underwriting works. It is whether your current technology platform can support it.
That is an honest question worth asking plainly, without defensiveness. Can your system securely connect to a bank data aggregator. Can it bring transaction-level data into the file an underwriter is reviewing, rather than requiring someone to open a separate tool and manually cross-reference it. Can it document which cash-flow variables informed a given credit decision, in a form that would satisfy a funder or an examiner asking how that decision was made. If the honest answer is no, that gap is not a reason to keep cash-flow underwriting on the someday list. It is simply the next problem to solve, and it is a solvable one.
I would also push back gently on a version of this conversation I hear often, which is treating the technology gap as a reason to wait for a better moment. There is no better moment coming. The evidence is published. The pilots are running. Competing lenders in your market, including fintech lenders with far less mission alignment to underserved borrowers than a CDFI has, are already using cash-flow data to approve loans your traditional underwriting process would decline. Every quarter a CDFI spends without the infrastructure to act on this research is a quarter where bankable, viable, financially healthy small businesses are being turned away not because they are risky, but because the system evaluating them cannot see what is actually happening in their bank account.
The mission case for cash-flow underwriting was never really in question for most CDFI leaders. What this study removes is the last credible reason to treat it as unproven. What remains is an implementation question, and implementation questions get solved with the right platform, the right data integrations, and a workflow that puts cash-flow data in front of underwriters at the moment they need it, not after the fact. That is a much better problem to have than the one most of the sector has been stuck on, which is whether the methodology itself can be trusted. It can. Now it is a matter of building the operational capability to use it.
Blog
Why CDFIs Aren’t Using Cash-Flow Underwriting Yet
I spend a lot of my time talking to Heads of Lending and COOs at CDFIs, and there is a conversation that comes up more often now than it did even two years ago. It usually starts the same way. Someone on the credit side brings up cash-flow underwriting, everyone in the room nods, and then the conversation quietly moves on to something else. Nobody argues against it. Nobody says the data is wrong. It just does not turn into action. I have started paying closer attention to why that happens, because I think it says something important about where CDFI technology actually stands today.
The methodology is not the problem
Cash-flow underwriting is the practice of evaluating a borrower’s creditworthiness using their actual bank transaction data — income patterns, expense behavior, deposit consistency, cash flow trends — instead of relying primarily on a credit score. The research behind this, including work compiled by Opportunity Finance Network’s innovation resources, is not ambiguous. Studies consistently show that cash-flow variables are as predictive of loan performance as traditional credit metrics. Borrowers with thin or damaged credit files but strong, consistent cash flow default at low rates. And when lenders combine cash-flow data with conventional credit information, the predictive accuracy of the underwriting model improves further. This is not a fringe theory circulating in fintech conference decks. It is a body of evidence that has been building for years.
For CDFIs specifically, this matters more than for almost any other category of lender. An estimated 45 to 60 million American adults have little to no credit history, and a disproportionate number of them are exactly the population CDFIs were built to serve. Minority-owned businesses, immigrant-owned businesses, women-owned businesses — many of these borrowers have been systematically excluded from the traditional credit system not because they manage money poorly, but because the system was never designed to see them clearly. A credit score is a proxy for creditworthiness. Cash flow is the thing itself. When a CDFI underwrites primarily on score, it inherits every historical exclusion baked into that score. When it underwrites on cash flow, it gets a chance to evaluate the borrower who is actually in front of it.
So if the research is this clear and the mission alignment is this obvious, why isn’t cash-flow underwriting standard practice across the CDFI industry already? I don’t think it’s a belief problem. I think it’s an infrastructure problem, and it’s worth being specific about what that means.
Fintech figured this out years ago — and not because they were smarter
Fintech lenders have been underwriting off bank transaction data for the better part of a decade. They did not adopt cash-flow underwriting because they had superior credit theory. They adopted it because they built, from day one, the technical plumbing required to make it work: direct integrations with bank data aggregators, automated ingestion of transaction history, standardized categorization of cash flow patterns, and underwriting models built to consume that data natively. The methodology was available to everyone. The infrastructure was not.
Most CDFIs were not built this way. Many are running on a patchwork of legacy loan origination systems, spreadsheets, and manual document collection processes that were designed around a different underwriting model — one where a loan officer requests financial statements, tax returns, and a credit report, and manually assembles a credit memo. That process was not designed to accommodate a data feed of hundreds or thousands of individual bank transactions per borrower, and retrofitting it after the fact is exactly the kind of operational lift that gets deprioritized when your team is already stretched thin serving borrowers with limited hands and limited budget.
What the infrastructure gap actually requires
It is worth being precise about what “the technology to do this” actually means, because I think the abstraction is part of why it stalls in planning conversations. Cash-flow underwriting at scale requires four specific capabilities working together, not as separate initiatives but as one connected workflow.
The first is secure access to bank transaction data. This means integrating with an open banking data aggregator that can connect to a borrower’s bank account, with appropriate consent, and pull transaction history in a structured format. This is not a manual PDF upload and review process. It has to be an API-level connection that can run reliably across every application that comes through the pipeline.
The second is the ability to bring that data directly into the underwriting workflow, not as a side document sitting in a shared drive, but as a structured part of the loan record itself. If a credit analyst has to export transaction data into a separate spreadsheet, manually calculate cash flow ratios, and then paste a summary back into the loan file, you have not really implemented cash-flow underwriting. You have added a manual analytics step on top of an already manual process. The data needs to live inside the same system where the credit decision is made and documented.
The third is a consistent framework for interpreting that data. Cash flow underwriting is only as good as the standardization behind it. If every underwriter is eyeballing bank statements differently, you introduce exactly the kind of inconsistency that credit risk and compliance teams are trying to eliminate. The platform needs to support a repeatable methodology for scoring and documenting cash-flow analysis so that two different underwriters looking at two different files reach comparable conclusions using comparable logic.
The fourth, and the one that gets underestimated most often, is data protection and borrower privacy. Bank transaction data is some of the most sensitive information a lender can hold. A CDFI that starts pulling this data needs a platform with the security architecture, access controls, and data governance to handle it responsibly — not just to satisfy a regulator, but because these are often the borrowers with the least margin for error if something goes wrong with their financial data.
The pattern I keep seeing in the field
When I visit CDFIs and talk to their lending and operations leadership, there is a pattern that has become pretty consistent. The organizations actually piloting or deploying cash-flow underwriting at scale are, without exception, the ones that have already modernized their core lending platform. They are running loan origination systems that can integrate with open banking data sources, that can absorb structured data feeds into the underwriting record, and that give their credit team one place to work instead of five. For these organizations, cash-flow underwriting is not a separate technology project. It is a natural extension of infrastructure they already have.
The CDFIs that are not moving are almost always the ones still operating on legacy loan origination systems or spreadsheet-driven processes. And to be clear, this is not a failure of leadership or vision. I have sat across the table from Heads of Lending at these organizations who understand the research on cash-flow underwriting as well as anyone. They are not choosing to ignore it. They are looking at their current technology environment and correctly concluding that there is no realistic path to implementing it reliably without first solving a more foundational problem. You cannot bolt an open banking integration onto a system that was never built to receive structured external data feeds and expect it to hold up across hundreds of loan files a year.
This is the gap that matters. Not a gap in belief. A gap in what the underlying platform can actually do.
The questions worth asking before the next technology decision
If you are a COO or Head of Lending at a CDFI and this resonates, the useful next step is not to commission another research review on cash-flow underwriting. The research already exists and it is convincing. The useful next step is to turn the question inward and ask it about your own environment, specifically and without diplomacy.
Can your current loan origination system connect to a bank data aggregator and pull transaction data into an underwriting record automatically, without a manual export and reimport step in the middle? Can your credit team analyze that data inside the same system where the credit decision itself gets made and documented, so the analysis and the decision are not living in two disconnected places? Can you report on cash-flow underwriting outcomes — default rates, approval rates, portfolio performance — to your funders and board in a way that demonstrates the methodology is working, using data your system already captures rather than a manual reconciliation project every quarter?
If the honest answer to those questions is no, that is not a strategy failure. It is a platform limitation, and it is one worth naming clearly in your next technology roadmap conversation. The barrier to serving more of the borrowers CDFIs exist to serve is not a lack of conviction about what works. It is infrastructure that has not caught up to the methodology. And unlike a lot of the structural challenges CDFIs face, this particular one is solvable. It requires a platform that treats cash-flow data as a native part of the underwriting workflow rather than a side project, and it requires making that investment deliberately rather than waiting for it to become unavoidable.
The organizations that make that move first are not doing anything exotic. They are simply closing the distance between what they know about their borrowers and what their systems allow them to act on. For a sector built specifically to reach people the traditional credit system has left behind, that distance is worth closing as fast as possible.