Vendor and Third-Party Risk Management

Assessing, controlling and monitoring service dependencies

Assess the relationship and actual dependence

Third-party risk management governs services and other relationships on which a bank depends. Providers can affect security, data, financial integrity, service continuity and customer rights. A brand name or questionnaire score does not establish the bank's actual exposure.

Identify the service, activities, entities, records, access and downstream dependencies. Payment schemes, correspondents and technology vendors can require different frameworks. Do not force every relationship into one identical supplier process.

Tier and assess proportionately

Determine criticality from the service and failure consequences. A messaging provider can be important if it supports the only recovery route; an infrastructure provider may support a low-impact test workload. Tier labels and review frequency are institution-specific or framework-specific, not universal four-tier rules.

Examine security, financial viability, resilience, legal scope and access according to risk. Standard questionnaires and certifications can help but do not replace service-specific evidence. A custom assessment is not inherently wrong, and one penetration-test age limit cannot be imposed on every relationship as a worldwide rule.

Consider common providers, regions, software and subcontractors. Multi-region or multi-provider designs can help while retaining common failure points. A fixed 50% capacity headroom and a promise of no possible single failure are not universal regulatory requirements.

Contract and implement controls

Terms should support relevant service levels, information access, security, incident coordination, data rights, subcontracting and exit. Requirements depend on the applicable activity and framework. A contract penalty does not restore a missed payment or make an unusable export adequate.

Provision least-privilege access, protect credentials and test integration and financial semantics. A compliant supplier identity cannot authorise every customer action. Version changes in fields, statuses and permissions can alter controls even when an API remains technically reachable.

The Basel third-party-risk principles and US interagency guidance provide banking-risk references with their own application. Outsourcing does not remove the bank's own duties.

Monitor and respond

Use service outcomes, incidents, control findings, material changes and risk trends. Continuous tooling can support monitoring; not every supplier must expose real-time logs or accept quarterly onsite tests. Obtain adequate evidence for the actual obligations and risks.

Define joint incident contacts and action authority. Supplier restoration and the bank's customer recovery are distinct. Reconcile affected financial effects, assess reporting and communicate confirmed status rather than relying solely on the provider's green dashboard.

Exit and residual duties

Plan termination, replacement or run-off according to realistic feasibility. Preserve required records, customer access, financial positions and complaints. Revoke access and rotate relevant shared credentials under controlled timing; immediate indiscriminate revocation can also disrupt necessary transition work.

Data return, deletion, backup retention and legal duties need separate treatment. A blanket promise to delete everything immediately can conflict with required records. Verify completion under the actual agreement and framework.

Fictional example: provider field change

A supplier changes an account-status definition. The bank assesses affected decisions, tests versions and prevents the new interpretation from silently relaxing a financial restriction. It monitors the migration and investigates any prior effects.

Takeaway

Third-party governance should produce usable evidence and actions throughout the relationship. Assess actual service dependence and continuity, rather than relying on tier names or signed clauses alone.