Video: Preparing applications for GDPR and open banking

Facebook’s poorly designed APIs allowed an app developer to collect the private data of more than 80 million (unaware) users, providing an extreme example of the insufficient attention to security in API design.

While the data Cambridge Analytica collected in the Facebook breach (likes, birthdays, etc.) pales in comparison to the personal financial and credit data accessed during the Equifax breach, both security slips have prompted governing institutions to take action. Deliberate steps to regulate data privacy and integrity are inevitable.

In light of both breaches and their resulting headlines, we decided to take a look at the General Data Protection Regulation (GDPR) taking effect in the EU on May 25, as well as implications of the Open Banking standards.

Specifically, we focus on how EU governing institutions have introduced two new seemingly conflicting regulations regarding data privacy and integrity: GDPR and PSD2 (Second Payment Services Directive). While GDPR is restrictive, PSD2 ushers in the new era of open banking.

While GDPR and PSD2 both originate in the EU, they should be top-of-mind for American and Canadian companies as well. After all, it’s only a matter of time before similar laws take effect in the US. Plus, compliance is required for any institutions with EU customers.

How should you prepare for this changed world? In this blog post, I will discuss GDPR and PSD2, and their ramifications for CIOs.

General Data Protection Regulation (GDPR) explained

GDPR is a data protection and privacy law for individuals in the EU. Taking effect on May 25, 2018, it will address the export of personal data outside of the EU. This regulation aims to give citizens and residents control of their personal data and to help enforce data security by design (e.g. pseudonymizing stored data). The stakes of noncompliance are high: fines could range from €20 million to four percent of a company's annual revenue.

Four functional requirements influence how apps and services need to be updated to remain GDPR-compliant:

  • Right of access: Apps must provide customers with access to their personal data and reveal how this data will be processed and/or shared.

  • Right to erasure: Apps must allow customers to request that all of their personal data be erased.

  • Data portability: People must be able to transfer their personal data from one electronic processing system to another. The data provided must be structured and in a common electronic format, such as XML, JSON, etc. A good use case would be an individual who decides to switch pension service providers while retaining historical performance data.

  • Breach notifications: A clause states that data processors must notify users of a breach within 72 hours of becoming aware of an intrusion.

Second Payment Services Directive (PSD2) explained

Since 2012, open banking has been standard in the EU. A new directive, PSD2 regulates payment services and payment service providers throughout the EU. Administered by the European Commission, it introduces new opportunities for market strategy, customer engagement, and digital experience design. PSD2’s open API requirements stipulate that customers be allowed to share their payment data with third-party processors, meaning bank APIs must allow third-party providers to access customer payment data. The result: these third-party providers (such as Amazon or Google) will be able to offer your customers additive services related to behavior intelligence, data aggregation, and more.

How should your company respond?

Data and app security need to become fundamental to the app delivery process. To ensure this, CIOs should ask themselves the following questions:

  • Are we embedding security and privacy best practices in our app design?

  • Are we leveraging microservice design to accommodate scalability requirements from third-party data processors?

  • Is our core banking ecosystem prepared for a transactional data model versus a batch-oriented one?

A few solutions include:

  • Providing security training to developers

  • Including a security advisor on the development team

  • Conducting comprehensive and regular code scanning and reviews

On the topic, below are some Devbridge blogs for further reading: