The Life Cycle of a Delegated Service
The subject here is the life cycle of a bank’s arrangement with a third-party service provider. The specific problem is temporal: a dependency that looks acceptable when selected can become riskier as the provider, the bank, the technology, or the surrounding environment changes. This chapter follows the path from engagement decision to live operation so the reader can distinguish what must be assessed about the arrangement, what must be learned about the provider, and how a contract and onboarding preserve the bank’s control.
The engagement decision starts with two risk assessments
The Basel Committee separates two questions that are often compressed into one vendor review. The first asks what the proposed arrangement would mean for the bank. The second asks whether this particular third-party service provider, or TPSP, can deliver the service and manage the associated risks. The questions inform each other, but they are not interchangeable.
Arrangement-level risk assessment starts with the service and its consequences. What activities, systems, data, or legal and regulatory obligations would depend on the relationship? How much interruption could the bank tolerate? What would happen if the service were degraded rather than completely unavailable? Could the service be substituted, moved to another provider, brought back in-house, or supported by a compensating control? Would the arrangement add concentration to an existing portfolio of providers or supply-chain dependencies?
These questions do not assume that internal delivery is automatically safer. A bank may lack specialised staff, mature technology, or the capacity to replace an obsolete internal system. The Basel principles ask banks to consider the potential risks of not entering an arrangement against the risks the new relationship could introduce or amplify. A provider can therefore be a sensible choice precisely because it supplies capability the bank would struggle to maintain itself. But that benefit is part of a comparison of real alternatives, not a reason to stop examining the dependency.
The assessment should also consider the information and authority that would cross the boundary. Data may be stored or processed in another location. Access rights may be administered by the provider. A service may rely on a long or complex supply chain. A new technology may make the service more efficient while making its risks harder for the bank’s staff to evaluate. Geography can add natural-disaster, political, legal, financial, or regulatory dependencies. The question is not whether any one of these features is disqualifying; it is whether their combination fits the bank’s risk appetite and tolerance for disruption.
The result should be a documented decision about whether to engage, what controls and reporting are needed, and which contractual terms must be negotiated. That decision should be specific enough to guide later stages. If the service is critical, for example, the bank should know why it is critical, what evidence would demonstrate acceptable performance, what recovery commitments are needed, and what would trigger reconsideration or exit. A generic conclusion that a provider is “low risk” cannot answer those operational questions.
Due diligence then turns to the prospective TPSP. It examines the provider’s capacity and ability to deliver the service, not just its marketing claims or financial size. The bank should consider operational and technical capability, qualified staffing during ordinary operations and disruption, support for legal and regulatory obligations, internal controls, cyber and other operational risks, and the provider’s ability to identify and manage important supply-chain parties. It should also examine whether the provider maintains business-continuity, disaster-recovery, and crisis-communication plans that are consistent with the bank’s tolerance for disruption for the relevant service.
Provider-specific risks can arise even when the arrangement itself appears useful. The provider’s financial condition may affect continuity. Its service locations may create geographic dependencies. Conflicts of interest, relevant complaints, investigations, or litigation may change the bank’s understanding of the relationship. Alternative TPSPs may exist in theory but have different limitations, transition times, or dependencies. The bank should consider whether the proposed arrangement would create unacceptable concentration when added to its existing portfolio.
The two assessments meet in a decision, but they should not collapse into the same score. A provider can be technically capable while the arrangement creates unacceptable concentration. An arrangement can be strategically valuable while the provider cannot demonstrate adequate staffing or recovery. A provider’s certification can offer useful baseline information while leaving unanswered questions about the particular critical service. A principles-based framework does not supply a universal scoring formula, so the bank has to preserve the reasoning that connects evidence to its own service, risks, and tolerance.
The assessment is also not complete when the contract is signed. The Basel principles describe risk assessment as iterative. The bank should revisit it regularly and whenever a major change affects the arrangement, the provider, or the external environment. A change in service location, subcontractor, ownership, technology, financial condition, or the bank’s own operating model can alter criticality and substitutability. A renewal is therefore not merely an administrative extension; it is an opportunity to test whether the original decision still describes the relationship that exists.
Contracts and onboarding preserve the bank’s control
Once the bank decides that an arrangement is acceptable in principle and that the provider can support it, the decision has to become an operating relationship. The Basel principles call for a clearly written, legally binding contract, proportionate to the risks and criticality of the service. The contract is not just evidence that procurement completed a transaction. It is the control surface through which the bank obtains information, access, performance commitments, and a path out of the relationship.
The life cycle is not a one-way march from approval to operation. New information can send the bank back to assessment, while monitoring can support renewal or trigger termination. The transitions below show what persists: the bank’s responsibility, the provider relationship, and the evidence needed to decide whether the arrangement remains acceptable.
One group of provisions makes performance visible. The parties should agree on meaningful benchmarks and service-level expectations, and the bank should have the right to receive accurate, comprehensive, and timely information about performance, risk-management practices, and incidents affecting the service. A benchmark matters only if the bank can determine how it is measured and what happens when it is missed. For a critical arrangement, the Basel principles call for additional indicators and metrics, such as service-level results, continuity-test results, control-effectiveness findings, and customer-complaint information where relevant.
A second group preserves oversight. The bank needs rights to access the provider, audit it, and obtain relevant information. Supervisory authorities may also need access, audits, or information under applicable law and supervisory agreements. These rights matter because the bank’s responsibility cannot be exercised through assurances it is not allowed to examine. They also need to reach key nth parties when those parties are essential to delivery. The direct TPSP may remain the contractual counterparty, but its ability to identify, manage, and provide information about a key part of its supply chain is part of the service the bank is relying on.
A third group makes responsibilities explicit. Security, resilience, technical configuration, business continuity, and disaster recovery are often shared across the bank and TPSP. “Shared” should not mean undefined. The contract should make clear which party performs each important activity, what evidence the other party receives, how a failure is escalated, and how the parties support testing and recovery. The bank does not need to perform every provider control itself, but it needs enough clarity to detect a gap at the interface between the two operating environments.
A fourth group protects the bank’s ability to continue or leave. The contract should address where the service is performed and where data is processed or stored, as well as ownership, access, use, and timely transfer of logical assets such as data, applications, application interfaces, models, and intellectual-property rights. It should address confidentiality and the risk that one client’s information is mixed with another’s. It should also establish default and termination conditions, responsibilities and notice periods, mechanisms for regulatory changes, and provisions that support an exit strategy.
For a critical arrangement, these provisions become more demanding. Contracts should address conditions governing key nth parties, including notification of their use or change and incident reporting. They should give the bank rights to receive information about incidents and material changes affecting the TPSP or its key nth party, and rights to access and audit relevant parties where permitted. Continuity obligations should be measurable. Uptime or maximum downtime commitments, recovery time objectives, and recovery point objectives give the bank something concrete to test against its tolerance for disruption.
The OCC’s 2026 report illustrates why incident information cannot be left vague in a U.S. banking arrangement. It describes an interagency computer-security incident notification rule under which a banking organisation must notify its primary federal regulator as soon as possible and no later than 36 hours after determining that a qualifying notification incident has occurred. It also describes a provider obligation to notify at least one designated contact at each affected customer bank when an incident has materially disrupted or is reasonably likely to materially disrupt or degrade covered services for four or more hours. These are details of the U.S. framework described by the OCC, not universal deadlines for every jurisdiction. Their operational lesson is broader: a bank needs a reliable path from a provider event to the information and decisions the bank itself must make.
Contract language still cannot create capability by itself. A provider may promise an alternative site without demonstrating that it has independent infrastructure, staff, data access, or tested procedures. A termination clause may exist while the bank lacks the budget, knowledge, or technical capacity to use it. Rights to audit may be difficult to exercise in practice. The contract therefore establishes the bank’s ability to demand evidence; onboarding and later monitoring must establish whether the promised controls work.
Onboarding is the transition from an agreed arrangement to a service that people and systems actually operate. The provider needs an adequate understanding of the bank’s policies, people, processes, technology, facilities, and interconnections required to deliver the service lawfully. The bank, in turn, needs to know how the provider’s operating model fits into its own controls and responsibilities. A service can fail at this transition even when the contract is well drafted if the teams running it do not understand access boundaries, escalation paths, data handling, or recovery dependencies.
The transition should update the bank’s register and dependency map. The map is not an artefact created for selection and then filed away. Onboarding may reveal a previously unknown subcontractor, a different service location, a new connection to the bank’s systems, or a responsibility that was assumed but never assigned. Each discovery can change the risk assessment and the concentration analysis. If a key nth party supports the service, that relationship needs to become part of the bank’s understanding even if the bank does not contract with that party directly.
Onboarding also tests the meaning of responsibility. In a shared-responsibility arrangement, the bank should confirm that both parties understand the obligations they accepted and that the provider has implemented the contracted service in the expected way. The bank’s internal control environment must be ready to perform its own side of the relationship. A provider cannot compensate for a bank that has not configured its access, trained its staff, prepared its escalation routes, or decided who can invoke a continuity plan.
At the end of onboarding, the bank should not merely have a supplier marked “active.” It should have a service whose dependency structure, control ownership, information rights, performance measures, continuity commitments, and exit assumptions are understood well enough to observe. That creates the conditions for the next question: what evidence will show that the arrangement remains reliable after it goes live, and what should happen when conditions or threats change? A delegated service becomes accountable only when the bank can keep learning about it and can act on what it learns.