Are Banks on a Collision Course with Data Privacy Laws?

While data is increasingly a company's most significant asset, whose data is it anyway - the company's or the customer's? The complexity of this question can be seen in the conflict between national data privacy laws and the global enterprises that wish to move data and information across the borders of the many countries they operate in. Enterprises need a systematic approach to data privacy that will help them navigate these difficult issues.

Karl Marx foresaw the rise of massive global capital structures when he was plotting revolutions in the early 1800s. He ultimately foresaw them leading to the withering away of the national state. Like many of Marx's prophecies, he was right in some things but wrong on others. Where he is wrong continues to pose major problems to those super national, global capital, structures, such as universal banks, that have been built over the last few decades and the regulators attempting to corral them.

Many countries, highlighting the ongoing importance of national sovereignty issues, have put laws in place that make it potentially illegal for entities, say banks with branches in different countries, to share certain types of information between those branches, particularly when the information is moving cross-border. The type of information potentially subject to such restrictions ranges from any sort of personal identifying information to data of a more sensitive nature. While business logic drives global banks and their like to want to share, aggregate and leverage customers' data wherever it is from, they come across significant obstacles to them in doing so, when locating operations in countries with strong data protection laws. Such countries fiercely protect the rights of their citizens to maintain the privacy of this data. They generally do not trust other countries' laws to protect those rights, hence, they seek to stop data from leaving their borders. The cultural gap between the importance attached to privacy rights say in Europe versus the US, can lead to a tendency amongst US decision makers in both the private and government sectors to overlook the importance of the issue in Europe. In fact the penalties for failure to comply with privacy laws can in the case of many countries be very serious indeed, including lengthy periods of incarceration for the offender.

No large bank today, however, can manage its business without moving data cross-border and so this issue should be front and center of any bank's IT, data and compliance architecture programs. First, a global privacy office is required to ensure the Firm has a real time understanding of the privacy laws in each operating country and the know how required to apply this understanding to real use cases: anti-money laundering, CCAR, use of biometric data. Second, privacy requirements should be built into the upfront design of operating models and global IT systems not as an afterthought. On the business side this means building consent into customer account agreements governing the use to which customer data will be put. On the system side, this means incorporating data privacy questions into the system's design methodology. What typically happens, however, is that those tasked with building new global systems will come to the issue of data privacy at the last minute. This can set off a series of incoherent and poorly planned interactions between data privacy compliance officers and system developers. In these interactions, several problems can occurr. First, the bank's data privacy office can be seen as blocking progress when significant time is needed to address their real concerns. Second, in dealing with data privacy at the midnight hour, something may get sacrificed, be it privacy's requirements or some of the goals of the system.

These problems can be avoided if the privacy issue is part of the bank''s system's design and architecting methodology. First of all, having a data classification schema that distinguishes clearly between personal identifiable information and other types of date, less subject to privacy concerns and laws, for instance, is critical. Second, the lineage of the data, its physical origin and destination, any staging or enhancement points en route, need to be clearly understood to ensure the privacy requirements of each location are understood. Third, it is important to understand who are the users of the system: where are they located: what is their role and how are they interacting with the data. Fourth, the purpose to which such data is put should be understood, since purpose can matter in determining the extent to which the information can be shared. A regulator or law in different countries may carve certain exceptions for certain purposes such as identifying criminal activities or fulfilling a regulatory requirement. It is important to understand whether the system's purpose will fit with one of those exceptions and how this may change the requirements.

In planning for the future then, international banks and other global private entities need to ensure that they do more than pay lip service to the laws of these sovereign states. Putting privacy front and center into the system design methodology, corporate compliance and contractual language will be important factors in doing so and will go some way towards assuaging regulators concerns.