The Insourcing Decision Most CTOs Get Backwards: Capacity vs. Capability

Key Takeaways

• Cost is no longer the primary reason institutions outsource technology work - Deloitte's 2024 Global Outsourcing Survey found it fell from 70% of respondents in 2020 to 34% in 2024, overtaken by access to talent (42%), quality and performance (33%), and delivery-model fit (33%).

• The same survey shows 70% of organisations have selectively insourced previously outsourced work in the last five years - but the leading reasons are better control over quality (68%) and building strategic capability (64%), not cost. The market has already moved past the headcount-cost framing; most internal business cases haven't caught up.

• The expensive mistake isn't choosing insourcing or an offshore delivery centre (ODC) - it's building the business case on capacity (how many engineers, at what blended rate) when the actual decision is about capability: domain knowledge, delivery process discipline, or governance maturity.

• source[code]'s Capability Compass gives CTOs a two-axis diagnostic - capacity need versus capability specificity - to identify which of four sourcing situations they're actually in before a single job requisition or vendor RFP goes out.

• Regulators responsible for operational resilience (APRA, EIOPA, the Central Bank of the UAE, the Basel Committee) already require banks and insurers to apply due diligence, ongoing monitoring and tested exit planning to critical service providers. The same rigour - not a lighter version reserved for outsiders - belongs in how an insourced or extended engineering team is selected and governed.

Introduction

Most insourcing decisions in banking, insurance and fintech start with a spreadsheet, and the spreadsheet asks one question: how many engineers can we get, and at what fully loaded cost, if we build a captive team or an offshore delivery centre instead of running through a vendor? It's a legitimate question. It is also, on its own, the wrong one to be answering first.


The better question - the one that determines whether the insourcing decision actually works - is which specific capability gap the new team is meant to close. Is the organisation short on people who understand how claims adjudication logic, regulatory reporting rules or underwriting risk appetite actually work? Is it short on a disciplined, repeatable way of shipping software - release cadence, testing rigour, change control? Or is it short on the governance muscle to manage any delivery relationship responsibly, whether that relationship sits inside the building or outside it?


Those are three different problems with three different solutions, and a headcount-cost business case answers none of them. This matters more in BFSI than almost anywhere else, because the delivery model a CTO chooses doesn't just affect velocity and burn rate - it sits inside the same operational-resilience and third-party-risk frameworks that regulators now expect boards to actively govern.

The Numbers Behind the Swing Back to Insourcing

The pendulum swinging back toward insourcing is real, but the reasons for it have changed, and the change is the story. Deloitte's Global Outsourcing Survey 2024, based on more than 500 global business and technology leaders including over 150 C-suite executives, found that cost reduction - the driver that defined the offshoring wave of the 2000s and 2010s - has fallen sharply as the stated reason for outsourcing: from roughly 70% of organisations citing it in 2020 to 34% in 2024 (Deloitte, 2024). It has been overtaken by improved access to talent (42%), rising customer expectations (35%), and improved quality or performance (33%).

The insourcing side of the same survey tells a matching story. Seventy percent of organisations report having selectively insourced work they had previously outsourced over the past five years. The leading reasons are better control over quality and performance (68%) and investing in or growing strategic capability (64%) - well ahead of spend optimisation (56%) and risk or security considerations (46%) (Deloitte, 2024). Tellingly, 82% of the same respondents say their outsourced relationships still meet or exceed expectations. This isn't a story of outsourcing failing and insourcing rescuing it. It's a story of institutions rebalancing which capabilities they want to own directly, independent of whether the vendor relationship was working.

The same pattern shows up in how banks are using global capability centres (GCCs). EY estimates the financial-services "right-shoring" market - the broader category that includes GCCs and offshore delivery centres - at roughly USD 150 billion, having grown at double-digit rates for the past decade (EY, 2026). But EY's own research flags the gap this growth has outrun: nearly 80% of banking GCCs report fewer than 10% of their leadership roles based locally (EY, 2026). Scale arrived well ahead of the senior judgement needed to govern it. That gap - headcount growing faster than decision-making maturity - is precisely the failure mode this article is about, just visible at the portfolio level rather than the individual sourcing decision.

