Blog
Why Lending Organizations Are Splitting Into Two AI Camps
I keep having the same conversation with lending executives, and I think it deserves a direct article because of how stark the divide has become. I am not talking about a divide between organizations that are ahead on technology and organizations that are behind. That gap has always existed and always will. What I am hearing now is something different — a genuine philosophical split about whether AI belongs in a lending organization at all, and that split is showing up in real strategic planning conversations, sometimes between people sitting on the same board.
Two Positions, Same Room
Here is what I keep hearing. One organization says AI is a company mandate. We are going all in. We are looking at every workflow, every process, every role, and asking how AI can make it faster, cheaper, and more consistent. Underwriting, document review, servicing, collections, reporting — nothing is off the table. The other organization says AI has no presence here. Full stop. We looked at it, we explored it, and we decided it is not ready and not appropriate for what we do. We will keep watching, but we are not moving.
Both of these positions are held by sophisticated people who have thought carefully about their organizations. Neither camp is being careless or naive. And in my conversations, I have come to believe both of them are partially right and both are missing something important. That is the more useful way to think about this divide — not as a contest to determine who is correct, but as two incomplete answers to the same question.
What the All-In Camp Gets Right
The organizations going all in are right about one fundamental thing: AI is not optional over a long horizon. The competitive dynamics of lending are shifting quickly enough, and the productivity gains from applying AI to the right workflows are real enough, that an organization ignoring AI entirely is taking on real competitive risk over a five to ten year window. Document-heavy processes, data extraction, portfolio monitoring, and pattern recognition across large volumes of loan data are exactly the kind of work AI is suited for, and lenders who build capability in these areas now will have a structural advantage over lenders who wait.
Where the all-in camp runs into trouble is governance. Moving fast across every workflow at once, without a clear framework for what data is going into these tools, how outputs are validated, and who is accountable for decisions influenced by AI, creates real exposure. In a regulated lending environment, that exposure is not abstract. It shows up as data handling questions from examiners, as compliance gaps in underwriting documentation, and as operational dependence on tools that were adopted faster than they were vetted. I have seen organizations get most of the way through an ambitious AI rollout only to discover that nobody had mapped which processes actually touch protected borrower data or how a decision made with AI assistance would be defended in an audit. That is not a reason to stop. It is a reason to slow down the parts of the rollout that deserve more scrutiny while continuing to move on the parts that do not.
What the Hold-Back Camp Gets Right
The organizations holding back are right about something too, and it is worth taking seriously rather than dismissing as fear of change. Most AI implementations in lending today are overpromised and underdelivered. The underlying tools are real and improving quickly, but the number of use cases that work reliably, consistently, and defensibly in a regulated lending environment is narrower than most vendor pitches suggest. A model that performs well on a demo data set is not the same as a model that performs well on your actual loan portfolio, with your actual document formats, your actual borrower population, and your actual exception cases. Lenders who have looked closely at specific tools and concluded that the reliability is not there yet for their use case are making a defensible judgment, not an outdated one.
The risk on this side of the divide is different but just as real. Waiting for perfect clarity before doing anything creates a window during which competitors are building operational advantages that become harder to close the longer the window stays open. AI adoption in lending is not just about the tool itself. It is about the organizational learning that happens while using it — the data cleanup, the process documentation, the internal expertise in evaluating vendor claims, the muscle memory of running a structured pilot. Organizations that wait for the technology to be perfect before starting also delay the organizational learning that has to happen before any technology can be used well. That learning curve does not compress just because an organization decides to move quickly once it finally commits.
The Question Neither Camp Is Asking
What I keep seeing in the organizations navigating this best is that they are not trying to answer either version of the big question. They are not asking should we adopt AI, and they are not asking should we avoid it. They are asking a narrower, more operational question: which specific workflows in our lending operation would benefit from AI augmentation right now, what is the data governance framework that makes that adoption responsible, and how do we build the organizational capability to evaluate new AI use cases systematically as the technology matures.
That reframing matters more than it sounds like it should, because it turns an all-or-nothing cultural debate into an operational planning question. A cultural debate about whether an organization is an AI company or not tends to produce a stalemate, because it is really a debate about identity and risk tolerance, and those debates rarely resolve cleanly in a single meeting. An operational planning question about which three workflows would benefit from augmentation in the next twelve months produces a list, an owner, a timeline, and a way to measure whether it worked. For a COO or Head of Lending at a community lender or specialty finance company, that second kind of question is exactly the kind they are equipped to answer, because it looks like every other operational decision they have made — evaluate the workflow, understand the constraint, pilot the change, measure the result, scale what works.
Why This Maps Onto Digital Transformation More Broadly
I would go a step further and say this pattern is not unique to AI. It is the same pattern I have seen play out with every wave of digital transformation in lending over the past decade, including the shift away from spreadsheet-driven origination and the move toward platforms like Salesforce-native loan origination and servicing systems. Organizations that treated the decision as should we modernize or not tended to get stuck in the same kind of stalemate. Organizations that asked which specific processes are creating the most manual work, the most reconciliation burden, or the most reporting risk right now, and started there, tended to build momentum and organizational trust in the process. AI adoption is following the same script, just compressed into a faster timeline because the underlying technology is moving faster than core lending infrastructure typically does.
This is also why governance and platform architecture matter more than the AI conversation alone suggests. An organization running loan origination and servicing on a fragmented set of disconnected tools is going to have a much harder time applying AI responsibly than an organization running on a unified platform with clear data lineage. If you do not know where your data lives, how it flows between systems, or who has access to it at each stage of the loan lifecycle, you are not in a position to answer the governance half of the operational question, no matter how promising a specific AI use case looks. That is not an argument for adopting any particular platform. It is an observation that the lenders who are navigating the AI divide most calmly tend to be the ones who already have their operational and data foundation in reasonable shape, because they are not trying to solve a data governance problem and an AI adoption problem at the same time.
The Practical Takeaway
If your organization is heading into a strategic planning conversation about AI, the most productive frame is not how do we feel about AI as a company. That question invites a philosophical debate that tends to split a room rather than move it forward. The more productive frame is three specific questions. Which three workflows would benefit most from AI augmentation in the next twelve months. What does responsible adoption look like for a regulated lender, specifically around data handling, documentation, and audit defensibility. And who owns that decision going forward, so that the organization is not relitigating the same debate every quarter as the technology continues to change.
Those three questions produce an action plan with an owner and a timeline. The all-or-nothing debate produces a stalemate that gets revisited at every board meeting without ever quite resolving. I have watched both versions of this conversation play out across enough lending organizations now to be confident that the operational framing wins, not because it is more sophisticated, but because it is the only version of the conversation that actually produces a decision. The organizations that figure this out are not the ones with the boldest AI mandate or the most cautious AI ban. They are the ones who stopped arguing about identity and started arguing about workflows instead.
Blog
Why Lean Lending Organizations Need an Implementation Partner
I have had a version of the same conversation with enough CDFI executives and community lending leaders that I no longer think of it as an anecdote. It is a pattern. Someone who has just come through a complex platform implementation pulls me aside, usually after the formal presentation is over, and says something like: the software is not the problem. We just cannot keep up with it.
That comment gets dismissed too quickly in most vendor conversations, including ones I have been part of. It sounds like a training issue or a change management issue, something that will resolve itself once the team gets more comfortable with the system. But when you sit with it, the real issue is structural, and it has almost nothing to do with the quality of the platform. It has to do with organizational capacity.
The infrastructure gap nobody talks about
When a large commercial bank or a well-capitalized specialty finance company implements a Salesforce-native lending platform, they almost always have a layer of internal infrastructure built around the project before it even starts. There is a dedicated Salesforce administrator who understands the platform’s data model. There is a business analyst or product owner whose job includes translating operational needs into configuration decisions. There is often a project management office that owns the vendor relationship, tracks every open issue to resolution, runs a regular cadence of check-ins, and makes sure nothing sits unaddressed for long.
That internal layer does something specific and easy to underestimate: it absorbs complexity. A sophisticated configurable platform generates a constant stream of small decisions, questions, and adjustments. Which fields should be required at which stage of the loan file. How a new servicing feature should map to the organization’s existing payment workflows. Whether a support ticket represents a bug, a training gap, or a legitimate configuration request. In a well-resourced organization, someone’s job is to sit with those questions daily and keep the platform aligned with how the business actually operates.
A CDFI with fifteen people on staff does not have that layer, and it is not because they made a poor staffing decision. It is because their mission and their funding model do not support it. The person responsible for the lending platform at a lean organization is usually also responsible for compliance reporting to multiple funders, supporting loan officers who are fielding borrower calls, and a dozen other operational duties that do not disappear just because a new system went live. Platform ownership is one line item on a job description that already has fifteen line items.
Where the friction actually lives
Once you see the capacity gap clearly, the day-to-day symptoms make a lot more sense. A support ticket goes unanswered for two weeks and nobody escalates it, not because the vendor does not care but because nobody on the client side has the bandwidth to chase it. A new feature ships and nobody evaluates whether it is relevant to the organization’s workflow, so it sits unused indefinitely. A configuration decision that would take twenty minutes to make gets deferred meeting after meeting because something more urgent is always in front of it.
Over time this produces a very specific and very frustrating dynamic on both sides of the relationship. The vendor’s support team ends up fielding reactive tickets instead of engaging proactively with the account, because reactive tickets are the only signal coming through. The client team, meanwhile, starts to feel like the platform is not delivering the value they were promised during the sales process, even though the platform itself has not changed. What has actually happened is that the gap between what the platform is capable of and what the organization has the capacity to operationalize has quietly widened, month over month, until it becomes visible as dissatisfaction.
This is worth sitting with because it reframes a problem that gets misdiagnosed constantly in our industry. When a lean lending organization is unhappy with a platform eighteen months after go-live, the conversation almost always jumps to whether the software was the wrong choice. In my experience, that is rarely the actual diagnosis. The platform is very often still the right fit for the organization’s lending model. What was missing was never re-evaluated: the internal or external infrastructure needed to keep the platform aligned with the organization as both evolve.
What an implementation partner actually does
The model I have seen work consistently well for lean lending organizations is the deliberate addition of an experienced Salesforce implementation partner positioned between the vendor and the client. I want to be precise about what that role is, because it gets confused with general IT consulting, and it is not the same thing.
A general IT consultant can help with a server migration or a network issue. An implementation partner who understands lending operations on Salesforce is doing something much more specific. They know the platform’s data model and configuration logic well enough to make changes without waiting on a vendor engineering queue for every small adjustment. They understand loan origination and servicing workflows well enough to know what a given configuration decision will actually mean for a loan officer’s daily work, not just what it means technically. And critically, they sit close enough to the client’s day-to-day operations to notice a problem before it becomes a crisis, rather than hearing about it three weeks later in a quarterly business review.
In practice this means the implementation partner manages the vendor relationship on behalf of the client. They are the ones tracking open tickets to resolution, evaluating new platform features for relevance, and making the dozens of small configuration calls that would otherwise sit in someone’s inbox indefinitely. They carry institutional knowledge about how the platform behaves and how the organization uses it, which is exactly the kind of knowledge a fifteen-person team does not have the bandwidth to build and maintain on its own.
Why adding a layer reduces friction instead of creating it
There is a natural instinct to resist this idea. Most of us have learned, correctly in a lot of contexts, that removing intermediaries improves communication and speed. Fewer layers between a problem and its resolution usually means faster resolution. So the suggestion to add a layer between the vendor and the client can sound like it is working against that principle.
But the friction in this specific scenario was never really between the vendor and the client. Vendors want their platform used well and clients want their operations to run smoothly; those interests are aligned. The actual friction is between the complexity of a sophisticated, configurable platform and a lean organization’s capacity to absorb that complexity day to day. An implementation partner does not sit between two parties who are working against each other. They sit in the gap between a platform’s potential and an organization’s bandwidth, and they close that gap directly.
This is why the model holds up even though it looks counterintuitive on paper. The partner is not adding a communication step. They are removing the burden of translation that was previously falling, unevenly and inconsistently, on whichever staff member happened to have the platform on their plate that week. Once that translation work has a dedicated owner who knows the platform and the operating context well, the vendor gets a more informed point of contact, and the client team gets consistent, proactive attention instead of the occasional emergency escalation.
What this means for a CDFI evaluating a platform
If you are a COO, a head of lending, or a digital transformation lead at a CDFI or another lean community lending organization evaluating a Salesforce-native lending platform, the practical takeaway is straightforward, even if it is uncomfortable to say out loud during a vendor selection process. The software evaluation is only half the decision. The other half is an honest assessment of your organization’s capacity to operationalize whatever you select, and a plan for closing that capacity gap if it exists.
That does not mean the platform is wrong for you if your team is lean. Some of the most operationally sophisticated CDFIs I have worked with have fifteen or twenty staff members total. It means the implementation partner question deserves the same rigor in your evaluation process as the platform question itself. Who is going to own the vendor relationship day to day. Who is going to evaluate new features as they are released. Who is going to make the hundred small configuration decisions that a living platform requires over its first year and beyond. If the honest answer is nobody on your current team has the bandwidth, that is not a reason to walk away from a strong platform. It is a reason to plan for the partner who will fill that role before you go live, not eighteen months after you realize the gap exists.
The organizations that get the most out of a complex platform are rarely the ones with the most sophisticated internal technology function. They are the ones who were honest early about what they did not have in-house and built a plan around it. For a lean lending organization, that plan usually includes an implementation partner who knows the platform, understands lending operations, and can absorb the complexity that your team was never staffed to absorb on its own. Get that piece right, and the software you have already chosen has a real chance to deliver what it was capable of delivering all along.
Blog
Why Over-Customizing Loan Origination Software Backfires
I have spent a lot of time in the offices of specialty lenders, CDFIs, and commercial finance companies over the past several years, usually a year or two after they went live on a new loan origination or servicing platform. There is a pattern I keep running into, and it is common enough that I think it deserves a name: the customization hangover. It is one of the most expensive and least discussed mistakes in lending technology, and almost nobody sees it coming until they are already living with the consequences.
How the Customization Hangover Starts
It rarely starts as a mistake. It starts as ambition. A lending organization kicks off an implementation with a clear and often well-researched vision of what they want their operation to look like. The core platform covers most of what they need, but there are gaps. Maybe underwriting needs a workflow that does not exist out of the box. Maybe there are fields specific to a niche lending product, or a servicing process that was built around a legacy system years ago and has become part of the institutional muscle memory. The vendor’s implementation team is capable and accommodating. The client’s team has strong, well-earned opinions about how things should work, usually shaped by years of doing this manually or on a system that no longer fits. And so, without anyone deciding it explicitly, the implementation stops being a configuration project and becomes a build project.
This is the moment that determines whether an organization will be in a strong position three years later or dealing with a system nobody fully understands. Not the moment the contract is signed. Not the moment the platform is selected. The moment the team decides how much of the standard product to trust versus how much to rebuild in their own image before they have ever processed a single real transaction on it.
What the System Looks Like Two Years Later
The pattern I see across lending organizations that have been on a platform for two or more years is remarkably consistent. The system is technically functional. It does what was asked of it. But it has drifted a long way from the vendor’s standard product, and that drift has a cost that compounds over time rather than showing up all at once.
There are custom workflows that nobody fully documented, because documentation felt like a lower priority than hitting the go-live date. There are fields and objects added at the client’s request during implementation, based on assumptions about what the operation would need, that are now the client’s sole responsibility to understand, maintain, and explain to anyone new. There are configurations built for one specific use case, at one specific moment in the organization’s history, that now sit quietly in the environment creating complexity that touches everything downstream, including reporting, servicing, and integrations that were added later.
Then a new team member joins the organization and tries to learn the system. They cannot, at least not from any training material, because half of what they are looking at was never in any training material to begin with. It exists only in the heads of the two or three people who were in the room when it was built. Support tickets that should take a day take a week, because the vendor’s support team has to first reconstruct what was customized before they can even begin diagnosing the actual issue. A new platform release comes out with genuinely useful new capabilities, and instead of being a quick win, the upgrade becomes a project of its own, because every customization has to be tested against every new feature to make sure nothing breaks.
The Real Cost Is Opportunity, Not Just Maintenance
Here is the part that I think gets missed in most conversations about technical debt in lending operations. While the client’s customized environment has been sitting still, the vendor’s core product has kept moving. New capabilities get added. Workflows get refined based on feedback from hundreds of other lenders solving similar problems in slightly different ways. Underwriting logic, document handling, and reporting all improve because the vendor is iterating across a broad customer base, not just one institution’s specific interpretation of its own process.
The uncomfortable truth many organizations eventually face is that the standard version of the platform, two or three years later, is often better than what they built for themselves at the start. Not marginally better. Meaningfully better, in ways that would reduce manual work, improve visibility, and make the system easier to support. But getting back to that standard version requires unwinding years of customization work, and unwinding custom work is never as simple as removing it. Reports depend on custom fields. Downstream integrations depend on custom objects. Staff have built habits around workflows that technically work but no longer match how the vendor’s product, or the rest of the industry, actually operates. The result is a project that feels too large to prioritize, so it gets deferred, and the gap between the client’s environment and the vendor’s evolving product keeps widening.
This is the real cost of over-customization. It is not just the maintenance burden, although that is real and it shows up in every support ticket and every slower response time. The larger cost is the growing distance between what your organization is running and what the industry, and your own vendor, has learned works best. Every year that gap widens, the eventual correction gets more expensive and more disruptive to schedule.
Why This Happens More Often in Lending Than in Other Industries
Lending operations are unusually vulnerable to this pattern, and I think there is a specific reason for it. Lenders, particularly specialty lenders, CDFIs, and commercial lenders managing diverse loan portfolios, tend to believe their process is more unique than it actually is. Every underwriting team has a story about why their credit process cannot be standardized, why their servicing workflow has to accommodate some particular quirk of their borrower base, why their reporting requirements to funders or regulators demand a bespoke structure. Sometimes that belief is correct. Often it is not, or it is only partially correct, and the truly unique part of the process is a small fraction of what ends up getting custom-built.
The problem is that this belief tends to get expressed loudest at the exact moment an organization has the least operational experience with the new platform, which is during implementation, before they have processed a single loan through it. Teams are specifying customizations based on how they used to do things on a legacy system or on spreadsheets, not based on how they will actually operate once the new platform is live and workflows have had a chance to settle. That is backwards. It front-loads the highest-stakes decisions, the ones about system architecture and long-term maintainability, into the period when the organization has the least information to make them well.
What the Organizations That Avoid This Pattern Do Differently
The lending organizations I have seen avoid the customization hangover made a different decision at the start, and it was rarely the more exciting decision in the moment. They started with the standard product. They learned it thoroughly. They went live on the standard workflows, even in cases where the standard workflow felt slightly uncomfortable compared to how they had always done things. They processed real loans, real borrowers, real servicing events, and let the operational experience surface exactly what needed to be different, rather than trying to predict it in advance.
Only after they had that real operational experience did they begin making targeted customizations, and by that point the customizations were informed by evidence rather than assumption. They knew precisely which workflow needed to change, why it needed to change, and what the actual operational impact of that change would be, because they had lived with the standard version long enough to know its real limitations rather than its theoretical ones. That is a fundamentally different starting point than customizing based on what a team thinks it will need before it has used the system at all.
This approach also tends to produce customizations that are smaller, better documented, and more isolated, because they are solving specific, well-understood problems rather than attempting to rebuild an entire process from scratch. A system built this way stays closer to the vendor’s core product over time, which means it benefits more directly from platform improvements, upgrades are less disruptive, and new staff can actually be trained using standard documentation instead of institutional folklore.
Treat Customization as Something Earned, Not Specified
The practical advice I give to any lending organization starting an implementation right now is simple to state and hard to follow, because it requires patience during a phase where everyone is eager to move fast. Resist the urge to rebuild the platform in your own image before you have actually used it. Get the foundation right first. Go live on the standard workflows wherever possible. Process real transactions on them. Let your underwriters, your servicing team, and your operations staff generate real feedback grounded in real use, not in speculation about what they might need.
Then make customizations, and make them deliberately, based on that operational experience rather than upfront specification. Treat customization as something your organization earns through usage, not something you front-load because it is easier to ask for everything during the excitement of a new implementation. A platform built this way, whether you are running loan origination for a CDFI managing multiple funder reporting requirements, a commercial lender with a complex portfolio, or a specialty finance company scaling into new products, will be more maintainable, easier to upgrade, and considerably more likely to still be working well for you three years from now.
The organizations that get this right are not the ones with the least ambitious visions for their technology. They are the ones disciplined enough to sequence that ambition correctly, learning first and customizing second, so the system they end up with reflects what their operation actually needs rather than what it guessed it would need before it had ever gone live.
Blog
Where AI Should and Shouldn’t Make Lending Decisions
I have spent the last several months working on a book about artificial intelligence in lending, and one question keeps surfacing in almost every conversation I have with COOs, Heads of Lending, and digital transformation leaders at specialty and commercial lending institutions. It is not whether AI can do more inside the lending process. At this point, it clearly can, and the pace of what it can do is accelerating quickly. The real question, the one that separates organizations that will get stronger from those that will get burned, is where exactly the line falls between AI that augments the judgment of an experienced lender and AI that quietly replaces that judgment in ways nobody planned for.
This is not an abstract question. It is showing up right now in how lenders are configuring their loan origination software, how they are training staff to interact with AI-enabled tools, and how they are thinking about risk governance as they modernize operations that were built on spreadsheets and manual review. Getting the answer right determines whether AI becomes a durable operational advantage or a liability that does not reveal itself until a bad decision has already happened.
The lending process is not one workflow, it is many
The mistake I see most often is treating the lending lifecycle as a single, uniform workflow and applying the same posture toward AI across all of it. In practice, the lending process is a sequence of decisions with very different characteristics, and those differences matter enormously when you are deciding where AI belongs.
Some decisions in the lending lifecycle are high-volume, repetitive, and governed by clear, definable rules. Others are low-volume, complex, and dependent on the kind of contextual judgment that a credit officer builds only after evaluating hundreds of deals across different market cycles. AI performs very differently in these two environments. Applying it uniformly, as if a rules-based screening step and a complex credit approval carry the same risk profile, is one of the most common and most consequential errors lending organizations make when they start deploying AI tools inside their operations.
The organizations that get this right are not the ones asking whether to adopt AI in lending. They are the ones doing the harder work of mapping their process step by step and asking, honestly, what kind of decision is actually happening at each point.
Where AI is genuinely transformative
On the repetitive, rule-based end of the spectrum, AI is not incremental improvement. It is transformative, and the case for using it is straightforward. Document extraction and data validation are an obvious example. Lending operations have historically absorbed enormous amounts of manual labor simply moving information from borrower-submitted documents into origination systems, checking it for completeness, and flagging discrepancies. AI-enabled document extraction does that work faster and more consistently than manual review, and it does it without the fatigue-driven error rate that creeps into any high-volume manual process.
Initial application screening against defined credit criteria is another clear fit. If a lender has established thresholds, debt service coverage minimums, loan-to-value caps, or industry exclusions, AI can apply those consistently across every application without the variability that inevitably shows up when different underwriters interpret the same policy slightly differently. Payment processing and ACH management fall into the same category. These are operational tasks with clear rules and low tolerance for inconsistency, which is exactly the environment where automation performs best.
Portfolio monitoring is where I think AI is proving to be the most quietly valuable. Flagging loans that show statistical patterns associated with future default, patterns a human reviewing a portfolio manually might not catch until they are already showing up in delinquency reports, gives lending teams an early warning capability that did not exist at scale before. And generating first-draft credit summaries from structured data inputs frees experienced underwriters from repetitive writing so they can spend their time on analysis rather than data assembly.
What all of these use cases have in common is that they reduce manual work, increase consistency, and free experienced lending professionals to spend their time on the decisions that actually require their judgment. That is the correct framing, and it is worth repeating because it gets lost in a lot of AI marketing. The goal is not to remove people from the process. The goal is to remove low-judgment work from their day so their judgment gets applied where it is worth the most.
Where the picture changes
On the complex judgment end of the spectrum, the picture changes considerably, and lending executives need to be honest with themselves about why. Consider a thirty million dollar commercial real estate bridge loan. That evaluation involves the experience and track record of the borrower, the specific market dynamics of the asset’s location, the quality and credibility of the proposed exit strategy, and often the relationship history between the lender and the borrower built over multiple deals. None of that reduces cleanly to a rule or a statistical pattern, because each of those factors is context-dependent in ways that resist standardization.
An experienced credit officer brings years of pattern recognition to that kind of evaluation. They have seen exit strategies that looked sound on paper fail because of market timing. They have seen borrowers with thin track records outperform because of factors that do not show up cleanly in a credit file. That pattern recognition is not something AI can replicate, because it is built from lived experience across ambiguous, non-repeating situations, not from labeled data. AI can support that evaluation. It can surface relevant comparable transactions, summarize borrower history, and flag inconsistencies across documents. But it should not be rendering the final judgment.
The risk of over-relying on AI in that kind of decision is not just the possibility of one bad loan, though that is real. The deeper risk is organizational. Credit judgment capability takes years to build inside a lending organization, and it erodes quietly if it stops being exercised. If an organization leans on AI outputs for complex decisions long enough, the muscle of contextual credit judgment atrophies, and by the time a market cycle turns and that judgment is needed most, it may not be there anymore. That is a risk that does not show up on a dashboard. It shows up years later, and by then it is expensive to rebuild.
Augmentation versus replacement is the right frame
The frame I keep coming back to, and the one I think every lending executive evaluating AI adoption should adopt, is augmentation versus replacement. AI should be making experienced lenders faster, better-informed, and more consistent. It should be handling the work that does not require judgment so that judgment can be applied where it actually matters. It should be surfacing information and flagging patterns a human might miss when managing a large and complex portfolio. What it should not be doing is serving as the final word on a complex credit decision.
Organizations that blur that line are not necessarily making a decision they will regret immediately. That is what makes the risk dangerous. They are taking on risk that will not be visible until something goes wrong, often well into a credit cycle, when a concentration of loans approved with insufficient human judgment starts underperforming at the same time. By the time the pattern is visible in delinquency data, the exposure has already been built.
This is also why governance conversations around AI in lending need to happen earlier than most organizations are having them. It is not enough to deploy AI tools and see what happens. Lending organizations that are thoughtful about this are defining, in advance, which categories of decisions AI is permitted to influence, which categories it can only inform, and which categories require a human decision-maker with clear accountability. That distinction needs to be built into workflow design, not left to individual discretion in the moment a loan is being reviewed.
Why this matters for how lending platforms are built
This is directly relevant to how lending software gets architected, and it is part of why I think the platform question matters more than most lenders initially assume. A lending platform built on Salesforce has an advantage here, because the underlying architecture supports configurable workflows where AI-enabled steps, document extraction, initial screening, portfolio monitoring, can be embedded directly into the process while structurally routing complex credit decisions to human reviewers with full visibility into the supporting data.
That is a meaningfully different design philosophy than treating AI as a bolt-on tool sitting outside the core system. When AI capabilities are embedded natively into the same platform that manages origination, underwriting workflows, and loan servicing, the organization has one place to define where automation applies and where human judgment is required, rather than trying to enforce that distinction across a patchwork of disconnected point solutions. An alternative lending platform that cannot make that distinction configurable at the workflow level is going to struggle to give lending executives the control they actually need as AI capability keeps expanding.
This also matters for auditability. Regulators and internal risk committees are going to want to know, for any given loan, what role AI played in the decision and what role a human played. A platform where that distinction is baked into the workflow, rather than reconstructed after the fact from disconnected systems, makes that conversation far easier. It also makes it easier to demonstrate that the organization has thought seriously about where automation belongs, which increasingly matters for both regulatory conversations and for institutional investors evaluating a lender’s operational maturity.
The practical exercise every lending executive should run
The practical exercise I would recommend to any lending executive thinking seriously about AI adoption right now is straightforward, even if it takes real effort to execute well. Map the lending process step by step, from initial application through servicing, and for each step ask a single question. Does the decision at this step benefit primarily from speed and consistency, or does it benefit primarily from experience and contextual judgment.
Steps that benefit from speed and consistency are strong candidates for AI augmentation, and the case for moving quickly there is strong. Steps that benefit from experience and contextual judgment are steps where AI can inform the decision but should not be making it, and where human oversight is not a compliance checkbox. It is the product. It is the thing the organization is actually selling when it tells a borrower, an investor, or a regulator that it exercises sound credit judgment.
That mapping exercise will look different for every lending organization depending on the complexity of their portfolio, the diversity of their loan products, and how much of their process is already standardized versus still dependent on individual underwriter discretion. But the exercise itself is not optional if an organization wants to adopt AI responsibly rather than reactively. The lenders who do this mapping deliberately, rather than letting AI adoption happen piecemeal across departments, are the ones who will end up with AI that makes their organization stronger. The ones who skip that step are the ones who will eventually discover, usually at the worst possible moment in a credit cycle, exactly where the line should have been.
Blog
How Workflow Automation Simplifies Alternative Lending
I have sat in enough operations rooms with MCA funders and alternative lenders over the past few years to notice a pattern. It shows up almost the same way every time. A lender implements a configurable lending platform, expecting it to finally give their team a single system of record and a faster way to work. The platform has every capability they were promised. And yet, three or four months into using it, someone on the operations team says some version of the same sentence: this system has everything we need, but finding it and using it efficiently means wading through a lot of functionality that was clearly built for somebody else.
That complaint is worth taking seriously, because it is rarely about the platform being deficient. It is about the platform being general. And general-purpose is not the same thing as poorly designed. It is, in fact, usually the opposite. A platform capable of serving commercial real estate lenders, CDFIs, SBA lenders, and MCA funders at the same time has to be built with enough breadth to accommodate all of those lending models. That breadth is a strength at the platform level. But it becomes a daily friction point at the desk level, unless someone does the work of narrowing it back down to what a specific lender actually needs.
The gap between platform capability and daily usability
Here is what that gap looks like in practice for a merchant cash advance funder. Most MCA operations teams are not dealing with an unlimited universe of transaction types. They are dealing with roughly ten to fifteen transaction types that come up regularly, week in and week out. Early payoff with a discount. Early payoff without a discount. A one-time payment made outside the regular repayment schedule. A temporary restructuring of the payment amount, where a merchant’s weekly payment is reduced for a defined period before returning to the standard amount. A refund that needs to be recorded because a payment processed after the underlying advance had already been paid off. None of these are exotic. They are the standard operational vocabulary of the MCA business, repeated constantly across a servicing portfolio.
The problem is that a platform designed to also serve commercial real estate lenders and SBA lenders cannot default to an MCA-specific screen for these transactions. Its default configuration reflects the union of every use case it supports, because that is what makes it flexible enough to be adopted across the industry in the first place. So when an MCA operations team member needs to record something as simple as a refund, they land on a workflow designed for the broadest possible scenario. Dozens of fields. Terminology borrowed from loan products they have never originated. Options and settings that simply do not apply to their business model. A transaction that should take thirty seconds instead takes fifteen minutes, several clarifying questions, and, in the worst cases, an email to a colleague or a support ticket to figure out which fields actually matter.
I want to be precise about what is happening here, because it is easy to misdiagnose. This is not a training failure, even though it often gets treated as one. It is not a data quality failure. It is not evidence that the platform was the wrong choice. It is a configuration gap between what the system is capable of and what a specific team’s daily workflow actually requires. And configuration gaps have configuration solutions.
Why the instinct to switch platforms is usually wrong
When operations friction becomes visible and persistent enough, it tends to escalate. Team members complain. Managers notice throughput dropping on routine tasks. Eventually someone asks whether the platform itself is the problem, and whether it is time to evaluate alternatives. I understand the instinct. When something feels clunky every single day, it is natural to assume the tool itself is wrong for the job.
But in the vast majority of cases I have seen, switching platforms does not solve this problem. It just resets the clock on it. A new platform, evaluated and selected under pressure, will almost certainly also be a general-purpose system with a default configuration built to serve a range of lending models. Unless the new vendor happens to build something narrowly for MCA funders and nothing else, the same tension between platform breadth and workflow specificity will reappear, just with a different interface wrapped around it. Worse, a lender who switches platforms to solve a configuration problem takes on all of the real costs of a system migration — data conversion, integration rebuilding, staff retraining on an entirely new interface, borrower and investor-facing disruption — without addressing the actual root cause.
The fix that actually works is less dramatic and far less risky. It is tailoring the configuration of the platform you already have to the specific transaction types your team actually performs. This is not a philosophical point. It is an operational one, and it has a name in the Salesforce ecosystem that FUNDINGO and other Salesforce-native lending platforms are built on: quick actions.
What workflow simplification actually looks like
A quick action, in practical terms, is a simplified workflow screen that presents only the fields relevant to one specific transaction type, instead of exposing the full underlying record with every field the platform supports. Rather than opening a general payment record with fifty available fields — most of which are irrelevant to the task at hand — the operations team member opens a screen built specifically for, say, recording a refund after an early payoff. That screen might have five fields. All five are relevant. None require guessing, cross-referencing a manual, or asking a more experienced colleague what to do with a field that has nothing to do with the transaction in front of them.
This is not a cosmetic change, and it is not about making the interface look nicer. It is a structural change to how work gets done. A transaction that used to take fifteen minutes because the operations person had to identify which fields mattered, ignore the ones that did not, and hope they had not missed something now takes thirty seconds because the ambiguity has been engineered out of the workflow entirely. Multiply that time savings across every early payoff, every temporary restructuring, every refund, every day, across every member of an operations team, and the aggregate impact on throughput is substantial, even though no single instance of it looks dramatic on its own.
This is precisely why workflow simplification tends to be underrated. It does not photograph well. Nobody puts “we built a five-field screen for recording refunds” into a sales deck, because it does not sound impressive in isolation. But when I ask lenders what has actually made their day-to-day operations feel faster and less error-prone after implementation, this is consistently one of the first things they mention — more often, frankly, than any of the flashier capabilities that get top billing during a platform evaluation.
The training and hiring dividend
There is a second-order benefit here that deserves more attention than it usually gets, and it shows up specifically in how fast new employees become productive. When a new operations hire is handed a general-purpose payment workflow with fifty fields and asked to figure out which subset applies to an early payoff versus a temporary restructuring versus a refund, you are effectively asking them to internalize the entire logic of a multi-vertical lending platform before they can competently complete a single task. That is a lot to ask of someone in their first weeks on the job, and it shows in error rates, in the volume of clarifying questions sent to more senior staff, and in how long it takes before that person is trusted to work independently.
Compare that to handing the same new hire a workflow that was built specifically for the transaction they need to complete. There is no translation required. The screen does not contain any field that does not belong on it. Training time compresses significantly, not because the new hire is smarter or better trained in the abstract, but because the tool itself has already done the work of filtering out everything that is not relevant to their job. I have talked to operations leaders who cut new-hire ramp time on servicing tasks by more than half after building out a set of simplified, transaction-specific workflows, without changing anything about their training program itself. The workflow was the training program.
How to identify where this investment pays off
The practical starting point is not complicated, and it does not require a large project team or a lengthy discovery process. Look at where your operations team is generating support tickets, informal Slack questions to colleagues, or repeated requests for clarification. If those tickets cluster around transactions that, on paper, sound simple — a refund, a one-time payment, a short-term restructuring — that clustering is the signal. It means the underlying workflow has more complexity built into it than the transaction itself warrants, and the gap is being absorbed by your team’s time and patience rather than being engineered out.
The instinct in that moment is almost always to schedule more training. More documentation. A refresher session. I would push back on that instinct. If a transaction that should take thirty seconds consistently takes fifteen minutes, more training on the existing workflow is treating a symptom. The underlying cause is that the workflow was not built for that specific transaction type in the first place, and no amount of familiarity with a poorly fitted process will make it fit. The answer is almost always to build a simpler, purpose-specific version of that workflow — not to train harder on the general-purpose one.
This is where the value of a configurable, Salesforce-native platform actually gets realized, and it is worth separating this point from platform selection generally. The capability to build simplified, transaction-specific workflows is not itself the differentiator between lending platforms — most modern configurable systems offer some version of it. The differentiator is whether a lender’s implementation actually uses that capability deliberately, mapped against the real, specific list of transaction types that team performs every day, rather than leaving the default configuration in place and assuming that broad capability is the same thing as efficient capability.
The larger operational lesson
The broader point here extends past MCA funders and past any single platform. Any lending organization operating on a system built to serve multiple lending verticals will encounter some version of this gap between what the platform can do and what their specific operation needs on a daily basis. The lenders who get the most out of their technology investment are not necessarily the ones who chose the most feature-rich platform. They are the ones who did the disciplined work of mapping their own operational vocabulary — their actual, recurring transaction types — and then configured their workflows around that vocabulary rather than around the platform’s full range of theoretical possibility.
That is a less exciting story than “we switched to a better system,” but it is a far more reliable path to operational improvement, and it is one that does not require the risk, cost, or disruption of a migration. If your team is fighting the system every day on transactions that should be routine, the fix is probably sitting inside the platform you already have. It just has not been built yet.
Blog
Why Lenders Don’t Know What They Need Until Go-Live
Something comes up in almost every conversation I have with lending organizations that have been live on a platform for six months or more. It is some version of the same honest reflection. They could not have told you at the beginning of the implementation what they actually needed. They only figured that out by doing real transactions and running into real situations that the initial configuration did not anticipate.
I want to be careful about how I frame this, because it is not a criticism of vendors or of implementation teams. It is a structural reality of how lending operations work. You cannot fully spec a loan origination software implementation the way you might spec a piece of manufacturing equipment, where the requirements are fixed and knowable in advance. Lending is a living process, full of exceptions, and the decisions that matter most in a configuration are the ones nobody thinks to ask about until they are staring at an actual transaction that does not fit the mold.
The decisions that actually matter are invisible at the start
Think about what a typical requirements-gathering process for a new platform looks like. You get the operations team in a room, sometimes with the vendor, sometimes with an implementation partner, and you walk through your loan products, your servicing workflows, your reporting needs. It is a thorough process, and the people in the room are experienced. But they are describing what they remember, not what is about to happen.
How should payment allocation logic handle an odd partial payment that does not match the amortization schedule. What does the payoff workflow need to look like when a borrower on a specialty product pays off eleven days into a new cycle. How should collections triggers behave for a borrower who has a temporary hardship but a strong payment history otherwise. What does the investor reporting structure need to produce when a loan gets restructured mid-term and two different funders need to see it reflected two different ways.
These are not exotic questions. They are the ordinary texture of a lending operation. But they require operational context that most organizations do not fully have until they are living inside the platform, processing real transactions, watching real exceptions surface. You can ask an operations leader to imagine these scenarios in a discovery workshop, and they will do their best. But imagining a scenario and encountering it are different experiences, and only one of them generates the specificity a configuration actually needs.
What actually happens after go-live
The pattern I see across specialty lenders, CDFIs, commercial lenders, and private credit shops is remarkably consistent. The implementation covers the obvious workflows well. Origination, basic servicing, standard reporting. The team goes live and things work reasonably well for the straightforward cases, which is most of the volume in the early weeks.
Then the edge cases start appearing. A payment comes in for an unusual amount. A borrower requests a temporary restructuring. An early payoff generates a refund situation the servicing team has never had to process through the new system. And suddenly the team is submitting support tickets for transactions that feel like they should be basic but somehow require five emails and two escalations to resolve, because the system was never configured for that specific scenario. Nobody knew to configure for it, because nobody had run into it yet.
I want to underline this point because it changes how you should think about the first ninety days on a new alternative lending platform. This is not a failure of the implementation. It is the natural second phase of it. The first phase gets the foundation right, meaning the loan products, the intake workflows, the basic servicing rules, the reports your board and your funders expect to see. The second phase, which often starts three to six months after go-live, is where the real customization happens. It is driven by actual operational experience rather than anticipated requirements, and it is where a genuinely well-configured system gets built.
Why this catches organizations off guard
Most digital transformation initiatives in lending are budgeted and staffed as if the implementation ends at go-live. The project plan has a clear finish line. The steering committee reports success. The implementation partner rolls off. And then, three months later, the operations team is quietly accumulating a backlog of workflow gaps, unsure whether raising them again constitutes admitting the project failed.
This is where a lot of the frustration I hear about lending technology actually originates. It rarely comes from the platform itself being wrong for the organization. It comes from the mismatch between how the implementation was resourced and how lending operations actually mature. Nobody budgeted for the second phase, so when the second phase’s needs surface, there is no obvious mechanism to address them. The requests pile up, the operations team starts working around the system instead of through it, and six months later someone concludes the platform does not fit, when what actually happened is that the configuration was never allowed to finish maturing.
I have also seen this cut the other way, where a lender tries to solve the problem by over-specifying everything up front. They spend four extra months in discovery trying to anticipate every possible scenario before writing a single configuration. This rarely works either. You end up with a configuration built around hypothetical edge cases that may never occur, at the cost of months of delay, while the real edge cases, the ones that only show up once borrowers and transactions start flowing through the system, still surprise you anyway.
What the lenders who navigate this well actually do
The lenders who handle this transition best are the ones who plan for the second phase explicitly, rather than being surprised by it. That planning takes a few concrete forms.
They budget for ongoing managed services or build internal Salesforce administration expertise, so there is a standing capacity to make configuration changes without opening a formal change request every time an edge case appears. This matters more than it sounds. A team that has to escalate every workflow gap through a vendor’s support queue will let a backlog build for weeks. A team with someone internally who can adjust a flow, a validation rule, or a report in an afternoon will fix small things before they become recurring pain points.
They build a running list of workflow gaps as they encounter them rather than letting frustration accumulate informally in Slack channels and hallway conversations. This sounds almost too simple to matter, but the organizations that keep a disciplined, prioritized backlog of items they noticed in production that the configuration should handle end up systematically closing those gaps over two or three post-go-live cycles. The organizations that do not keep this list end up re-discovering the same problems repeatedly, because nobody wrote down that it happened the first time.
And critically, they treat the post-go-live period not as a sign that something went wrong, but as the expected and necessary continuation of the implementation. This is as much a leadership and communication issue as it is a technical one. If your steering committee believes the project is done at go-live, then every subsequent configuration request looks like a failure or a scope creep argument. If your steering committee understands from the outset that configuration maturity is a twelve-month journey, not a ninety-day sprint, then the same requests look like exactly what they are, the system getting better because you are using it.
The practical implication for how you approach implementation
The advice I give lenders about to start an implementation is to resist the urge to over-specify upfront. Get the foundation right. Your core loan products. Your basic servicing workflows. The essential reporting your board, your regulators, and your funders actually require on day one. Then go live. Do real transactions. Let the operational reality of your portfolio start generating the specific questions that only real transactions can generate.
Then iterate on the configuration based on what you actually encounter, not what you tried to anticipate. This approach produces a better-configured system in roughly the same total timeline, with significantly less pre-implementation paralysis. It also produces a healthier internal relationship with the platform, because the operations team experiences the system improving in response to their actual work, rather than experiencing a static configuration that feels increasingly out of step with what the business needs as it grows.
This has direct implications for how software vendors should set expectations too. A vendor who promises that a discovery process will capture every requirement before a single transaction runs through the system is setting up an implementation for disappointment, because that promise is not really possible to keep. A vendor who is upfront that the first six months of production use will surface real requirements, and who has a structure in place to address those requirements without friction, is setting a far more honest and ultimately more successful expectation.
At FUNDINGO, this is part of why we think about implementation as a relationship that continues well past go-live rather than a project with a hard finish line. The configuration work that happens in the months after a lender starts processing real loans is not rework. It is the part of the implementation that could not have happened any earlier, because the operational knowledge it depends on did not exist yet. Lenders who plan for that phase, rather than treating it as a surprise, end up with platforms that genuinely fit how they operate, not just how they described operating in a discovery workshop months before they ever processed a single loan.
If there is one thing I would want a Head of Lending or a Digital Transformation lead to take from this, it is to stop treating the post-go-live adjustment period as evidence that something was chosen wrong. In nearly every case I have seen, it is evidence that the organization is finally using the system the way it was always going to need to be used, and is now positioned to configure it accordingly.