The Dependency Map: Criticality, Concentration, and nth Parties
The subject here is the dependency structure behind a bank’s critical service. The practical question is not how many provider names appear in a procurement system, but what must remain available, which organisations and locations make it available, and what happens if several of them fail together. A useful dependency map lets a bank identify hidden concentration and choose mitigation that matches the service’s criticality and substitutability.
A critical service has more than one provider boundary
A critical service is defined by the effect of its failure, not by the prestige of the organisation delivering it. The Basel Committee describes a critical service as one whose failure or disruption could significantly impair a bank’s viability, critical operations, or ability to meet key legal and regulatory obligations. A critical third-party service-provider arrangement is one that materially supports or affects such a service.
That definition changes what the bank has to draw. Start with the bank operation that must continue, then identify the service that supports it. From there, identify the third-party service provider, or TPSP, that performs the contracted work. The map should then follow the provider’s own dependencies: software, infrastructure, facilities, staff, subcontractors, and other suppliers. The Basel Committee calls a provider in that supply chain an nth party. A key nth party is one that is essential to the ultimate delivery of a critical service to the bank.
The distinction matters because the bank may have a direct agreement with the TPSP but no direct agreement with the key nth party. The absence of a direct contract does not remove the dependency. It changes the bank’s route to information, assurance, incident notification, and remediation. For a critical arrangement, the Basel principles say that relevant obligations and information rights should cascade to key nth parties where appropriate. The bank therefore needs to know not only who it hired, but whether the provider can identify and manage the parties on which the service ultimately depends.
A dependency map should also preserve ownership at each boundary. The bank owns the decision about whether the service is acceptable and what disruption it can tolerate. The TPSP owns the performance of the contracted service and the controls within its operating environment. A key nth party may own a capability that neither the bank nor the direct TPSP can quickly replace. A supervisor may have authority to examine or coordinate, but that authority is not operational ownership. Keeping these roles visible prevents a common mistake: treating a control that exists somewhere in the chain as if it were controlled by the bank.
A register and a dependency map serve different but connected purposes. The register records the arrangement as an object of governance. It should preserve facts that alter a decision, including the arrangement’s criticality, the substitutability of the service, contingent providers, what proprietary or confidential information is shared, where the service is performed, and where data is processed or stored. The map adds the relationships: which bank activity uses the service, which provider performs it, which nth party supports the provider, and which other services or institutions share the same dependency.
This is more informative than a list such as “payment provider, cloud provider, software provider.” A list tells the bank that relationships exist. A map can reveal that three apparently separate services rely on the same identity system, facility, region, or subcontractor. It can show that data crosses a boundary the bank did not treat as material, or that a supposedly contingent provider uses the same underlying infrastructure as the primary provider. Those are not merely technical details. They determine whether a disruption can be contained or will move across several paths at once.
The map should be read as a failure model, not as an inventory exercise. For every important edge, the bank should be able to ask what crosses it and what happens when it is cut. Data may cross into a provider’s environment; an authentication signal may cross into a shared service; a recovery decision may depend on a subcontractor’s staff; an incident notification may have to travel back through the direct TPSP. The more critical the service, the more important it is to know whether those edges have independent controls, measurable recovery commitments, and a person or organisation responsible for acting when they fail.
This is particularly important where “shared responsibility” is used to describe a service. Sharing a responsibility can clarify who performs a control, but it can also create a gap if each party assumes that the other party owns the outcome. A map makes the interface testable: which party configures access, which party detects a compromise, which party preserves records, which party informs the bank, and which party can restore the service? The bank need not perform every task itself, but it must know how the tasks combine into a service it remains responsible for delivering.
The following model keeps responsibility and dependency separate. The bank remains the owner of the service obligation and the tolerance for disruption. The TPSP performs the contracted service, but the key nth party may be the component that makes delivery possible. The wider banking sector is relevant because other banks may share the same provider. Supervisory oversight can examine and coordinate across those relationships, but it does not become the bank’s operating substitute.
The map is not valuable because it contains a large amount of information. It is valuable because each relationship answers a failure question. If the critical service stops, which provider is expected to restore it? If that provider is unavailable, which key nth party is the next constraint? If data cannot be reached in one location, can the service continue elsewhere? If a contingent provider is activated, does it really use different people, facilities, software, and supply-chain dependencies? If other banks rely on the same provider, could the bank’s fallback be unavailable precisely when the sector needs it most?
Two concentration problems: one bank and the whole sector
The Basel Committee separates bank-level concentration risk from systemic concentration risk. Bank-level concentration is the risk to an individual bank, or a banking group where relevant, from dependence on one provider or a limited number of providers when disruption could affect critical operations. It can arise even when the bank has several contracts. Multiple services may be supplied by the same TPSP. Several TPSPs may operate in one geographic region. Or different providers may depend on the same key nth party.
Systemic concentration is a different question: could the failure of one provider or a limited group of providers affect the banking sector, and in some cases the broader financial sector? The bank cannot answer that from its own register alone. It may know that its payment service depends on a particular provider, but not how many other banks use the same provider, how many services they receive, or whether those banks have independent alternatives. That wider pattern is part of the supervisor’s field of view.
The two risks interact. A provider can be manageable for one bank but still matter systemically because many institutions depend on it. Conversely, a bank can have an urgent concentration problem even when the provider is not systemically important: if the bank has no realistic alternative and the service is critical, the bank’s own tolerance for disruption may already be exceeded by a relatively local failure.
The OCC’s 2026 report gives the threat mechanism a concrete shape. It describes attackers exploiting vulnerabilities in widely used information-technology systems and third-party software. In a supply-chain attack, software used to maintain clients’ systems or networks can be compromised and used to spread malicious activity, affecting thousands of customers. The report does not attribute a particular event to a named provider, but it makes the propagation problem clear: a common dependency can turn one compromise into many institutions’ operational problem.
This is why counting providers is a weak test for diversification. Suppose, as an illustrative scenario, that a bank divides payment processing between three TPSPs. The arrangement looks more diverse than a single-provider design. But if all three rely on the same authentication service or the same key infrastructure supplier, the bank has divided the contract while retaining a common failure path. If the three providers operate in the same region and face the same hazard, the number of contracts has not created geographic resilience either.
The failure can also move in the other direction. A compromise at a shared software supplier may not immediately stop every customer, but it can create a common need for urgent patching, credential rotation, investigation, or service suspension. Those responses compete for scarce technical staff and may occur while customers are already experiencing degraded service. A dependency map helps the bank ask whether its own response capacity is independent, rather than assuming that a provider’s technical redundancy also guarantees an independent recovery process.
The opposite design can also mislead. A single TPSP may offer service from multiple regions, or a bank may combine the provider’s service with on-premises capability. Those choices may reduce a particular concentration, but they do not automatically make the bank independent. The bank still needs to understand whether the regions, control planes, software, staff, and recovery arrangements are genuinely separable. A fallback is useful only to the extent that it can operate when the primary path and its relevant dependencies are unavailable.
Substitutability is therefore not a yes-or-no field in a register. It is a judgment about time, cost, technical feasibility, contractual restrictions, data movement, staff knowledge, and the consequences of transition. The Basel principles expect banks to explore options such as using multiple geographic regions, combining external and internal infrastructure, maintaining backup or alternative TPSPs, and retaining the capability to bring a service back in-house. These are options for managing concentration within the bank’s risk appetite and tolerance for disruption, not promises that every service can be made fully interchangeable.
A proposed alternative should be tested against the same dependency questions as the primary arrangement. Can the bank reach the required data in a usable format? Does the alternative have the necessary staff and capacity during a sector-wide event? Can the bank transfer the service within the period its tolerance allows? Are its legal, security, and operational responsibilities understood? If the answer is unknown, the alternative is an assumption, not yet a resilience capability. This is why critical arrangements require more than a list of backup names: they require evidence that the bank can activate the option under realistic conditions.
The same reasoning applies to key nth parties. A provider may tell the bank that it has redundancy, but the bank has to ask what “redundant” means in the service’s actual dependency graph. Two facilities may share a network. Two software paths may depend on the same identity service. Two suppliers may be separate legal entities but use the same specialist subcontractor. The map should preserve enough information for the bank to distinguish independent recovery paths from duplicated labels.
The result is a more disciplined sequence of judgment. First, identify the service whose failure would matter and define the bank’s tolerance for disruption. Second, map the direct TPSP and the key nth parties, including data and geographic dependencies. Third, look for concentration within the bank’s own portfolio. Fourth, ask whether the arrangement participates in a wider sector concentration that the bank cannot observe by itself. Finally, choose mitigation that addresses the actual common dependency: stronger monitoring, more frequent testing, alternative capacity, internal capability, geographic separation, or a decision not to proceed.
There is no universal numerical threshold in the BCBS principles that tells every bank when concentration becomes unacceptable. The principles are designed to be proportionate to the bank and the arrangement, and their criticality definition is functional rather than a fixed list of services. That flexibility is useful because banks and jurisdictions differ. It also means that a bank cannot outsource the judgment to a generic rating or a vendor category. The decision has to be grounded in the service’s consequences and the evidence available about its dependencies.
Once those dependencies are visible, the next problem is time. A map made before a contract is signed can become inaccurate when a provider changes its subcontractors, location, technology, or recovery design. The bank therefore has to carry the map through assessment, due diligence, contracting, onboarding, monitoring, and eventual termination. That is where a dependency becomes an accountable operating relationship rather than a static entry in a vendor system.