McKinsey's Global Banking Annual Review 2026 adds the strategic framing: leading institutions are shifting technology and capability acquisition "from scale to precision," building active pipelines of fintech partnerships and targeted acquisitions aimed at "plugging discrete capability gaps" rather than buying breadth (McKinsey & Company, 2026). The report also points to lean, digitally native challengers generating superior returns on equity with a fraction of the headcount of incumbent banks - evidence that adding capacity is not, by itself, what separates strong technology organisations from weak ones.

The Question CTOs Actually Need to Answer

Ask most CTOs why they're standing up an ODC or converting a vendor engagement to an insourced team, and the initial answer is almost always denominated in engineers and dollars: "we can get forty developers in Bangalore or Manila for the cost of fifteen onshore," or "our vendor day rate has crept up 20% over three renewal cycles and we want to bring it back in-house." Both are real, defensible observations about unit economics. Neither answers the question that actually determines whether the move will work: what specific thing is this team supposed to be able to do that the current arrangement can't?

That distinction - capacity versus capability - sounds academic until you watch it play out. A newly insourced or ODC-based team can hit every headcount and cost target in the business case and still fail to move the metrics leadership actually cares about: release predictability, defect escape rate, regulatory change turnaround time, incident frequency. When that happens, the retrospective conversation is almost always about the wrong variable - "did we hire the right people at the right price" - when the real miss was structural: the business case never specified which capability gap the team was meant to close, so nobody built the team, the operating model, or the success metrics around closing it.

This is not an argument against ODCs, captive centres, or insourcing generically - the evidence above shows institutions are moving toward all three for good reasons. It's an argument that the business case needs a second, prior question, before the headcount-and-cost model gets built at all.

Where the Capacity Lens Breaks Down

The capacity lens breaks down because it treats every sourcing decision as if it were the same decision at a different price point. It isn't. A gap in domain knowledge - engineers who don't understand how a claims triage rule, a Basel capital calculation, or an AML typology actually needs to behave - shows up as code that passes every test and still produces the wrong business outcome, because the tests themselves were written by people without the domain context to catch the error. A gap in delivery process - no consistent release cadence, thin test automation, undocumented change control - shows up as unpredictable velocity and production incidents that have nothing to do with individual engineer quality. A gap in governance discipline - no one clearly owns risk for the arrangement, no exit plan has been tested, no one has asked what happens if the team or the vendor disappears - shows up later, usually during an audit, a regulatory review, or an actual disruption, by which point it's expensive to fix.

Each of these gaps calls for a different remedy. More headcount fixes none of them reliably. A capacity-only business case will hire against the first gap (bodies), staff the team, hit the budget target, and only discover months later that the actual constraint was domain fluency or delivery discipline - at which point the fix requires unwinding and rebuilding, not simply adding more people at the same rate card.

The Capability Compass: A Diagnostic for Sourcing Decisions

