OR 5 – Risk Mitigation

Risk mitigation covers every measure a firm takes to bring its operational risks down to a level it is willing to live with, while the business carries on operating. It is the third step of the risk management cycle, after risks have been identified and assessed.

Operational risk sits inside the same risk-return logic as every other business risk, but with an important difference. A bank chooses how much credit, market or liquidity risk to take on, whereas operational risk arrives largely as a by-product of doing business, so the firm has less control over how much it accepts. It helps to split it into two families.

External and internal operational risks

External operational risks come from the environment the firm operates in: geopolitics, competitors, regulation and outside events. A firm cannot stop these from existing. What it can do is shrink its exposure to them, for example by pulling back from a volatile market, accepting that this may also cut it off from profitable opportunities, or it can sharpen the way it responds when the event hits.

Internal operational risks come from people, processes and systems inside the firm. They are much more preventable than external ones, and the main tool for preventing them is the internal control environment. Because the firm controls the inputs, these risks can be managed actively as a trade-off between the cost of controls and the risk they remove.

Fees as payment for carrying operational risk

A bank deliberately takes on credit, market and liquidity exposures because that is how it earns money, and running those businesses unavoidably generates operational risk, as any business does. Some activities generate more of it than others. A useful way to see fee income is as compensation for the operational risk a bank absorbs while producing and delivering a service. When a client asks the bank to wire money to a foreign account, the bank takes on the chance of a system failure or delay, a wrong execution, or internal or external fraud, all on the client’s behalf. Part of the fee pays for bearing that exposure.

Internal operational risk also rises with the range of products a firm offers, especially new ones, and can be pushed down through automation, planning and controls. Spending on mitigation improves the firm’s risk-return position only when the benefits, namely fewer loss events, steadier results and better performance, outweigh what the mitigation costs.

Capital, residual risk and appetite

Operational risk can be reduced through a strong control environment, through insurance, or by abandoning certain activities, but it can never be removed entirely, since it is part of the business itself. That is why every firm, not only a bank, needs capital to absorb unexpected outcomes. Regulation sets a minimum. The capital a bank or insurer holds above that minimum reflects its risk appetite: a firm with a higher appetite holds less spare capital, while a more cautious firm holds more.

Appetite also decides how far a firm pushes its residual risk down. One bank may be content with a medium level of residual risk after controls, while another insists on driving it lower. Appetite can differ by risk type inside the same firm: a bank may set a low appetite for non-compliance with regulation and a medium appetite for routine execution errors, and its mitigation spending will follow that split.

The ISO 31000 enterprise risk management standard groups every possible reaction to a risk into four responses, usually remembered as the four Ts. Each one makes sense under different conditions, and a single firm will use all four across its risk register.

Treatment, the most common response, combines internal controls with action plans that reduce the uncertainty and volatility of outcomes; a control may cut the chance of an event, its damage, or both.

Transfer works most often through insurance, where the firm pays a premium and an insurer takes over the financial loss if the risk materializes. Outsourcing is the other common route: by handing a process to a third party, the firm also hands over part of the operational risk attached to it. What it cannot hand over is accountability. A bank that outsources a service remains answerable to its customers for that service being delivered properly, and some impacts, reputational damage above all, do not travel to the other party at all.

Internal controls are the foundation of risk treatment. Several classifications exist, but a simple and effective one, used by the Institute of Internal Auditors, sorts controls by where they act on the path from a cause to an event to its consequences. The diagram below places the four types on that path.

Preventive controls

A preventive control acts before a risk event and works on its causes, so its job is to lower the likelihood of an incident. Segregation of duties is the most widely known example and the classic defense against fraud: initiating, validating and settling a transaction are given to different people, so no single person can complete a fraudulent transaction alone. The principle reaches well beyond trading: a supplier’s invoice is issued by the supplier, approved by the department that used the service, paid by accounts payable or treasury, and booked by accounting, while on a trading floor the front office executes, the middle office validates, and the back office and treasury confirm and settle.

