For decades, our loan servicing platform has been learning from the real world. An escrow bug that appeared only under a particular set of conditions. A few fields added for one kind of lender. An entirely new calculation process needed to support another. These are only a few of the tens of thousands of changes that have accumulated over the years.
Each represents something encountered by a real servicer: reversed fees, leap years, prepaid interest, escrow balances, backdated transactions, unusual investor agreements, or single-cent remainders that should cancel one another out.
Hundreds of similar rules exist across payments, escrow analysis, investor accounting, reporting, interest calculations, and client-specific workflows. Once you understand the scale of that accumulated behavior, it becomes easier to see why replacing a mature financial system is so dangerous.
A new platform can reproduce the screens. It can copy the database fields, rebuild the reports, and demonstrate a clean calculation using a clean loan.
Then a real loan arrives.
It has a rate change entered in April but effective the previous May. The borrower prepaid interest beyond the payoff period. A late fee was assessed, reversed, and later waived. A loan-level setting is blank, so the calculation must check the loan template and then the division default. A calendar exception changes which date should be used.
The old system knows what to do because someone encountered each problem before. The new system usually knows what the requirements document said.
That gap is where modernization projects fail.
A servicing system is made from accumulated judgment
The same history runs through every major part of our platform. A paid-off loan can still accept certain transactions, but the permitted transaction types depend on how the loan was closed. A loan closed with money remaining in escrow follows different rules from one closed with funds left in suspense.
A backdated payoff calculation must land on an actual scheduled due date. It cannot precede the loan’s paid-to date. A lockbox payment retains the amount scanned from the payment rather than allowing the system to replace it with an expected amount.
An escrow analysis may use an anticipated tax bill instead of the historical bill, then increase it by a municipality-specific estimate. A small surplus within the permitted tolerance may be zeroed out. A larger surplus becomes an exception requiring human review. A payment change below a client’s minimum threshold may never be sent to the borrower.
Investor accounting adds another layer. A residual interest pool can own none of the principal while still earning a servicing strip calculated to six decimal places. One investor may receive remittances monthly while another receives servicing fees quarterly. Equal and opposite penny remainders must disappear together.
Most of these rules will never appear in a sales demonstration. Many were never written into a formal specification. They entered the software because a client encountered a real situation, someone understood it, and the platform learned how to handle it permanently.
After decades, that accumulated judgment becomes the product.
Why enterprise keeps getting left behind
Every startup founder and venture capitalist shares some version of the same advice: focus on one thing, then do it many times. Talk to 100 potential customers. Find the 20 who describe the same problem. Build for those 20 and sell the solution repeatedly.
They would call that listening to customers, and they would be right. It can produce a useful product for those 20 and create a clean path to revenue, growth, investment, and acquisition.
The other 80 still have problems.
They run lenders, housing agencies, hospitals, manufacturers, utilities, insurance companies, and local governments. Their needs do not line up because their organizations do not line up. Each has its own terminology, policies, systems, regulations, history, and exceptions.
Those differences are much harder to describe in a pitch deck. Serving them requires discovery and judgment. It requires people willing to spend time inside an organization and learn what everyone there takes for granted.
Eventually, many of those customers are classified as too unusual, too early, too difficult, or too expensive to serve. The startup moves on in search of a cleaner market. Within the venture model, that makes sense: find a repeated problem, build a repeatable solution, raise money against the size of the market, grow quickly, and expand from there. Perhaps the standardized product eventually becomes flexible enough for some of the other 80 to use it too.
This model has created many valuable companies and dramatically improved the quality of software across entire industries. But it has also left an opening. Many of the institutions with the most complicated requirements are still operating on software built decades ago because their complexity has proven difficult to fit into standardized products.
The cleanest problems attracted enormous amounts of capital while complicated institutions continued waiting for products designed around how they actually operate.
The real world needs options
There are two competing visions for the future of software.
One is to combine more and more capabilities into a single platform: a system broad enough to do almost everything, with customers adapting their work to the decisions of one vendor.
The other is to let highly skilled, specialized teams build deeply for particular industries and organizations, then make the connections between those systems increasingly seamless.
These philosophies are often advanced by different groups. Specialized companies are frequently created by people who understand one particular problem exceptionally well. Larger companies then acquire and combine them, reasonably arguing that customers benefit from fewer vendors, simpler purchasing, and a more unified experience.
Consolidation has real advantages: fewer systems to manage, easier integration, simpler purchasing, and a more consistent experience. But it creates tradeoffs too. Integration, product priorities, and future capabilities increasingly depend on the judgment of one organization, and on whether that organization can retain enough understanding of each specialized domain.
A one-stop shop can offer extraordinary breadth. A specialist can offer something shaped around the particular business or problem in front of them. Great businesses usually become great because they do something distinctive and remarkable, not because they operate exactly like the ten businesses most similar to them. Their software should not require them to give that up.
AI should allow us to have both: the depth and personalization of specialized software with the convenience and interoperability of a unified platform. Instead of choosing between specialization and integration, we should be able to connect deeply specialized systems far more seamlessly than before.
We see another possibility.
The software industry has spent years teaching people that great software should feel effortless. Apple helped turn simplicity into a measure of quality. SaaS companies extended that expectation into enterprise systems: fewer settings, fewer choices, one preferred workflow, and a polished interface that keeps complexity out of sight.
I like simple software too.
Good design should keep people from confronting every possible choice on every screen. It should organize complexity, reveal options at the right time, and remember how each person works.
But there is no single system design that perfectly solves every instance of a business problem. Two lenders can service the same kind of loan and still have different investors, accounting policies, approval structures, escrow rules, reporting obligations, and definitions for the same words. Even two people inside the same organization may need different views of the same information.
Customization, personalization, parameters, filters, and sorting are not failures of design. They are necessary for operating in the real world. A good interface organizes those choices. It cannot erase legitimate differences between organizations.
When software forces an institution to reshape itself around an oversimplified product, the actual work often moves elsewhere. Employees create spreadsheets, side databases, manual reconciliations, custom reports, email chains, and procedures held together by people who understand what the official system does not.
The software may still perform an important function, but it is no longer carrying the full weight of the operation. The organization has effectively built another system around it.
That should be a warning sign. Simplicity is valuable when it removes unnecessary complexity. It becomes limiting when it removes legitimate differences in how businesses operate.
We have already carried this logic across one generation
Benedict Servicing began on an earlier generation of technology. Years later, we moved it onto the .NET platform our clients use today.
We knew a conventional rewrite would lose too much. Interviews and documentation could capture the major workflows, but no one could remember every exception accumulated across thousands of programs and decades of client history.
Years before the current AI boom, we built a relational source graph that reads our code and turns it into a structured model of the entire system. It records programs, screens, individual statements, data references, calls, and the relationships among them.
The model is detailed enough to generate working software.
That became our test of truth. If the model can reproduce a running system, then it has captured something far more dependable than a summary written by someone reading the code.
Our previous technology migration was driven by that model. We converted the platform while preserving the original system as the reference for correct behavior throughout the process.
The resulting system is now used to service more than one million loans with over $250 billion in balances for state housing finance agencies, insurance companies, and commercial and multifamily lenders.
We changed the technology without discarding the history encoded inside it.
Why this migration suddenly accelerated
A couple of years ago, our next migration was moving forward, but far too slowly. The work was tedious, and client projects had to take precedence.
Real institutions depended on us every day, so the long-term project advanced whenever we could make room for it.
That is the reality of being a smaller company. Good ideas compete with immediate obligations. Some survive on the backlog. Others sit there long enough to fade.
But we could see how our source graph might work with AI. It had already organized the system into programs, statements, screens, data, and connections. An AI system should have been able to navigate that structure, trace behavior through the code, and help us understand deep areas much faster.
At first, it could not come close.
Context windows were too limited. Our platform was too large and interconnected. Every meaningful question crossed too many programs, fields, calculations, screens, and client variations. There were simply too many pieces.
Then the AI harness arrived.
Claude Code CLI could search the system itself. It could follow dependencies, inspect related programs, trace data references, test a conclusion, return to the source, and continue working through the problem.
We no longer had to identify and package every potentially relevant file before asking a question. The harness could help locate the context.
That changed what we were able to attempt.
Most importantly, it allowed us to take the first credible step forward. Then another.
We moved carefully. We compared behavior, traced results back to the original logic, corrected mistakes, and updated our deterministic conversion process.
That distinction matters enormously.
AI helps us investigate fuzzy questions, navigate complexity, and understand why something happened. But the converted output still has to come from repeatable mechanisms.
We are not asking a model to improvise the critical behavior of a financial system every time it runs. AI helps us understand the system; it does not become the system of record for the financial logic itself.
When we discover a conversion problem, we fix the converter. The correction becomes deterministic, repeatable, testable, and subject to the same validation as the rest of the platform. Sometimes one correction resolves the same issue across a hundred programs.
That is where progress begins to compound.
Areas that once required long stretches of uninterrupted attention can now be explored much faster. Knowledge scattered across thousands of programs has become something we can trace, connect, explain, and act on.
Work that once advanced intermittently between client projects can now move forward every day. It is difficult to articulate how far that has carried us.
We already had decades of proven behavior, a structured model of the code, experience from the previous migration, and people who understood why the system behaved as it did.
The AI harness gave us enough leverage to begin turning all of that into the next platform.
Bringing it all together
We are now bringing that same body of servicing logic into Benedict Servicing Pro. Each converted screen and calculation engine retains a traceable relationship to the original system.
The original and new generations can run side by side against the same data. Calculations can be compared. Exceptions can be tested. Differences can be traced to specific logic instead of disappearing inside a black-box rewrite.
That gives us something we consider essential in financial software: the ability to modernize aggressively without giving up the ability to explain, test, and verify what the system is doing.
The structured logic also gives us capabilities that were difficult to offer before:
- An assistant that can explain how the platform calculates a payoff, spreads an escrow shortage, or derives a balance.
- APIs that invoke the same proven engines used by the servicing system for decades.
- Data analysis that can trace a number through the transactions and business rules that produced it.
- Client-specific behavior without maintaining an entirely separate product for every institution.
This is where AI becomes remarkably useful in financial software. It can navigate and explain a deep body of existing logic when that logic has been captured faithfully.
Someone still has to learn the institution
I have clients with no meaningful AI implementations, even though they have countless places where it could help.
The value is there. Deep understanding is expensive.
Every client has its own vocabulary, software, policies, data, workflows, and institutional memory. A useful implementation requires someone willing to enter that environment, learn how the organization works, and connect AI to its reality.
A generic assistant can summarize a manual or draft an email. It doesn't arrive knowing what a client means by a particular balance, why one transaction follows a special rule, how a field acquired its meaning, or which old exception still governs a current workflow.
Someone has to dig in.
The industry now calls this forward-deployed engineering. It is often presented as a new model, although it closely resembles how software was built before SaaS encouraged companies to generalize for margins, valuations, and speculative investment.
Customer-specific work used to be the work. Then software companies were told to reduce it, isolate it, outsource it, or eliminate it.
The changes inside our calculation engines represent decades of forward-deployed engineering. A client encountered an unusual situation. Someone who understood both the servicing business and the code investigated it. The resulting knowledge became part of the platform.
Loan servicing never became uniform.
Every institution still carries its own programs, investors, reporting obligations, transaction history, accounting policies, and regulatory interpretations.
AI gives specialized software companies a chance to serve those differences at scale.
AI gives vision more leverage.
Every software company knows about AI. Many have teams a hundred times our size, with more engineers, more capital, larger sales organizations, and far greater capacity to pursue new products.
Yet much of the first wave of AI in mature industries has understandably appeared near the surface: chat interfaces, writing tools, document summaries, search, and assistants layered over existing products. Those are useful applications, but we believe some of the largest opportunities go much deeper.
AI can help us understand and modernize the underlying systems themselves: the calculations, workflows, data relationships, exceptions, and accumulated decisions that actually make an enterprise platform work.
Now obviously, there is still a lot to do, but it does make us wonder whether headcount was ever the scarcest resource.
Deep modernization requires someone to understand what the system does, why it does it, which behavior must survive, where it can improve, and how thousands of connected decisions fit together.
Large teams provide enormous capacity. They can also divide that understanding across products, departments, contractors, and layers of management. Each group sees its part while the complete idea becomes harder for any one person to hold.
AI gives enormous leverage to the people who can see the whole system.
A small group with deep domain knowledge can now investigate, build, test, and coordinate work that once required a much larger organization. The tools amplify the judgment, history, and vision already present.
For a smaller company like ours, that may be the biggest change of all.
Vision no longer has to fade because the people who hold it lack the manpower to pursue it.
What if understanding becomes the scalable unit?
The traditional scalable unit in software is one identical workflow sold ten thousand times.
AI gives us another possibility.
A company can reuse its tools, architecture, source graphs, conversion methods, testing systems, and accumulated knowledge while still building for the actual needs of each customer.
With every implementation, it becomes faster at understanding the next institution. It gets better at mapping unfamiliar systems, recovering buried knowledge, identifying meaningful differences, and preserving the rules that matter.
The venture world learned how to scale infrastructure, distribution, and standardized workflows. We may now be able to scale deep understanding without forcing every customer into a composite model of everyone else.
The other 80 do not have to become the 20 before anyone will build for them.
The next great enterprise software companies may look less like factories producing identical products and more like institutions capable of understanding thousands of organizations deeply.
The migration is only the first use case
A reliable migration requires a logical representation of the source.
We need to know that every branch, calculation, field reference, database update, parameter, workflow, and business rule survived the conversion.
Once that corpus exists, it becomes useful far beyond migration. It can explain the system, generate tests and documentation, trace data lineage, expose APIs, identify dead code, compare implementations, and support entirely new interfaces.
Languages and frameworks become implementation choices.
The enduring asset is the logic itself, stored in a form that AI can reason over and deterministic systems can render.
That is what we are building toward with Benedict Servicing: transparency throughout the entire platform.
A developer should be able to select a screen, calculation, or field and trace its complete path through the source, data, dependencies, conversion history, and tests.
A user should be able to ask why a balance has a particular value, why a transaction behaved a certain way, or how the system reached a decision, and receive an answer grounded in the actual logic.
A report should never be a black box.
Every important number should be traceable through the transactions, calculations, and business rules that produced it.
And when we improve the platform, we should be able to prove what changed, what remained the same, and which parts of the system were affected.
That is the standard we want for everything we build.
Traceable. Testable. Explainable.
Understandable from the developer all the way to the end user. Supported by an enormous ability to learn, explain, test, and improve.
We have already carried this system across multiple generations of technology. This time, we are doing more than moving it onto another generation of technology. We are preserving and abstracting the logic that makes each business distinct while building the tools to understand that logic more deeply than ever before.
The goal is not modernization for its own sake. It is to give institutions the advantages of modern technology without requiring them to discard the knowledge, differences, and judgment that made their businesses successful in the first place.
So the future can offer more - not merely a more polished version of less.