Blog
Why CDFI Growth Now Means Mergers, Not Just More Loans
For most of the history of community development finance, growth has meant one thing: make more loans. Raise more capital, hire more loan officers, open another office, deepen relationships in another underserved market. That model has worked for decades, and it still works today for the majority of Community Development Financial Institutions, or CDFIs, serving small businesses, affordable housing developers, and borrowers that traditional banks routinely pass on.
But I have started to notice a different growth pattern taking shape among a smaller group of more ambitious CDFIs, and I do not think enough people in this industry are talking about it yet. These organizations are not just trying to originate more loans. They are trying to become the operational backbone for an entire network of community lenders. Instead of growing loan by loan, they are growing institution by institution, acquiring and merging with smaller CDFIs and absorbing their portfolios, their staff, and their operations onto a shared platform.
The Business-in-a-Box Model for Community Lending
The clearest way to describe what these organizations are building is something close to a business in a box for community lending. A smaller CDFI, often one that is well-run mission-wise but operationally stretched thin, gets acquired or merged into a larger organization. Rather than continuing to run its own systems, its own reporting, and its own back office, it gets folded into a shared infrastructure. The acquiring organization brings standardized underwriting workflows, centralized servicing, consolidated reporting, and a technology platform that the smaller organization never had the resources to build on its own.
Over time, the acquiring organization stops looking like a single lender and starts looking like a network. It has multiple entities, multiple program types, multiple funding sources, and multiple geographies, all operating under one operational umbrella. That is a fundamentally different organization than the CDFI that exists to make loans in one region or one asset class. It is closer to a platform business that happens to be in the business of community lending.
This is still an early trend. Not every CDFI is positioned to pursue it, and not every CDFI should. But the organizations pursuing this model tend to be some of the most sophisticated operators I encounter in the community lending space right now, and the implications for how they think about technology infrastructure are worth examining closely.
Why the Funding Mix Matters
One detail I find particularly telling about this emerging model is the capital structure behind it. The CDFIs pursuing acquisitions and mergers are generally not the ones relying primarily on annual government grant cycles. They have diversified their capital sources considerably, drawing on large bank partnerships, private investment capital, and New Markets Tax Credits alongside traditional grant funding.
That diversification matters because it changes the time horizon an organization can operate on. A CDFI that depends heavily on grant funding is often planning in twelve-month increments, because that is the cadence its funding operates on. An organization with a more diversified capital base, including private investment and bank partnerships, can plan in five and ten year horizons. That longer horizon is a prerequisite for pursuing acquisitions, because mergers are not one-quarter decisions. They require patient capital, a stable balance sheet, and the ability to absorb the operational cost of integration without disrupting day-to-day lending activity. The CDFIs building toward a network model have generally done the work on the funding side first, and the operational ambitions follow from that financial stability rather than the other way around.
What a Single-Location Lender Can Get Away With
It is worth being honest about what a smaller, single-entity community lender can operate with, because it explains why this shift in ambition changes everything on the technology side. A CDFI running a few hundred loans out of one office can survive on a legacy loan management system, a set of shared spreadsheets, and a handful of employees who know the exceptions and workarounds by heart. It is not efficient, and it is not scalable, but it is survivable. Tribal knowledge fills in the gaps that the systems cannot cover.
That approach does not survive contact with a merger. An organization absorbing another CDFI is not just adding loan volume. It is adding an entirely separate set of workflows, reporting requirements, program rules, and often an entirely separate technology stack that has to be reconciled with its own. The tribal knowledge that held the smaller organization together does not transfer. It has to be replaced with documented, standardized process, and that process has to live inside a system that can actually enforce it across two organizations instead of one.
What the Network Model Actually Requires From Technology
Once an organization decides it wants to grow by acquisition rather than by origination volume alone, its technology requirements change in specific and predictable ways.
The first requirement is configurability across multiple program types and multiple entities. A CDFI network is rarely lending under one uniform program. It might be running small business loans, affordable housing construction loans, and New Markets Tax Credit-financed projects simultaneously, each with different underwriting criteria, different compliance requirements, and different reporting obligations to funders and regulators. A platform that was built around a single loan type or a single workflow will not bend to accommodate that diversity without significant custom development, and custom development is exactly the kind of implementation risk that slows down an acquisition strategy.
The second requirement is reporting that gives leadership visibility across the entire network, not just one location or one entity. When a CDFI acquires another organization, the board and the executive team need to see performance across the combined portfolio almost immediately. They need to know how the acquired organization’s loans are performing, whether its underwriting standards match the parent organization’s risk tolerance, and where operational bottlenecks are showing up. If that reporting has to be manually assembled from two disconnected systems, the acquisition’s value is diminished before it even has a chance to prove itself.
The third requirement is onboarding infrastructure that does not require a year-long implementation every time a new organization joins the network. This is the requirement I think gets underestimated the most. An organization that plans to make one acquisition can tolerate a slow, painful onboarding process as a one-time cost. An organization that plans to make acquisitions repeatedly over five or ten years cannot. If every merger requires a twelve-month systems integration project, the acquisition strategy itself becomes unworkable, because the operational drag outpaces the benefit of scale. The organizations that get this right treat onboarding a newly acquired CDFI the way a franchise treats opening a new location: a repeatable, largely standardized process rather than a bespoke project each time.
Why the Platform You Are Already On Matters More Than You Think
There is a dimension to this that goes beyond configurability and reporting, and it has to do with what happens on the day two organizations actually try to merge their operations. In my experience, the hardest part of any merger is rarely the strategic rationale or the deal terms. It is the technology consolidation. Data has to move from one system to another. Workflows built around one organization’s assumptions have to be reconciled with another organization’s assumptions. Staff who have spent years learning one system have to be retrained on another, often while continuing to service existing borrowers without interruption.
That process is dramatically smoother when both organizations are already operating in the same technology ecosystem. This is where the choice of underlying platform becomes a strategic decision rather than a purely technical one. Salesforce is the most widely adopted enterprise platform in the nonprofit and financial services world, which means the odds that your next merger partner is already running on Salesforce, or is at least familiar with how it works, are considerably higher than with almost any other platform on the market. A shared underlying architecture does not eliminate the work of a merger, but it removes an entire category of friction. Data structures are more likely to be compatible. Staff face a shorter learning curve. Integrations that already exist for one organization are more likely to work, or work with modest adaptation, for the other.
For a CDFI with no acquisition ambitions, this consideration is close to irrelevant. Pick whatever system fits your current operations best. But for an organization that has decided its growth strategy runs through mergers and acquisitions, the platform decision starts to look less like a vendor selection and more like a piece of long-term strategic infrastructure. Building loan origination and servicing operations on a Salesforce-native platform is not simply about the features available today. It is about reducing the friction of every integration that has not happened yet.
An Early but Real Advantage
I want to be clear that the super CDFI model, if we want to call it that, is still early. Most CDFIs are not pursuing this strategy, and most do not need to. Making more loans in your existing market, to your existing borrower base, is still a perfectly legitimate and often the right growth path for a mission-driven community lender.
But for the organizations that are pursuing this network model, the technology decisions they make in the next two or three years are going to matter enormously. The CDFIs that build configurable, well-integrated operational infrastructure now are going to be positioned to move quickly when an acquisition opportunity presents itself, because the hard work of standardizing workflows and centralizing reporting will already be done. The CDFIs that wait, or that continue to run critical operations on legacy systems with no integration path, are going to find that the technology consolidation itself becomes the barrier to growth, even when the strategic and financial case for a merger is sound.
The organizations I am watching most closely right now are not the ones talking about growth in terms of loan volume. They are the ones talking about becoming the infrastructure other community lenders plug into. That is a meaningfully different ambition, and it deserves a meaningfully different approach to the technology underneath it.
Blog
Why the Sales-to-Implementation Handoff Makes or Breaks Lenders
When lending organizations evaluate new technology, they spend most of their time evaluating the things that show up on a scorecard. Features. Workflows. Integrations. Pricing. Implementation timelines. Those things all matter, and they deserve the scrutiny they get. But there is a moment in almost every technology relationship that gets far less attention than it should, and it tends to define how the entire engagement feels for years afterward. That moment is the handoff from sales to implementation.
The Pattern I Keep Seeing
I spend a lot of time talking to COOs, Heads of Lending, and Digital Transformation leaders at specialty and community lenders. I hear a version of the same story often enough that I no longer think of it as an outlier. A lending organization goes through a months-long evaluation process. There are demos, reference calls, pricing negotiations, security reviews. Somewhere in that process, real context gets built between the buyer and the vendor’s sales team. The vendor learns about the lender’s loan products, their servicing quirks, their reporting requirements, the specific reasons their current system is holding them back. Trust accumulates slowly, conversation by conversation.
Then the deal closes. And in a lot of cases, the buyer is handed off to an implementation team that was not part of any of those conversations. That team is starting from a document, or a summary email, or a kickoff call where everyone is meeting for the first time. The context that took months to build is gone, or at best partially reconstructed from notes.
That experience is jarring for the buyer. It is also completely avoidable, which is what makes it frustrating when it happens. The erosion is not because the implementation team is incompetent. It is because the buyer spent months building a relationship with one set of people, and now has to start over with another set of people, at exactly the moment when they need the most confidence that they made the right decision.
Why This Moment Carries More Weight Than It Looks Like It Should
It is worth being precise about why this particular transition matters so much, because on the surface it can look like a soft, relationship-oriented concern rather than an operational one. But the timing is what makes it significant. The handoff happens at precisely the point where the buyer has the least information and the most exposure. They have just committed budget, internal political capital, and staff time to a decision. They have not yet seen the platform perform in their own environment. The only evidence they have that they made a good choice is how the vendor behaves in the first few weeks after the ink dries.
If that experience feels disjointed, it does not just create friction. It plants a seed of doubt that colors every subsequent interaction. Buyers start reading extra scrutiny into things that would otherwise be treated as normal implementation bumps. A delayed data migration becomes evidence of a pattern rather than a scheduling issue. A miscommunicated requirement becomes proof that the vendor does not understand the lender’s business rather than a rough patch in onboarding. Once that lens is in place, it is very hard to remove.
Contrast that with what I hear from lending executives who describe their implementation experience positively. Almost without exception, they describe a specific mechanic, not a vague feeling of good service. The transition was done live, on a call, with both the outgoing salesperson and the incoming implementation lead present at the same time. The context was communicated directly, in front of the client, not through a handoff document that nobody reads carefully. The buyer got to hear, in real time, that the person who understood their business was transferring that understanding to the person who would be building their system.
That sounds like a small operational detail. It is not common, and the lenders who experience it notice immediately.
This Is Not a Transaction, It Is the Start of a Dependency
Part of why this matters more in lending technology than in a lot of other software categories is the nature of what is being purchased. CDFIs, community lenders, and specialty finance companies are not buying a commodity tool that they can swap out in a quarter if it does not work. They are entering a multi-year operational dependency. Loan origination and servicing platforms sit underneath the entire lending lifecycle. Once a lender is live on a system, unwinding that decision is expensive, disruptive, and organizationally painful. Everyone involved in the buying process knows this going in, even if they do not say it out loud during the evaluation.
Because the relationship is long-term and hard to exit, the way it begins matters disproportionately. The implementation is not the final step of a sales process. It is the first chapter of a relationship the lender is going to be living inside of for years. Buyers who have been through a bad software transition before, and most executives evaluating a new platform have, are attuned to this. They are watching for signals early, because they know that whatever they experience in the first thirty days is a preview of what year three is going to feel like when something goes wrong and they need support fast.
This is also why the handoff moment tends to reveal more about a vendor’s operating discipline than almost anything in the sales process itself. A sales team can present a polished demo regardless of how well-run the company is behind the scenes. A smooth, well-orchestrated handoff is much harder to fake. It requires internal coordination, shared documentation practices, and a culture where the sales team is incentivized to set up the implementation team for success rather than just close the deal and move on to the next prospect. Those are structural things. They show up in the handoff whether or not the vendor intends for them to.
What This Means for a Lender Going Into an Evaluation
If you are a COO or a Digital Transformation lead running a technology evaluation right now, there is a practical implication here that is worth acting on directly, not just filing away as an observation. The handoff between sales and implementation is something you can and should evaluate before you sign, not something you discover after the fact.
Ask the vendor directly how they handle the transition from sales to implementation. Not in the abstract, but specifically. Is there a live call where both teams are present? Is there a formal internal process for context transfer, or is it left to whoever remembers to send an email? These are fair questions to ask during a sales process, and how a vendor answers them tells you something real about how seriously they take what happens after the deal closes.
Ask to meet the implementation team before you sign. This is a reasonable request, and a vendor that resists it or treats it as unusual is telling you something. A vendor confident in their implementation process will generally welcome the opportunity to introduce that team early, because it reinforces the sale rather than complicating it.
Ask whether the people who will be working on your account after go-live are the same people who will be involved during implementation, or whether there is another handoff coming once implementation wraps. Multiple handoffs compound the risk. Each one is another point where context can be lost and where the relationship has to be rebuilt.
None of these questions will show up on a feature comparison matrix. But the answers will tell you more about what your actual day-to-day experience is going to feel like than almost anything in a product demo. A platform can have every feature you need and still deliver a poor experience if the people responsible for making it work in your environment were never properly briefed on why you bought it in the first place.
The Real Differentiator Is Not Always the Platform
I want to be direct about something that runs against the instinct most buyers have during an evaluation. It is natural to assume that the smoothest implementation will belong to whichever vendor has the most capable, most fully-featured platform. Capability matters, and it is not something to compromise on. But in practice, the lenders who describe the smoothest implementations are not always the ones who picked the platform with the deepest feature set. They are the ones who picked a partner that treated the handoff from sales to delivery as seriously as they treated the sale itself.
That is a different kind of diligence than most evaluation processes are built to capture. Feature comparisons and pricing models are easy to put in a spreadsheet. Organizational discipline around client handoffs is not. But it is just as real, and it has just as much bearing on whether the implementation actually succeeds and whether the lending organization ends up with a partner they trust or one they tolerate.
For lenders building out their evaluation process, this is worth building in explicitly rather than leaving to chance. Treat the handoff conversation as part of the diligence, not an afterthought you discover after the contract is signed. The vendors who take it seriously will be glad to talk about it. The ones who have not thought about it will tell you that too, just less directly.
Blog
Why Growing CDFIs Are Outgrowing Legacy Loan Servicing Systems
I have been spending a lot of time lately with CDFIs and community lenders that are in growth mode. New locations, new loan products, sometimes an acquisition on the horizon. And in almost every one of those conversations, the same story comes up. The core loan servicing platform that carried them for the last decade is starting to show its age, and the organization is finally ready to admit it.
This is not a new phenomenon in lending. Every generation of community lenders eventually reaches a point where the systems that got them off the ground can no longer support where they are headed. What is different right now is the specific shape of the problem. It is not that these legacy systems are unreliable or that they crash. Many of them are stable, well-understood, and have years of institutional history baked into them. The problem is narrower and, in some ways, more urgent. It comes down to two things I hear over and over again: no integrations and no AI.
The System That Was Good Enough Stops Being Good Enough
Every organization I talk to describes roughly the same arc. The loan servicing platform was implemented years ago, sometimes on-premise, sometimes as an early cloud tool built before open APIs and modern integration standards became the norm. At the time, it did exactly what was needed. It tracked loans. It processed payments. It generated the reports regulators and boards required. For an organization with twenty staff and a few hundred loans on the books, that was more than sufficient.
Growth changes the math. Once an organization crosses into multiple locations, fifty or more staff, and a more diverse loan portfolio, the operational center of gravity shifts. It is no longer just about whether the system can process a payment correctly. It is about whether the organization can move information across departments, locations, and systems fast enough to keep pace with its own growth. That is where legacy platforms start to buckle, not because they fail outright, but because they were never designed to be connective tissue. They were designed to be a standalone system of record.
No Integrations Is Not a Technology Problem. It Is an Operational Risk
The first thing that comes up in nearly every one of these conversations is integration, or the lack of it. The accounting system does not talk to the loan servicing platform. The CRM has no connection to servicing data. Every time information needs to move between systems, a person is doing it manually, usually through exporting a spreadsheet, reformatting it, and importing it somewhere else.
At a small scale, this is annoying but survivable. At the scale these growing CDFIs are now operating at, it becomes something more serious. It becomes an operational risk. Every manual handoff is an opportunity for data to fall out of sync. A payment gets applied in one system and not reflected in another. A borrower’s updated contact information lives in the CRM but never makes it into servicing. Reconciliation between systems, which should be a routine background process, becomes a recurring fire drill that consumes real staff hours.
What strikes me most is where this shows up in the organization. It is rarely the frontline loan officers who feel it first. It is the operations team, the people responsible for keeping everything reconciled and reportable, who end up absorbing the cost. Their time gets consumed by coordination work instead of the analysis and process improvement they were hired to do. When I ask leaders what their operations team actually spends its day doing, the honest answer is often some version of moving data between systems that should already be talking to each other.
This is worth naming clearly because it rarely gets described this way internally. Nobody walks into a board meeting and says the organization has an integration problem. They say the team is stretched thin, or reporting takes too long, or they cannot get a clean picture of the portfolio without pulling data from three different places. Those are all the same problem wearing different language.
No AI Is a Forward-Looking Problem, Not a Current One
The second theme is a little different in character. It is not about a pain point happening today. It is about a door that is closing for the future. CDFI leadership teams are watching the broader financial services industry move deliberately toward AI-enabled operations. They are attending industry events where this is the dominant topic. They are hearing about co-pilot tools, automated underwriting assistance, and agent-based workflows that reduce manual review time. Salesforce, in particular, has made a very public and very large investment in AI for financial services, and lenders across the industry are paying attention to it.
The problem for organizations on legacy servicing platforms is that none of this is available to them, not because they are behind on adoption, but because their core system has no pathway to connect to any of it. It was built in a different technological era, often before cloud-native architecture was standard, let alone before AI tooling existed as a layered capability on top of a platform. These organizations are not choosing to sit out the AI conversation. Their infrastructure is making that choice for them.
This creates a specific kind of frustration among leadership teams, because it is not a problem they can solve with more effort or better training. You cannot work around an architectural limitation. Either the platform has a path to modern data infrastructure and automation, or it does not. And for a growing number of CDFIs, the answer is no, and they know it.
What Actually Triggers the Decision to Move
One pattern I find genuinely interesting is that the decision to finally replace a legacy servicing platform is almost never triggered by a single dramatic failure. There is rarely one bad audit or one catastrophic outage that forces the issue. Instead, what I see consistently is a combination of two forces arriving at the same time.
The first is organic growth pressure. New branches, new products, higher loan volume, sometimes an acquisition that suddenly requires integrating a second organization’s loan portfolio into the fold. This growth exposes the operational cracks that were tolerable at a smaller scale but are no longer sustainable.
The second is a change in leadership, or at least the arrival of someone in a senior operations or technology role who has direct experience with what modern infrastructure looks like elsewhere. This person has usually worked at an organization, inside or outside the CDFI space, where systems were integrated, data flowed cleanly, and technology decisions were made with a longer time horizon in mind. They bring a frame of reference that the existing team may not have had internally. Suddenly there is a name for the problem, and a sense of what good looks like on the other side of it.
When those two forces combine, growth pressure and a new frame of reference, that is when evaluations that had been quietly postponed for years finally move forward. I have seen organizations sit with a known limitation for a long time simply because no one internally had seen an alternative that felt tangible. It takes someone with outside experience to turn a vague sense of falling behind into a concrete case for change.
The Real Opportunity Is Bigger Than Fixing Two Problems
Here is the part of this conversation that I think gets underappreciated. When a CDFI finally makes the move to a modern, Salesforce-native lending platform, they are not just solving the integration problem and the AI problem in isolation. They are repositioning their entire technology stack for the next decade of the organization’s growth.
This matters because Salesforce itself continues to invest heavily in AI, automation, and data infrastructure across its platform. An organization running its lending operations natively on Salesforce does not need to evaluate, purchase, and integrate each new capability as a separate project. It becomes available as part of the platform they are already standing on. That is a fundamentally different posture than trying to bolt modern capabilities onto a legacy system that was never designed to receive them.
This is also why I think the framing matters so much when CDFI leadership teams evaluate this decision. It is easy to think about a platform replacement as a defensive move, something you do because the old system is causing problems. The more accurate framing is that it is an offensive move. It is choosing an operational foundation that keeps pace with where the rest of financial services technology is headed, rather than a foundation that requires a separate, disruptive migration every time the underlying technology environment shifts again.
What This Means for Lenders Weighing the Decision
If you are a COO or head of lending at a CDFI reading this and recognizing your own organization in it, the questions worth asking are not really about features. They are about trajectory. Can your current platform connect natively to the other systems your organization depends on, or does every connection require custom, brittle, one-off work? Does your platform have any pathway to participate in the AI and automation investments happening across the broader industry, or is that door permanently closed by the architecture itself?
And perhaps most importantly, what would it take for your organization to build the case internally? In my experience, that case tends to build itself once growth creates enough pressure. The more useful thing leadership teams can do is make sure someone in the organization has real visibility into what modern lending infrastructure looks like, so that when the pressure arrives, the path forward is already clear rather than something the team has to discover from scratch under time pressure.
The CDFIs I see making this transition successfully are not doing it because a vendor convinced them to. They are doing it because they looked honestly at where their operations were headed, recognized that their current platform could not go there with them, and decided that the disruption of a transition was smaller than the cost of standing still.
Blog
Why Lending Ops Leaders Want Configurable Systems, Not Vendors
A client told me something this morning that stuck with me, and I think it captures one of the most underrated qualities a lending platform can have. He is not live yet. He is still in implementation. But instead of waiting for our team to configure every setting on his behalf, he has been spending his extra time learning to do it himself. Underwriting rules. Stipulation checklists. Basic workflow settings. When I asked him why, his answer was direct. He does not want to have to call us every time he needs to make a change to something that should be straightforward. He wants to own it.
Then he said something sharper. In his previous system, he could not even email the vendor directly to request a change. He had to route the request through someone else, who would email the vendor on his behalf. And it took forever. Every small adjustment to his process became a project with a timeline, a queue position, and a wait.
That friction is more damaging than most lending executives realize, and it is worth taking seriously because it is not really a technology story. It is an operations story. Lending is not static. Underwriting guidelines change as risk appetite shifts. Regulatory requirements move, sometimes with short notice. New loan products get launched to capture new segments. A lending team that cannot make basic configuration changes without submitting a support ticket and waiting weeks is a lending team that is permanently a step behind where it needs to be. The gap between when a change is needed and when it actually happens in the system becomes a hidden tax on the entire operation.
The hidden cost of dependency
Most lenders do not measure this cost directly, which is part of the problem. Nobody puts a line item in the budget for time waited on vendor tickets. But talk to any head of lending or COO who has lived through it, and they will describe the same pattern. A regulatory change comes down. Compliance flags a new stipulation requirement. Someone opens a ticket with the software vendor. The vendor’s implementation or support queue is backed up, because every client is submitting similar requests through the same narrow channel. Weeks pass. In the meantime, the operations team improvises. They track the exception manually in a spreadsheet. They add a manual review step. They tell underwriters to remember the new rule instead of having the system enforce it.
That improvisation is where risk creeps in. Manual workarounds are exactly the kind of gap that shows up in an audit finding or an inconsistent underwriting decision. And the irony is that the software was supposed to prevent that kind of inconsistency in the first place. When the system cannot flex to match the current rule, the team works around the system, and the system stops being the source of truth. It becomes a formality that operations quietly route around.
I have sat in enough of these conversations now to hear the pattern repeat across very different lending businesses. A commercial real estate lender needed to add a new stipulation for a specific loan type after a servicing issue surfaced. A CDFI needed to adjust its underwriting workflow when a new grant program came with its own eligibility rules. A specialty finance company needed to change a document collection sequence after a compliance review. None of these were complex technical problems. They were operational adjustments that any experienced lending operator could design in an afternoon. The only question was whether the system let them make the change themselves or required them to wait on someone else.
Configurability is not the same as customization
This is where I think a lot of lenders get confused when they are evaluating platforms, and it is worth being precise about the distinction because it changes how you should be asking vendors questions during due diligence.
Customization means changing the underlying code of the system to do something it was not built to do. It requires developers. It creates a version of the software that is uniquely yours, which sounds appealing until you realize what it costs you at the next upgrade cycle. Every custom change has to be retested, sometimes rebuilt, every time the vendor pushes a new release. That is technical debt, and it compounds. Lenders who go deep on customization often end up afraid to upgrade at all, because the risk of breaking something custom outweighs the benefit of the new release. I have seen lending teams running years-old versions of their core system for exactly this reason. They customized themselves into a corner.
Configurability is a different thing entirely. Configurability means the system was designed with flexibility built in, so that an operator with no coding background can adjust underwriting rules, stipulation requirements, workflow steps, approval routing, and document logic within the system’s existing framework. No code. No developer. No service ticket. A lending operations leader who understands their own process makes the change and moves on with their day. When the vendor releases an upgrade, the configuration carries forward cleanly, because it was never a departure from the core system in the first place. It was always working inside the system’s designed parameters.
The distinction matters because vendors will often use the word flexible to describe both. It is worth asking directly, in any evaluation process, whether a given change requires a developer or a service order, or whether it can be made by an operations person inside the application itself. That single question tends to reveal a lot about how a platform was actually architected, versus how it is being positioned in a sales conversation.
Why this becomes a strategic requirement, not a feature request
What I keep hearing from operations leaders, across company size and loan type, is that configurability has stopped being a nice-to-have and become something closer to a strategic requirement. The reasoning is straightforward once you see it play out over a few years rather than a single implementation.
Lending businesses evolve. A lender that only originates one loan product today is very likely to originate a second or third product within a few years, either through organic growth or through a shift in market opportunity. Regulatory frameworks are not fixed either. State and federal requirements move, sometimes predictably and sometimes not, and the lenders who can absorb those changes quickly avoid the compliance exposure that comes with a slow response. Risk appetite changes too, particularly as portfolios season and as economic conditions shift. An underwriting rule that made sense two years ago may need to tighten or loosen based on what the portfolio is actually telling the credit team.
Every one of those changes eventually has to show up in the system that runs day-to-day operations. If that system requires a vendor engagement every time, the lender is essentially outsourcing its own pace of adaptation to someone else’s support queue. That is a strange position for an operations leader to be in, because the pace at which a lending business can respond to its own market is arguably one of the more important competitive variables it has. Underwriting speed, product breadth, and compliance responsiveness are all downstream of how quickly the operating system can absorb a change.
The lenders who choose platforms with genuine configurability are the ones who can respond to a regulatory change in a matter of days rather than a quarter. They are the ones whose operations leaders describe a feeling of ownership over their system rather than dependency on a vendor relationship. That shift in language matters more than it might seem. Ownership implies confidence and control. Dependency implies waiting. Those are two very different postures for a lending operation to hold, and over time they produce very different outcomes.
What this means during implementation and beyond
There is a practical implication here that shows up most clearly during implementation, which is where my client’s comment came from in the first place. A lender that spends its implementation window learning to configure the system, rather than simply waiting for the implementation team to hand them a finished product, ends up in a fundamentally different position on day one of going live. They are not just users of the system. They understand how it works underneath the surface. When the first regulatory update or product launch comes along after go-live, they are not starting from zero. They already know where the levers are.
This also changes how a lender should think about implementation budget. A common mistake is to treat the implementation phase as the moment when the system gets built exactly right, once, and then stays static. That mindset leads to spending heavily on getting every configuration perfect up front, and then treating every future adjustment as an unplanned cost, often routed through change orders with the vendor. A more useful mindset treats the implementation phase as the moment when the operations team learns the platform well enough to keep adapting it themselves indefinitely. The budget goes toward capability building rather than toward a one-time deliverable. That distinction pays for itself many times over across the life of the platform, because the changes never stop coming. They just show up on a schedule nobody can fully predict in advance.
None of this is an argument against having a strong implementation partner or a responsive vendor. Complex integrations, data migrations, and genuinely novel product structures will always benefit from expert involvement, and a good vendor relationship still matters for the things that are actually complex. But the day-to-day adjustments that keep a lending operation aligned with its own market and its own regulatory environment should not require that kind of involvement. Those changes should sit in the hands of the people who understand the lending process best, which is almost always the operations team itself, not the software vendor. The platforms that recognize this distinction, and are architected around it, tend to be the ones that lending operations leaders describe as genuinely built for how lending actually works.
Blog
The Real Cost of Domain Gaps in Lending Implementations
I had a conversation with a client this morning that I have not been able to stop thinking about. We were in the middle of discussing a technology implementation, and he asked me a question that was not really about technology at all. He asked whether anyone on an implementation team had ever actually worked as a lender. Not in the technology department of a lending company. Not as an analyst who supported the lending business from the outside. He meant someone who had actually processed a loan. Someone who had sat across from a borrower, reviewed a personal guarantee, and watched how information moves through an underwriting decision from intake to close.
It was a fair question, and it came from a specific place. Earlier in their implementation, before we were involved, a configuration decision had been made that mapped guarantor data to the primary contact field. If you look at that decision from a purely technical standpoint, it is defensible. The primary contact field exists, it needed a value, and a guarantor is a person associated with the loan. Technically, the box was checked. Functionally, it was a mistake that cost the organization weeks of downstream cleanup.
Why the mistake was invisible to the people who made it
Here is the problem. A guarantor is not just a contact. A guarantor is an owner, an obligor, someone whose personal financial standing is directly tied to the credit decision and who carries legal liability if the loan defaults. A primary contact, in a lot of lending organizations, is whoever happens to answer the phone. It might be an office manager. It might be a bookkeeper. It might be someone with no ownership stake and no legal exposure at all. Collapsing those two roles into a single field is not a small data modeling choice. It changes how risk is tracked, how compliance documentation gets generated, how servicing teams know who to contact for a payment issue versus who to contact for a covenant default, and how reporting rolls up exposure across a portfolio.
None of that is visible if you are looking at the system from a pure configuration standpoint. The field existed. The data went somewhere. The screen populated correctly. Everything worked exactly as it was built to work. The failure was not in the execution. The failure was in not knowing that the distinction mattered in the first place.
This is the pattern I want to talk about honestly, because I think it gets missed in most conversations about technology risk. When implementations go wrong, the instinct is to look for a technical root cause. Something was misconfigured, a workflow rule fired at the wrong time, an integration dropped a field. Sometimes that is exactly what happened. But increasingly, in my experience, the root cause sits one level up from the technical layer. It sits in the gap between what a system can be configured to do and what a lending operation actually needs it to do, and that gap only becomes visible to someone who has lived inside the operation.
Technical competence and domain competence are not the same skill
I want to be careful here, because this is not a criticism of technical skill. The people who built that configuration were almost certainly skilled at what they do. They understood the platform, they understood data architecture, and they built something that worked exactly as specified. The issue is that nobody in the room knew enough about how guarantors actually function in a lending relationship to know that the specification itself was wrong.
This distinction matters more in lending than in a lot of other industries, because lending is full of terms and relationships that sound simple from the outside but carry very specific operational meaning on the inside. A guarantor is not a co-borrower. A commitment is not a disbursement. A covenant is not a condition precedent. A borrowing base is not a credit limit. Every one of these distinctions has real consequences for how a system needs to be built, and every one of them is the kind of thing that gets glossed over by someone who has read the documentation but never lived the workflow.
I have sat in enough implementation kickoffs to see this play out the same way almost every time. A technically strong team asks the client good, structured questions. What object should hold this data. What fields do we need. What is the relationship between these two records. And the client, who is usually not a systems person, answers in the language of their business. They talk about borrowers, guarantors, servicers, participants, syndication partners, draw schedules. If the person translating those answers into a data model does not fully understand what those words mean operationally, something gets lost in translation. It is not a large loss most of the time. It is a field mapped slightly wrong, a status value that does not capture an intermediate state that matters to the servicing team, a workflow that assumes every loan has one borrower and one guarantor when the client routinely handles loans with multiple guarantors in different lien positions.
Individually, these are small decisions. Collectively, they compound. By the time a lender is six months into using a system built on a foundation of small domain misunderstandings, the cost is no longer measured in configuration hours. It is measured in reconciliation work, in reports that do not match what the servicing team knows to be true, in underwriters who stop trusting the system and go back to shadow spreadsheets, in compliance teams who have to manually verify things the system was supposed to track automatically.
Why this problem hides so well during implementation
What makes this pattern particularly dangerous is that it is almost invisible during the implementation itself. Everyone in the room is oriented toward a launch date. Requirements get gathered, screens get demoed, sign-off gets given. A configuration that is technically wrong but plausible looking will pass every review that is designed to check whether the system does what it was told to do, because it does exactly that. The review that catches this kind of error is a different kind of review. It is not asking whether the system was built correctly against the specification. It is asking whether the specification itself reflects how a loan actually works.
That second kind of review requires someone in the process who has done the job the system is meant to support. Not read about it. Not managed people who do it. Done it. Processed the intake, chased the missing documentation, walked a deal through underwriting, watched what happens when a guarantor’s information is wrong at the point where it matters, which is usually not during implementation but six months later when there is a default and someone needs an accurate legal name and contact information for a demand letter.
I bring this up not to make a point about any particular vendor or approach, but because I think it is a useful filter for any lending organization evaluating a technology partner or building an internal implementation team. The question is not only whether the team knows the platform. Most competent technology teams know their platform. The better question is whether anyone on that team has enough lending experience to recognize when a technically sound answer is operationally wrong. That is a different kind of expertise, and it is much rarer than platform expertise, because it can only be built by actually working in lending operations, not by studying them.
What lenders can do about it before it becomes expensive
If you are heading into an implementation, or you are in the middle of one and something feels slightly off even though every individual piece looks correct, there are a few practical things worth doing. The first is to insist that someone with real lending operations experience, not just systems experience, reviews the data model before it gets built out. Not after. Before. That review should specifically test the assumptions behind every relationship in the system. Ask what happens when a loan has more than one guarantor. Ask what happens when a guarantor is also a borrower on a different loan. Ask what happens when the primary point of contact changes but the guarantor does not. If the answers require workarounds, that is a signal the model was built without someone in the room who understood the operational reality.
The second is to treat your own operations team as the domain experts they are, and make sure their input is weighted appropriately during requirements gathering. It is common for implementation conversations to be dominated by whoever is most comfortable talking about systems, which is often not the person who actually knows the lending workflow best. The credit analyst who has processed hundreds of loans and the servicing lead who fields collection calls every day often have a better instinct for what will break than anyone in the room with a systems title. Their input should not be a formality. It should shape the model.
The third is to build in a period, after launch, specifically dedicated to finding these domain gaps before they compound. Most organizations budget time for technical bug fixes after go-live. Fewer budget time for a structured review of whether the system’s logic actually matches how the business runs. That second review is often more valuable than the first, because technical bugs get noticed quickly. Domain gaps get noticed slowly, usually after they have already caused a problem downstream.
The lesson underneath the story
The client I spoke with this morning was not upset about the platform. He was making a point about what happens when deep technical capability is not paired with deep operational understanding of lending itself. I think that is the honest lesson here. Technology does not fail lenders because the software is weak. It fails them when the people configuring it do not know what a guarantor actually is, what a covenant actually means to a credit committee, or how a single misclassified relationship can ripple through servicing, reporting, and compliance for months.
The fix is not more technology. It is making sure the people translating your business into a system actually understand your business. That sounds obvious when you say it out loud. It is much harder to guarantee in practice, which is exactly why it is worth asking about directly, the same way that client asked me this morning.
Blog
Why Borrowers Abandon Loan Applications Before Underwriting
I was talking with a client this morning, a community lender, a Community Development Financial Institution that does real work in underbanked communities and with small businesses that traditional banks will not touch. This is a good team. Thoughtful leadership. They are in the middle of modernizing their technology and they know what they are doing. So when something they said in passing stopped me cold, I paid attention.
They mentioned they are running an active marketing campaign for a loan product right now. And their application abandonment rate is around fifty percent. Half the people who start an application never finish it. His words were direct. The application is so painful to get through that people just give up.
Sit with that for a second. This organization is spending real money to generate loan demand. The marketing is working. People are showing up, ready to apply, motivated enough to start. And then half of them disappear. Not to a competitor. Not because they found a better rate somewhere else. They disappear because the application itself pushed them out the door.
The problem you cannot see is the problem that is costing you the most
Here is what makes this dangerous. Application abandonment is largely invisible in most lending operations. Your reporting shows you funded loans. It shows you declined applications. Both of those outcomes get logged, tracked, and reviewed. But the borrower who starts an application and never finishes it typically leaves no trace. They do not show up in a pipeline report. They do not generate a decline reason code. They just vanish, and unless you are specifically instrumenting your intake process to catch that moment, you have no idea it happened.
That is the trap. You cannot manage what you do not measure, and most lending organizations are not measuring this at all. I have sat with COOs and Heads of Lending who can tell me their approval rate, their time to close, their portfolio yield down to a basis point. Ask them what percentage of started applications never reach a decision, and the room goes quiet. Not because they do not care. Because nobody built the report.
This is exactly why the problem persists. It is not that lenders are ignoring their borrower experience on purpose. It is that the cost of a bad application process is structurally hidden from the people who could fix it. A slow underwriting queue creates visible pain. A servicing error creates a phone call. An abandoned application creates silence. And silence does not get escalated in a leadership meeting.
The investment gap between the front door and everything behind it
What I keep observing across community lenders and specialty finance companies is a real imbalance in where the technology investment has gone. These organizations have made genuine progress on underwriting workflows. They have tightened up compliance infrastructure. Servicing has gotten more automated. Reporting has gotten more sophisticated. All of that is good, necessary work, and I do not want to undersell it.
But the application, the very first interaction a potential borrower has with the organization, has not kept pace. In a lot of cases it is still a PDF that gets emailed back and forth. In other cases it is a multi-step online form that times out, loses data, or requires the borrower to gather documentation before they even understand whether they qualify. In some cases the process simply cannot be completed without a phone call, which means the borrower has to interrupt their day, wait on hold, and explain their situation to someone instead of just finishing what they started.
None of this is a knock on the people running these organizations. It is a natural consequence of where the pressure has historically come from. Regulators care about compliance. Auditors care about servicing accuracy. Boards care about portfolio performance. Almost nobody has historically applied that same pressure to the borrower’s first five minutes with the organization. So that part of the operation quietly fell behind everything else.
Borrowers now have a different reference point
The reason this gap has become urgent, rather than just an area for gradual improvement, is that borrower expectations have shifted permanently. People now apply for credit cards, insurance, and consumer loans from their phone in a matter of minutes. They have a reference point for what a modern application should feel like, and that reference point did not come from another lender. It came from every other digital experience in their life.
When a borrower hits friction against that reference point, they do not usually complain. They do not call and tell you the form is broken. They do not send feedback. They just leave, quietly, and you never hear from them again. That is what makes this problem so easy to underestimate. There is no complaint volume to point to. There is just a number, buried somewhere in your funnel, that nobody is tracking.
And this applies with particular force to the borrowers that mission-driven lenders like CDFIs exist to serve. Underbanked borrowers and small business owners are often applying for credit with less margin for error in their time and less patience for a process that assumes they have hours to spend gathering documents and re-entering information the organization may already have. If your mission is to serve borrowers that traditional banks overlook, the application experience is not a secondary concern. It is core to whether you actually reach the population you are trying to serve.
This is a product problem, not a marketing problem
Here is the core insight I want lenders to sit with. A fifty percent abandonment rate is not solved by spending more on lead generation. I have seen organizations respond to a weak funnel by doing exactly that, pouring more budget into the top of the funnel, assuming the answer is more volume. But if half of every new lead is being lost to friction in the application itself, doubling your marketing spend just means you double the number of frustrated people who never finish applying. You are not fixing the leak. You are running more water through it.
The actual fix is removing the friction between a borrower’s intent and their completed application. That is a product and process problem, not a demand generation problem. It means looking honestly at how many steps stand between a borrower clicking start and a borrower submitting a complete application, and asking whether every one of those steps is actually necessary. It means eliminating redundant data entry, where a borrower is asked to type in information the organization could reasonably pull from a prior interaction or verify through a connected data source. It means building for mobile first, because a large share of your applicants are starting this process on a phone, whether or not your form was designed with that in mind. And it means respecting the borrower’s time at every step, which sounds simple but is routinely violated by processes that make someone stop, gather a document, and come back later, at which point a meaningful share of them do not come back at all.
Why this matters more as lending operations get more complex
I want to be clear that this is not a call to make lending decisions less rigorous. Underwriting complexity exists for good reasons. Risk needs to be assessed properly. Documentation requirements exist to protect both the borrower and the lender. The point is not to strip out necessary steps in the name of speed. The point is to separate the friction that serves a real underwriting or compliance purpose from the friction that exists simply because the application was built years ago and nobody has revisited it since.
In my experience, when you actually walk through an existing application process step by step, a meaningful share of the friction has nothing to do with risk management. It is redundant fields. It is a form that does not save progress. It is a process that requires the borrower to know which document goes with which loan type, without guiding them there. It is a workflow that was built for one loan product and awkwardly reused for three others. None of that protects the lender from anything. It just costs borrowers time and costs the organization pipeline.
This is also where operational visibility connects directly back to the abandonment problem. Lenders that have built a single, connected view of the borrower’s journey, from first application click through underwriting, servicing, and repayment, are in a much better position to see exactly where borrowers are dropping off and why. When the application process lives in a disconnected system, separate from underwriting and servicing, that visibility gap becomes structural. Nobody can see the full picture because the full picture does not exist in one place. That disconnect is precisely why abandonment goes unmeasured in the first place. It is not that lenders do not care about the metric. It is that their systems were never built to produce it.
The return on fixing this compounds
The lenders who take this seriously and fix it first are going to see a disproportionate return, and it will not come from getting better at marketing. It will come from stopping the loss of half their pipeline before the process even begins. Every marketing dollar an organization spends is already paying to get a borrower to start an application. If that borrower abandons the process, the organization has already paid the acquisition cost and received none of the value. Fixing the application experience does not require spending a single additional dollar on demand generation. It just means the demand that is already being generated actually converts.
That is a different kind of return on investment than most lending organizations are used to calculating, and I think that is exactly why it gets missed. It does not show up as a new revenue line. It shows up as more of the pipeline you already paid for actually reaching a funded loan. For a mission-driven lender trying to serve borrowers who have historically been shut out of traditional credit, that is not just a financial improvement. It is the difference between reaching the community you set out to serve and quietly losing half of them at the door.
If there is one thing I would ask any Head of Lending or Digital Transformation leader to do after reading this, it is simple. Go find out what your actual application abandonment rate is right now. Not your approval rate. Not your decline rate. The number of people who started and never finished. If you cannot answer that question today, that is the first problem to solve, because you cannot fix friction you are not measuring.