Other preventive controls include checking records, matching signatures before a client instruction is executed, and restricting access to systems or premises. In retail banking the best-known preventive control is the know-your-customer (KYC) check, as it is called in the United States; the EU term is customer due diligence (CDD). It exists to catch financial crime and money laundering, but it also cuts ordinary account management errors because the bank holds accurate information about the client from the start.

Detective controls

Detective controls are built to raise an alert when an incident happens, speed up its resolution and contain the harm to the firm and its stakeholders. Smoke alarms, intruder detectors, network monitoring tools and the fraud alert a cardholder receives after an unusual purchase are familiar cases. A detective control can become preventive when it spots a cause rather than an event. A file reconciliation is detective if it finds an error that has already been booked, but preventive if it catches the error and fixes it before the transaction is executed.

Corrective controls

Corrective controls do nothing to the probability of an event; their purpose is to reduce the pain once it occurs. Typical examples are data back-ups, duplicate IT systems that take over on failure, continuity plans, and prepared strategies for crisis communication. Backing up a laptop will not stop its drive failing, but it turns a disaster into an inconvenience, much as seatbelts and airbags do in a car crash.

Directive controls

Directive controls are the rules and guidance that tell people how a process should run: policies and procedures, training, governance structures, and defined roles and responsibilities. They are often missing from formal taxonomies, yet every organization has them, and they cut operational risk considerably when complete and applied consistently.

Key controls and non-key controls

A key control, also called a primary control, is one that can stop a risk from materializing all by itself. Most of the examples in the table above are key controls. A key control can also be corrective when it fully neutralizes the negative impact: a cloud back-up of a laptop is a key control against accidental data loss because, with it in place, the loss does not really happen. Every well-designed process should build key controls into its design.

A non-key control, or secondary control, supports or strengthens key controls but cannot mitigate the risk on its own. The distinction matters for testing, since the most rigorous testing is reserved for key controls.

Controls can also be classified by whether a person or a system performs them, and automation makes a control far more reliable. Common automated controls include:

• system-enforced access rights and restrictions that keep segregation of duties intact;
• automatic matching of client names against bank account details;
• reasonableness or data validation checks built into data collection tools;
• pricing and invoicing calculated by the system;
• digital face recognition.

Some bank risk managers now argue that technology leaves no excuse for manual controls, since automation makes possible controls that people could never perform efficiently, such as cyber surveillance and real-time fraud screening of card payments.

Automation changes the shape of the risk

Automation does not make risk vanish; it converts the risk of human error into technology risk and model risk. Instead of worrying that a person will execute a control badly, the firm now has to worry that the system running the control will fail, or that the code or model behind it is wrong or stops fitting the business when market conditions or the operating environment change. Artificial intelligence sharpens the problem, because AI controls learn from large data sets, and a bias hidden in that data can leave the control badly deficient without anyone noticing.

The deeper effect is on the profile of losses. Manual errors tend to be frequent but isolated and small. An automated control that breaks fails the same way on every transaction it touches, so the firm swaps many small, likely losses for a rare but potentially very large systemic breakdown.

Choosing among mitigation options resembles pressing on a water mattress: push one risk down and another rises somewhere else. Good mitigation means giving up the risks the firm does not want in return for risks it can accept and manage. Typical failures of automated controls include:

• false positives (type 1 errors) and false negatives (type 2 errors) when systems screen bank, card or system activity for abnormal behavior;
• controls that simply switch off while their system is down;
• back-up jobs that keep running against a server with no free space, so data overflows and no back-up exists.

The last failure comes from a real case. An IT department was convinced that, for twelve months, it had been backing up all of the firm’s data. A consulting firm hired to test the back-up found that every back-up over the previous year had failed because the server’s storage was full, and nobody had been alerted that space had run out. With automated controls, even more than with manual ones, early detection and escalation of alerts are what allow people to step in, especially where transactions are numerous, fast and large.

Case study: the Knight Capital trading loss

