When a Critical Control Depends on a Third Party: Who Owns the Control, the Evidence and the Escalation?

Many financial firms rely on third parties to perform activities that sit directly inside important control processes. Identity verification may be handled by an external provider, sanctions and PEP screening may depend on a vendor platform, transaction monitoring rules may run through third-party infrastructure, while CASPs may rely on external custody technology, wallet infrastructure or blockchain analytics. Payment firms may similarly depend on processors, fraud tools or routing platforms that have become deeply embedded in day-to-day operations.

Operationally, these arrangements can work very well. The documentation problem begins when the organisation starts describing the control as though responsibility has moved with the activity.

A procedure may state that screening is performed by a third-party provider, but that tells us only who performs part of the process. It does not explain who defines what should be screened, which data should be submitted, how a potential match should be treated, what happens when the provider produces no result or an ambiguous result, who monitors whether the service continues to work as intended, or which evidence must remain available to the organisation afterwards.

Once a third party becomes part of a material control, the documentation therefore needs to describe more than the service being purchased. It needs to describe the control model around the dependency.

Performing the activity and owning the control are not the same thing

A third-party provider may perform an activity that contributes to a control without becoming the owner of the organisation’s control objective.

Consider sanctions screening. A vendor may receive customer data, compare it against relevant datasets, apply matching logic and return a result. From a technical perspective, much of the screening activity takes place outside the organisation, but the organisation still needs to determine what the control is intended to achieve, which customers or transactions should be screened, at what point in the process screening should occur, which data should be used and what constitutes an actionable result.

The distinction matters because a provider can perform its contracted service correctly while the organisation’s wider control still fails. The wrong data may have been submitted, the screening may have taken place too late in the process, an alert may have been returned without anyone reviewing it, or a timeout may have been treated as a clear result. The organisation may also have changed its risk approach without updating the vendor configuration, leaving the external service technically functional but no longer aligned with the internal control logic. In each of these cases, the provider may have operated exactly as designed while the end-to-end control failed to achieve its purpose.

This is why the documentation should distinguish between the external activity performed by the provider and the internal control objective that the organisation still needs to understand, govern and evidence.

A third-party control still needs an internal owner

Once an activity crosses the organisational boundary, responsibility can fragment very quickly unless internal ownership remains explicit.

Operations may assume the provider owns the process because the activity is outsourced. Compliance may assume Operations manages the relationship. Procurement may focus on contract terms, while Technology monitors system availability. Each function can therefore be performing a legitimate role without anyone clearly owning the end-to-end control.

An internal control owner does not need to perform every operational step, but the role should be able to understand how the control works across the organisational boundary. That includes knowing what the provider is expected to perform, which inputs the organisation supplies, what output is returned, how that output is interpreted internally, which exceptions require intervention, how failures are identified, what evidence is retained and how continuing performance is reviewed.

The purpose of documenting ownership is not to centralise every task with one person or function. It is to ensure that someone remains accountable for understanding whether the complete control, rather than only the outsourced activity, is operating as intended.

Provider output should not quietly become the organisation’s decision

This becomes particularly important where external services produce outputs that directly influence customer or transaction decisions.

A screening tool may return a potential match, an identity provider may produce a verification score, a fraud engine may assign a risk indicator, a blockchain analytics provider may classify wallet exposure, and a transaction monitoring platform may generate an alert. These outputs can be highly significant, but they are not necessarily the same thing as the organisation’s final decision.

The documentation should therefore preserve the distinction between provider output, internal interpretation, decision and action. In a sanctions-screening process, for example, the provider may identify a potential match, but the organisation still needs a documented basis for determining whether that match is relevant, whether additional information is required, who is authorised to clear or escalate the case and what evidence must be retained.

The same principle applies to apparently benign outcomes. A provider’s “clear”, “verified” or low-risk result should not automatically acquire a meaning that the organisation has never formally defined. The organisation should understand what the result means within the provider’s methodology, which assumptions sit behind it and whether that result is sufficient for the internal decision being made.

