Blog
Why Loss Curves Matter for Scaling MCA Lenders
I had a conversation recently with a merchant cash advance lender that has grown fast over the past couple of years, and it surfaced one of the more underappreciated ideas in alternative lending. Not underwriting models. Not pricing algorithms. Something quieter and, in my view, more consequential for a lender’s survival as it scales: the loss curve.
Most lending conversations I have these days focus on origination speed, underwriting automation, or borrower experience. Those things matter. But this particular operator raised a different question, one that only becomes urgent once volume gets serious. When you are funding fifteen million dollars a month, you can manage a lot of things manually. Spreadsheets work. Gut checks work. A sharp operations lead who knows every deal by feel can catch most problems before they compound. When you are funding eighty million dollars a month, that same approach does not just get harder. It becomes dangerous. The margin for error on portfolio monitoring shrinks dramatically, and the tools that got you to fifteen million are usually the same tools that fail you on the way to eighty.
What a loss curve actually is
Here is the concept in plain terms. When an MCA lender funds a group of deals in a given month, that group is called a vintage or a cohort. Those deals do not default all at once, and they do not pay off all at once either. Losses emerge over time in a pattern that, for a mature lending book, is remarkably predictable.
In the first month after funding, losses on that cohort might sit around half a percent. By month three, maybe two percent. By month six, four and a half percent. By month twelve, six and a half percent. After that, the curve tends to flatten because most of the deals in that cohort have either paid off in full or already defaulted. Plot that progression over time and you have a loss curve for that specific cohort. Plot it across many cohorts, month after month, and you have something far more valuable: a benchmark for what normal looks like in your portfolio.
This is not a new idea. Credit card issuers and auto lenders have used vintage curve analysis for decades. What is different in merchant cash advance and other forms of alternative commercial lending is that the discipline has been slower to take hold, partly because the products are shorter-duration and higher-velocity, and partly because a lot of MCA operations grew up around sales and funding speed rather than portfolio science. That is changing, and the lenders making the shift are the ones most likely to still be standing in five years.
Why this matters more as volume grows
The reason loss curve discipline becomes non-negotiable at scale is that it lets you compare vintages against each other in a way that catches problems early. Say your January cohort has historically reached three percent cumulative losses by month four. That is your benchmark. Now your June cohort hits five percent at month four. Something has changed, and you know it well before that cohort has finished seasoning.
The value here is diagnostic as much as it is quantitative. A deviation like that could mean underwriting standards slipped somewhere in the funnel. It could mean a new lead source or broker relationship is producing lower quality deals than your legacy channels. It could mean a specific industry vertical, restaurants or trucking or a seasonal retail category, is underperforming relative to how it was priced. It could mean pricing simply did not keep pace with the risk profile of the deals you were funding that month. In every one of those cases, the loss curve is what surfaces the problem while there is still time to do something about it, rather than six or nine months later when the losses have already fully materialized and the capital is already gone.
This is also the mechanism experienced MCA lenders use to predict ultimate losses on a cohort before it has fully seasoned. If your historical pattern shows that roughly half of a cohort’s eventual losses have typically emerged by month four, and you are looking at three hundred thousand dollars in losses on a cohort at month four, your model is telling you to expect something closer to six hundred thousand dollars in ultimate losses on that vintage. That is not a guess. It is a projection grounded in your own portfolio’s historical behavior. And that projection is what allows a lender to make intelligent decisions about capital allocation, pricing adjustments, and underwriting tightening in real time, instead of reacting after the fact when the only options left are collections and write-offs.
The gap between knowing this and operationalizing it
Almost every experienced credit or risk leader in alternative lending understands loss curves conceptually. The gap is operational, not intellectual. Most MCA lenders that track loss curves at all are doing it in spreadsheets or basic business intelligence tools. Someone exports funding and payment data, builds a chart, lines up cohorts against each other, and manually flags anything that looks off. It works, in the sense that it produces a correct answer eventually. But it is slow, it depends on someone remembering to run the analysis, and it is fundamentally backward-looking. By the time a spreadsheet-driven review surfaces a deviating cohort, that cohort may already be three or four months further into its loss development than it needs to be before someone notices.
This is where the infrastructure question becomes unavoidable. A lender funding fifteen million a month can absorb the inefficiency of manual cohort analysis because the absolute dollar exposure of any single vintage is limited, and there are fewer moving parts to track. A lender funding eighty million a month is originating far more cohorts, far more lead sources, far more industry concentrations, and far more pricing variations simultaneously. Manual analysis does not scale linearly with that complexity. It scales worse than linearly, because the number of comparisons that matter grows faster than the data itself.
Where AI actually changes the picture
This is the part of the conversation I keep coming back to, because it is a rare example of AI in lending solving a problem that is concrete and operational rather than a vague promise of intelligence layered on top of existing workflows. The opportunity is not an AI underwriter that replaces credit judgment. It is a monitoring system that watches loss curve development continuously across every active cohort and surfaces deviations the moment they appear, rather than at the end of a reporting cycle.
Instead of a report that someone runs on the first of the month, imagine a system that is always comparing current vintages against their expected loss curve trajectory, flagging the ones that are developing worse than history would predict, and pointing to the likely contributing factors. Not just “your April cohort is off pace,” but which lead source is disproportionately represented in the deviation, which merchant segment is driving it, and which specific deals are contributing most to the divergence. That turns loss curve analysis from a historical accounting exercise into a genuine early warning system, and it does so without requiring a risk team to manually rebuild the analysis every time volume or channel mix shifts.
The distinction matters because timing is the entire value proposition here. Catching a cohort deviation at month two, when a small pricing or underwriting adjustment can correct the trajectory for future originations and tighten monitoring on the affected vintage, is a manageable operational correction. Catching that same deviation at month six, after the losses have compounded and the affected deals are too far along to salvage, is a capital event. Same underlying problem. Radically different outcome, determined entirely by how quickly the deviation was detected.
What this means for a lender’s underlying platform
This is ultimately a question about infrastructure, not analytics sophistication. Cohort-level loss curve monitoring requires clean, connected data across origination, underwriting, and servicing. If funding data lives in one system, payment performance lives in a servicing platform that does not talk to it, and portfolio reporting is reconstructed manually every month by exporting from both, real-time cohort monitoring is not really possible no matter how good your risk team is. The lag is built into the architecture before anyone even opens a spreadsheet.
This is why I think about loss curve monitoring as a test case for whether a lender’s technology stack is actually built for growth or just built to survive the volume it has today. An alternative lending platform that unifies origination, underwriting, and loan servicing on a common data model is what makes continuous cohort monitoring feasible in the first place. Without that foundation, an AI layer has nothing reliable to watch. With it, the same underlying data that supports day-to-day servicing operations becomes the basis for a live view of portfolio risk, one that updates as payments come in rather than one that gets reconstructed after the fact.
The practical question every scaling MCA lender should be asking
If you are running a merchant cash advance operation, or any alternative lending business that funds in cohorts and monitors performance over time, the question worth sitting with is not whether you understand loss curves conceptually. Most experienced risk leaders do. The question is whether your current infrastructure can support cohort-level monitoring at the pace your origination volume now demands. If the honest answer is spreadsheets, manual exports, and a monthly review cycle, the monitoring is going to lag behind the volume no matter how skilled the people running the analysis are.
And at scale, that lag is where the real risk lives. Not in any single bad deal, and not in any single underwriting mistake. In the gap between when a cohort starts to deviate from its expected trajectory and when someone notices. Closing that gap is not primarily an analytics problem anymore. It is an operational and technology problem, and it is one that more scaling lenders are going to have to solve deliberately rather than by accident.
Blog
Why Lending Is Ahead on AI, Not Behind
I keep having the same conversation with lending executives, and I want to share why I think it needs to be reframed. The conversation usually starts with some version of this: regulated industries like lending and financial services are behind on AI. Retail companies and technology firms are racing ahead, building AI agents into every corner of their operations, while lenders sit back and wait for the technology to mature before they take the risk. I hear this at conferences. I hear it from clients. And I have heard it used, more than once, as the reason a lending organization is deferring an AI investment for another year.
The data does not support that narrative. Not even close.
What the Data Actually Shows
Salesforce recently released its 2026 Agentic Enterprise Index, which analyzes real AI agent usage across industries rather than survey responses about intentions or sentiment. It measures what organizations are actually doing with AI agents in production, not what they say they plan to do. Financial services is growing AI agent output thirteen times year over year. That is not a rounding error or a soft trend line. That is one of the fastest growth rates of any sector the index tracks.
The more interesting number is not growth. It is sophistication. The index includes a sophistication measure that looks past raw task volume and asks a harder question: how complex is the work these AI agents are actually doing. Not how many tickets they close or how many simple lookups they perform, but how many steps, how many systems, how much judgment is embedded in the tasks being handled. On that measure, financial services ranks among the highest of any industry in the index. Higher than retail. Higher than technology. Higher than sectors that get far more attention in the general conversation about AI leadership.
If you have spent time in lending operations, this should not surprise you. It should confirm something you already know intuitively about the nature of the work.
Why Lending Work Is Inherently More Sophisticated
Think about what a retail AI agent typically handles. A customer asks about an order status. The agent checks a database, returns an answer, maybe processes a return. It is useful, it saves a human agent time, and it resolves a real customer need. But it is narrow. One system, one type of question, low stakes if something goes slightly wrong.
Now think about what a lending AI agent has to do in a single interaction. It has to verify a borrower’s identity against internal and external data sources. It has to check compliance requirements that vary by loan type, jurisdiction, and sometimes by funding source. It has to pull account status and payment history. It has to evaluate eligibility against underwriting criteria that may involve multiple data points and conditional logic. It has to update records across origination and servicing systems so nothing falls out of sync. It has to trigger downstream workflows, whether that is routing a file to an underwriter, generating a document, or flagging an exception for human review. And it has to communicate all of this back to a borrower or a loan officer in a way that is accurate and compliant.
That is not one task. That is a chain of interdependent tasks, each with its own risk profile, executed in a regulated environment where the cost of an error is not a bad customer experience but a compliance finding or a bad credit decision. This is exactly the kind of multi-step, cross-functional, judgment-adjacent work where sophisticated AI delivers the most value and where the bar for getting it right is highest. It makes complete sense that financial services would rank at the top of a sophistication index rather than the bottom. The work itself demands sophistication. Simple AI implementations do not survive contact with lending operations. Only the sophisticated ones do.
The Real Risk Is Not Moving Too Fast
This reframing matters because of what it implies for the lending executives who are waiting. I understand the instinct. Lending is a regulated business. A bad decision does not just cost money, it can create legal exposure, regulatory scrutiny, and reputational damage that takes years to repair. Caution is a rational default in this industry, and I would never tell a Head of Lending to abandon that instinct.
But there is a difference between caution and delay, and the data suggests a lot of lenders have drifted from one into the other. The lenders I talk to who are waiting for AI to be more proven before they invest are operating on an assumption that the proof does not yet exist. That assumption was reasonable two or three years ago. It is not reasonable now. The proof is already in the data, and it is specifically strongest in industries like theirs, not despite the regulatory complexity but because of it. Financial services organizations that have already built sophisticated agentic workflows are not doing so in spite of compliance requirements. They are building compliance logic directly into the agent workflows, which is precisely why the sophistication score is so high.
Waiting for a clearer signal is not the safe move it feels like. It is a way of falling behind while telling yourself you are being prudent. The lenders who are furthest along are not the ones who took the biggest risks. They are the ones who started building operational discipline around AI earlier, while others were still debating whether the category was mature enough to touch.
Why Salesforce-Native Lenders Have an Advantage They May Not Be Using
There is a specific detail in this story that I think gets lost, and it matters a great deal for lenders who are already operating on Salesforce. The infrastructure to deploy Agentforce AI agents is not something these organizations need to acquire, evaluate, or bolt on through a separate integration project. It is already sitting inside the platform they are running their lending operations on today.
This changes the nature of the decision. For a lender running loan origination and servicing on a fragmented mix of point solutions and spreadsheets, deploying sophisticated AI agents means solving an integration problem before you can even start solving a workflow problem. You have to figure out how an AI agent will read data that lives in three different systems, how it will write back updates without breaking a downstream report, and how it will maintain any kind of audit trail across tools that were never designed to talk to each other. That is a real project, and it is a legitimate reason to move cautiously.
A lender already operating on a Salesforce-native platform is not solving that problem. The data model is unified. The workflow engine already governs how records move through origination and servicing. The audit trail already exists because it was built into the platform from the start. Activating an AI agent in that environment is not a new infrastructure project. It is an extension of infrastructure that is already in place and already trusted. That is a meaningfully different starting point, and it is one of the more concrete reasons Salesforce-native lenders are showing up as leaders in sophistication rather than laggards waiting on the sidelines.
I want to be careful here not to overstate this into a pitch, because it is not one. Having the infrastructure available does not mean the work of deploying AI responsibly is done. It means the starting line is much closer than it would otherwise be. What a lender does next still determines the outcome.
The Real Question Is Where to Start, Not Whether to Start
Once you accept that the data has already answered the readiness question, the conversation with a lending executive changes. It stops being about whether AI is proven enough for a regulated lending environment. It becomes about sequencing. Where does an AI agent add value first without introducing new risk. What existing manual, repetitive, multi-step process is the best candidate for an initial deployment. How do you validate outputs before you extend an agent’s authority to touch more of the workflow.
The lenders getting this right are not starting with the most complex, highest-stakes decision in their operation. They are starting with a process that is well understood, well documented, and already governed by clear rules, then expanding from there as trust and evidence accumulate. Document intake and verification is a common starting point. So is routine borrower communication tied to loan servicing, or the reconciliation work that consumes hours of staff time every week without requiring much judgment once the rules are codified. These are not glamorous use cases. They are the ones that build the operational muscle memory an organization needs before it asks an AI agent to touch anything closer to a credit decision.
Governance Is the Real Differentiator, Not the Technology
The practical question for any lending executive right now is not whether AI is ready for lending. The data answers that question clearly. The question that actually matters is how to build a governance framework that makes AI adoption sustainable rather than one that creates new compliance risk in the process of chasing efficiency gains.
Governance in this context means something specific. It means defining which decisions an AI agent is permitted to make outright, which decisions require human review, and which decisions remain entirely off limits to automation regardless of how well the agent performs elsewhere. It means establishing an audit trail that regulators and internal compliance teams can actually inspect, not just a log file that nobody reviews until something goes wrong. It means testing agent behavior against edge cases and exceptions before it ever touches a live borrower interaction, because the failure modes in lending are not forgiving in the way a mishandled retail return is forgiving.
This is where I think the sophistication data point becomes most useful for a lending executive building an internal business case. It is not just evidence that AI works in financial services. It is evidence that the industry is already solving the governance problem at scale, because sophisticated multi-step agent work cannot exist in a regulated environment without governance built into it. The organizations posting the highest sophistication scores are not the ones who ignored compliance to move fast. They are the ones who figured out how to move fast because they built compliance into the design from the beginning.
What This Means for the Rest of 2026
I do not think the narrative about lenders lagging behind on AI is going to hold up much longer once this kind of data becomes more widely known. The gap that actually exists is not between financial services and other industries. It is between the lenders who have started building sophisticated, well-governed AI workflows and the lenders who are still waiting for a signal that has already arrived.
For lenders running on Salesforce-native infrastructure, the calculus is even more direct. The capability is not something to plan for next year’s budget cycle. It is available now, inside a platform many of these organizations already trust for their core lending operations. The decision in front of most lending executives is not whether to pursue AI. It is whether to keep waiting for proof that already exists, or to start building the governance and sequencing that will let them use it responsibly. I know which side of that decision the data supports, and I think most lending leaders, once they see the numbers, will land in the same place.
Blog
Why Lenders Resist AI: It’s About Rework, Not Trust
I have sat across the table from a lot of operations leaders over the years, and I keep noticing the same pattern whenever the conversation turns to AI for lending. The objections almost never sound like what they actually are. A COO tells me we are not ready for that yet. A Head of Lending says we are already handling this fine. A digital transformation lead says we have bigger priorities this quarter. On the surface, those statements read as skepticism about the technology itself, as if the person doubts AI can do what vendors claim. But after enough of these conversations, I have come to believe that is almost never the real objection. What I am actually hearing is resistance to rework.
That distinction matters more than it sounds like it should, because it changes everything about how AI needs to be introduced to a lending organization. If the objection were genuine skepticism about capability, the right response would be more proof, more case studies, more demonstrations of accuracy. But if the objection is really about the disruption cost of adopting something new, then proof of capability does nothing to solve the actual problem. You can convince someone that a tool works perfectly and still lose the deal, because the resistance was never about whether it works. It was about what adopting it would cost the organization in time, retraining, and risk to processes that already function.
The Real Cost Lending Leaders Are Weighing
Here is what is actually happening inside the head of an experienced operations leader when an AI vendor walks in the door. That leader is not evaluating the technology in a vacuum. They are evaluating it against everything their team has already built. Someone on that team designed the underwriting checklist that every file runs through. Someone configured the document collection sequence that borrowers and processors follow every day. Someone spent months getting the pipeline stages to reflect how the credit committee actually wants to see files move. None of that was free. It represents real institutional knowledge, real organizational effort, and in many cases, real political capital spent getting the team to agree on a standard process in the first place.
When an AI vendor shows up and opens with a pitch about transforming the underwriting process, what the experienced leader hears is not an offer to help. What they hear is a request to throw away what took years to build and start over on someone else’s terms. That is not an unreasonable reaction. It is actually a fairly disciplined one. Any operations leader who has lived through a bad system migration, a stalled digital transformation project, or a vendor implementation that ate a year of the team’s time knows that rebuilding a working process is expensive even when the new process is theoretically better. The theoretical benefit has to clear a very high bar before it justifies that kind of disruption.
This is where the math either works or it does not. A major workflow transformation that requires retraining the entire team, reconfiguring the system end to end, and rebuilding processes that already function reasonably well carries real cost and real risk regardless of how good the underlying technology is. If the benefit on the other side of that transformation is marginal, uncertain, or takes eighteen months to materialize, no rational operations leader signs off on it. Based on how AI has been positioned and sold to lending organizations over the past few years, that calculation has frequently been correct. The industry has done itself a disservice by pitching AI as transformation rather than as capability, because transformation implies disruption, and disruption is exactly what a working operations team is trying to avoid.
Addition Changes the Conversation Entirely
What changes the calculation, and what I have seen work consistently across the specialty and commercial lenders I talk to, is positioning AI as an addition to the existing workflow rather than a replacement for it. The most successful AI implementations I have observed in lending organizations are not the ones that ask a team to restructure how they operate. They are the ones that slot quietly into a process the team already runs every day, without asking anyone to learn something new.
Think about what this looks like in practice. Document extraction that feeds structured data directly into the same fields a processor currently fills in by hand is not a new process. It is the same process, minus one manual step. Missing item detection that surfaces automatically on the same screen a processor already uses to track a file is not a new tool the team has to open. It is the existing screen doing more work on its own. Red flag alerts that appear inside the underwriter’s existing queue, next to the files they already review every morning, do not require the underwriter to change how they start their day. The team does not have to be retrained on a new system. They simply notice that certain steps they used to do manually are now happening before they even get to them.
That is a completely different value proposition than transformation, and it produces a completely different reaction from the operations leader on the other side of the table. It also happens to be the more honest way to talk about what AI is actually good at in a lending context right now. AI is very good at accelerating specific, well-defined steps inside a process, like reading a document and populating a field, or scanning a file for a missing signature, or flagging an anomaly in a financial statement. It is much less reliable, and much riskier, when it is asked to redesign judgment-based decisions or restructure how a team thinks about credit risk. Positioning AI as an addition to the workflow is not just a sales tactic. It reflects where the technology genuinely adds the most value with the least risk.
How the Objections Change When the Framing Changes
Once you reframe AI as something that connects to an existing workflow instead of something that replaces it, the entire objection landscape shifts. We already built something, which used to be a polite way of saying no, becomes an opening, because the right response is that this integrates with what you built rather than asking you to replace it. We have bigger priorities right now stops being a deflection, because the honest answer is that this does not require a major project or a dedicated implementation team pulled off other work. It adds a capability to what the team is already doing, on the timeline they are already running. Our process is custom and would not translate, which is one of the most common objections I hear from lenders with specialized underwriting models, becomes far less threatening once the framing is that the tool learns the process that already exists rather than imposing a generic one on top of it.
None of this is about being clever with language. It reflects a genuine difference in how the technology is actually deployed. A lending organization that has spent years refining a document collection workflow for a specific loan product, whether that is a CDFI managing multiple funder reporting requirements or a commercial real estate lender with a construction draw process full of specific triggers, has real reasons for the process looking the way it does. Good AI implementation respects that. It does not ask the organization to conform to a generic workflow designed for a different kind of lender. It observes what the team already does and removes the manual steps inside that specific process, which is a very different proposition than asking anyone to change how they operate.
What This Means for Evaluating AI Honestly
The practical lesson for any lending organization evaluating AI capability right now is to demand specificity before agreeing to evaluate anything. Not a general pitch about what AI can do across the lending lifecycle, and not a demo built around a hypothetical borrower that has nothing to do with the loan products the team actually originates. The useful question is much narrower. Which specific step in our specific workflow does this eliminate or accelerate. Where does the output land. Does the underwriter or processor have to change how they work to benefit from it, or does the benefit show up inside the screen and the queue they already use every day.
That level of specificity is what separates AI capability that actually gets adopted from AI capability that gets piloted once, generates some interesting results, and then quietly gets shelved because nobody wants to be the one who forces the team through a second round of retraining. I have watched both outcomes happen at organizations with very similar starting points and very similar technology. The difference was almost never the quality of the underlying AI model. It was whether the implementation respected the workflow the team had already built or asked the team to abandon it.
This also has implications for how a digital transformation initiative should be sequenced inside a lending organization. Leaders who are building a broader modernization roadmap, whether that involves consolidating systems onto a platform like an alternative lending platform built for the complexity of specialty finance or simply trying to get better visibility across origination and servicing, should treat AI capability as something layered on top of a stable operational foundation, not as the foundation itself. Trying to introduce transformative AI into an organization that is still running on fragmented spreadsheets and disconnected systems usually fails, not because the AI does not work, but because there is no stable, consistent workflow for it to plug into. The organizations that get the most value from AI capability are almost always the ones that had already done the harder work of standardizing their process first, so that the AI has something real and repeatable to attach itself to.
The Underlying Point
Lending organizations are not rejecting intelligence. They are protecting the operational capability they have already built, often through years of trial and error, internal negotiation, and hard-won institutional knowledge. That protectiveness is not an obstacle to modernizing a lending operation. It is actually a sign of a well-run one. The organizations that get this right are not the ones that convince a skeptical team to trust a new technology. They are the ones that show a confident, experienced team exactly how a new capability fits inside the process they already trust, without asking them to give any of it up. That is a much harder thing for a vendor to demonstrate than a generic AI pitch, but it is the only version of the conversation that actually leads anywhere.
Blog
Where AI Actually Delivers Value in Lending Operations
One of the most common questions I get from lending executives right now is not whether AI is relevant to their business. Most of them have already accepted that it is. The real question is where to start. And I think that is actually the right question, because the answer is not obvious, and the wrong starting point leads to pilots that never scale into anything real.
I spend a lot of my time in conversations with COOs, Heads of Lending, and digital transformation leaders at specialty and commercial lenders. Almost every one of them is under pressure to have an AI strategy. Almost none of them want to gamble a budget cycle on a flashy proof of concept that never makes it into production. That tension is understandable, and it is also solvable, because the data I am seeing across these organizations points to a small set of use cases that consistently generate real operational value and that are achievable on modern lending platforms today.
None of these five use cases are the most dramatic AI applications you will read about in a general technology article. There is no autonomous underwriting engine replacing your credit team, and there is no chatbot approving loans while everyone sleeps. What these five use cases have in common is something more useful for an operations leader: they eliminate specific, measurable manual work that lending teams perform every single day, and they do it in a way that scales.
Document extraction: the starting point for a reason
The first use case, and usually the right place to start, is document extraction. A processor receives a bank statement, a tax return, a financial statement, or a business license and manually enters the relevant data points into the loan origination system. That work is repetitive, it is error-prone when done at volume, and it is almost entirely mechanical. AI document extraction reads those documents and populates the system automatically, removing the manual entry step altogether.
The accuracy of extraction depends heavily on the consistency of the document format. Standardized documents, like tax returns or bank statements from major institutions, extract cleanly because the structure is predictable. Highly variable documents, like rent rolls from a diverse pool of borrowers using different property management software, are harder. But even imperfect extraction that correctly handles eighty percent of cases automatically represents a significant time savings at scale, and it is the reason this use case tends to be the first one lenders deploy successfully. It is bounded, it is measurable, and the return on the investment is visible within a single origination cycle.
Underwriting file preparation shifts where time is spent
The second use case is underwriting file preparation. Before a file ever reaches an underwriter, it needs to be complete. Every required document needs to be present, every key data point needs to be extracted, and preliminary verification checks need to be run. Traditionally, that preparation work falls to a processor or a junior analyst, and it consumes hours that have nothing to do with credit judgment.
An AI preparation assistant built into the loan origination workflow can gather documents, identify what is missing, extract key financial metrics, run initial verification checks, and deliver a prepared package directly to the underwriter. The underwriter’s time is then spent evaluating credit risk, not assembling a file. This is a meaningful distinction for lending organizations trying to scale volume without proportionally scaling headcount. It does not change who makes the credit decision. It changes how much of an underwriter’s day is spent on decisions versus administration.
Missing item detection replaces the static checklist
The third use case is missing item detection. Most lending operations still rely on some version of a manual checklist, where a processor checks a list of required documents against what has actually been received. That process is fine when volume is low and files are simple. It breaks down when volume increases or when loan products introduce complexity, because checklists do not update themselves and they do not communicate status to anyone outside the person holding the list.
An AI system that continuously monitors the file and surfaces what is still needed changes that dynamic entirely. Instead of a static checklist, the system tells you the file is eighty-two percent complete and identifies the three specific items still outstanding. That level of real-time visibility eliminates a significant amount of back-and-forth communication between processors, borrowers, and underwriters, and it is one of the clearest examples of workflow automation actually reducing operational friction rather than just adding another dashboard nobody checks.
Next best action guidance reduces navigation, not judgment
The fourth use case is next best action guidance. At any point in the underwriting workflow, the person handling a file should know exactly what needs to happen next. In practice, that is rarely true. Operations teams spend real time simply figuring out where a file stands and what the appropriate next step is, especially when a team member is juggling dozens of files with different conditions attached to each one.
An AI next best action system looks at the current state of the file and recommends the specific next step. That might mean requesting a specific document, rerunning a verification, escalating to underwriting, or sending a particular communication to the borrower. It is important to be precise about what this does and does not do. It does not replace the team member’s judgment about how to handle the situation. It eliminates the navigation and decision overhead that slows throughput, which is a different and more achievable goal than replacing human decision-making. For lending organizations evaluating AI for lending operations, this distinction matters, because it sets realistic expectations for what the technology will actually change.
Red flag detection focuses attention where it belongs
The fifth use case is red flag detection. Instead of an underwriter reading every page of every document looking for issues, an AI system scans the file and surfaces specific anomalies. That might include inconsistent revenue figures across different financial documents, ownership discrepancies between entity documents, unusual deposit patterns in bank statements, or documents that are stale and fall outside their validity window.
The underwriter still reviews the file and makes the judgment call on every flagged item. What changes is that they are directed immediately to the things that warrant attention, rather than having to discover them through a full, unguided document review. This is particularly valuable for lenders managing complex or high-volume portfolios, where the risk is not that an underwriter lacks the skill to catch an issue, but that the sheer volume of documentation makes consistent, exhaustive review difficult to sustain over time.
What these five use cases have in common
These five use cases share a common characteristic that I think is the most important takeaway for any lending executive building an AI roadmap. They are all workflow problems, not intelligence problems. The value of AI in each case is not that it thinks better than a human underwriter or processor. It is that it does consistent, rules-based, mechanical work faster and more reliably than a human can do it at scale.
That distinction should shape how lending organizations prioritize their initial AI investments. If you are looking for a use case that will impress a board with its sophistication, none of these five will do that on their own. If you are looking for use cases that will measurably reduce the manual work slowing down your underwriting, document processing, and portfolio monitoring, this is exactly where to start. The lenders I see getting real traction with AI are not the ones chasing the most advanced application. They are the ones who identified the specific manual bottleneck in their loan origination workflow and applied a bounded, well-scoped AI capability directly against it.
There is also a sequencing lesson embedded in this list. Document extraction and missing item detection tend to be easier to deploy and validate first, because the inputs and outputs are relatively well defined. Underwriting file preparation and next best action guidance require deeper integration into the operational workflow itself, which is why they tend to follow rather than lead. Red flag detection often benefits from having the other four already in place, since a system that has already extracted and organized the file’s data has a much stronger foundation for identifying anomalies within it. Lenders who try to jump straight to the most sophisticated use case, without the underlying data and workflow structure in place, are usually the ones who end up with a pilot that never scales.
None of this happens automatically just because a lending organization adopts a platform with AI capability built in. The underlying loan origination software has to be structured in a way that supports these workflows in the first place. Data needs to flow consistently between origination, underwriting, and servicing. Documents need a consistent home and a consistent taxonomy. Workflow stages need to be defined clearly enough that a system can actually determine what the next best action is. This is the part of the conversation that gets skipped when AI is discussed as a standalone feature rather than as a capability that sits on top of a well-structured operational platform.
That is ultimately the point I try to make to lending executives asking where to start. The question is not which AI tool to buy. The question is which manual bottleneck in your underwriting and origination process is costing you the most time and consistency today, and whether your current platform can support a targeted AI capability against that specific bottleneck. Start there, prove the operational value, and expand from a position of evidence rather than ambition. That is how these five use cases move from interesting demonstrations to permanent, load-bearing parts of a lending operation.
Blog
Why ‘AI Underwriting Assistant’ Beats ‘AI Underwriter’
I have sat in enough rollout meetings now to notice a pattern that has nothing to do with the technology itself. It has to do with what the technology is called. Two lending organizations can deploy the exact same AI capability, built on the exact same underlying models, and get completely different reactions from their credit teams based on nothing more than the label attached to it. Call it an AI underwriter and you get defensiveness, skepticism, and quiet resistance. Call it an AI underwriting assistant and the same people who bristled at the first term start asking how soon they can use it.
This is not a minor communications footnote. For any lender thinking seriously about digital transformation, the language you choose to describe AI internally is one of the most consequential decisions in the entire rollout, and it is one that almost nobody treats with the seriousness it deserves.
The Reaction Is Rational, Not Emotional
When a lending organization announces it is implementing an AI underwriter, experienced credit staff hear something specific and concrete. They hear that a core piece of their professional value, the pattern recognition built across hundreds or thousands of deals, the judgment calls that come from having seen a borrower’s story go wrong in a dozen different ways, is being handed to a machine. That is not paranoia. It is an accurate reading of what the word “underwriter” implies. An underwriter renders a credit decision. If AI is the underwriter, the natural conclusion is that AI is now rendering the decision, and the human’s role has been reduced to oversight or, worse, made redundant.
The defensive reaction that follows is not a training problem or an attitude problem. It is a logical response to an accurate interpretation of the language being used. I think this point gets missed constantly in AI for lending conversations, because vendors and even well-intentioned internal champions treat resistance as something to be managed away with better change communication, rather than something to be addressed by choosing more accurate language in the first place.
Now change one word. Announce the same technology as an AI underwriting assistant, and the entire frame shifts. An assistant does not make decisions. An assistant does preparation work: gathering the borrower’s financial documents, extracting the data points that matter, identifying what is missing before a loan officer has to ask for it a second time, flagging early risk indicators so nothing gets buried on page fourteen of a file. The underwriter still underwrites. They just spend less time assembling the file and more time doing the part of the job that actually required their expertise in the first place.
Same technology, same outputs, completely different reception. That gap is not a matter of spin. It is a matter of accuracy, because in the vast majority of implementations I have seen across specialty and commercial lenders, “assistant” is actually the more honest description of what the AI is doing.
Where AI Genuinely Adds Value in the Lending Process
The highest-value AI applications in lending are not the ones that attempt to replace judgment. They are the ones that augment it by taking mechanical, repetitive, and error-prone work off a human’s plate. Document extraction is the clearest example. Pulling structured data out of tax returns, bank statements, rent rolls, and financial statements is exactly the kind of task where AI can operate faster and more consistently than a person doing it manually for the two-hundredth time that month, without the fatigue-driven errors that creep into manual data entry late in the day.
Missing item detection is another. A well-trained AI underwriting assistant can compare an incoming file against the documentation requirements for a given loan type and immediately surface what is absent, rather than waiting for a human reviewer to notice the gap three days into the review cycle. Early risk flagging works the same way. The system is not deciding whether a borrower is creditworthy. It is surfacing the anomalies, inconsistencies, or red flags that deserve a closer look from someone who understands the context well enough to interpret them.
In every one of these cases, the AI is doing assembly and pattern-matching work, not judgment work. That is an important distinction because it maps directly onto where AI is reliable today and where it is not. Assembly and pattern-matching are workflows where consistency and speed genuinely improve outcomes. Judgment, particularly the kind of judgment that weighs qualitative context against quantitative signals, benefits from experience in a way that current AI systems cannot fully replicate, and it is the part of the process a lending organization should be most careful about automating away.
The Narrower Case for Full Automation
I want to be careful here, because I am not arguing that AI should never touch a credit decision. There are narrow, well-defined use cases, typically involving smaller, highly standardized loan products with thin credit boxes, where a greater degree of automated decisioning makes sense and has been used successfully for years, often under names like automated underwriting rather than AI underwriting. But the range of situations where full automation of a credit decision is appropriate is considerably narrower than a lot of vendor pitches suggest, and it requires a level of governance, model validation, and ongoing monitoring that many organizations underestimate when they first evaluate the technology.
The reason for that caution is not theoretical. It is regulatory and practical. In a regulated lending environment, someone is accountable for every credit decision the organization makes. When an examiner, an auditor, or a borrower disputing an adverse action asks why a loan was approved or declined, “the model decided” is not an answer that satisfies anyone. It does not satisfy compliance. It does not satisfy fair lending review. It does not satisfy a borrower who has a legal right to understand the basis for a decision that affects their business or their life. Human accountability for credit decisions has not gone away, and I do not think it is going away anytime soon. What AI actually changes is how efficiently a human can exercise that accountability, not whether the accountability exists.
This is where the underwriter versus assistant distinction becomes more than a branding exercise and turns into an actual design principle for how AI should be deployed inside a lending organization. If you build and talk about your AI as an underwriter, you are implicitly setting an expectation, internally and potentially externally, that the system is making decisions. That is a much harder position to defend to a regulator, and it sets your credit team up to either overtrust the system’s outputs or resent its presence. If you build and talk about it as an assistant, you are setting an accurate expectation that a human is still exercising judgment and remains accountable for the outcome, with AI doing the preparatory work that makes that judgment faster and better informed.
Framing Determines Whether Teams Adopt or Resist
I have watched this play out on the ground enough times to be confident it is not a coincidence. Credit teams that understand an AI tool as something that prepares a cleaner, more complete file for their review engage with it. They use it. They give feedback on what it is missing or getting wrong, which is exactly the input a lending organization needs to improve the tool over time. Credit teams that experience the same tool as something encroaching on their professional judgment tend to work around it instead of with it. They find informal ways to avoid depending on outputs they were never given a reason to trust, and the organization ends up with an expensive system that nobody actually uses the way it was designed to be used.
That gap between adoption and quiet resistance is not fixed by a better training session after launch. It is set months earlier, in how the initiative was framed the first time someone described it to the team. Getting that framing right before rollout is one of the most important and most underrated parts of any AI implementation in a lending organization, and it deserves the same deliberate planning that goes into the technical architecture, the data migration, or the workflow configuration.
For any COO or Head of Lending thinking through a digital transformation roadmap that includes AI, I would put the naming and framing decision on the list of things to get right before the first pilot goes live, not something to patch after the fact. Talk to your underwriters before you talk to your vendor about terminology. Ask them what they actually spend their time on today, and be honest about which parts of that work are mechanical assembly versus which parts genuinely require their judgment. Build the language of the rollout around that honest inventory, not around what sounds most impressive in a sales deck.
What This Means for Lending Platform Decisions
This distinction also matters when evaluating an alternative lending platform or any lending software with embedded AI capabilities. Ask a vendor to walk you through exactly which parts of the underwriting workflow their AI touches, and be skeptical of any answer that is vague about where the human judgment step occurs. A platform built with this augmentation principle in mind should be able to show you, concretely, where document extraction happens, where missing item detection surfaces to a human reviewer, where risk flags are presented as inputs rather than conclusions, and where the actual credit decision is made by a person who can be held accountable for it.
The lenders I have seen get the most value out of AI are not the ones chasing the most aggressive automation claims. They are the ones who understood early that the goal was never to remove their underwriters from the process. The goal was to give experienced underwriters better files, faster, so their judgment could be applied to more deals with more consistency. That is a fundamentally different pitch than replacing judgment with a model, and it is the pitch that actually earns buy-in from the people who have to live with the tool every day.
Language is not a soft consideration in an AI rollout. It is one of the first operational decisions you make, and it will shape whether your organization ends up with a tool your team fights against or a tool your team helps build. Get the name right, and you will find the adoption conversation is a lot shorter than you expected.
Blog
Why Lending Leaders Shouldn’t Start With AI Tools
I have had a version of the same conversation with a dozen different lending operations leaders over the past year. It usually starts the same way. Someone on the executive team, often a COO or a Head of Lending, says something like “we need to figure out our AI strategy.” And within a few minutes, the conversation drifts toward a list of AI vendors, feature comparisons, and demos scheduled for next month.
I want to push back on that starting point, because I think it is the single most common mistake lending organizations make when they approach AI. Nobody wakes up in the morning and decides they need AI. That is not how lending executives actually think about their day. What they say, when you ask them directly, is something much more specific. We need to reduce clicks. We need our underwriters to stop manually copying information from one system into another. We need to stop losing files in someone’s email inbox. We need our credit team spending their time reviewing credit, not assembling packages and chasing down documents.
Those are the real problems. AI is one way to solve them. But the order in which you approach that problem determines whether your AI investment actually changes how your organization operates, or whether it becomes a pilot program that quietly disappears from the roadmap a year from now.
The Wrong Question Leads to the Wrong Evaluation
When a lending organization opens its AI evaluation by asking “which AI tools should we buy,” it almost always ends up in the wrong conversation. The team starts comparing platforms on the basis of how sophisticated the underlying technology looks in a demo. They get excited about capabilities that sound impressive in a sales presentation. They ask about model architecture, about accuracy benchmarks, about whether a vendor uses one large language model or another.
None of that is irrelevant, exactly. But it is downstream of the actual question that matters, and starting there almost guarantees that the technology never fully connects to a specific operational pain point. And when AI tooling does not connect to a pain point that your team feels every single day, it gets adopted slowly, used inconsistently across the organization, and eventually deprioritized the moment something more urgent shows up on someone’s desk. I have watched this happen at lenders with real budget and real intent. The tool was not bad. The starting question was.
This is not a small distinction. It is the difference between technology adoption and technology novelty. A novel tool gets a few champions inside an organization who use it enthusiastically for a few months. An adopted tool becomes part of how the whole operation runs, because it eliminates something painful that everyone in that role has to deal with regardless of how they feel about new technology.
Starting From the Workflow Instead of the Technology
The lending organizations that are getting AI adoption right are starting from a completely different place, and it is a place any operations leader already knows how to think about. They are asking where their team spends the most time on work that does not require human judgment. What do people click on repeatedly throughout the day. What information gets manually re-keyed from one system into another. What causes a loan file to sit in a pending status while someone tracks down a missing document or waits on a callback. What slows underwriting down before a credit decision ever gets made.
Those questions do not sound like an AI strategy conversation. They sound like an operations review. And that is exactly the point. Workflow problems have specific, identifiable AI solutions attached to them, but you can only find the right solution if you have correctly identified the problem first. Skipping that step and jumping straight to evaluating AI platforms is a little like hiring a contractor before you have decided what room needs to be renovated. You might end up with a beautiful result, but it is unlikely to be the result you actually needed.
I want to be specific here, because this is where the abstraction usually breaks down in these conversations. Document extraction is a useful example, because it is one of the clearest cases where the framing genuinely changes the outcome. No lending executive has ever called me and said “we need AI document extraction.” But every single lending operations leader I have talked to has felt the specific pain of a processor spending forty-five minutes manually entering data from a bank statement, a tax return, or a financial statement into their loan origination system. That is a real, measurable, felt problem. When you frame the AI solution as eliminating that forty-five minutes per document, the conversation changes immediately. It stops being about AI as a category and starts being about giving a processor back three or four hours a day that they were spending on data entry instead of on the parts of their job that actually require judgment.
That reframing matters because it changes who signs off on the project, how success gets measured, and how quickly the organization actually uses the tool once it is live. A project framed around “reducing manual document entry time by X hours per week” gets measured against a number operations leadership already tracks. A project framed around “implementing AI” gets measured against enthusiasm, which fades.
The Same Logic Applies Beyond Document Extraction
Document extraction is the easiest example because it is so visible and so universally painful, but the same logic applies to a wider set of workflow problems that show up across origination and servicing. Missing document detection is another good case. Loan processors spend a meaningful amount of time simply checking whether a file is complete, chasing down a signature page or a missing insurance certificate, and following up with borrowers or brokers to close the gap. That is rule-based, repetitive work. It does not require years of underwriting experience. It requires consistency and speed, which is exactly what AI-driven workflow tools are good at providing.
Underwriting preparation follows the same pattern. Long before a credit decision gets made, someone has to assemble the file, verify that the numbers tie together, flag inconsistencies, and get the package into a reviewable state. That preparation work is where a lot of underwriting time actually goes, and it is largely mechanical. Portfolio monitoring is similar at the servicing end. Someone has to track covenant compliance, watch for early warning signs across a portfolio, and flag accounts that need attention before they become a real problem. That is exactly the kind of ongoing, pattern-based monitoring that benefits from automation, because it does not rely on judgment until an exception actually gets flagged for a human to review.
In every one of these cases, the underlying technology is AI. But the value proposition that actually gets budget approved and actually gets adopted by the team doing the work is operational, not technological. Nobody in operations cares what model is running underneath the tool. They care whether their week got easier and whether their team is spending time on the parts of the job that matter.
Leading With Operational Value Changes the Adoption Curve
I have started paying close attention to which lenders successfully scale an AI tool past the pilot stage and which ones stall out after an initial rollout, and the pattern is remarkably consistent. The lenders who lead with operational value rather than technology novelty are the ones who get genuine adoption. The lenders who lead with the technology itself tend to get a proof of concept that never becomes part of daily operations.
Part of the reason is straightforward change management. If you tell your credit team “we are implementing an AI underwriting tool,” you have told them almost nothing about how their day changes, and you have introduced a category of technology that a fair number of experienced underwriters are skeptical of, often for good reason given how much AI hype they have already absorbed from outside the industry. If you tell that same team “we are eliminating the manual data entry step that currently delays every file by half a day,” you have told them exactly what changes, and you have framed it around a problem they already want solved. The second framing gets buy-in. The first framing gets questions and hesitation.
The other reason is measurement. Operational framing gives you a baseline and a target. You know how many hours per week your team currently spends on manual entry, how many files sit in a pending state waiting on documents, how long underwriting preparation currently takes from submission to a reviewable package. You can measure whether the AI tool actually moved those numbers. Technology framing does not give you that baseline, because “how is the AI going” is not a metric. Operations leaders who cannot measure the impact of a new tool struggle to defend continued investment in it when budget conversations come around, and that is often exactly when a promising pilot quietly disappears.
The Practical Question Every Lending Executive Should Be Asking
If you are a COO, a Head of Lending, or a digital transformation leader at a specialty lender thinking about AI right now, the practical question is not “what AI should we implement.” It is a more familiar and more useful question: where does our team spend the most time on repetitive, rule-based work that does not require experienced human judgment. Walk through origination and servicing end to end and answer that question honestly, department by department. Talk to the people doing the work, not just the managers overseeing it, because the person entering data from a bank statement into your loan origination system every day has a much clearer view of where the time goes than a dashboard does.
The answer to that question is your AI roadmap. It will be more specific than anything a vendor’s feature list will hand you, because it is built from your own operation rather than from a generic sales pitch. It will also be easier to get approved and easier to defend later, because it is framed in terms your organization already uses to measure operational performance rather than in terms of a technology category that means something slightly different to everyone in the room.
This is not an argument against AI. It is an argument for sequencing. Identify the workflow problem first, with real specificity about where time and accuracy are being lost. Then let that problem point you toward the right AI capability to solve it, whether that is document extraction, missing document detection, underwriting preparation, or portfolio monitoring. The lending organizations getting this right are not the ones with the most advanced AI. They are the ones who correctly diagnosed the operational problem before they went shopping for a solution.