Knight Capital Group, founded in 1995, was a publicly listed firm described as the largest market maker in the world. Its reputation may be defined forever by a single hour in which an algorithmic trading failure consumed all of its capital.

The firm loaded a piece of poorly tested new code into its order routing technology. While handling just 212 small retail orders, the system generated millions of erroneous orders in 154 stocks, covering 397 million shares and creating a gross exposure of nearly $7 billion. Within a window of 45 minutes, the trading losses reached nearly $460 million. Investors had to inject roughly $400 million of emergency capital to keep the firm from collapsing, and its acquisition by another firm was announced a few months afterwards.

No single control failed. The disaster combined repurposed old code, weak version control, inadequate testing, alerts that were not prioritized, no incident response procedure, and nobody with the authority to pull the circuit breaker that would have halted all trading by the system.

A control that is badly designed cannot be applied well, so it cannot reduce risk well either. Such controls waste resources, and they can be worse than useless because they give management a false sense of security while the weakness stays in place. Three patterns of weak design are especially common.

Optimistic controls

An optimistic control only works if the person performing it brings exceptional skill or exceptional motivation. Because such checks tend to be performed superficially, they are often called tick-box controls. Signing off a stack of documents minutes before a deadline, clicking “accept” on pages of online terms and conditions, approving software access from a printed list of coded user names that nobody explains, and any approval where the signer lacks the time or information to understand what is being approved all fall into this category.

Collective controls

A collective control spreads the duty of checking across several people, and in doing so it dilutes each person’s accountability. The four-eyes check, also called maker-checker, is the most common form. Having a second person look at the same work sounds safer, but each reviewer may assume the other has done the real checking, so attention drops and the overall risk can rise. The four-eyes check works better when the two people are a manager and a subordinate, or come from different departments, and in general whenever accountability for each task is clearly assigned to a named person.

More of the same

The third pattern is a reaction to an incident: a control of a certain design fails, and the response is to add more controls of the very same design. Answering a failed collective control by adding more checkers dilutes accountability even further. Tightening an onboarding process that managers already bypass because it is cumbersome and out of proportion to the risk only drives more bypassing.

The lesson is that more controls do not automatically mean less risk. Poorly designed controls can make a process more fragile, whereas a well-organized process lowers inherent risk through the arrangement of its tasks alone, without needing any extra control. Only once a control has been judged sound in its design should it be tested for operating effectiveness, which asks whether it is actually performed as intended and works as prescribed.

A firm cannot know its residual operational risk without knowing how well its mitigation works, and control testing is how it finds out. The industry is shifting attention from assessing risks towards assessing controls, because controls can be observed and largely measured, while risks are hard to see directly even if their consequences are not. Testing should establish two things: that a control is properly conceived, and that it is applied correctly and consistently.

There are four main testing methods, and the scrutiny they provide rises from the first to the fourth. The higher the inherent risk a control is guarding, the stronger the test it deserves, because a firm cannot simply hope its mitigation will hold up when conditions deteriorate.

Examination is only as good as the documents it relies on, so its value depends on whether those documents are relevant and adequate. Observation lets the tester judge both design and practical execution, though it too depends on sampling because observation time is limited. Reperformance comes in many forms: mystery shopping to assess customer service or a call center, slipping fake trades or invented data into trading systems to see whether the middle or back office catches them, and model validation, where a model’s output is checked against different data sets or against code written independently.

What makes control testing effective

Three factors shape how much a test result can be trusted. The first is independence: apart from self-certification, the tester should be separate from the owner of the control so that conflicts of interest and bias do not distort the result. The second is frequency, which should be proportionate to how severe the risk is, so that higher risks and unstable environments are tested more often. The third is scope and sample. The sample should represent the whole population as closely as possible, and reliability must be weighed against the time and effort put in, since a small or biased sample can easily paint a misleading picture of how well a control works.

Who tests controls