Without that distinction, vendor output can gradually become a substitute for internal decision logic, even though the documentation continues to suggest that the organisation itself owns the decision.

API success is not the same as control success

The issue becomes even less visible when the third-party activity is embedded through APIs and the operational process appears seamless.

From a technology perspective, the interaction may look successful because the request was sent, the provider responded and no technical error was generated. That still does not demonstrate that the control worked as intended.

A technically successful API call does not show whether the correct customer or transaction data was submitted, whether all required fields were populated, whether the expected dataset or configuration was applied, whether the returned result was interpreted correctly or whether an alert received the review required by the organisation’s own procedures. It may also conceal cases in which a timeout, fallback response or incomplete result was treated as though the control had completed successfully.

This distinction matters because increasingly automated integrations can make third-party controls less visible to the people who rely on them. The smoother the technical process becomes, the easier it is to assume that the control exists simply because the systems continue communicating.

Documentation therefore needs to preserve visibility over the control logic surrounding the integration. API success confirms that systems communicated; it does not, by itself, confirm that the control achieved its purpose.

Exceptions reveal where ownership really sits

Normal processing often makes ownership appear simpler than it is. A customer submits information, the provider returns a result, the internal process continues and nobody needs to intervene.

The real control model becomes much clearer when the expected path breaks.

If the screening provider becomes unavailable during onboarding, the organisation needs to know whether the process must stop, whether onboarding can continue pending screening, whether an alternative provider or manual control may be used and who has authority to approve that fallback. It may also need to consider what happens to customers processed during the outage if the issue is discovered only later.

A different problem arises when the provider responds but the result is ambiguous. The organisation then needs to know who investigates the case, what additional information can be requested, which team has authority to clear the result and under what circumstances escalation becomes mandatory. Similar questions arise where the provider changes the format, methodology or classification behind its output.

These situations show why exception handling cannot sit entirely inside vendor documentation. The provider may explain how its service behaves technically, but the organisation still needs its own rules for deciding what happens when the expected external service does not produce an expected operational outcome.

A third-party dependency becomes genuinely governable only when both the normal path and the failure path are visible in the organisation’s documentation.

Evidence cannot sit entirely outside the organisation

Third-party controls also create an important evidence problem because the most detailed operational records may sit with the provider rather than with the regulated or supervised firm using the service.

A provider may retain technical logs, screening history, configuration records, model outputs or detailed decision data, while the organisation stores only a status field confirming that a check was completed. Depending on the nature of the activity, that may or may not be sufficient.

The more useful question is what the organisation would need to reconstruct a material decision after the event. For a customer-screening process, this may include the data submitted, the date and time of the check, the provider used, the result returned, any relevant alert, the internal reviewer, the decision taken, the rationale where judgement was required and any escalation or follow-up action.

This does not mean that every technical event must be copied from the provider into the organisation’s own systems. Excessive logging can generate large volumes of information without necessarily producing better evidence. The documentation should instead define which records matter for accountability, investigation and control testing, where those records are retained and how they can be accessed when needed.

Otherwise, the organisation may know that a control was performed without being able to demonstrate how a material outcome was reached.

Provider oversight should connect back to the control objective

Third-party governance often becomes heavily centred on contracts, service levels, due diligence reviews and periodic supplier assessments. Those elements are important, but they do not necessarily demonstrate that the underlying control continues to operate effectively.

A provider can meet availability targets while the quality of the control deteriorates elsewhere. A configuration change may reduce alert quality, a new product may introduce data fields that the integration does not capture, or a change in the organisation’s own customer risk methodology may no longer be reflected in vendor thresholds. A provider may also alter its subcontracting arrangement or processing model in a way that changes an operational dependency without causing any obvious service disruption.

For material controls, oversight therefore needs to look beyond whether the supplier is meeting contractual SLAs and ask whether the service still produces the information, decisions or protections that the internal control framework expects.

