A Lending Technology Team for Mid-Size Lenders

Mid-size business-purpose lenders, roughly the ones between $100M and $2B in originations or assets, sit in a genuine gap: their systems are too complex for off-the-shelf tools alone, yet their volume is too small to justify the in-house engineering organizations the largest platforms run. The difficulty is not the lender; it is the market for the specific people who can build lending software, because engineers who understand both software and the vocabulary of lending are scarce and take a long time to ramp. This is an honest comparison of the ways to build that team, including a lending-specialized dedicated team in India through a Global Capability Center (GCC), and where each one genuinely fits.

I have helped lenders stand these teams up, and I want to be straight about the tradeoffs rather than sell one answer. Every option below is the right answer for some lender, and the goal is to match the option to your size, your growth plan, and how much of the capability you want to own.

Why do mid-size lenders end up with three systems and a spreadsheet?

Because each system was the right choice on its own day, and nothing ever connected them. A lender buys an origination tool because originating is the first problem. Servicing grows into a second system. Reporting to warehouse lenders and investors starts in spreadsheets because it begins small and specific. Each decision is reasonable, and the sum is an origination system, a servicing system, and a set of spreadsheets that only a few people fully understand.

This is not a mistake so much as a stage. It is where a lender lands after doing everything right at small scale, and it works until the business grows past it: more loans, more products, a warehouse line, an investor asking for cleaner data. At that point the spreadsheets between the systems become the constraint, and the lender needs engineering that understands lending, not just software, to turn three disconnected systems into one that produces the loan tape and the histories on demand. Our companion piece on the path to a rated RTL securitization walks through exactly what a capital-markets deal asks of that stack.

What does a lending engineering team actually need to know?

More than a generic engineer knows on day one, which is the whole reason this is hard. A team building lending software has to understand the domain deeply enough that the data model is right the first time, and that knowledge is specific.

Start with the regulatory perimeter. An engineer does not need to be a compliance lawyer, but they do need to know which rules shape the data. Business-purpose real estate lending sits largely outside the consumer-mortgage disclosure regimes, such as TRID, that govern owner-occupied loans, while data-security expectations in the spirit of GLBA, state licensing, and the covenants written into warehouse and investor agreements very much apply. Knowing that perimeter is what keeps a team from building for the wrong rulebook. Beyond the rules, the team needs the working vocabulary of the business: loan tape standards and the fields a tape has to carry, draw and inspection workflows for construction and rehab loans, and the warehouse and investor reporting a lender depends on. Our explainer on the journey of a loan is a good measure of the surface area a lending engineer has to hold in their head. A generic engineer can learn all of this, but the learning is the long part, and it is the part a lender is really paying for.

What are the four ways to staff it?

There are four honest options, and the right one depends on your size and how much you want to own. The table compares them on the dimensions that actually decide the choice.

Each row is a real, defensible choice. Hiring in the US gives you a team in your building, if you can find lending-domain engineers and wait out the ramp. A US fintech development firm gets you moving quickly at a premium, as a category, and is a fair fit when the need is a defined project rather than a standing team. Generic offshore is inexpensive and fast to start, with the honest caveat that lending vocabulary is not included and has to be taught. The fourth option, a lending-specialized dedicated team in India built as a GCC or a build-operate-transfer pod, aims to combine the cost structure of offshore with the domain fit of a specialist team, and to end with the lender owning the team outright.

How does a GCC work for a lender?

A GCC gives a lender its own dedicated engineering team in India, staffed and run for it, that becomes the lender's own over time. For a mid-size lender the practical shape is a pod: three to eight engineers who work only on that lender's systems, build in its domain, and accumulate the vocabulary rather than rotating away with it.

The model that fits mid-size lenders best is usually build-operate-transfer. A partner builds the pod, operates it while the lender's processes and knowledge take hold, and then transfers it so the team becomes the lender's own, with the option to bring it fully in-house. That structure matters here because the whole value of a lending team is the domain knowledge it accumulates, and a BOT keeps that knowledge with the lender rather than with a vendor. Our micro-GCC playbook covers how a small pod is stood up, our writeup on what actually transfers in a BOT covers the exit, and our comparison of a GCC versus outsourcing covers why ownership and continuity are the structural advantages over a pure vendor arrangement.

The reason the pod stays small is deliberate. Three to eight engineers who stay on one lender's systems compound their domain knowledge month after month, which is the opposite of a large, rotating team where the vocabulary leaks out the door with every reassignment. A lender is not really buying headcount here; it is buying continuity of understanding, and a small, stable, owned team protects that far better than either a big vendor bench or a revolving contractor pool. That continuity is also what makes the eventual transfer real rather than nominal, because the people who carry the knowledge are the people who stay.

What did we learn building one?

The lessons are about the domain, not the org chart. We worked with a business-purpose real estate lender that completed a $300M rated securitization, and at the category level, a few things held true that are worth passing on without any identifying detail.

The first is that the vocabulary is the moat: a pod that knows what belongs on a loan tape and why is worth far more than a larger team that has to be told. The second is that the team should own the seam between systems, the reconciliation and reporting layer, because that is where a mid-size lender's real pain lives and where generic help struggles. The third is that starting narrow works: one workflow, proven, then the next, rather than a grand rebuild. And the fourth is that ownership changes behavior, because a team the lender will eventually own is built with more care than a team that will rotate off the account. None of these require naming anyone; they are the shape of the work.

When should you not do this?

A dedicated lending team is the wrong answer for several kinds of lender, and it is worth being clear about them. A lender under roughly $100M in originations should almost always buy software off the shelf, because the complexity does not yet justify building anything, and good SaaS will serve well for a while. A platform above $2B usually already has an engineering organization, and the question there is how to extend it, not whether to start. And a balance-sheet-only shop with no real growth plan does not need a standing engineering team at all, because the systems it has will carry a static book.

The honest sweet spot is the lender in the middle with a growth plan: complex enough that off-the-shelf tools have started to strain, serious enough about scaling that owning the capability pays off, and not yet large enough to run a full in-house engineering org. If that is you, our GCC work builds exactly this kind of lending-specialized pod, our loan origination system work is what it usually builds first, and we also hire developers in India for lenders who want to add to a team they already run. When you want to talk it through against your own size and plan, talk to us.