Testing used to belong mainly to internal audit. Today the first line of defense in many firms also routinely tests its own key controls. The central operational risk management (ORM) function does not usually test controls itself, but it needs assurance that controls are well designed and well operated, enough to keep risks within appetite. It also needs evidence that control assessments exist and that their results feed into the qualitative and quantitative assessment of operational risk.

Extensive guidance is published by COSO and by the Institute of Internal Auditors (IIA) on designing, setting up and testing controls. In the United States, the Sarbanes-Oxley Act obliged operating companies to develop, and formally attest to, internal controls over financial and accounting information, known as SOX controls. That requirement has improved the organization of processes, controls and testing in financial firms, and operational risk managers in firms subject to it can borrow these practices when they review or advise on controls.

Operational risks and their controls are tied closely to how a firm organizes its work, which makes process design a powerful mitigation tool. Process re-engineering, one form of it, reorders tasks and process flow to cut errors and raise efficiency.

Prevention through design

Prevention through design (PtD), also called safety by design, builds the structures that minimize incidents into a process while it is being designed, rather than bolting controls on later. Checklists, communication protocols, standardization, and well-optimized working environments and systems are all forms of PtD.

Much of this thinking comes from James Reason, the researcher behind the Swiss cheese model of accident causation, whom the health care sector regards as the father of patient safety. His work on human error in health care and aerospace, and that of engineering safety researchers such as Leveson, is gradually reaching operational risk management in finance. Reason’s central argument is that human nature cannot be changed, but the conditions people work in can; if fallibility is accepted, then well-designed systems must support people and error traps must be removed wherever possible.

Engineering treats human error as a symptom of a safety problem rather than its cause. A person’s mistake signals a faulty process or a process that is not being followed. Seen this way, there are no human errors as such, only poor processes or processes that people do not adhere to, so the right controls are those that improve the process itself and people’s adherence to it.

Slips, mistakes and violations

Reason’s typology starts by separating slips from mistakes. A slip is involuntary: the person meant to do the right thing but was inattentive, distracted or tired. Fat-finger errors are the standard example in finance, such as transposing two digits in an amount or booking a put option when a call option was intended. The responses target the conditions behind the slip, chosen according to its root cause: a better work environment, a sensible pace, less noise, clearer accountabilities, or visible consequences for each action.

A mistake, by contrast, is a deliberate action that turns out wrong, captured in Reason’s phrase “strong, but wrong”. Rule-based mistakes happen when the rules themselves are flawed or create conflicts of interest. Mis-selling driven by aggressive sales incentives is the typical financial case, and regulators watch closely for pay structures that push staff towards poor conduct. Knowledge-based mistakes happen when someone faces an unfamiliar situation and chooses the wrong action, usually because they lack familiarity, training or guidance. Directive controls are the natural remedy here: help files, escalation procedures and on-the-job training.

A violation is a fourth kind of harmful human action, and it is not really an error. The person knows the correct rule or process and chooses to depart from it. Supervisory controls, whether through the management hierarchy, cameras or automated recordings, are widely recognized as effective against violations, especially when paired with a risk and compliance culture that rewards following the rules.

Lean Six Sigma studies processes and collaborative tasks in order to streamline workflow and raise performance, attacking two enemies at once: waste and variation. It merges two management traditions. The Lean side concentrates on removing waste, meaning any activity that uses resources, consumes time or adds steps without adding value. Lean practitioners recognize eight kinds of waste, remembered through the word DOWNTIME.

The Six Sigma side aims at output quality: it finds and removes the causes of defects and errors and reduces variability in manufacturing and business processes. Motorola developed Six Sigma and deployed it in 1986, as an alternative to the Japanese kaizen approach to lean manufacturing made famous by the Toyota production system from the 1950s. It then spread through US automotive and manufacturing firms during the 1980s and 1990s. Financial firms have since applied Lean Six Sigma (LSS) to large, complex processes and products, and successful programs are associated with lower operating costs, better quality and greater efficiency, as reported by Delgado and Branco (2010).

The DMAIC cycle

