OR 13 – Third-Party Risk Management

A bank that buys goods or services from any firm outside itself takes on a third party: vendors, suppliers, partners, contractors and service providers all qualify. Third-party risk management (TPRM) is the work of identifying, assessing, mitigating and monitoring the risks those outside firms bring to the institution that hires them.

Practitioners often call the same thing “outsourcing risk”. Strictly, outsourcing risk concerns activities the bank has handed to someone else, while third-party risk is broader and covers every way an outside firm can hurt the client institution, but in daily use the two labels are near synonyms.

Why outsourcing does not remove operational risk

Firms usually outsource to save money, sending work to specialists with better systems or know-how in a narrow field. Handing back-office processing or cloud data storage to such a specialist can cut process errors or strengthen cyber defences, so outsourcing is sometimes described as a way of mitigating operational risk. The mitigation is only partial, though, because the bank swaps part of its own process risk for a new exposure, the risk that the provider fails, which needs its own management effort.

Fourth and fifth parties

The chain does not stop at the provider the bank signs with. A fourth party is a third party of the third party, such as a subcontractor of the service provider or a supplier of a supplier. Less often, a bank looks one link further to fifth parties. Picture a bank whose procurement function relies on a service provider that appoints a central intermediary (the fourth party), which in turn hires contractors (the fifth parties). Followed far enough, TPRM covers the whole supply chain.

Almost any operational risk that can strike a bank can strike its third parties too, and the damage flows back to the bank. Examples are service disruption, poor service quality, fraud, an accidental data privacy breach or a deliberate information leak, compliance breaches, espionage and theft of intellectual property, and reputational damage.

In the Basel event-type taxonomy, “third-party failure” sits at level 2, under the seventh level 1 event type, Execution, Delivery and Process Management (EDPM). Its weight has grown so much that many institutions now treat TPRM as a level 1 operational risk category in its own right, with dedicated practices around it, and the revised ORX taxonomy also lists third-party risk at level 1.

What banks now outsource

Over recent decades, banks have moved core processes outside, from deposit and loan processing, payroll, funds transfers and mortgage servicing to treasury services and call centres, and FinTech partners now supply digital certification, bill payment and account aggregation tools. These providers and their staff are frequently based in another country.

Crossing a border adds country risk as well as compliance and legal risk. A US bank using a provider abroad must still meet every US rule on record retention, sanctions, consumer protection and data privacy, and some of those rules may clash with the law where the provider operates.

Pandemic, connected devices and the data on breaches

The COVID-19 pandemic deepened reliance on outsourcing and exposed fragile international supply chains, and connected internet of things (IoT) devices widen the problem further. At Avanti Markets, a snack vending machine linked to staff payment cards gave hackers a back door to personal data. So, TPRM overlaps heavily with information security management, data privacy and business continuity management.

The evidence on breaches is stark. A 2018 Ponemon Institute study reported that almost 60% of surveyed companies had suffered a data breach caused by a third party or vendor during the previous year. A 2020 survey by two TPRM consultancies, BlueVoyant and DW Solutions, polled over 1500 security, information and procurement chiefs across several industries in five countries.

Countries covered: Mexico, Singapore, Switzerland, the UK and the United States.

Regulators have set standards on third-party risk for about the past 20 years, and growing complexity has brought a wave of new and proposed guidance.

A practical way to organise TPRM tasks is a five-stage loop modelled on Shared Assessments, a US body that certifies third-party risk professionals (the CTPRP credential). Firms differ in detail, but most programmes map onto these stages.

Business model decision

The loop begins with strategy. Whether to keep an activity in-house or outsource it, and how much quality to buy at what price from a given provider, are choices that must sit inside the firm’s risk appetite.

Evaluation, risk rating and due diligence

Before a new relationship starts, the firm must know whom it is dealing with, much as anti-money laundering work demands customer due diligence. The key principle is proportionality. An outside consultant who runs two days of training creates no dependency and receives no data, so light checks suffice, while a cloud company hosting sensitive data needs a far deeper review, and most relationships fall between those poles. For consistency, many firms use standard questionnaires, notably the SIG questionnaires from Shared Assessments.

The depth of checks follows from a risk rating, set out in the next section, whose criteria, thresholds and attached controls should all fit the company’s overall risk appetite.

A risk-based vendor rating sorts providers into four tiers, Mission critical, High, Medium and Low, using five criteria. Here the criteria run as rows, so each line reads as a scale from the most to the least demanding tier.

More critical processes, more sensitive data, deeper system access and harder replacement all push a vendor up the scale. The regulation row deserves a second look: a vendor that is itself regulated (Y) appears only in the two lower tiers, since a supervised firm already works under external standards, while an unregulated vendor (N) appears in the upper two.

