Have you ever thought about what it would be like to open a bank?
Arguably, today it’s easier than ever to start a new bank. The popularization of internet banks and online banking means you no longer need ATMs, hard currency, vaults, physical branches, tellers, or security guards.
So why isn’t everybody just doing it?
It’s the regulations.
To run a bank, you’ll need to navigate a multifaceted, regularly shifting environment where regulations, laws, and standards are complex, demanding, and sometimes contradictory. Right off the bat, this requires a non-trivial effort to understand the legal intricacies, nuances, and ramifications of compliance.
Then, you’ll need to spend time and money ensuring the right tools and processes are put in place to ensure compliance with all requirements.
Let’s examine the many cybersecurity compliance hurdles financial institutions face.
Stringent cybersecurity regulations #
Imagine Huxley Credit Union is coming to a web browser near you. Here’s what you must comply with for cybersecurity if you start a local credit union doing business only in the United States:
Industry standards and frameworks #
To recap, all the above are just for cybersecurity. There will be other regulations to consider for the rest of the business — each with their own requirements and standards to meet.
Compliance is ongoing — and regulations change #
Setting up tools and systems to ensure compliance isn’t a one-and-done event either.
Compliance is a continuous process. And to make matters worse, regulations change — with the updated versions imposing new or altered requirements. For example:
- 2021: Clarifications on multi-factor authentication (MFA) and risk assessments.
- 2020: Updates on incident response, encryption, and vendor management.
- 2020: Version 4.0 released with updated requirements for encryption, logging, and vulnerability management.
- 2019: Updates in version 3.2.1 on incident response and service provider controls.
Regulatory language is open to interpretation #
Different interpretations of the language used in regulations can lead to additional costs or unexpected penalties.
Real-life example: Interpreting requirements
In 2003–2004, I led numerous secured email projects to help bring institutions into compliance with a new regulation. In particular, we had to ensure that all email communication between the company and its customer was secured.
All but one of my customers interpreted the regulation to mean they had to authenticate the recipients. It took additional cost and effort to maintain a database of email addresses and passwords, and support the forgotten password and password reset functionalities, but was deemed necessary.
There was one exception among my customers who interpreted the regulation more minimally. This company believed that the payload had to be encrypted in transit, but no more. Hence, we implemented a one-click, passwordless envelope.
I’m not aware of what’s happened since then. If it turned out that they were never in violation due to this interpretation, then many other institutions spent more time, effort, and cost than necessary for compliance.
How to define ‘material’? #
More recently, the Security and Exchange Commission (SEC) released an update stating:
“The new rules will require registrants to disclose on the new Item 1.05 of Form 8-K any cybersecurity incident they determine to be material and to describe the material aspects of the incident’s nature, scope, and timing, as well as its material impact or reasonably likely material impact on the registrant. An Item 1.05 Form 8-K will generally be due four business days after a registrant determines that a cybersecurity incident is material.”
How an institution interprets ‘material’ can materially impact cost and effort (pun intended).
A bank may expose itself to fines or penalties with a stricter interpretation of ‘material’. While with a looser interpretation, it may end up doing unnecessary work.
Unfortunately, regulatory deadlines typically apply to large swathes of institutions simultaneously. So you can’t wait to see how the agency judges your peers and then act accordingly.
Customer expectations shape what’s viable #
Even when — or especially when — financial institutions are expending significant effort on compliance, they mustn’t lose sight of the fact that their primary purpose is to service customers.
Borrowers and depositors come from all walks of life, with varying levels of tech-savviness and tolerance for hurdles to accessing and moving their money.
Compliance could be easier if banks could put more onus on customers. But if a bank required a retinal scan for each online banking login, customers would offboard in droves.
Following regulations would be less complicated if banks could spend a longer period undertaking certain processes. But if a bank took three weeks to vet a digital transfer, they would lose out to their speedier competitors.
Even the data doesn’t make it easy to comply #
Complying with these various regulations and requirements would be challenging enough if each bank had just a single database. But that is not remotely the case.
Financial institutions deal with millions, even billions of records, typically spread across several databases and systems: countless customers, accounts, transactions, financial instruments, and internal operations.
Transaction data, in particular, stands out as a data type with extremely high velocity. This makes it difficult to conduct any sort of real-time monitoring that regulations may require. Monitoring is made even harder given that the data is often unstructured (e.g. email messages) or binary (e.g. uploaded screenshots or Microsoft Word documents).
Compounding the problem, financial data often comes from legacy systems. Compliance when working with legacy data from legacy systems becomes drastically more difficult.
Real-life example: Making sense of Kafkaesque legacy data and systems
Several years ago, I was building a secured messaging system for a bank. They had three different types of global unique identifiers (GUIDs). (Yes, I realize that those aren’t truly GUIDs, but that’s what they called them.)
Even further back in time, the three different types of GUIDs had been pulled into a single denormalized table. A customer could have one, two, or three of these GUIDs, in any combination!
My code had to painstakingly examine other fields to see which GUID to use for which purpose, and to extract data from other systems. To make things more Kafkaesque, the GUIDs were called TBP, CIF, and UWN, and no one could tell me what the acronyms stood for.
Exchanging data with (many) third parties #
Let’s not forget that it’s not just the data stored in-house that needs managing in a compliant way. Banks are also responsible for ensuring data security and compliance when data is shared with or handled by third parties.
Here is a non-exhaustive list of third parties that banks typically interoperate with:
Ensuring cybersecurity compliance #
From keeping up with changing regulatory requirements to meeting customer expectations, and from deciphering ambiguous meanings to unpacking legacy data, cybersecurity compliance is a complex challenge for financial institutions.
They face a huge array of complicated and continually evolving regulations, laws, and standards on cybersecurity. Ensuring compliance with these requires a comprehensive and robust security program, including tools and processes to generate periodic reports or disclosures, processes to remediate any violations, and the staff to make it all happen.
And while all of this costs time and money, the costs of non-compliance — either through fines or cybercrime — are considerably heftier.
All of this is why you won’t, after all, see Huxley Bank in a web browser near you any time soon.
