Open banking requirements add complexity to protecting customer data. Banks need to juggle the complexity of keeping customer data safe and adhering to privacy requirements and expectations — while also sharing data with authorized institutions. These regulations also inform the software development process, which must implement ever-increasing functional capability and efficiencies while adhering to the prescribed directives. The question is, how?
Software development efforts are not conducted independently of regulatory requirements. While ultimately banks must ensure that customer data is not stolen or altered in the process of sharing and that customer privacy is not compromised – violations can risk a bank’s reputation and incur financial penalties from regulators – there is a clear need for developers to contribute significantly to better privacy engineering standards.
Guidelines for privacy engineering for developers
“Privacy by design,” an essential part of the GDPR, calls for privacy to be taken into account throughout the application development process. This is just one example of why developers should proactively embed privacy considerations in the design and development of applications.
The following are questions that software developers, architects and others involved in the development process may consider when handling customer data to provide acceptable levels of privacy:
- What customer data will the bank share with other parties?
- Can the customer expect or anticipate a transfer of his data to other parties?
- Is customer personal data adequately protected (with encryption, etc.)?
- Is the data storage transient or persistent?
- Are there secondary uses of the data that the customer may not foresee?
- Is there a way to minimize the processing of customer data by delegating the pre-processing on the client devices?
To answer these questions, developers need to understand customer data’s level of:
- Affinity (in context with the application)
Let’s examine each of these attributes.
Data sensitivity is the control of access to data that might result in loss of an advantage or level of security if disclosed to others. Data sensitivity can be classified as follows:
- Highly sensitive: anything with legal, contractual or ethical requirements for restricted disclosure such as credit and debit card and banking account numbers.
- Moderately sensitive: data that a customer may not wish to disclose, such as their date of birth, home address or phone number.
- Low sensitivity: data that anyone can find in public records or platforms and websites in online directories.
Data visibility describes the exposure of a data item by default once the customer discloses it to the application. Data visibility can be classified as follows:
- Highest visibility: this is data visible to anyone with access to the application. For example, a customer name in a funds transfer transaction or the payment method.
- Moderate visibility: data that is visible to the customer, or depends on the customer’s privacy preferences. For example, the last four digits of a credit card number.
- Low visibility: data that is only visible to the application. For example, a customer’s PIN.
Data affinity describes how a data item is bound to the functionality of the application and it can be classified as follows:
- Highest affinity: data that, in its absence, will not permit the application to perform its desired goal. Therefore, the item is essential for the primary functionality of the application.
- Moderate affinity: the data could add additional functionality to deliver more value from the functionality.
- Low affinity: the application will still be able to function without this data.
These data classification categories can guide and enable software developers to implement data protection in their applications, ensure customer data is protected from unauthorized access or disclosure, and enhance privacy engineering.
Developers can help significantly reduce privacy risk by controlling the sensitivity, visibility, and affinity of data within applications. When data is less visible in a system, the risk associated with loss is reduced, suggesting that developers should use only the necessary data (i.e., higher affinity) for the applications. Data privacy regulations such as the GDPR also emphasize and echo this requirement.
Open banking is an inevitable component in the shift to true digital transformation in the banking sector. By deploying a flexible, interoperable open banking environment, organizations can adhere to regulatory compliance requirements and create a platform for ongoing innovation and revenue generation.
Red Hat’s open, modular framework enables an agile, effective, and security-focused infrastructure that can help financial institutions adapt as business and industry change. Learn more.
About the Author:
Fadzi Ushewokunze, Global Architect – Financial Services, Red Hat
As a Global Principal Architect for the Financial Services vertical, Fadzi Ushewokunze steps in with innovative initiatives that help global corporations recalibrate to optimize their processes and reach their target customers, efficiently and with powerful business outcomes.