How to Reduce Operational Risk in Banking

The 2018 Verizon Data Breach Investigations Report once again pointed to financial services organizations being a primary target for hackers. Although trending downward from 2015-2017, external actors account for 79% of breaches. Moreover, the August 2018 Fiserv security vulnerability highlighted the impact of operational risk and cybersecurity. As a payment processing vendor, Fiserv’s weakness is an operational risk for any banks using the system.

Control Operational Risk for Banks with Effective Workflow Management

Where Operational Risk and Cybersecurity Overlap

Data breaches last longer than the initial discovery. The costs associated with them can continue for two years or more. Unfortunately, current financial institution compliance requirements become outdated rapidly as cybercriminals continue to evolve their attack methods.

Every day, hackers look to find new, previously un-discovered vulnerabilities in systems and software, frequently referred to as “zero-day” attacks. These attacks put even the most secure system at risk. After all, you can’t secure something you don’t know is vulnerable.

Modern operational risk management must account for the risk of loss arising out of failed or inadequate internal business processes caused by both people and technology.

What Do Financial Services Organizations Struggle With?

Defining operational risk continues to challenge banks. In May 2018, the Board of Governors of the Federal Reserve System outlined three primary challenges facing financial institutions when attempting to calculate operational risk costs.

External losses

External data loss reporting remains a primary limitation for bank models. Although a few vendor datasets exist, most information available focuses on large losses and comes from publicly available sources, like news articles and financial disclosures.

Scenario analysis

A primary operational risk analysis approach incorporates bringing together a variety of stakeholders to estimate exposure. These workshops identify key risks and estimate potential frequency and severity. The external loss data limitations once more impact the ability to adequately evaluate cyber risks. Unlike the abundance of market risk historical data that enables a strong assessment, cyber risk remains elusive not just because the information isn’t available but also because the historical context is limited.

Business, environment, and control factors (BEICF)

BEICF, the catchall for other factors impacting operational loss exposure, often relies on subject risk control self-assessments that suffer from the external loss data problem. Others, like key risk indicators, lack standardization.

Where Basel 4 Fails

In 2017, the Basel Committee on Banking Supervision (BCBS) released its finals rules on operational risk capital. The new operational risk capital calculation implemented a Standarised Approach (SA) that will apply beginning January 1, 2022.

Basel 4 intends to simplify and standardize operational risk capital requirements to overcome the problems associated with the Advanced Measurements Approach (AMA). However, the new SA lacks the risk sensitivity factor because it incorporates a ten-year loss data capture requirement.

Basel III incorporated two types of risk sensitivity. Ex ante risk sensitivity focused on distinction arising out of individual exposures or transactions. Ex post risk sensitivity looked at risks that could only be assessed after a loss event occurred. Thus, cyber risk events and cyber risk appetite were difficult to estimate. Data limitations and the range of bank complexities created a challenge for determining ex ante risk. Meanwhile, since ex post risk requires an event to have occurred, this modeling lacked predictive powers since assumptions might fail.

Removing the risk sensitivity factor when creating the SA calculation ignores the potential impact that external events, specifically cyber attacks, have on operational risk. While KPMG noted that national supervisors might continue to push for banks to focus on mitigating operational risk arising out of cyber events, the official standardized calculation ignores the impact and removes the incentive for cyber risk mitigation strategies.

How Using a Security-First Compliance Approach Helps the Bottom Line

While Basel 4 attempts to standardize operational risk capital calculations, it fails banks by ignoring the interconnectedness between operational risk, legal risk, and reputation risk.

Traditionally, market risk, operational risk, legal risk, reputation risk, and credit risk were often independent of one another. For example, credit risk focuses on the potential that a borrower will fail to meet their credit obligations, such as loan and credit card payments. Banks could easily disaggregate credit risk from operational risk.

However, today, operational risk potentially impacts credit risk. A failed data control opens up the bank’s systems to cybercriminals who then steal identities. When the cybercriminal makes unauthorized purchases with the credit card, the customer no longer need to pay it back. Now, the bank has a credit risk exposure. If multiple customer credit cards were used, then the credit loss increases exponentially.

Those customers then sue the bank under a variety of cybersecurity and privacy laws. Additionally, the bank’s reputation lowers, leading to fewer deposits. Ultimately, a single breach impacts four of the five major capital risks, not just one.

Expanding the scenario to incorporate the increasing use of hacktivists and nation-state actors, the breach may impact more than a single targeted bank. Coordinated data attacks affecting a shared vulnerability through a shared fintech vendor could impact market risk as well.

Creating an Operational Risk Monitoring Workflow

Security-first compliance incorporates continuous monitoring of your data environment to mitigate the risk of an attack. With more vendors accessing banks’ information, financial institutions increase their risk of a data breach. A single zero-day attack across a shared vendor can impact institutions across the industry. To protect against this, financial institutions need to secure their environments and ecosystems.

As part of the security-first continuous monitoring and continuous compliance approach, organizations also engage in continuous auditing. Being alerted to threats is the first step. Responding to them to maintain compliance is the second step. Proving the threats were remediated is the third step.

ZenGRC enables continuous monitoring through a centralized dashboard. With real-time notifications, organizations can prioritize alerts and delegate risk management tasks. Continuous monitoring allows continuous compliance. Moreover, as a single-source-of-truth, ZenGRC creates an audit trail that enables continuous auditing to document the organizations can prove the effectiveness of their security controls and their remediation efforts in the event of a new security risk.

For more information about how ZenGRC can streamline your GRC process, contact us for a demo today.