source[code] built the Capability Compass to give CTOs a fast, structured way to answer the prior question before the headcount business case gets written. It plots any sourcing decision - insourcing, ODC, vendor extension, staff augmentation - across two axes: capacity need (how much sheer delivery throughput the work requires) and capability specificity (how much domain knowledge, process maturity or governance sophistication the work demands that the organisation doesn't already have). The intersection defines four situations, and each calls for a different decision - and a different way of judging success.

The diagnostic value isn't the quadrant labels - it's forcing an honest answer to which quadrant a specific decision actually sits in before the business case gets written. Most of the insourcing mistakes we see happen because an organisation is actually facing a Capability Transplant or Governed Build decision but runs the business case, the hiring plan and the success metrics as if it were a Scale Play. The team gets resourced correctly for throughput and governed for nothing in particular - and the capability gap it was meant to close stays open.

What This Means for Governance and Delivery Architecture

Once a decision lands in Capability Transplant or Governed Build territory, the practical implication is that the new team - insourced, captive, or ODC-based - needs to be brought inside the same governance perimeter the organisation already applies to critical vendors, not a lighter one reserved for "our own people."


This isn't a stretch of existing regulatory expectations; it's closely aligned with where they already sit. APRA's CPS 230 requires regulated entities to identify and assess the operational risk introduced by material service-provider arrangements, maintain a documented register of them, and monitor performance on an ongoing basis, with additional governance attention on offshored arrangements specifically (APRA, 2026). EIOPA's guidelines on outsourcing to cloud service providers require insurers to apply due diligence and oversight proportionate to the criticality of the function, with documented exit strategies for anything material (EIOPA, 2020). The Central Bank of the UAE's outsourcing regulation for banks requires board-approved materiality assessments, a bank-wide risk view of outsourcing arrangements, and retains full accountability with the bank regardless of who is doing the work (Central Bank of the UAE, 2022). And the Basel Committee's principles for operational resilience direct banks to manage dependency on any party - internal or external - delivering a critical operation, including testing whether the function could be substituted or brought back in-house if needed (BIS, 2021; BIS, 2022).

None of these regimes were written with an internal engineering pod or a captive delivery centre specifically in mind. But the test they apply - is this arrangement material, is it governed, is there a tested plan if it fails - doesn't stop applying just because the team sits on the payroll instead of on a vendor invoice. An insourced team that owns a regulated function is a material dependency in exactly the sense these frameworks describe, whether or not procurement ever reviewed it as one. Treating "insourced" as synonymous with "lower scrutiny" is the gap most CTOs don't realise they've created - and it's the one an internal-audit finding or a regulatory review tends to surface first.

The Fair Case for Cost-Led Insourcing

None of this means a capacity-and-cost business case is always the wrong tool. For genuinely Scale Play work - well-specified, standardised, low-ambiguity delivery where the process and domain knowledge already exist and are well documented - a headcount-and-rate-card decision is not a shortcut, it's the economically correct approach. Deloitte's own data supports this: even in 2024, spend optimisation remained the third most-cited reason for insourcing (56%) and cost the fourth most-cited reason for outsourcing (34%) (Deloitte, 2024) - cost hasn't disappeared as a driver, it's been correctly demoted to the situations where it actually belongs. Production support queues, regression test execution, data-migration factory work, and well-bounded maintenance backlogs are reasonable candidates for a scale-and-cost lens, precisely because the capability specificity is genuinely low: the knowledge required to do the work well is already documented, stable, and transferable.


The failure mode isn't cost-led sourcing itself. It's applying a Scale Play business case - and a Scale Play level of governance - to a decision that was actually Capability Transplant or Governed Build the whole time.

What Leaders Should Do Next

Before the next insourcing, ODC, or vendor-conversion business case goes to the investment committee, three questions are worth answering in order, ahead of any headcount modelling: First, which specific capability gap - domain knowledge, delivery process, or governance discipline - is this arrangement meant to close, stated precisely enough that it could be tested six months from now? Second, using the Capability Compass, which quadrant does this decision genuinely sit in, and does the proposed team structure, hiring profile and governance model match that quadrant, or does it default to a generic "extended team" template regardless? Third, if this arrangement is Governed Build or Capability Transplant, is it entered in the same material-dependency register, subject to the same board-level materiality assessment and the same tested exit plan the organisation would require of an external vendor performing the same function?

An institution that can answer all three has a defensible business case. One that can only produce a cost-per-engineer comparison has a budget line, not a sourcing decision.

The source[code] perspective

Across our delivery engagements with banks, insurers and fintechs in APAC and the Gulf, the insourcing conversations that go well start from a precise statement of the capability gap, not a headcount target. The ones that struggle almost always trace back to a business case built purely on cost-per-seat, with governance treated as an afterthought once the team was already staffed.


We don't think insourcing, ODCs, or extended teams are inherently riskier than vendor relationships - but we do think they get evaluated with less scrutiny by default, purely because they feel like "us" rather than "them." Applying the same materiality, due-diligence and exit-planning discipline to an insourced team that a bank would apply to any critical vendor isn't extra bureaucracy.

It's the difference between a delivery model that survives an audit and one that becomes the finding. Talk to us for more discussion!

Conclusion

The debate over insourcing versus outsourcing, or which countries to build an ODC in, is a proxy for a more useful debate that most institutions skip: which capability gap does this specific arrangement need to close, and does the governance around it match the stakes of that gap. Cost has already been demoted as the primary driver in the market's own data - the institutions still running every sourcing decision through a cost-per-engineer lens are optimising for a variable the rest of the industry has moved past.


The Capability Compass won't make that decision for a CTO. It will make sure the right question gets asked before the wrong one gets funded.

Frequently Asked Questions

What's the difference between insourcing and an offshore delivery centre (ODC) in BFSI? Insourcing means bringing work previously done by a vendor onto the organisation's own payroll, wherever those people sit. An ODC (or global capability centre) is a specific structure for doing that - a wholly owned delivery centre, typically offshore, that the institution staffs and manages directly rather than through a third-party vendor. Both are forms of insourcing; an ODC is one operating model for delivering it.

Should our BFSI organisation insource engineering or outsource it? Neither answer is right by default. The evidence shows both models can work well - Deloitte (2024) found 82% of organisations remain satisfied with outsourced relationships even as they selectively insource other work. The decision should follow from which specific capability gap needs closing and how specific that capability is (the Capability Compass), not from a general preference for one model over the other.

How do we know if a capability gap is domain knowledge, process, or governance? Look at where the current arrangement is actually failing. Correct-looking code that produces the wrong business outcome points to a domain-knowledge gap. Unpredictable velocity, weak test coverage, or recurring production incidents point to a delivery-process gap. No one being able to say who owns risk for the arrangement, or no tested plan for what happens if the team disappears, points to a governance gap. Most struggling arrangements have more than one gap at once.

Does an insourced team need the same governance as an outsourced vendor? For any team performing a material or regulated function, yes. Regulatory frameworks like APRA's CPS 230, EIOPA's outsourcing guidelines, the Central Bank of the UAE's outsourcing regulation, and the Basel Committee's operational resilience principles all require due diligence, ongoing monitoring, and tested exit planning for critical dependencies - a test that doesn't stop applying because the team is on the payroll rather than a vendor invoice.

Is cost-led insourcing ever the right call? Yes - for well-specified, standardised, low-ambiguity work where the required knowledge is already documented and stable (what this article calls the Scale Play quadrant). Deloitte's 2024 data shows cost remains a legitimate driver for a meaningful share of organisations; the mistake is applying a cost-only lens to work that actually requires deep domain, process, or governance capability.

How does source[code] help with this decision? We work with BFSI CTOs and Heads of Engineering to diagnose which specific capability gap a sourcing decision needs to close, using the Capability Compass as a starting structure, and to design the delivery and governance model - insourced, ODC, extended team, or vendor - around that gap rather than around a generic headcount template.

Reference List

APRA (2026) Operational risk management. Australian Prudential Regulation Authority. Available at: https://www.apra.gov.au/operational-risk-management (Accessed: 15 September 2026).


Bank for International Settlements (2021) Principles for Operational Resilience: Executive Summary. Financial Stability Institute. Available at: https://www.bis.org/fsi/fsisummaries/op_resilience.htm (Accessed: 15 September 2026).

Basel Committee on Banking Supervision (2022) Newsletter on third- and fourth-party risk management and concentration risk. Bank for International Settlements. Available at: https://www.bis.org/publ/bcbs_nl28.htm (Accessed: 15 September 2026).

Central Bank of the UAE (2022) Outsourcing Regulation for Banks. CBUAE Rulebook. Available at: https://rulebook.centralbank.ae/en/rulebook/outsourcing-regulation-banks (Accessed: 15 September 2026).

Deloitte (2024) Global Outsourcing Survey 2024. Available at: https://www.deloitte.com/content/dam/assets-shared/docs/services/consulting/2025/global-outsourcing-survey-2024.pdf (Accessed: 15 September 2026).

EIOPA (2020) Guidelines on outsourcing to cloud service providers. European Insurance and Occupational Pensions Authority. Available at: https://www.eiopa.europa.eu/publications/guidelines-outsourcing-cloud-service-providers_en (Accessed: 15 September 2026).

EY (2026) Five ways banks turn GCCs into AI value engines. Available at: https://www.ey.com/en_us/insights/banking-capital-markets/five-ways-banks-can-scale-global-capability-centers-for-ai-value (Accessed: 15 September 2026).

McKinsey & Company (2026) Global Banking Annual Review 2026. Available at: https://www.mckinsey.com/industries/financial-services/our-insights/global-banking-annual-review (Accessed: 15 September 2026).