Banks are tasked with protecting customer data at all levels in a world that is becoming increasingly digital. Ramakant Mohapatra, director of privacy & 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 coming into force across geographies. Thus far, nearly 137 out of 194 countries have enacted data privacy laws for business and society. It is imperative for every organization and individual to understand the objectives of these laws, their applicability, and ways of embedding them into business and individual lifecycles involving personal data. This can only be realized through the Privacy by Design (PbD) approach, which is independent of any country-specific privacy regulations and with minimal scope of local tailoring.
In the context of banking, at the onset, it may appear a daunting challenge to realize PbD principles across the bank’s application landscape with privacy technologies as system enablers. Adopting a structured and progressive approach would help achieve the desired result. The International Association of Privacy Professionals (IAPP) publication suggests a model that outlines two strategies to be adopted. One is the process strategy – enforce, demonstrate, inform, and control. The other is the data strategy – separate, minimize, hide, and abstract. This article describes one of the entitlement approaches used in banking, which addresses many of the needs required for strategies around separating, hiding, and minimizing.
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 might be violated. Any party who interacts with an individual or their information represents a potential threat. In the context of banking, “customer” can be mapped to “individuals or subject” and “bank staff” to “domain/threat actors.” Hence as per FAIR risk analysis, there is a potential for privacy violation by “bank staff” (domain actor) for “bank customer” (Individual) information.
Understanding Entitlement Controls
One of the well-known techniques for minimizing risks is through “controls.” In the context of banking and bank staff as threat actors, it can be referred to as “entitlement controls.” At an abstract level, entitlement should answer the question, “Is this permitted?”. While banks have a well-defined entitlement schematic based on the ‘role matrix’ and ‘need to know’ philosophy, but it does not suffice adequate and sufficient for PbD. However, the good news is there are multiple mechanisms that can be enforced in the context of PbD. One of them is presented here.
The question “is this permitted” can be looked at various depths as described below.
- Level 1 – Domain level: Is this activity permitted by the domain? In this category, the domain prevents certain operations irrespective of the threat actors and subjects, for example, cash deposits on the closed banking accounts.
- Level 2 (in addition to Level 1) – Application level: Is this activity permitted for the given application by the given bank staff? Banks deals with multiple applications, and as per the need, bank staff will have access to them. For example: Retail banking applications, Corporate Banking applications, Wealth banking applications etc.
- Level 3 (in addition to Level 1 and 2) – Functional level: Is this activity permitted for the given function by the given bank staff? Based on the role of the domain actor, they will be entitled to certain functions of the given application. For example: opening of bank account, cash deposit, address update, statement printing etc.
- Level 4 (In addition to Level 1,2 and 3) – Data Level: Is this activity permitted for the given subjects’ data by the given staff? Bank staff, who is the domain actor, facilitates banking operations by processing customer (subject) data. Hence this level deals with access control related to customer data access/process by threat actors.
Data Level Control and Its Gradations
Banks usually have well-defined entitlement controls up to and including level 3. These existing controls are subject-agnostic and not sufficient in the context of PbD. Hence banks need to design Level 4 controls. At the abstract level, these controls translate to the entitlement to act upon a given record, sub-class of information and attributes belonging to the given subject for the given domain actor and well-stated, legitimate purpose with fair means. This serves multiple PbD data strategies and can be termed as “product-persona-purpose” based controls in design of product schematic. The subject’s data level control can be designed in the following grades.
See More: The Importance of Data Science for Decarbonization Rates in Finance
Grade 1: Domain entity level
Domain entities are the foundation on which transactions and operations are conducted. Examples include accounts, customers, bank staff, corporate users. There should be ways to specify access control of the domain entity records owned by the subject. For example, one bank staff cannot access (view, operate, delete or transfer) another peer bank staffs accounts. Only nominated bank staff can access and operate high net-worth individual accounts based on the customer’s risk profile and standing instructions.
Grade 2: Sub-class info of domain entity
Each domain entity has logical grouping or sub-class of information, and not all that information needs to be accessed for all the operations. Irrespective of the physical separation in the data store of such information, there needs to be a logical separation, and hence controls must be implemented for the given legitimate purpose. For instance, any banking account has multiple logical sets of information on contact, balance amount, transactions, nominee, joint account, Lien information, clearing information etc.
Having the permission to access a given banking account doesn’t mean that the access is allowed for all its sub-entity information, but it should depend on the purpose and actor. For example, the bank staff facilitating payment need not have access to the nominee or transaction history. Likewise, those processing address change of the subject need not have access to balance details.
Grade 3: Attributes of the subject’s record
In certain instances, an actor is given access to entity level and entity sub-level, where access may not be required for all attributes. Controls are required here. For example, bank staff working on service requests related to transaction history have access to the banking account (entity) and transaction history (entity sub-level) they need not access all attributes of the transaction history like running balance.
The process or operation can be facilitated in certain instances without needing to access the subject’s identification data. Controls must be in place to hide such details. For example, to approve a loan, the approving officer needs to know the income, expenditure, history of loan repayments, industry segment, loan amount, duration etc. but need not know the applicant’s name, national id or address etc.
In combination, entity level, entity sub-level and attribute-level access to the given actor for the stated legitimate purpose work powerfully to manage the PbD data strategy aspects of separate, minimize and hide.
Keeping Up with Data Privacy Regulations
As described earlier, entitlement implementations are instrumental in achieving the PbD. While banks may have sophisticated entitlement controls across the application, functions, and context, these need to expand to the adequate data level to make sure that only authorized domain actors can process the data of subjects for the well-stated, legitimate purpose of keeping data privacy context and alignments and being held accountable for the actions.
Importantly, such controls must be cohesive, binding, harmonized, and well-integrated into their applications through technical controls and measures to be truly impactful as data privacy regulations evolve.
This article was previously published in Spiceworks.
