Reimagining rights control in banking through privacy by design

Reimagining rights control in banking through privacy by design

[ad_1]

Banks are tasked with protecting customer data at all levels in a world that is becoming increasingly digital. Ramakant Mohapatra, Director of Privacy and Data Protection at EdgeVerve Systems Limited and N. Narasimha Prasad, Senior Director of Product Management and Strategy at Finacle, Share how the Privacy by Design (PbD) approach is key to managing data effectively and ensuring data privacy.

Data privacy regulations are taking effect in all geographies. So far, almost 137 out of 194 countries have enacted data privacy laws for business and society. It is imperative that every organization and individual understand the goals of these laws, their applicability, and ways to integrate them into business and individual lifecycles involving personal data. This can only be achieved through the privacy-by-design (PbD) approach, which is independent of country-specific privacy regulations and with minimal scope for local adaptation.

In the banking context, at first, it may seem like a daunting challenge to bring PbD principles to life across the bank’s application landscape with privacy technologies as system enablers. Taking a structured and progressive approach would help to achieve the desired result. The International Association of Privacy Professionals (IAPP) publication suggests a model that outlines two strategies to adopt. one is the process strategy – enforce, demonstrate, report and control. the other is the data strategy – separate, minimize, hide and abstract. This article describes one of the rights approaches used in banking, which addresses many of the needs required for separation, concealment and minimization strategies.

abstract privacy model

The abstract privacy model consists of two types of actors: threat actors who violate an individual’s privacy and those whose privacy could be violated. Any party that interacts with an individual or their information represents a potential threat. In the banking context, “customer” can be assigned to “individuals or subjects” and “bank personnel” to “domain/threat actors”. Therefore, according to the FAIR risk analysis, there is a possibility that “bank staff” (domain actor) violate the privacy of “bank customer” (individual) information.

Description of rights controls

One of the best known techniques to minimize risks is through “controls”. In the context of banking and bank staff as threat actors, it may be referred to as “rights checks”. At an abstract level, ownership must answer the question “Is this allowed?”. While banks have a well-defined rights scheme based on the ‘roles matrix’ and ‘need to know’ philosophy, it is neither sufficient nor adequate for PbD. However, the good news is that there are multiple mechanisms that can be applied in the context of PbD. One of them is featured here.

The question “is this allowed?” it can be analyzed at various depths, as described below.

Level 1 – Mastery Level: Is this activity allowed by the domain? In this category, the domain prevents certain operations regardless of the actors and subjects of the threat, for example, cash deposits in closed bank accounts.

Tier 2 (in addition to Tier 1) – Application Tier: Is this activity allowed for the application given by the staff of the given bank? Banks handle multiple applications and depending on the need, bank staff will have access to them. For example: retail banking apps, corporate banking apps, wealth banking apps, etc.

Level 3 (in addition to Level 1 and 2) – Functional level: Is this activity allowed for the function given by the staff of the given bank? Depending on the role of the domain actor, it will be entitled to certain functions of the given application. For example: bank account opening, cash deposit, address update, account statement printing, etc.

Tier 4 (in addition to Tiers 1, 2, and 3) – Data Tier: Is this activity allowed for data of given subjects by given personnel? Bank staff, who are the domain actor, facilitate banking operations by processing customer (subject) data. Therefore, this layer deals with access control related to customer data access/processing by threat actors.

Data level control and its gradations

Banks usually have well-defined rights controls up to and including level 3. These existing controls are independent of the subject and are not sufficient in the context of PbD. Therefore, banks must design level 4 controls. At the abstract level, these controls translate into the right to act on a given record, subclass of information, and attributes belonging to the given subject for the given domain actor and a well-established legitimate purpose with just means. This serves multiple PbD data strategies and can be referred to as “product-person-purpose” based controls in product schema design. The subject data level control can be designed in the following grades.

See more: The importance of data science for decarbonization rates in finance

Tier 1: domain entity level

Domain entities are the foundation on which transactions and operations are performed. Examples include accounts, customers, bank staff, corporate users. There should be ways to specify access control of domain entity records owned by the subject. For example, bank staff cannot access (view, operate, delete or transfer) other bank staff accounts. Only designated bank personnel may access and operate individual high net worth accounts based on the customer’s risk profile and current instructions.

Tier 2: domain entity subclass information

Each domain entity has a logical grouping or subclass of information, and it is not necessary to access all of that information for all operations. Regardless of the physical separation in the data warehouse of such information, there must be a logical separation and therefore controls must be implemented for the given legitimate purpose. For example, any bank account has several logical sets of information about contact, balance amount, transactions, owner, joint account, lien information, compensation information, etc.

Having permission to access a given bank account does not mean that access is allowed for all of your subentity’s information, but it should depend on the purpose and actor. For example, bank staff facilitating the payment do not need to have access to the nominee or transaction history. Likewise, those who process the subject’s change of address do not need to have access to the balance data.

Grade 3: Attributes of the subject file

In certain cases, an actor has access to the entity level and the entity sublevel, where access may not be required for all attributes. Here controls are required. For example, bank staff working on transaction history service requests have access to the bank account (entity) and transaction history (entity sub-level); they do not need to access all transaction history attributes, such as the current balance.

The procedure or operation can be facilitated in certain cases without the need to access the identifying data of the subject. Controls must be in place to hide such details. For example, to approve a loan, the approving officer needs to know the loan’s income, expenses, repayment history, industry segment, loan amount, duration, etc., but does not need to know the name. of the applicant, national identification or address, etc.

In combination, entity level, entity sublevel, and attribute level access to the given actor for the stated legitimate purpose work powerfully to manage the separate, minimize, and hide aspects of the PbD data strategy. Pictorially this can be presented as follows.

Keeping up with data privacy regulations

As described above, rights implementations are critical to achieving PbD. While banks may have sophisticated rights controls in application, role and context, these need to be expanded to the appropriate data level to ensure that only authorized domain actors can process subject data for the legitimate purpose and well established to maintain the data. privacy context and alignments and be responsible for actions.

Importantly, such controls need to be cohesive, binding, harmonized, and well integrated into your applications across controls and technical measures to have real impact as data privacy regulations evolve.

How are you adapting to new data privacy regulations to achieve privacy by design? Share with us on FacebookOpen a new window