What is the difference between captive IT units and internal technology teams in challenger banks?

A captive IT unit is a separate legal entity that provides technology services to the parent company, often used to optimise cost or access talent in another location. An internal technology team sits inside the bank’s own operating structure. The choice affects cost allocation, talent strategy, and operational control, especially when banks want to separate service delivery from core banking governance.

What separates a captive IT unit from an internal technology team?

The practical difference is governance and operating model. A captive IT unit usually sits outside the bank as a distinct legal entity, even if it serves only the parent group. An internal technology team is part of the bank itself, so its people, budgets, accountability, and control environment are embedded in the regulated organisation rather than contracted across a service boundary.

A captive can look “internal” from a delivery perspective while still creating a supplier-style relationship for procurement, oversight, and control design. That distinction matters because the legal structure changes where risk sits, who owns the service, and how change, access, and assurance are managed.

Why challenger banks use one model instead of the other

Challenger banks often choose a captive when they want lower-cost access to engineering talent, geographic flexibility, or a distinct delivery centre that can scale quickly without expanding the local operating footprint. An internal team is more common when the bank wants tighter day-to-day control, simpler management reporting, and fewer cross-entity coordination points.

The trade-off is not just cost. A captive can separate service delivery from core banking governance, but it also introduces interface management, intercompany charging, and dependency on the captive’s operating discipline. An internal team reduces that structural friction, but it can be more expensive to scale and may be harder to isolate for cost or location strategy.

For banks that already run shared services or outsourced platforms, the operating model choice should be aligned with where decision rights actually sit. If architecture, release approval, and control ownership stay with the bank, the captive is mainly a delivery construct. If those decisions move with the captive, the bank is effectively delegating part of its technology control plane.

What changes in control, accountability, and regulatory oversight

The key difference is that a captive creates an additional governance layer between the bank and the people building or operating the technology. That can be workable, but the bank still needs clear accountability for material services, access decisions, production support, and resilience. Internal teams do not remove those obligations, but they usually make the lines of responsibility easier to trace.

In practice, regulated banks should treat the captive like a closely governed service relationship, not like a loophole that moves core technology risk outside the bank. The bank remains responsible for ensuring that the operating model supports secure change control, access management, incident response, and evidence of oversight. A captive can help with delivery efficiency, but it does not dilute the need for bank-owned control assurance.

That is why the most important question is not “who employs the engineers?” but “who can approve, alter, and recover the systems that matter to the bank?” If those rights are fragmented across entities, the bank needs stronger operating controls than it would for an embedded internal team.

Risk and Threat Considerations

A captive structure can increase exposure if the bank assumes legal separation equals operational separation. The main risk is weaker visibility into privileged activity, change approval, and service continuity when the technology function is delivered through another entity with its own management chain.

Failure mechanism: control gaps appear when responsibility for build, run, and oversight is split across entities without clear evidence of who owns access, who approves changes, and who can restore service during an incident.

Impact: the bank can end up with slower incident response, harder auditability, and larger blast radius if a platform failure or access issue affects systems that support customer-facing banking services.

Practitioner Guidance

What to verify: confirm whether the captive is acting as a service provider, a shared services unit, or a proxy for core technology decision-making. The answer should determine how you document accountability, review privileged access, and evidence control ownership.

Decision rule: if the captive can change production systems, manage credentials, or influence resilience, treat it as a high-governance dependency and require bank-owned oversight of those controls. If it only performs bounded delivery tasks, the oversight burden is lighter, but still formal.

Practitioner takeaway: the operating model is less important than the control boundary it creates, because challenger banks fail when legal structure, accountability, and technical authority do not line up.