Both Six Sigma and Lean Six Sigma run improvement projects through the DMAIC cycle: define, measure, analyze, improve, control. Its purpose is to locate the root causes of inefficiency in a process, product or service, and it works best in areas rich in data or in characteristics that can be measured.

Define sets out the process and the boundaries of the problem. Measure collects data on the process’s input and output variables. Analyze digs into the root causes of defects. Improve puts in place a plan that removes those causes. Control then watches the results through a monitoring plan so that the gains are kept rather than slowly lost.

Quality improvement and the PDSA cycle

Quality management dates from the 1940s and grew up mainly in manufacturing. Its model for improvement poses three questions: what is the goal, what would make a change count as an improvement, and which changes will actually produce one? The model is usually run as the plan, do, study, act (PDSA) cycle, also called the Deming cycle.

• Plan: set the objective for the product or service, decide the desired outcomes and how success will be measured, and settle what will be done, where, when and by whom.
• Do: carry out the plan, record problems and unexpected observations, and gather performance data.
• Study: analyze the data, compare results with the targets and predictions set in the plan, and identify where improvement is possible.
• Act: absorb what was learned, adjust the outcomes, metrics or process as needed, and launch the next cycle.

Repeating the cycle builds insight into how a product or service can improve. The approach is widespread in education and health care and is now used successfully in financial services.

Anything new in a business, whether a project, a product or an initiative, brings unfamiliarity and uncertainty, and those are fertile ground for operational risk. The standard mitigation is the New Product Approval Process (NPAP), along with its broader version for any initiative, the New Initiative Risk Assessment Process (NIRAP).

A new initiative is any new plan or process meant to reach a business goal or solve a problem that changes the way business is currently done. Three broad families are common, and each usually connects to a policy of its own:

• new financial products, services or activities for customers, which fall under the NPAP policy itself;
• outsourcing that is new, or a change to an arrangement already in place, which are also governed by the firm’s outsourcing risk management policy;
• new projects and restructurings, whether IT-based or not, which typically also fall under the project management policy.

The business case

Good practice requires the owner of every new initiative to justify the resources it needs with a business case. Whatever the initiative, the business case should address at least five topics, adapted to the needs of the particular project.

How involved the risk function should be

The riskier the project, the more the risk function is involved and the more mitigation is required. This risk-based approach can reuse the same rating methodology the firm applies to other non-financial risks. The everyday project risks, namely delivery quality, budget and time, are managed by the project team itself, without the risk function intervening, although a regular project report covering both execution risk and project risk goes to every stakeholder, the risk function included.

Beyond delivery risk, a new initiative can change existing risks or create new ones by disturbing business as usual. The danger is greatest when a new product, piece of software or process goes live and responsibilities pass to the operations team. At that point the ORM function should help the project team identify, assess and mitigate every direct and indirect risk the change creates. Projects rated critical or important, meaning those that materially affect the firm’s main functions, carry the highest risk rating and get priority.

Serious post-delivery work, meaning reviews, quality evaluations and debriefings, marks out more mature firms. Some keep a database of lessons learned so that mistakes are not repeated and successes are copied, and the risk function can start that collection or make sure it is used.

Mergers and acquisitions are the largest and most complex projects a firm can take on. As a rule, the buyer inherits all the credit, market and operational risks attached to what it buys, whether that is a portfolio, a subsidiary or a whole company, so the risk team faces a detailed and difficult assessment.

The different risks are not equally visible. Credit risk can be assessed reasonably well if accurate data exist on borrowers, collateral and contract terms. Operational risk is far less transparent, because it is the accumulated product of the people, processes and systems that created the assets over many years. These hidden problems behave like skeletons in the closet: they may surface weeks, months or even years after the deal closes. When the target operates in a geography or business line that is new to the buyer, the assessment needs extra care. ORM adds value here by building a risk profile from whatever data are available, so that management understands the operational exposures it is taking on in an unfamiliar business.

Integration risk

