Compliance and security: two problems that one data layer can handle for the global banking industry.
Database sector veteran David Walker outlines a way that banks can start to use data layer thinking to finally unify two sides of the same data coin.
We all know there’s a ton of data out there. By 2020, we’d already accumulated well over 60 digital zettabytes of the stuff—a crazy number that might reach 180 zettabytes by 2025. (In case you’re wondering, a zettabyte is a billion terabytes.) To operate successfully and be friction-free in multiple geographies, global financial service players need to manage and work with those billions of terabytes of data securely and accurately.
Increasingly, that means working in full operational compliance with local or regional data compliance regulation, such as the European Union’s GDPR or the Consumer Privacy Act of California. It also means parallel adherence to industry-specific regulations, like PCI DSS in the payment sector, FCA rules, AML legislation, and so on. That complexity goes up several notches when your share of the 80 zettabytes is across multiple countries, and you need to manage the processing of that customer information, as well as its storage. So, as a constant operational burden, all sizes of banks need to have structured support for a range of cross-border, multi-country data protection legislation, across horizontal and vertical axes. And let’s face it, you wouldn’t be going to all this trouble (and expense) unless you had to! Since it was introduced in 2018, GDPR cost Amazon 746 million euros and WhatsApp 221 million in 2021, and retailers like H&M 35 million in 2020—just a few names of the multiple organizations fined for breaching it (out of a very long list).
Big GDPR fines are one existental risk. So is potential cyber social chaos
Your risk management team don’t want your name on that list, nor on any other list of compliance sinners in any trading area. While a financial penalty on its own might not kill you off, failing to have the appropriate controls for the geographical locations you’re in could disable your ability to operate. In IT terms, we’re talking about data governance and geo-location. These should be a C-suite level item, though unfortunately they are often not. Just as puzzling is how, even today, cyber security is often seen as an after-thought.
Anyone with insight into how wild and scary things can get out there on the Internet will understand this. Indeed, cyber risk is now such a scourge that it might start fraying our already loosening social stability. The World Economic Forum’s new Global Risks Report 2022, summarises its latest Global Risks Perception Survey and stresses how cybersecurity threats are growing and indeed outpacing societies’ ability to effectively prevent or respond to them. “Attacks on critical infrastructure, misinformation, fraud and digital safety will impact public trust in digital systems and increase costs for all stakeholders,” it warns. “As attacks become more severe and broadly impactful, already-sharp tensions between governments impacted by cybercrime and governments complicit in their commission will rise as cybersecurity becomes another wedge for divergence, rather than cooperation, among nation states.” So, what links worrying about safely storing private customer records and staving off hackers? Surely, they are both important business processes, but operationally different at the workflow level? One is banking compliance or risk team-oriented, one is bank IT security team-oriented.
Actually, they are just two sides of the same coin: the currency of data. Not seeing it this way makes no sense at all.
Two very different profiles of people and reporting lines
Ultimately, compliance helps the business look after data. For security, it’s trying to make anything that happens around data as securely as possible. Structures like GDPR focus on always knowing where the data is, who is handling it, and whether it can be shared with somebody else. IT security is about where you put and protect that data, and the policies around it to ensure that only the right people can handle it and it can’t be accessed outside of those policies. So, if both are about data, why do we segment them? Simple: the org chart. Managers in the finance sector, but also beyond, consider it easier to deal with two different groups of specialists: compliance officers and the IT people.
We’ve ended up with two very different sets of people and reporting lines, even though this is all zeros and ones in databases. There’s also a cost to this split. Duplication and extra resourcing happen every day. Yes, the auditors are happy they know who to call to probe, and there usually isn’t an equivalent (maybe there should be?) for your security gaps. But why are two separate internal teams sitting on separate floors when there should be one common and strengthened data issue response team? Shareholders don’t see it, but they’re really double paying for two sets of data hygiene experts that should be just one line item.
Quietly, this is finally starting to change. Instead of parallel approaches, recent database industry advances mean there is just a way to unify compliance and security and achieve some real economies of scale and optimization of workflows. The basis for this shift is something that gives you 90% of what both sides need. This means you have to add on the other 10% as necessary. It’s the move to microservices and Web-based data and development thinking. What does that mean? It can only happen—and it’s admittedly early days—if the bank takes a more data layer-based approach. That’s a way to describe abstracting all your data challenges in one place and is only practicable if you have just one database for all your uses.
Time to unify compliance and security workflows into one
To be clear, I don’t mean Oracle here (great as that is)! I mean a fully cloud-based, secure, distributed database that is efficient working with the kinds of transaction loads your compliance work (also payments processing and so on) calls for, and also the bigger-picture and analysis demands the security task mandates. This is why GDPR and security couldn’t be in the same place until now. If you had to manage multiple business databases for every country with different solutions to sit on top of it, your agility as a business was always hampered. And cloud database architecture has now emerged that can be used for all these different needs, in different locations, and which also (handily) uses the lingua franca of business reporting, SQL. Oh—and it’s open source too, meaning immediate access to a wide range of helpful third-party analysis and visualisation tools.
Just as important is the geo-location angle. Imagine being able to run, safely, the same data engine in whatever compliance or data protection jurisdiction you need to. Storing data where it was created or has to be owned, but also fully empowered to work with it on a global scale. This can only really happen with a data layer, of course, as it means you are now concentrating on the data itself, not how you physically store it in your computers.
Add in support for agile development over waterfall and CI/CD (continuous integration and continuous delivery). Moving to one unified way of scalable and secure data management means all your business, legal and security targets can be met with one architecture. Doing this will lower costs, but also empower you to respond much more quickly to compliance change (which seems a feature, not a bug, of this area) and give you the manoeuvrability you need to fight the 24×7 war against malware and the rest.
Not unifying compliance and cyber security means continuing to pay for two separate teams, two separate development budgets, two parallel workflows and two sets of stakeholders and process owners who don’t know how much they’d achieve by collaborating.
Keeping compliance and security as parallel data in financial services focuses may have once made sense. Now, it just doesn’t. It’s time to bring them together, and make the data layer work for you and your customers.
