Choosing the Right Foundation for Credit Decisioning

Beyond the false choice between building and buying

Every lender builds its decisioning capability. The real choice is how much of the underlying foundation it should build and maintain itself and what it should build on top of it.

The conventional “build versus buy” debate makes the choice sound binary. It is not. A commercial platform does not supply a lender’s credit strategy, proprietary models, data relationships, workflows or customer experience. Those still have to be built—and they are often where the lender creates its competitive advantage.

What a platform can provide is the productized foundation needed to put that intelligence into operation: authoring, orchestration, deployment, testing, version control, auditability and governance.

Yves Duhoux, GDS Link’s co-founder and Chief Strategy and AI Transformation Officer, explained:

“Build versus buy is not really the right question. Whatever you choose, you are always building something. The real questions are what you should build, what you should own and what you should build it with.”

— Yves Duhoux, Co-founder and Chief Strategy and AI Transformation Officer, GDS Link

The distinction sounds simple until you are the one drawing the line. A useful rule of thumb is to build and own what protects your unique value and improves your process, while using productized technology for the capabilities that every lender needs but that rarely create differentiation on their own.

The cost of getting that boundary wrong rarely appears all at once. It accumulates slowly: each model update requires an engineering ticket, every product launch competes for space in the development queue, and one workaround leads to another. The in-house system may have seemed inexpensive to build, but the organization begins paying invisible interest on it every day.

Two lenders illustrate how strong internal teams changed the foundation beneath their decisioning capability without giving up the intelligence that differentiated them.

Capital on Tap: from bottleneck to four-week launches

Capital on Tap started in 2012 with a small team that manually reviewed up to 80 loan applications each day. As the company grew to serve more than 200,000 businesses and handle more than £10 billion in spending, it built an in-house automated underwriting system to keep pace.

The system worked for a time. However, as Capital on Tap added higher funding limits and a business credit card, the system became more complex and required more resources. Building new models had to compete with other engineering priorities, and the delays became especially clear during the COVID-19 pandemic.

Capital on Tap did not stop building. Instead, it added GDS Link’s decisioning platform alongside its existing system, preserving ten years of custom logic while shifting engineering effort away from maintaining decisioning mechanics and toward differentiated lending capabilities. The impact showed up quickly:

• The time required to make credit-rule changes fell by 30%, enabling new model integration within weeks instead of months
• The data science team can launch new products and pricing in under four weeks
• Credit risk resource needs dropped by 50%, freeing engineering capacity for other priorities
• Third-party data waterfalling generated significant cost savings
• The company continued its expansion, launching its Business Credit Card, issued by WebBank, in the United States in 2021

“The GDS Link platform has enhanced our automated credit decisioning and underwriting processes, providing us with greater flexibility to iterate on new models and pilot new products faster and more frequently. This integration has reduced our dependency on in-house engineering resources for simple credit rule changes, making these adjustments a quick and straightforward process.”

— Hugh Acland, Chief Commercial Officer, Capital on Tap

This is invisible interest in action: not the cost of having engineers, but the cost of repeatedly using scarce engineering capacity for changes that should not require it.

goeasy: cutting deployment time in half

goeasy Ltd. offers non-prime lending and leasing across Canada through its easyfinancial and easyhome divisions. At the time reflected in the original case study, the company had served more than one million Canadians and originated more than $3.3 billion in loans, with one in three customers eventually moving up to prime credit.

To keep up with growth, goeasy’s team built adjudication and lending models in SAS, then hand-translated each one into pseudocode and technical specifications before it could go anywhere near production. That translation step consumed much of the time, introduced opportunities for miscommunication and slowed the iteration that a growing lender needed.

By deploying models directly in PMML format using GDS Link’s deicsioning platform, goeasy did not outsource its modeling expertise. It removed a manual translation layer between analytical work and production execution. With one system change, the team was able to deploy more than eight models at once:

• At least 50% faster implementation—from roughly 20 hours to 5–10 hours
• Reduced risk of error by removing manual translation steps
• Continuous model releases and greater agility since 2014

“By using the PMML tool, we were able to reduce time to implement by 50%, from about 20 hours previously to 5–10 hours, and with better accuracy because the process reduces the risk of manual errors.”

— Zaur Akhmedov, Director, Acquisitions, Risk and Analytics, goeasy

The pattern behind both stories

Both Capital on Tap and goeasy had strong internal data science and engineering teams. Skill was never the issue. The problem was that manual, code-dependent decisioning could not keep pace with the speed the business and market required.

The lesson is not that strong teams tried to build and eventually had to buy. It is that strong teams became more effective by deciding which layers they no longer needed to build and maintain themselves.

Adam Taylor, GDS Link’s Head of Customer Success, described this as a matter of predictability. With a pre-built engine, “you can quickly get to a pricing range and timeline range… they’ve already gone through all those hurdles.” Building an entire platform internally means tackling problems that vendors have already solved, and the real costs often emerge only after the organization is committed.

As Adam put it, hardcoding a few rules is the easy part. “It’s what happens next, like updating a policy, testing a change, or rolling it back, that’s the necessary part of the platform that, especially in our industry, is required.”

Yves made a similar point about where engineering investment matters most: “The success or failure of a lending system is not really the decision engine—it’s everything that you build to make your process go better.” Automated testing, validating new models with real data before production, and quickly iterating on the capabilities that create an edge are where in-house effort pays off. The decision engine itself usually is not.

What “buy” actually buys you

Buying a decisioning platform does not mean giving up control of credit strategy, and it does not mean the lender stops building. Capital on Tap and goeasy retained their own models, logic and expertise. They changed what they built those capabilities with.

The difference is not whether the underlying work exists. Every lender needs authoring, deployment, versioning, testing, rollback, permissions, auditability, security and ongoing support. The difference is whether the lender creates and sustains each capability independently or adopts a supported platform in which those capabilities have already been productized.

A commercial foundation should allow the lender to concentrate internal investment where it matters most: proprietary models, credit policy, data strategy, workflow design, customer experience and the feedback loops through which the organization learns.

If your team spends more time maintaining the mechanics of the decisioning engine than improving what operates on top of it, that is often the first sign that invisible interest is building up.

The better questions

The decision is not simply whether to build or buy. It is whether the organization has made deliberate choices about three different layers:

• What should we build? The credit strategy, proprietary models, workflows, data usage and customer experience that make the business distinctive.
• What must we own? The logic, knowledge, governance, testing standards and feedback loops that protect control and compound learning over time.
• What should we build it with? A commercial platform, internal framework, open-source components, cloud services—or a deliberate combination of them.

You are always building. The strategic advantage comes from choosing the foundation deliberately.

Curious what the right foundation looks like for your team? Talk to GDS Link →

Want to hear this directly from Yves and Adam?