Once the deal is done, integration brings a fresh layer of operational risk. Merging customer and account platforms, payroll and management systems, and inter-company communications are all points of failure. ORM can surface these risks through risk identification workshops and then work with the integration team to put mitigation in place for the failures most likely to occur, including the contingency measures discussed in the next section.

A lender with excellent underwriting still expects some defaults and relies on collections and collateral sales to limit its losses. Operational risk works the same way: even with good preventive and detective controls, some events will happen, so corrective controls and other mitigating measures are needed to cut their impact. The main tools are contingency planning, resilience planning, and crisis management with its communication.

Contingency planning

Contingency plans are prepared courses of action that help an organization respond well to a significant future event that departs from what was expected. Put simply, it is Plan B: what the firm does if the expected result does not arrive. It forms part of business continuity, disaster recovery and corrective risk management more broadly, and it is the planning stage of corrective and directive controls.

A good contingency plan states clearly who does what, and when, once an incident occurs. It can be as small as a spare laptop kept in a cupboard or as large as a disaster recovery site ready for a terrorist attack in a city where the firm operates. In essence, contingency means building buffers, spare capacity and alternatives into systems, people and processes. Like insurance, it looks expensive in calm periods but proves central to resilience when things go wrong.

Business continuity and operational resilience

Business continuity management (BCM) and disaster recovery plans (DRP) are specific kinds of contingency planning. They matter most for operational resilience, meaning the ability to adapt and to recover mission-critical functions despite an adverse event. Critical infrastructure sectors such as water and energy supply, public services and health care have run BCM and DRP for decades. Financial regulators now give them close attention under the heading of resilience, and this matters most for systemically important financial institutions (SIFIs), since a long disruption to their services could spread across the financial system.

BCM is an ongoing process that coordinates a set of tasks aimed at keeping the business running if a crisis strikes. It makes a firm look at where it is vulnerable, decide which areas are critical, and plan to keep going through any catastrophe. Where the business continuity plan (BCP) is the document, the BCM structure is what keeps that document alive, current and ready to use. The plan must be tested regularly, so the firm knows it can be executed quickly and practically in an emergency, and it needs a clear owner responsible for designing and executing the actions, including communication with outside parties. If disaster strikes, it is senior management that the world will watch.

The stages of building a BCM program

The business impact analysis (BIA) is the hinge of the process. For each event it examines which processes are affected and how badly, and that determines the recovery time objective (RTO) for each. Part of the response strategy can be external insurance or contracts with crisis management specialists covering the technical, reputational or financial side. Smaller firms often find it cheaper to buy in providers offering financial support, technical help or external communication when disaster strikes.

A disruptive event triggers the business continuity plan, yet a crisis can hurt a firm, its processes and its people even when service never actually stops. Handling a crisis or a large operational event well calls for three qualities.

• Speed. Crises such as cyberattacks can spread within hours, so the response has to be fast, firm and proportionate.
• Competence. Every task should go to a qualified specialist, brought in from outside for communication or technical recovery if the skills are not available in-house.
• Transparency. Losing the trust of customers, shareholders, the board, regulators or staff can be fatal. Trust is earned and kept by telling the truth openly, even about large operational losses, whereas hiding facts or back-pedalling only feeds bad headlines.

Incident response teams

Fast reaction depends on thorough BCM. In a crisis, a firm should field at least two incident response teams. The technical or recovery team is made up of specialists who assess the incident and restore normal processing as quickly as possible: IT and security experts handle IT disruptions and hacking, and continuity specialists deal with supply chain problems and business interruption. The communication team, internal or external, handles the media and every stakeholder group, employees included; in large firms these teams usually have media training and prepared crisis communication strategies. A dedicated member of senior management should oversee both teams. In an emergency, sticking to the BCP keeps emotions from clouding judgment and leading to poor decisions.

BCP testing is standard practice and mandatory. It is most valuable when it also rehearses stakeholder management and communication, not only technical recovery. A war room simulation gives realistic practice: specialists in operational resilience stage an extreme operational event and watch how the firm responds and recovers.