The contract, its service level agreements (SLAs) and the ongoing contract management behind them are often neglected in third-party control, yet ambiguity is a common reason relationships fail. When either side misreads what was expected, the relationship tends to break down and operational risk rises. So, the contract should spell out what each party may and may not do, who does it, when and where, and the SLA should set the quality and timing of the service with clear, measurable quality measures wherever possible.

Timing and review of the contract

Signing should come only after the assessment is complete and every open issue has been remediated, and the contract binds only once both parties sign. Good practice adds a periodic contract review to check compliance and a route for fixing contract deficiencies. With a foreign provider, the firm must ensure the vendor understands and will follow the applicable domestic laws.

Cross-border contracts and fourth parties

Contract management becomes harder across borders. When COVID-19 shutdowns began, US and European banks with call centres or other critical processes in India, the Philippines and similar locations had to either bring that work home quickly or rewrite contracts and controls so offshore third-party staff could work remotely.

The contract is also the natural tool for fourth-party risk. It can set standards or limits on what the vendor may itself outsource, largely copying the rules the bank applies to its own vendors so they pass down to subcontractors. To check this, the bank needs audit rights over its vendors, which links contracting to monitoring.

Once a service is running, the bank tracks delivery against the quality SLAs, compliance with regulation and adherence to the contract terms. This continuous monitoring gets easier when the earlier stages were done well: the more thorough the decision, rating, due diligence and contracting, the shorter the reassessment cycle when the contract comes up for renewal or change.

Trigger events for reassessment

Good practice does not wait for scheduled reviews or contract end; it defines events that force an early reassessment.

Remediation or termination

Most relationships end simply because the service ends. Still, every contract should carry a grievance procedure and an exit strategy, or termination clause, for when a situation deteriorates beyond repair, and termination may also come for convenience, regulatory change or more abrupt reasons. Fairness matters then, and both sides should plan a wind-down that can include handing over intellectual property (IP), moving the service in-house or to another provider, and evidence that any sensitive data the vendor held was transferred or destroyed.

In July 2019, Capital One, a US bank focused on cards, auto lending and retail accounts, disclosed that data on about 100 million people in the United States had been accessed illegally. The person later arrested was a former employee of Amazon Web Services (AWS), the bank’s cloud provider, and the charges covered the theft of 140,000 Social Security numbers and 80,000 bank account numbers.

How the breach happened

The attacker reportedly exploited a misconfigured web application firewall to reach files stored in an AWS database. Both firms knew the setup was exposed to server side request forgery (SSRF) attacks. Encryption would have made the stolen files worthless, but the data was unencrypted because Capital One had configured its own systems incorrectly. The bank said it fixed the flaw at once, checked for similar misconfigurations and added the issue to its automated scanning.

Regulatory and legal outcome

Capital One received an $80 million fine from the Office of the Comptroller of the Currency (OCC), which cited the bank’s failure to put effective risk assessment in place before moving significant IT operations to the public cloud. Its consent order called the deficiencies unsafe or unsound practices that breached the Interagency Guidelines Establishing Information Security Standards, and noted that an internal audit in 2015, four years before the breach, had missed many control weaknesses in the cloud environment. In 2020, the resulting lawsuits were merged into one case.

Lessons

Cloud providers build strong security into their products, but the client still owns risk management, monitoring, backups and maintenance, and must switch on the controls that keep stored data private. Specialists blame rising cloud breaches on exactly this kind of poor security hygiene, and, as in many fined cases, the weak controls had gone unaddressed for years.

The OCC imposed a $60 million fine on Morgan Stanley, acting through Morgan Stanley Bank and Morgan Stanley Private Bank, for weak risk management and oversight of the vendors it used to decommission two wealth management business data servers in 2016. Similar weaknesses surfaced again when wide-area application service devices were decommissioned in 2019, and that repetition led to the fine.

The regulator concluded that the bank had failed on three counts: it did not properly assess or address the risks of decommissioning its hardware, it fell short in judging the risk that its vendors and their subcontractors posed, and it did not keep a proper inventory of the customer data held on the devices. The OCC also found weak due diligence in choosing the vendors and inadequate monitoring of their performance.

In July 2019 the bank began telling wealth management clients that their personal data might have been exposed, because hardware it had disposed of still held some of that information. It notified customers hit by the 2016 incident at the OCC’s direction and those hit by the 2019 incident voluntarily, offered two years of free credit monitoring, and faces a class action.

Lessons

The case shows how tightly data security and TPRM are bound together, since a vendor hired only to dispose of old equipment caused a serious data breach. Outsourcing can shift some of the operational risk that an activity creates, but the accountability for that risk cannot be handed over.