Blog
Why CDFI Reporting to Multiple Funders Is So Hard
I have spent a lot of time in the offices of Community Development Financial Institutions over the past several years, and there is one operational burden that comes up in almost every conversation but rarely gets discussed in the broader lending technology conversation. It is not underwriting. It is not loan origination speed. It is reporting.
Most lenders report to a regulator, an investor, or a warehouse lender. A CDFI reports to all of the above, plus several more constituencies that a conventional lender never has to think about. The CDFI Fund requires detailed performance and compliance data on a recurring schedule. If the organization is also a New Markets Tax Credit allocatee, there is a separate and distinct reporting obligation tied to that program, with its own definitions of qualified investments and its own submission windows. Bank partners that provide capital or participate in loans want their own portfolio performance updates, usually in whatever format their credit committee is used to seeing. Foundation investors who provided program-related investments or grants want impact reporting that speaks to mission outcomes, not just financial performance. A single mid-sized CDFI can easily be managing five or six of these reporting relationships at once, each with a different cadence, a different data schema, and a different submission portal or format.
This is the part of the CDFI operating model that does not show up in a pitch deck or a strategic plan, but it consumes an enormous amount of staff time, and it carries a risk that most organizations have not fully priced in.
What the manual reporting process actually looks like
At organizations that have not modernized their lending platform, the reporting process follows a familiar pattern, and I have watched it play out almost identically across different CDFIs in different parts of the country. Someone on the team, often in operations or finance, goes into the loan servicing system and pulls an extract. They go into a separate origination system, or a legacy database, and pull another extract that has different fields but overlapping loans. They open a handful of spreadsheets that were built at some point to track information the core systems never captured well: minority ownership status of borrowers, jobs created, census tract designations, use of proceeds categories that matter to a specific funder but not to the loan system’s default fields.
All of that gets combined, by hand, into a master spreadsheet. From there, someone reformats subsets of that data to match each funder’s specific template. The CDFI Fund wants the data one way. The NMTC allocatee wants a different cut, tied to compliance periods for specific qualified low-income community investments. The bank partner wants a simplified performance summary. The foundation wants a narrative report with select metrics woven in. Each of these gets built separately, checked separately, and sent separately.
This is not a one-time event. It happens on whatever cadence each funder requires, and because the cadences do not align, there is rarely a quiet month. A CDFI executive I spoke with recently described her reporting calendar as something that never actually closes. As soon as one report goes out, the next one’s data pull begins.
The time cost is real, but it is not the biggest problem
It is easy to quantify the hours. Multiply the number of funders by the number of reporting cycles per year, add in the time spent reconciling numbers that do not initially match between sources, and you get a real number of staff hours that could otherwise go toward underwriting new loans, supporting borrowers, or expanding the portfolio. For a lean operations team, that is not a trivial amount of capacity to lose to spreadsheet assembly.
But the time cost is not actually the most important issue. The more consequential problem is data integrity, and it is the one that keeps CDFI leaders up at night once they think it through.
When reporting is assembled manually from multiple systems and multiple spreadsheets, by different people, on different timelines, the probability of small inconsistencies is not a hypothetical risk. It is close to a mathematical certainty over enough reporting cycles. A loan balance that gets pulled from the servicing system in March may not match a figure pulled for a different report in April, simply because a payment posted in between, or because someone applied a different as-of date, or because two different staff members interpreted a delinquency status differently. A jobs-created figure that gets manually updated in one spreadsheet might never get carried over to the version used for a different funder’s report.
Individually, these are minor and explainable. But they accumulate. And they surface at exactly the moment a CDFI least wants them to surface: during a funder audit, a compliance review, or a due diligence process ahead of a new capital commitment. A discrepancy between what the CDFI Fund received in a quarterly report and what a bank partner received in an annual summary is the kind of finding that turns a routine review into an uncomfortable conversation about internal controls. It does not matter that the underlying lending activity was sound. What matters is that the organization could not demonstrate a single, consistent version of the truth.
Why this problem is structural, not a staffing issue
I want to be direct about something, because it is a point that gets missed. This is not a problem caused by understaffed operations teams or by people not being careful enough. I have met extremely diligent, detail-oriented operations staff at CDFIs who still cannot fully eliminate this risk, because the problem is structural. When the underlying data lives in multiple systems that do not talk to each other, no amount of individual diligence closes the gap completely. You can build better spreadsheet templates. You can add more review steps. You can assign a second person to check the numbers before submission. All of that helps at the margins, but it adds more manual labor on top of an already manual process, and it does not address the root cause, which is that there is no single system of record generating a single, authoritative version of the loan data.
This is worth sitting with for a moment, because it reframes the conversation. The issue is not “we need to work harder on reporting.” The issue is “our operational infrastructure was not built to produce one consistent data source for many different audiences.” Once a CDFI’s leadership sees the problem that way, the solution set changes.
What changes with a single system of record
When a community lending organization consolidates loan origination, underwriting, servicing, and portfolio data onto a single platform, the reporting problem does not just get faster. It changes in kind. Every data point about every loan lives in one place. A loan’s balance, its delinquency status, its use of proceeds category, the borrower’s demographic and community impact attributes captured at origination, all of it sits in one system rather than being scattered and periodically synced by hand.
From there, reports can be built once, as configured views or automated exports tied to each funder’s specific requirements, and then run again every cycle without being rebuilt from scratch. The CDFI Fund report pulls from the same underlying data as the NMTC compliance report and the bank partner’s performance summary. When the reporting deadline arrives, the operations manager runs the report rather than assembling one. The formatting differences between funders remain, because those requirements are real and will not go away, but the underlying data feeding every one of those formats is identical, because it all comes from the same source.
This is the part that matters most for a CDFI’s relationship with its funders. Consistency is not a nice-to-have in this context. It is close to the entire basis of trust between a CDFI and the institutions that fund it. Bank partners, NMTC allocatees, and foundation investors are all, in their own way, evaluating whether the CDFI can be relied upon to manage capital responsibly and report on it accurately. An organization that can demonstrate the same numbers, consistently, across every funder relationship, every cycle, is telling those funders something important about its operational maturity, independent of anything it says in a pitch or a narrative report.
Reporting infrastructure as a growth constraint
There is a further consequence worth naming, because it affects CDFIs that are trying to grow. Every new funder relationship a CDFI adds, whether it is a new bank participant, a new NMTC allocation, or a new federal program, brings its own reporting requirement. If the reporting process is manual, each new funder relationship adds incremental manual work, and at some point the operations team’s capacity to take on new reporting obligations becomes a real constraint on the organization’s ability to accept new capital. I have seen CDFIs quietly hesitate to pursue a promising new funding relationship because the team already felt stretched thin on existing reporting commitments.
That is a strange position for a mission-driven lender to be in. The organization exists to deploy capital into underserved communities, and the constraint on doing more of that is not access to capital or lending demand. It is the operational capacity to report on the capital it already manages. A platform that treats reporting as a byproduct of well-structured data, rather than a separate manual exercise, removes that constraint. Adding a new funder becomes a matter of configuring a new report template against data that already exists, not building an entirely new manual process from the ground up.
What this means for CDFI leadership
If you are a COO, a head of lending, or a digital transformation lead at a CDFI, it is worth asking a direct question about your current reporting process. Does the data your team sends to the CDFI Fund, your NMTC compliance team, your bank partners, and your foundation investors all originate from a single, authoritative source? Or does it get assembled, cycle after cycle, from multiple systems and spreadsheets by people doing their best to reconcile numbers that were never designed to reconcile automatically?
If the answer is the latter, you are carrying two costs simultaneously. The first is the time cost, which is real but recoverable. The second is the data integrity risk, which is not something you notice until a funder notices it for you. For an organization whose ability to keep lending depends entirely on the confidence of its funders, that second cost is not a back-office inconvenience. It is a mission-critical exposure.
Modernizing the underlying lending platform is not primarily about speed or convenience, even though those benefits are real. For a CDFI, the more compelling case is about consistency, and about protecting the credibility that took years to build with every funder in the portfolio. A platform like FUNDINGO, built to serve as a single system of record across origination and servicing, addresses this problem at its root by ensuring that whatever report goes out the door, to whichever funder, on whatever schedule, is drawing from the same data every time. That is not a technology upgrade for its own sake. It is the operational foundation that lets a CDFI keep the trust of the institutions it depends on, while spending less of its time proving that trust is deserved.
Blog
What CDFI Leaders Should Expect From a Lending Platform Rollout
There is a conversation I have had with enough CDFI leaders now that I can predict how it will go before it starts. It happens after the implementation is done, usually six months or a year into using their new lending platform. The system is working. The team is faster. Reporting that used to take days now takes hours. By every measure, the project succeeded. And yet almost every one of these leaders says some version of the same thing when I ask how it went: they wish someone had told them, honestly and specifically, what the process was actually going to feel like.
That gap between expectation and reality is not a FUNDINGO problem or a competitor problem. It is a pattern across the industry, and it is worth naming directly because it is entirely avoidable. The organizations that go into a lending platform implementation with accurate expectations come out the other side faster, calmer, and with a system that genuinely reflects how they operate. The organizations that go in expecting a lighter lift almost always hit a frustration wall somewhere around month three or four, and that frustration is preventable.
The vision is real, and it is also the easy part
Every CDFI I talk to has the same picture in mind when they start evaluating a new loan origination platform. Configurable workflows that match their actual loan products instead of forcing every deal through a generic process. Custom reporting built around the specific requirements of their funders and their board, not a one-size-fits-all report that gets exported into a spreadsheet and reworked by hand every quarter. A system that bends to reflect how the team already works, instead of a system the team has to bend around.
That vision is achievable. It is why organizations move off spreadsheets and disconnected tools in the first place, and it is why digital transformation for lenders has become a board-level priority rather than an IT initiative. But there is a meaningful difference between the vision being achievable and the vision being simple to get to. Most of the disappointment I hear about in implementations does not come from the software failing to deliver. It comes from the distance between how exciting the destination sounded in the sales process and how demanding the road to get there actually was.
Why early configuration decisions carry more weight than they appear to
Here is the pattern I see consistently, almost regardless of the specific platform or vendor involved. A CDFI leadership team goes into implementation with genuine enthusiasm and a clear list of what they want the system to do. In the first weeks, the team starts making configuration decisions: how loan products are structured, how underwriting stages are sequenced, how documents map to workflow steps, how servicing hands off from origination. These decisions feel straightforward at the time because the team is looking at them in isolation.
The problem is that the team is learning the system at the exact same time they are building it inside the system. That is simply the nature of implementation, and there is no way around it entirely. But it means that a configuration choice that seemed obviously correct in month two can create a downstream constraint in month five, once other pieces of the workflow are built on top of it. The team goes back and fixes it, which is the right move, but the fix often shifts something else that depended on the original setup. Progress that felt steady suddenly feels like it is stalling. That is usually the exact moment I hear from a client, and it is usually not a sign that anything has gone wrong. It is a sign that the organization is doing the hard, normal work of translating a complex operation into a configured system.
Leaders who know this pattern exists going in tend to handle it very differently than leaders who are caught off guard by it. Knowing that early decisions will need revisiting is not a reason to slow down or second-guess every configuration choice. It is a reason to build revisiting into the plan from the start, rather than treating every adjustment as evidence that the implementation is behind schedule or off track.
What actually separates a smooth implementation from one that spins in place
Across the CDFIs and specialty lenders I talk to, the ones who come through implementation well have two things in common, and neither of them is luck.
The first is an implementation partner who does more than execute what the client asks for. There is a meaningful difference between a vendor team that takes requirements and builds exactly what was requested, and one that brings real lending domain knowledge to the table and says: here are three ways we could solve this particular workflow problem, and here are the tradeoffs of each. A CDFI’s operations team knows their loan products and their funder requirements better than anyone. But they are not implementation specialists, and they have not seen fifty other lenders solve the same underwriting sequencing problem or the same servicing handoff issue. The value of an experienced partner is not that they take orders faster. It is that they shorten the distance between a rough idea of what the team wants and a configuration that will actually hold up once it is stress-tested by real loan volume.
The second is a client-side owner who has real authority and real bandwidth to make decisions quickly and consistently for the duration of the project. This sounds obvious, but it is the single most common gap I see. Implementations stall not because the technology is difficult, but because decisions sit unmade for two or three weeks waiting for the right person to have time to weigh in, or because the person making decisions in week two is not the same person making decisions in week eight, and the workflow reflects that inconsistency. A loan origination software implementation is not a set-it-and-forget-it project. It requires a named owner whose job, for the duration of the rollout, includes being available and empowered to decide.
An organizational commitment, not a delegated project
This is the point I want every lending executive to hear clearly before they sign a contract, not six weeks after. Implementing a new lending platform is not a project you hand off to IT or to a single project manager and check in on periodically. It is an organizational commitment that requires active, sustained involvement from your operations team over an extended period. Underwriters, servicing staff, and portfolio managers need to be in the room, testing workflows, flagging edge cases, and confirming that what is being built actually matches how loans move through their organization in practice, not just how it looks on a process diagram.
Lenders who understand this going in staff for it. They protect time on their operations team’s calendar. They set timelines that account for real testing cycles, not just build cycles. And they set expectations with their board and their funders that the transition will take real, visible effort for a defined period, rather than promising a seamless switch that quietly slips deadline after deadline. Lenders who expect a faster, lighter process almost always end up disappointed, not because the platform underdelivered, but because the organization did not build in the capacity the process actually required.
This matters even more for CDFIs specifically, because the operational complexity is often higher than it appears from the outside. A commercial bank implementing new CDFI software for a single loan product line has a comparatively contained problem. A community development lender managing a blend of loan products, layered funding sources, mission-driven reporting requirements, and multiple funder relationships each with their own reporting expectations is configuring a genuinely more intricate system. That complexity is exactly why the platform is worth building correctly. It is also exactly why the implementation deserves realistic time and realistic staffing.
What realistic expectations actually look like in practice
Setting accurate expectations does not mean assuming the worst or padding every timeline defensively. It means being specific about what the process will require instead of relying on a general sense that it will be a few months of setup. It means asking a prospective implementation partner directly how they handle configuration decisions that need to be revisited, rather than assuming everything will be built correctly on the first pass. It means identifying, before the contract is signed, who on the internal team will own decisions day to day, and confirming that person has both the standing in the organization and the calendar space to actually do it.
It also means being honest internally about the fact that some period of the implementation will feel harder than expected, and building that expectation into how the leadership team communicates with staff and with the board. A rollout that is communicated as “this will take real, sustained effort from our team for several months, and here is why it is worth it” tends to generate far less internal frustration than one communicated as “this will be quick and mostly invisible to day-to-day operations.” The second framing sets everyone up to feel like something has gone wrong the moment reality diverges from that promise, even when the implementation is actually on track.
The time is real, and it is worth it
Every CDFI leader I talk to who has come through a successful implementation says the same two things in the same breath. The process took more time and more organizational energy than they expected. And it was worth it. Those two statements are not in tension. They are simply both true, and leaders who accept that going in are the ones who navigate the middle stretch of implementation without losing confidence in the outcome.
The platform you end up with, one that is genuinely configured around your loan products, your funder reporting requirements, and the way your team actually works, is a real operational advantage over spreadsheets, disconnected point solutions, and manual reconciliation between systems. That advantage compounds for years after implementation is complete. But it is built during a period that demands real attention from your best people, not a period you can quietly delegate and revisit once it is finished. Go in knowing that, staff for it accordingly, and the transformation on the other side will be everything the vision promised.
Blog
The Hidden Portfolio Risk in Spreadsheet-Based Lending
I have sat in enough conversations with COOs and Heads of Lending at community lending organizations to notice a pattern that most executive teams have not fully priced into their risk models. It shows up almost every time a CDFI or specialty lender moves off spreadsheets and legacy servicing tools and onto a single system of record. The migration itself becomes the moment of discovery. Not discovery of a better user interface or a faster reporting process, but discovery of things that were happening, or not happening, that nobody actually knew about.
Here is the pattern in its simplest form. A lending organization has been managing its portfolio across a combination of spreadsheets, a legacy servicing platform, email threads, and the institutional memory of a handful of experienced staff. From a distance, the operation looks like it is working. Loans are being serviced. Draws are getting processed. Borrowers are hearing from someone when they need to. Reports go out. Audits get passed. Nothing is visibly on fire.
But underneath that surface-level functionality is a structure that depends entirely on a small number of people staying personally close enough to every loan in the portfolio to catch what the systems are not tracking. That is not a criticism of those people. It is often a testament to how good they are at their jobs. But it is also a description of a fragile system, because the moment the portfolio grows faster than any individual’s capacity to hold it all in their head, or the moment that person leaves, goes on leave, or simply gets pulled onto something else, the coverage disappears with them.
What Migration Actually Surfaces
When a lending team begins migrating loan data into a centralized platform and, for the first time, builds reporting that pulls from one single source of truth, things start appearing that were never visible in the old environment. Not because the old environment was reported honestly and the new one reveals fraud or failure. Almost never that. What surfaces instead is far more mundane and, in some ways, more concerning precisely because of how mundane it is.
Processes that were assumed to be happening because someone was formally responsible for them, but that were never actually tracked anywhere, start showing up as gaps. A covenant review that was supposed to happen quarterly but had quietly slipped to twice a year because nobody had a system flagging it. Tasks that fell through the space between one spreadsheet and another, because two people each assumed the other one owned a step in the process. Portfolio conditions, like an insurance certificate lapsing or a borrower missing a financial reporting deadline, that had not been monitored consistently because there was no automated trigger built to catch them, only a person’s memory and habit.
One operations leader described this moment to me directly. During their migration, they found things that genuinely frightened them. Not because loans in the portfolio were failing or because there was evidence of mismanagement. What frightened them was realizing how close they had come to real problems that had stayed invisible purely because their team happened to be close to their borrowers and had caught issues manually that the system should have been flagging automatically. The portfolio had been fine. But it had been fine because of proximity and vigilance, not because of process. That is a very different thing, and it is not a sustainable operating model at scale.
Why This Is a Risk Management Problem, Not Just an Efficiency Problem
Most conversations about moving away from spreadsheet-driven lending operations get framed around efficiency. Faster underwriting. Less duplicate data entry. Fewer hours spent reconciling numbers across disconnected files before a board meeting. Those benefits are real, and they matter to any organization trying to do more with the same headcount. But they are not the most important reason to fix this problem.
The more important reason is portfolio risk. Efficiency problems cost you time and morale. Visibility problems cost you exposure you did not know you had. A missed insurance renewal on a piece of collateral is not just an administrative miss, it is uncovered risk sitting in the portfolio for however long it goes unnoticed. A borrower reporting requirement that quietly stopped being enforced means covenant violations could be accumulating without anyone noticing until a renewal or a downturn forces the issue. A draw request that sat unprocessed for three weeks because it fell into the gap between two people’s spreadsheets is not just a service delay, it is a borrower relationship risk and, depending on the loan program, potentially a compliance issue.
None of these things show up as a crisis on any given day. That is exactly what makes them dangerous. Spreadsheet-driven operations do not fail loudly. They fail quietly, one uncaptured task at a time, until the accumulated gaps are large enough that something breaks through to the surface, usually at the worst possible moment, during an audit, a regulatory exam, a warehouse lender’s review, or a credit event where the organization suddenly needs a complete and accurate picture of its portfolio and discovers it does not have one.
The Scale Problem That Nobody Budgets For
Here is the part that I think gets underweighted in most technology decisions. The personal-oversight model of portfolio management works fine at a certain scale. A team managing a hundred loans with a tenured servicing lead who knows every borrower by name can absolutely catch things manually that a less experienced or less staffed team would miss. That is real institutional capability, and it should not be dismissed.
But that model has a ceiling, and the ceiling is lower than most executive teams assume. It is not a function of loan count alone. It is a function of loan count relative to team capacity, portfolio complexity, and staff turnover. CDFIs and specialty lenders in particular tend to grow in bursts, driven by new funding sources, new government programs, or new investor capital, and those bursts often outpace the organization’s ability to hire and train new servicing staff at the same rate. The result is that the portfolio grows past the point where any individual can maintain personal oversight over every loan, while the operational model has not changed to compensate. The spreadsheets get bigger. The tabs multiply. The tribal knowledge gets thinner as it gets spread across more people who have each been there for less time.
This is the moment when the risk I am describing stops being theoretical. It is not that the team got worse at their jobs. It is that the operating model was never built to scale past a certain point, and nobody updated it before the portfolio outgrew it.
What a Migration Actually Gives You
This is why I think the migration process itself, uncomfortable as it can be, is one of the most valuable things a lending organization can go through. Moving loan data into a single system of record and building reporting that pulls from that one source, rather than from whoever happens to have the most current spreadsheet open, is often the first time a leadership team gets a complete and honest picture of their own portfolio. What is current. What is behind. Which processes have actually been running consistently, and which ones have only been approximated by good intentions and institutional memory.
For most organizations, once the dust settles, that picture turns out to be better than they feared going in. The team was doing more right than wrong. The instincts were sound. But almost every organization finds a handful of things during that process that would have stayed hidden indefinitely under the old model. And those are exactly the moments that make the investment worthwhile, because those are the gaps that, left unaddressed, eventually turn into losses, compliance findings, or reputational damage with funders and investors who expect institutional-grade portfolio management from an institution asking for institutional-grade capital.
This is also where the distinction between loan origination software and loan servicing software matters more than people initially think. Origination gets a lot of attention because it is customer-facing and tied directly to growth. But servicing is where portfolio risk actually lives day to day, long after the loan has closed and the excitement of funding has passed. A servicing platform that can automatically track conditions, trigger alerts on missed borrower reporting, and give operations leaders a live view of draw requests and outstanding tasks is not a convenience feature. It is the mechanism that replaces personal vigilance with institutional process. That replacement is the whole point.
The Practical Test Every Lending Executive Should Run
I would encourage any COO or Head of Lending reading this to run a simple test on their own operation. Try to answer three questions without asking anyone to manually pull and reconcile multiple spreadsheets. Which loans in the portfolio currently have outstanding conditions that have not been cleared. Which borrowers have missed a scheduled reporting requirement, whether that is financial statements, insurance documentation, or a covenant certification. Which draw requests have been submitted but not yet processed, and how long have they been sitting.
If your organization can answer those three questions in minutes, from a single source, with confidence that the answer is current and complete, you likely have the operational infrastructure you need, regardless of what specific tools you are using. If answering those questions requires pulling together information from multiple spreadsheets, cross-referencing with a legacy system, and checking in with two or three people to make sure nothing was missed, you have a visibility problem, whether or not it has caused a loss yet.
And that last qualifier matters. Visibility problems in lending operations do not stay invisible forever. They surface eventually, either through a controlled process like a system migration, where you get to find the gaps on your own terms and fix them proactively, or through an uncontrolled process like an audit, a regulatory exam, a credit event, or a departure of a key staff member, where you find the gaps on someone else’s terms and have to explain them after the fact.
Operational Capability Is the Real Investment
I want to be direct about something. This is not an argument that every CDFI or specialty lender needs to rip out its existing systems tomorrow. Plenty of organizations run disciplined, well-controlled operations on a mix of tools, provided they have built real process discipline around those tools and have not simply substituted good intentions for actual tracking. The problem is never the spreadsheet itself. The problem is when the spreadsheet, or the disconnected legacy system, becomes the only place a critical piece of portfolio information lives, with no automated way to surface it to the people who need to see it.
What lending organizations are actually buying when they invest in a modern platform is not software for its own sake. It is operational capability. The ability to see the full portfolio in one place. The ability to standardize workflows so that a task does not depend on which person happens to remember to do it. The ability to reduce the manual reconciliation that eats staff time and, more importantly, hides risk in the seams between systems. The ability to scale the operation without needing to scale personal heroics at the same rate.
That is the case for treating portfolio visibility as a risk management priority, not just an efficiency initiative. The organizations that get ahead of this tend to do it on their own timeline, through a deliberate migration and platform decision. The organizations that do not tend to get ahead of it eventually too, just not on their own terms.
Blog
What Automating Payment Processing Actually Saves Lenders
I have sat in enough operations meetings at community lenders and CDFIs to notice a pattern. When the conversation turns to modernizing loan servicing, the case for automation almost always gets made in soft terms. People talk about efficiency, or reducing errors, or freeing up staff. Those things are true, but they are also vague enough that a COO or Head of Lending can nod along and still not act. What changes the conversation is putting real numbers next to the words. So I want to walk through two of the most time-consuming manual workflows in community lending operations, payment processing and draw management, and show what actually happens to the time and capacity of an operations team when those workflows move from manual to automated.
The Real Cost of Manual ACH Payment Processing
Here is what manual ACH payment processing looks like at a typical small to mid-sized CDFI, and I suspect it will sound familiar to anyone running operations at a specialty lender. Every month, someone on the operations team manually builds a batch file. They go through every loan in the portfolio, enter payment amounts by hand, and for lines of credit with variable payments, they pull together supporting documentation loan by loan. Assembling that package takes between one and two hours, and that is before anyone has reviewed it.
Once the batch is built, it goes to a director for review and sign-off. That is a second set of eyes checking the same data, loan by loan, for errors before anything is submitted. From there it moves to finance, where another review happens, and then finance manually enters every payment into the accounting system so the general ledger matches what was actually collected and disbursed.
Add it up and you are looking at roughly one full day of staff time spread across three people, every single month, just to process payments. Not to originate new loans. Not to manage delinquency. Not to talk to borrowers. Just to move payment data from one system into another and make sure nobody made a mistake along the way.
When that same workflow runs on a modern lending platform with automated payment processing built in, the batch is generated, validated, and posted in about ten minutes. Not ten minutes per loan. Ten minutes for the entire monthly cycle. The review layers do not disappear, but they shrink dramatically because the system is validating data as it moves rather than relying on a human to catch inconsistencies after the fact.
Draw Management Tells the Same Story
Payment processing is not the only place this shows up. Construction draw management follows an almost identical pattern, and for lenders active in construction or rehab lending, the math is arguably even more compelling because draw volume tends to be higher and more variable.
A manual construction draw request typically takes forty-five minutes to an hour to process. Someone has to review the budget against what has already been disbursed, confirm that the milestone triggering the draw has actually been completed, process the disbursement itself, and then update the loan record so the balance, the remaining budget, and the servicing history all reflect reality. Every step is manual, every step depends on someone remembering to do it correctly, and every step is an opportunity for the loan record to drift out of sync with what is actually happening on the ground.
On an automated platform, that same draw takes about five minutes. The budget comparison, the milestone tracking, and the update to the loan record all happen as part of one connected workflow rather than as four separate manual steps performed by however many people happen to be involved that day.
For a community lender processing twenty to twenty-five draws a month, the difference between forty-five minutes and five minutes per draw is not a rounding error. It is somewhere between thirteen and eighteen hours of staff time returned every single month, on draw management alone.
Why the Time Savings Matter More Than They Sound
It would be easy to stop at the hours and call it a productivity story, but that undersells what is actually happening. The real value of this kind of automation is not the time itself. It is what that time enables an operations team to do instead.
A small CDFI operations team that spends a full day every month building payment batches is a team that is, by definition, not spending that day on borrower relationships, new loan origination, or portfolio monitoring. Multiply that across draw management, servicing exceptions, and the other manual processes that tend to accumulate in growing lending organizations, and you start to understand why operations teams at community lenders so often feel like they are treading water even as portfolio volume grows. The team is not underperforming. The team is running processes that were never designed to scale.
When that day comes back, it does not evaporate. It becomes capacity. It shows up in an operations team’s ability to actually get ahead of delinquency instead of just reacting to it, in a loan officer’s ability to spend more time with a borrower who is struggling instead of rushing to the next file, and in a leadership team’s ability to say yes to a new lending program without immediately asking whether they need to hire two more back-office staff to support it.
This is the part that gets lost when automation is pitched purely as an efficiency play. The value is not that the same team does the same work faster. The value is that the same team can now do more, without the organization needing to grow headcount at the same rate it grows loan volume. That is the difference between a lending operation that scales and one that hits a ceiling every time it tries to grow.
What This Looks Like in Practice
I think it is worth being specific about why this gap exists, because it is not that operations teams at community lenders are inefficient. It is that most of them are working across a patchwork of spreadsheets, a core servicing system, and separate accounting software, with no real connection between them. Every handoff between those systems is a place where a human has to manually reconcile, re-enter, or re-verify data that already exists somewhere else. That is where the hours go.
A modern lending platform built to handle both origination and servicing in one place removes most of those handoffs because the data does not need to move between disconnected systems in the first place. Payment data flows from the servicing record into the accounting entry without someone re-typing it. Draw requests are validated against the budget and the loan terms automatically because the platform already has the loan structure, the disbursement schedule, and the milestone requirements in one connected record. The reviews that matter, director sign-off, finance verification, still happen. They just happen against clean, validated data instead of a spreadsheet someone assembled by hand under a deadline.
This is also why the case for automation should not be framed as a technology upgrade. It is an operational capacity decision. The lenders I talk to who get the most value out of this kind of platform change are not the ones chasing the newest feature set. They are the ones who did the exercise of counting the actual hours their team spends on manual payment processing and draw management every month, and then asked what the organization could do with those hours if they came back.
The Question Every Lender Should Be Asking
If you are a COO or Head of Lending at a community lender or CDFI still running these processes manually, the exercise is straightforward. Count the hours your team spends building payment batches, routing them for approval, and manually entering them into accounting every month. Count the hours spent reviewing budgets, confirming milestones, and processing disbursements for every construction draw. Then ask what your organization could actually do with those hours if they came back.
For most organizations, the answer is not more of the same work done faster. It is capacity to grow the portfolio without proportionally growing back-office headcount. It is the ability to launch a new lending program without operations becoming the bottleneck. It is time for the operations team to focus on the borrower relationships and portfolio monitoring that actually require human judgment, instead of the mechanical work of moving numbers from one system to another.
That is the real business case for automating payment processing and draw management. Not a feature list. Not a vendor demo. The capacity that returns to a small, capable team and what they choose to build with it once it does.
Blog
Who Controls Your Loan Origination Software Changes?
There is a conversation I have had dozens of times with COOs and Heads of Lending, usually not during a vendor demo but months or years after a platform has already gone live. It starts the same way. Someone on the operations team needs to change something small. An underwriting threshold. A stipulation requirement. The routing logic for a new loan product. And the answer they get is not “sure, give me ten minutes.” It is “let me open a ticket and check with the vendor.”
That moment is where a lot of lending organizations realize, too late, that they evaluated the wrong thing during the buying process. They tested whether the platform could handle their loan products, their approval workflows, their reporting requirements. Those are the right questions to ask. But there is a question that almost never comes up in an RFP or a demo, and it turns out to be one of the most consequential decisions a lending organization makes. Who has to be involved every time something needs to change.
Change is not the exception in lending. It is the operating condition.
Lending organizations that are growing, adapting, and competing do not operate in a static environment, and treating a loan origination platform as if it will only ever need to support today’s rules is a planning mistake. Underwriting guidelines shift based on portfolio performance and market conditions. Regulatory requirements change and have to be reflected in workflows, documentation, and disclosures. New loan products get launched to capture opportunity. Existing products get modified as the organization learns what is working and what is not. Stipulation requirements get tightened or loosened depending on risk appetite. In a healthy lending operation, these changes are not rare events. They happen monthly, sometimes more often, and the pace tends to increase as the organization scales.
The operational question this raises is straightforward but rarely asked directly during a platform evaluation. When one of these changes needs to happen, who makes it happen, and how long does it take. In some platforms the answer is that a trained operations leader logs in, updates the rule, tests it, and moves on with their day. In other platforms the answer is a service ticket, a queue, a development cycle, a testing phase, and a deployment window that can stretch into weeks.
The hidden cost of the service ticket model
The lenders who describe this problem most clearly are almost always the ones who have lived through both experiences. They implemented a platform early in their growth that required developer involvement for every configuration change, and later moved to one that did not. The difference in operational agility between those two experiences is not incremental. It is enormous, and it shows up in ways that rarely get captured in a vendor comparison spreadsheet.
Here is what actually happens while a change request sits in a queue. The operations leader already knows what needs to change and why. They are not waiting because they are uncertain. They are waiting because the system will not let them act on their own knowledge. Meanwhile the team still has to serve borrowers and process loans under the old rule, or worse, they build a workaround. That workaround is almost always a spreadsheet tracking exceptions, an email chain documenting a manual override, or a side process that exists outside the system of record. The platform that was supposed to eliminate manual work and operational risk becomes, in that moment, the reason manual work and operational risk exist. The team is not failing to use the technology correctly. The technology was not designed to keep pace with how the business actually operates.
This is the part that tends to get missed during procurement. A platform’s capability list describes what the system can do on day one. It says nothing about how the organization will adapt that system over the next five years, and adaptation is where the real operational cost or benefit shows up.
Configurability and customization are not the same thing
It is worth being precise here, because these two words get used interchangeably and they describe fundamentally different operating models. Customization means altering the underlying code of a platform to make it do something it was not originally built to do. Customization requires developers, whether internal or from the vendor. It creates technical debt that accumulates with every change. It makes every future upgrade more complicated, because custom code has to be retested and often rewritten every time the underlying platform changes. Customization can solve an immediate problem while quietly creating a long-term maintenance burden.
Configurability is a different design philosophy entirely. A configurable platform is built from the ground up with the assumption that business rules will change, and it gives trained business users a defined, governed interface for making those changes without touching code. Underwriting criteria, workflow triggers, approval thresholds, document requirements, and loan product parameters are treated as data and settings that operations leaders manage, not as logic buried in code that only a developer can touch. No code. No service ticket. No multi-week wait.
The distinction matters because it determines who owns the system going forward. In a customized environment, ownership effectively sits with whoever wrote the code, whether that is an internal IT team or the vendor’s development staff. In a configurable environment, ownership sits with the people who understand the lending business, which is exactly where it should sit. The operations leader who knows why a stipulation needs to change, or why a new product needs a different documentation flow, is the same person who can make that change happen.
What genuine configurability looks like in practice
A well-designed lending platform separates the rules of the business from the mechanics of the software. Underwriting rules, workflow logic, approval hierarchies, and document requirements are exposed through an administrative layer that a trained non-technical user can navigate. That does not mean anyone in the organization can change anything at any time. Governance still matters, and a mature platform builds in permissions, version history, and audit trails so that changes are tracked, reversible, and compliant. The goal is not to remove control. It is to move control to the right place, with the right guardrails, instead of routing every change through a technical bottleneck.
This is where the difference between a demo and a real operating environment becomes obvious. In a demo, a vendor can show a system handling a defined set of loan products under a defined set of rules, and it will look impressive because it was built and tested to look impressive under exactly those conditions. What a demo rarely shows is what happens six months later when the organization needs to launch a new loan product with different underwriting criteria, different documentation requirements, and a different approval chain. That is the moment configurability either proves itself or reveals its absence.
Why this becomes a five-year decision, not a today decision
Every platform evaluation should include a version of this question, stated plainly. Can the system do what we need it to do today. That is necessary but not sufficient. The more important question is who is going to be in control of this system as our needs change over the next five years. That single question surfaces whether a platform will function as a strategic asset that the organization can shape and adapt, or as a managed dependency that requires ongoing outside involvement every time the business evolves.
Lending organizations that answer this question early tend to build very different implementation plans than organizations that skip it. They ask vendors to demonstrate configuration changes live, not just show finished screens. They ask how a new loan product is actually launched, step by step, and who is capable of doing each step. They ask what happens when a regulatory change requires an immediate update to a disclosure workflow, and how long that update realistically takes from decision to production. These are not exotic questions. They are the same operational due diligence lenders apply to underwriting decisions, applied instead to the platform that will run their operation.
The operational payoff of self-directed configuration
When operations leaders can configure their own platform, the effects show up across the organization, not just in IT efficiency. Compliance teams can respond to regulatory changes on a timeline measured in days rather than sprint cycles. Product teams can launch and iterate on new loan offerings without a multi-month development project attached to every idea. Underwriting teams can adjust risk criteria as portfolio data comes in, instead of running exception processes while a change request works through a backlog. Perhaps most importantly, the operations team develops a sense of ownership over the system they use every day, because they are not dependent on someone else’s schedule to do their job well.
That sense of ownership compounds over time. Teams that can shape their own tools tend to use those tools more fully, document their processes more consistently, and catch operational issues earlier, because the system reflects how they actually work rather than how it was configured during a implementation project years earlier. Teams that are locked out of configuration tend to drift toward workarounds, and those workarounds become the real operating system of the business, invisible to leadership and invisible to audit.
A different way to evaluate the next platform decision
For a lending organization currently evaluating loan origination and servicing software, or reconsidering a platform that has become a source of friction, the most useful exercise is to stop asking only what the system can do and start asking who will be doing it. Ask to see a business user, not a developer, change an underwriting rule during the evaluation. Ask how a new loan product actually gets built and launched, and how long that process takes end to end. Ask what governance and audit controls exist around configuration changes, because flexibility without control is its own kind of risk.
The lending organizations that get this right are not choosing configurability instead of capability. They are recognizing that configurability is what allows capability to keep up with a business that will look different in three years than it does today. Loan origination software and workflow automation only deliver lasting value when the people running the lending operation can shape the system as the operation grows. Everything else is a snapshot of what the business needed on the day the contract was signed.
Blog
Why AI in Lending Software Is Becoming a Tiebreaker
I want to share something I am seeing across lending software evaluations right now, because I think it reflects a real shift in how lending organizations are thinking about technology decisions. It is not a shift in what lenders need today. It is a shift in how they are planning for what they will need tomorrow.
When a lending organization runs a formal software evaluation — and I mean a real one, with requirements matrices, scored vendor demos, and a committee comparing responses line by line — the conversation used to stay almost entirely on functional fit. Can the platform handle our loan products. Can it support our underwriting workflow. Can it produce the reports our board and our regulators expect. Those questions still matter, and they still drive most of the scoring. But increasingly, when two platforms come out of that process close together, the conversation does not end there. It ends with a question about AI.
Not because the organization is ready to deploy AI today. In most cases, they are not. But because they understand they are making a five to ten year infrastructure decision, and they do not want to be locked into a platform that has no credible path to AI by the time they are ready to use it.
The tiebreaker pattern I keep seeing
Here is the pattern. Two platforms make it through a rigorous evaluation. The scores are close. The functional fit is comparable. Both can handle the loan products, the servicing workflows, the reporting requirements the organization laid out at the start of the process. On paper, it is a coin flip. And then the deciding factor turns out to be which platform has AI capabilities that already exist, already run in production, and are already being used by other lenders doing similar work today.
That is the tiebreaker. Not a roadmap slide. Not a promise about what is coming in a future release. AI as a present reality on the platform, not a future feature described in a sales deck.
I think this pattern tells us something important about how the more sophisticated lending executives are approaching technology decisions right now. They have stopped asking whether AI is going to matter in lending. That question is settled for them. The question they are actually asking is narrower and more practical: will the platform we are about to commit to be able to support AI workflows once our organization is ready to use them, and is that answer determined by something we can verify today, or something we are being asked to take on faith.
Why the answer depends on architecture, not intent
Every vendor in a competitive evaluation will tell you AI is a priority. That is not useful information. What is useful is understanding whether the platform’s underlying architecture makes AI a natural extension of what already exists, or whether it makes AI a bolt-on that has to be engineered, integrated, and maintained separately from the core system.
A lending platform built natively on Salesforce inherits Salesforce’s ongoing AI investment automatically. When Salesforce ships new AI capability — natural language querying of loan and portfolio data, workflow automation triggered by AI-identified risk conditions, predictive monitoring across a servicing book — that capability becomes available to lenders already operating on the platform without a new integration project and without a new vendor relationship. The AI layer and the lending operations layer are not two separate systems that someone has to stitch together. They already live in the same environment, on the same data model, governed by the same permissions and the same audit trail.
A platform that is not built on that kind of modern, extensible cloud architecture is in a fundamentally different position. Adding AI capability means building new connections to outside tools, standing up new data pipelines, and accepting new integration risk with every use case. Each AI capability becomes its own project, with its own budget request, its own implementation timeline, and its own point of failure. For a lending organization that is already stretched thin on IT resources — and most of them are — that is not a path that gets prioritized. It gets pushed to next year. And then the year after that.
This is the real distinction lending executives are picking up on, even if they do not always articulate it in architectural terms. They sense that one platform will let them adopt AI capability as it becomes available, almost as a natural extension of the system they already run. And the other platform will require them to make a new case, find new budget, and take on new implementation risk every time they want to move forward. One path compounds. The other path stalls.
Why this shows up now, and why it will not go away
It is worth asking why this is happening now, in this specific window, rather than a few years ago or a few years from now. Part of the answer is that the lenders running these evaluations have watched AI move from an abstract conversation to something they can see in production at other financial institutions, and in some cases at their own back office in narrow, unofficial ways — someone using a general AI tool to summarize a loan file, someone experimenting with automated first-pass document review. That visibility changes the psychology of the buying committee. It stops being a hypothetical.
The other part of the answer is more structural. Lending organizations are under real pressure to do more with the same headcount, to reduce the manual work buried in underwriting and servicing, and to give their leadership better visibility into portfolio risk without adding another layer of reporting overhead. AI is one of the few levers that plausibly addresses all three of those pressures at once. So even an organization that has no immediate AI project on its roadmap wants assurance that the platform they choose will not become the reason they cannot pursue that lever later.
I do not think this dynamic is temporary. I think it is the new baseline for how lending technology decisions get made. Functional fit gets you into the finals. Architecture and AI readiness decide who wins.
What this means for how you should run your own evaluation
If you are in the middle of a software evaluation right now, or planning one for later this year, there is one practical change I would make to how you run the process. Add a single question to every vendor conversation, and insist on a real answer rather than a demo built for the occasion.
Do not ask what AI features the vendor has. Every vendor has a list of AI features. Ask instead to see AI that is live in production, today, at a lender operationally similar to yours. Ask who is using it, what workflow it touches, and what measurable difference it has made. That question filters out roadmap talk immediately. A vendor with AI genuinely built into the foundation of their platform can answer it specifically, with a real customer and a real workflow. A vendor who is still describing a future direction will answer it in generalities, or will pivot to a demo environment that was clearly built for the sales process rather than for actual use.
You should also ask a second, related question: what does it take, technically, for your organization to turn on the next AI capability the vendor ships. If the answer involves a new integration project, a new contract with a third party, or a meaningful new IT lift, you are looking at a platform where AI adoption will always be slower and more expensive than it needs to be. If the answer is that the capability becomes available inside the environment you are already running, you are looking at a platform where AI adoption is closer to a configuration decision than a development project.
The larger point about buying operational capability, not features
I keep coming back to a simple idea in how I think about lending technology decisions. Lenders do not actually buy software. They buy operational capability. They buy the ability to originate loans faster, service portfolios with less manual reconciliation, give their leadership real visibility into risk, and scale their operations without scaling their headcount at the same rate. Technology is the mechanism. It is not the goal.
AI readiness fits into that same frame. The point is not whether a lending organization flips a switch and starts using AI next quarter. Most will not, and that is fine. The point is whether the platform they choose today preserves their ability to build that operational capability later, without forcing a painful re-platforming decision down the road. That is what the smartest executives I talk to are actually evaluating when they ask about AI in a vendor meeting. They are not asking about a feature. They are asking about optionality.
The lenders who are thinking clearly about this right now are treating AI readiness the same way they treat core system architecture, data ownership, and integration flexibility — as a long-term infrastructure decision that will shape what is possible five and ten years from now, not as a checkbox they need to be able to mark today. That is the right instinct. And it is why, in evaluation after evaluation, the platform with AI already live in production, already connected to the core system, already proven at other lenders, keeps winning the tiebreaker.