The documentation does not need to create an elaborate oversight regime for every supplier. It does need to show how the organisation will recognise when a third-party dependency begins to weaken an important control, even though the contractual service may still appear to be functioning normally.

Change management becomes a shared dependency problem

Third-party controls also make change management more complicated because changes can originate on either side of the relationship.

The organisation may change its risk appetite, customer methodology, onboarding model, product scope or escalation criteria, while the provider may change its methodology, API, data sources, system behaviour or service configuration. Either type of change can alter how the control operates.

Suppose the organisation changes the way certain jurisdictions affect customer risk. The internal methodology may be updated correctly, but if the third-party screening or monitoring configuration remains unchanged, part of the control framework will continue to operate according to the previous logic.

The reverse can happen just as easily. A provider may modify a matching algorithm, scoring model or alert taxonomy while the internal procedure continues to describe the old output and the old decision process.

Third-party dependencies should therefore form part of change impact assessment. The relevant question is not simply whether a contract, API or vendor document changed, but whether the change affected the control objective, the data sent to the provider, the activity performed, the output returned, the internal decision, the escalation route or the evidence available afterwards.

A relatively small vendor change can sometimes have a much wider internal documentation impact than the organisation initially expects.

Exit planning is also a documentation issue

Exit planning is often discussed mainly as a contractual, operational-resilience or procurement matter, but there is also a documentation question that can be easy to miss: what happens to the control itself when the provider changes?

A replacement provider may use different terminology, thresholds, workflows, data structures or evidence formats. A temporary manual fallback may allocate responsibilities differently, while historical evidence may remain stored with the previous provider. Internal procedures may continue to refer to screens, fields or workflow stages that no longer exist after the migration.

Changing provider therefore involves more than redirecting an API or signing a new agreement. The organisation may need to reassess how the control is documented from input through decision, escalation and evidence.

This becomes particularly important where employees have gradually come to treat the provider’s system design as though it were the organisation’s own process. The more deeply embedded the external tool becomes, the more important it is to preserve the distinction between the control objective and the current mechanism used to operate it.

A practical Third-Party Control Map

For a material third-party dependency, a simple control map can make the end-to-end arrangement much clearer. It should identify the control objective, the specific external activity performed by the provider, the internal owner who remains accountable for the complete control, the input supplied to the provider and the output returned.

The map should then continue beyond the vendor boundary by showing the internal decision point, the exception and escalation route, and the evidence and oversight needed to demonstrate that the control continues to operate as intended.

This does not need to become another large policy document. In many organisations, a concise dependency register or control map can provide more practical clarity than several pages of generic outsourcing language because it makes the full control chain visible rather than describing only the supplier relationship.

A practical test for third-party-dependent controls

A useful review of a material third-party-dependent control can begin with seven questions:

1. What control objective is the provider supporting?

2. Which part of the control does the provider actually perform?

3. Who owns the control internally?

4. Who interprets the provider’s output and makes the final decision?

5. What happens when the provider fails or returns an ambiguous result?

6. What evidence remains accessible to the organisation?

7. How would the control continue if the provider or service changed?

   
   

If those questions cannot be answered consistently across the relevant procedures, governance documentation, system design and third-party arrangement, the organisation may understand the supplier relationship without fully understanding the control dependency.

Key takeaway

Using a third party does not make a control external to the organisation. The provider may perform the screening, verification, monitoring or technical activity, but the organisation still needs to understand how that activity connects to its own decisions, responsibilities, escalation routes and evidence.

Strong documentation should therefore do more than state that a provider performs a particular control. It should make visible where the external activity sits inside the wider operating process, who owns the outcome, how ambiguous or failed results are handled, what evidence remains available and how the organisation will recognise when the dependency itself starts to weaken the control.

The provider may operate part of the control, but the organisation still needs to understand, govern and evidence the control as a whole.