The four phases of a major event

1. Crisis. In the first minutes or hours, the nature and scale of the problem become clear. Triggers range from cyberattacks and ransomware to a damaged building, violence, trouble at an operations site, or revelations about the firm that embarrass it, whether true or not.
2. Emergency response. Over minutes, days or longer, specialists assess the situation and quickly choose a course of action.
3. Recovery. Essential operations restart in recovery mode, within the expected time frame if the plan works. Two measures frame this phase: the recovery point objective (RPO) and the recovery time objective (RTO).
4. Restoration. The return to normal. Planning may start within hours or days, but after physical damage to premises or a major external disruption it can take far longer: two years after the first COVID-19 lockdown, many financial firms still had not reopened their offices and were working remotely.

The RPO is the amount of data, created or updated, that will be lost or must be re-entered after an outage. It is driven mainly by how often data are backed up, unless the back-up itself is lost or corrupted. The RTO is the longest disruption a process, system or service can tolerate, in other words the downtime the business can live with. For the key players in the financial system, regulators set a ceiling on the RTO.

Transferring risk can be a strong form of mitigation, but it has a price and can bring new risks, and some risks or their consequences barely move at all.

The main thing external insurance does is reduce the volatility of profit and loss. The firm pays a regular premium and in return is compensated, normally in cash, if a defined risk materializes. Errors and omissions policies are typical: they pay for some or all of the mistakes made by staff, such as fat-finger typing errors in equity brokerage, loss of information, or theft. Financial consequences are much easier to compensate than softer harms such as client detriment or damage to reputation.

Two conditions for insurability

Before buying cover, a firm judges whether the risk can be underwritten and whether a policy would truly mitigate it. Insurance tends to suit operational risks that meet two conditions. First, their likelihood and impact distributions are reasonably predictable and well understood, so an insurer can underwrite and price them properly. Second, both the exposure and its consequences can genuinely be transferred, so the policy really reduces the firm’s risk.

Premium against volatility

Then comes the trade-off between paying a premium and living with volatility. When risks are priced correctly, the premium will be about equal to the expected losses being insured, or higher, especially over long periods, because the insurer must cover its costs and earn a margin. So many large institutions cover small losses themselves, either through a captive insurance subsidiary or by simply absorbing the swings, and buy external cover only for very large events. They tolerate the limited volatility of small losses but will pay to avoid big swings in profit and loss. So insurance is most attractive for extreme tail events, such as cyber incidents, business interruption and major class actions; any potential loss large enough to threaten results is a natural candidate.

Insurance in capital and its limits

In the Basel standardized approach for operational risk capital, recoveries from insurers are subtracted from gross losses to obtain net loss amounts when losses feed into the loss multiplier. Even so, insurance is an imperfect transfer of risk. The firm remains exposed to whether the insurer can pay and whether it will choose to pay after the event. In the best case, the payout may still arrive months later, leaving the firm short of liquidity in between.

Whenever an activity moves to another operator, some risk moves with it. Outsourcing means contracting out some of a company’s tasks to another firm. Small firms commonly outsource their accounting, their digital marketing, the management of information and communications technology (ICT), or legal and HR administration. Banks and insurers outsource specialist work that sits outside their core lending or underwriting skills, such as running IT servers, cloud computing, call centers or data centers.

Specialized financial technology (FinTech) banks often mirror traditional ones: a traditional bank keeps credit decisions in-house and outsources parts of its ICT, while a FinTech bank tends to run its own platform and outsource credit risk decisions to specialists.

Does outsourcing reduce or increase risk?

The answer depends on what is outsourced, to whom and why. When a bank outsources mainly to save money, for example by moving call centers to countries where labor is cheaper, it takes on new risks from the new location and from weaker control and oversight in exchange for lower costs. In that case outsourcing is really a way of acquiring risk in return for higher expected operating margins.

The opposite case is outsourcing a non-core activity to a bigger and more capable specialist: handing payments and settlement to a larger, more secure provider, or moving data storage and maintenance to a top cloud provider whose security is stronger than anything the firm could pay for by itself. The service may well cost more than doing it internally, but the expected result is a net fall in operational risk.

Even then, outsourcing creates third-party risk, the exposure to control failures at the provider. The act of transferring is itself risky, and accountability cannot be transferred at all. That is why outsourcing is increasingly seen as risk sharing rather than true risk transfer. As with insurance, it shifts some types of operational risk but not all; reputational damage cannot really be outsourced, nor can insurance repair it.

Reputation is the value of the firm’s brand, rising or falling with its strategy, its behavior and the way it communicates. It is deliberately kept outside the definition of operational risk, because reputational damage does not come only from operational failures. Operational events, internal or external, can nonetheless hit reputation hard, so prevention and mitigation are needed to build a solid reputation and to respond quickly and appropriately when an incident threatens it.

Controls of every type play a part. Preventive controls and strategies build and maintain customer confidence, while detective controls, such as watching social media for customer complaints and following trends in system outages or refund requests, spot operational failures early and so limit their reputational fallout. Corrective controls protect the brand once an event has hurt customers or communities.

Building reputation day to day

Reputation has to be built continuously into everyday activity. Rewarding behavior that protects the firm’s name is good practice, for example gift vouchers for teams with the best customer satisfaction ratings or for operations teams that keep transactions running smoothly. A rarer but valuable practice is to reward, rather than punish, people and teams who report operational risks, near misses and undetected events themselves, since that can head off costly financial and reputational consequences.

Choices about shareholders, clients, staff and suppliers all shape reputation, and taking on the wrong type of client is one of the biggest operational risks many firms face, and the danger goes beyond regulatory non-compliance, legal exposure and the familiar questions of anti-money laundering and client identification.

The three Rs of crisis communication

When an incident strikes, corrective measures work best if communication follows the three Rs. Regret means acknowledging the incident and apologizing for it. Reason means explaining openly why it happened and what the firm’s own responsibilities were. Remedy means delivering a satisfactory solution that compensates stakeholders for the harm done.

Stakeholder analysis makes the response sharper, because stakeholders differ in importance and in how an event touches them, and the remedy has to fit each group. If a scandal hits a bank’s investment banking arm, the stakeholders to manage first are regulators, institutional investors and large corporate clients. Regulators matter greatly to financial firms, particularly large firms under heavy scrutiny, and a record of transparency, cooperation and respect towards them can be extremely valuable when the firm seeks approval for a merger or has to deal with an operational failure.

Reputation and resilience

Reputation and resilience reinforce each other. Constructive engagement with stakeholders builds up what can be called reputation capital, a reserve of goodwill that cushions the firm in a crisis and helps it absorb unexpected shocks; in turn, handling a crisis well strengthens reputation. Australian research by Tracey and French supports this: analyzing what senior executives told stakeholders in the annual reports of 10,582 Australian firms over 17 years, the authors found that a good reputation is itself a source of resilience, helping firms adapt to external difficulties and bounce back after a performance decline.

Well-handled crises carry an upside, as chances to learn and to stand out, because firms, like people, are judged by how they respond to adversity. One UK firm, cited anonymously by the Financial Conduct Authority, tells its teams, in effect, that people are defined less by the mistakes they make than by how they deal with them.

Capital One’s 2019 data breach shows both sides of mitigation. The bank had weak or missing controls that helped the breach happen, and the OCC later imposed a penalty for them. Yet the harm to customers and to the bank’s reputation was contained by corrective action and by communication that followed the three Rs.

Tokenization, a preventive control, capped the most serious harm, while failed detection let the breach run for months until an outsider raised the alarm. The attack came through the cloud provider’s side, yet Capital One carried the responsibility, which shows that outsourcing shares risk without moving accountability and that insurance can pay costs but not repair reputation. What protected the brand was the corrective response: prompt notification, an apology from the top, specific facts, and a tailored remedy.