Sensitive Payment Data: A Guide to PSD2, SEPA, and GDPR

Sensitive payment data (PSD2), SEPA, and GDPR: How do they interconnect?

The European Union and partner countries are leading the way in payments innovation with the Single Euro Payments Area (SEPA ) and the Payments Service Directive 2 (PSD2). These measures were created with the end goals of changing how currency is transferred within EU borders, as well as unifying and improving the efficiency of a federated financial network. Financial organizations and third-party vendors handle a tremendous amount of payment card data, as well as personally identifiable information (PII), so these regulations will overlap with aspects of the Global Data Protection Regulation (GDPR).

SEPA is Pushing the Boundaries on Payments

The SEPA framework is redefining how money moves between businesses, individuals, and financial markets. There are two primary instruments or agreements that currently exist under SEPA. As defined by the International Accounting Standards (IAS 32 and 39), a financial instrument is “any contract that gives rise to a financial asset of one entity and a financial liability or equity instrument of another entity.” The cash instruments include securities, loans, deposits, and payments that both a creditor and borrower (or sender and receiver) have mutually agreed upon to transfer. Then you have the derivative instruments, which include assets, indexes, or interest rates where a value is assigned from a core unit.

This framework translates into real-time payments with instant results. This requires that the payments must have 24/7 availability. Additionally, the new norm requires the immediate transfer of funds, which is irreversible, and immediate visibility on whether the payment was successful or failed. You can either be a payer or payee, and this extends to peer-to-peer (P2P), peer-to-business (P2B), business-to-peer (B2P), and business-to-business (B2B).

PSD and PSD2 Provide Legal Backbone

The original Payment Services Directive (PSD) was adopted in the EU in 2007 with the purpose of establishing a foundation of standard guidelines in regard to the transfer of digital money and payments in 30 European countries. A single market for payments was created, which gave SEPA a legal foundation. As the continued digitization of the financial sector evolved, though, new third-party services (fintechs, new digital banks, etc.) emerged, allowing financial institutions to offer new services to their customers.

Unfortunately, these new services fell outside the scope of PSD, so in order to maintain the legal foundation of SEPA, new regulation would be required. Enter PSD2, which has the goal of making payments more secure. This provides greater consumer security while pushing innovation to its boundaries, creating a greater level of fairness and, thus, competition for organizations of all sizes. This offers third parties a formal way to access customer data through financial organizations giving access to customer accounts through open APIs, so both consumers and organizations can use third parties to manage their finances. The third parties will now be licensed and regulated by PSD2.

Benefits of a Single System

Utilizing a single regulation, it becomes much more cost-efficient for financial organizations to operate across borders. Consumers will benefit from lower costs due to greater regulated competition, and third parties will be able to make payments for them. Surcharges for consumers will be banned, save for payments subject to interchange fee caps. With fraudulent payments, the consumer will pay no more than 50 Euro, where before it was 150 Euro. For both financial organizations and consumers, PSD2 will also reduce fraud for digital transactions, while enhancing the security of consumer data. Financial organizations are required to gain consent from consumers in handling their sensitive payment card data.

Authentication

PSD2 mandates strong customer authentication (SCA) each time a payment is created or a consumer accesses their payment account. SCA will require two or more elements via password, PIN, fingerprint, card authentication, or a unique authentication code for verification. The elements of the SCA will be determined based upon the financial organization or third party, but consent is required from the consumer. Consumer consent is a key focus of all EU regulations. Non-financial organizations will not be allowed to participate until 2018, so financial organizations have a little bit of time left to develop roadmaps and innovations for new processes, expand services, and discover new revenue streams.

Handling of Personal Data Creates GDPR Compliance

The General Data Protection Regulation was promulgated by the European Union to fortify and consolidate data protection for all individuals within the EU. GDPR replaces the Data Protection Directive 95/46/EC. The goal of the GDPR is to protect the personal information of all EU citizens and residents by setting standards for the collection, storage, sharing, transferring, processing, and management of various categories of personal information. It also addresses the export of personal information outside the EU. It is designed to standardize data privacy laws across the EU in order to “protect and empower all EU citizens’ data privacy and to reshape the way organizations across the region approach data privacy.” With the ever-growing threat of the theft of personal data, GDPR is one of the EU’s most important and impactful regulations.

GDPR protects the personal data of EU citizens, who are referred to within the law as natural persons or “data subjects.” Personal data is any information that can be used to directly or indirectly identify a data subject. This can be anything from a name, a photo, an email address, bank details, posts on social networking websites, medical information, a computer IP address, etc. Because organizations handle massive amounts of PII for their customers, SEPA and PSD2 increase the need for these organizations to also become compliant with GDPR.

Sensitive Payment Data (PSD2), SEPA, and GDPR: Changing the Payments Landscape

With the EU overhauling its payments infrastructure, how will the landscape of payments change? How will the secure collection of sensitive data impact organizations from a GDPR standpoint? Financial organizations will continue to answer the consumer call of faster, more efficient payments, which means these organizations will also need to enforce compliant handling, securing, and storing of payment card data and personal data.

Instant Payments Change the Landscape

PSD2 empowers consumers and organizations to use a third-party provider to manage their finances. These third-party providers can be fintechs who augment services to financial organizations or stand-alone providers, which means financial organizations will have to provide open API access to these third-party providers. These providers fall into two categories: Account Information Service Providers (AISPs) and Payment Initiation Service Providers (PISPs). AISPs will have access to the account of financial organization customers, and PISPs are the service providers that originate the payments on behalf of the consumer or organization.

An AISP performs analytics on spending patterns and summates sensitive data – all to gain greater business intelligence. Both AISPs and PISPs will be handling very sensitive data sets for both individuals and organizations, including payment card data, bank account information, first name, last name, and so on – basically, a treasure trove of PII to be used in a number of ways. This handling of PII causes these organizations to fall under GDPR compliance requirements. Before we look at GDPR, let’s look at the benefits of what both AISPs and PISPs bring to the table.

Big Data Enables Flexibility

For AISPs, data analysis requires the handling of PII for their customers. This allows organizations to act more rapidly on financial recommendations based on in-depth analytics. As a result, organizations will be able to continue to tailor the customer experience to create more services and greater transparency of the services, but more importantly, they will keep stride with consumer expectations. Meeting consumer expectations, as well as their financial needs with a positive experience guarantees greater retention. The flexibility to provide a better experience is not without its pitfalls. According to PSD2, FinTechs and Financial organizations are mandated to provide more consumer protection, lower potential fraud, and increased accountability. This has everything to do with how the sensitive data is ingested, handled, secured, and stored.

Monetization of Sensitive Data

Using the current sensitive data sets coursing allows financial organizations to build more efficient platforms, better services, and -most importantly- the ability to tailor the customer experience to exactly what the consumer wants. With GDPR, this data now must be handled in a secure and compliant fashion. One method to ensure the compliant handling of data is to pseudonymize it. Pseudonymization is defined in Article 4(5) of the GDPR as “the processing of personal data in such a way that the data can no longer be attributed to a specific data subject without the use of additional information.” If organizations do not pseudonymize data or handle it in a way that is otherwise compliant with the GDPR, it can be fined up to 4 percent of annual global revenue.

GDPR defines two primary roles for handling sensitive data: data controllers and data processors. Data controllers are subject to regulation regarding what PII will be handled, why the PII needs to be handled, whether the PII is handled in a GDPR-compliant fashion, and when third-party agreements may be utilized to handle the PII. Data processors can only handle the PII in the fashion that the data controller mandates and they can only utilize third parties for subprocessing as sanctioned by the data controller.

As both of these roles are defined, they come into play each time a transaction takes place where PII is required to execute and authenticate the transaction. In regard to PSD2, if a customer asks for it, a financial organization will have to provide access to a third party in order to facilitate payments, transfers, etc. This requires a bank to allow third parties access to its APIs.

ISO Compliance Has Gaps

Financial organizations have been using ISO (International Standards Organization) guidelines to help regulate the industry as a whole. The ISO/IEC 27000 class of standards was designed to make sure that organizations are keeping sensitive data sets secure, which requires that organizations manage the security of assets such as financial information, intellectual property, employee details, or PII entrusted by third parties. PSD2 is now requiring organizations to use the new ISO 20022 in APIs to define their data, so banks will open up their APIs to third parties for AISPs and PISPs.

The Regulatory Technical Standards (RTS) are not requiring financial organizations to standardize their API, given that they adhere to the ISO 20022 security requirements. The financial organizations must also provide free documentation to any third party who wants to use the APIs. With all of these regulations and standards, there are still major security gaps. Currently, ISO 20022 is very different from the conventional development of APIs in how it permits exceptions in the development of the APIs themselves. A prime example would be numerous forms of a given singular message being present at the same time and leading to the restriction of the message(s).

To further the potential issues, the vast majority of APIs use JSON for requests and responses, and ISO 20022 does not. Any time absolute standardization is not required for all organizations, it creates an expanded attack surface. Standardized APIs that are easy to maintain, adopt, and consume allow developers, architects, and technical writers to build upon the blueprint of the API to build safer and more secure experiences.

So What Does All of This Mean?

SEPA is the framework for sensitive payment data, PSD2 is the regulation backing the new payments framework, and GDPR is the regulation mandating that organizations protect the sensitive data of EU citizens. By regulation, PSD2 makes sensitive data sets available to third parties, and GDPR was created to make the data private. You can see where one regulation conflicts with another. However, every organization has a duty to their customers to make sure that all data being passed back and forth in their environments -business-to-business, business-to-customer, across international borders, etc.- is secure. GDPR puts that regulation into law.

GDPR and PSD2 have yet to be tested in courts, but they are setting the trends in how money and information associated with accounts or transactions can safely move between secure environments without exposing the consumer. Like any regulation involving sensitive data, it has everything to do with how the data is secured, transferred, and stored. ISO compliance, PCI compliance, GDPR compliance, and any other compliance-based initiatives are designed to keep organizations and individuals safe from data breaches.

Sensitive Payment Data (PSD2), SEPA, and GDPR: Solutions for Security and Compliance

According to the research 3rd Party Risks: The Cyberdimension, published by Deutsche Bank and Economist Intelligence Unit:

• Almost one out of five organizations (19 percent) don’t check whether their third-party suppliers use the same methods for identity authentication as they do.
• Almost all organizations in the survey performed internal penetration testing (92 percent).
• Only 38 percent of organizations require all of their third-party partners to perform penetration testing.
• One-third of organizations (33 percent) do not conduct external testing.

Simply put, global organizations are not performing due diligence to guarantee that their third-party vendors are safely and securely handling sensitive payment card data and PII. Even if they are GDPR-compliant themselves, organizations will be held accountable if their third-party vendors with whom they share sensitive data are not. It is therefore imperative for organizations to inquire and understand whether their third-party partners are handling sensitive data in accordance with appropriate technical and organizational controls.

Security Does Not Stop at Authentication

In regard to sensitive payment data and PSD2, the goal is to establish “strict security requirements for electronic payments and the protection of consumers’ financial data, guaranteeing safe authentication, and reducing the risk of fraud; the transparency of conditions and information requirements for payment services; the rights and obligations of users and providers of payment services.” This means that proper authentication and secure communication techniques must be in place within your organization and at any third-party partner with which you are sharing data. In addition, if you are handling any personal data, de-identification must be performed in order to maintain GDPR compliance.

De-Identification- Anonymization vs. Pseudonymization

According to GDPR Recital 26, anonymized data is defined as “personal data rendered in such a manner that the data subject is not, or no longer is, identifiable.” Although complete anonymization of data is very difficult to achieve, if all identifiable information is removed, and it is impossible to re-identify the data subjects, the storage and processing of the data is no longer subject to the GDPR. However, there are business requirements that prevent an organization from anonymizing all the personal data it controls in order for it to be useful. In these instances, organizations are encouraged to pseudonymize personal data.

The Road to Pseudonymization

There are generally two forms of pseudonymization: tokenization and encryption. For encryption, the parliamentary text requires that the “encryption key” necessary to identify data subjects be kept separate from the coded data and is subject to technical and organizational security measures to prevent inadvertent re-identification of the coded data. Tokenization, in contrast, requires no “key” and thus is an easier and more efficient method of pseudonymization.

Article 32 of the GDPR calls upon data controllers to implement a “level of security appropriate to the risk.” Tokenized data can potentially pose a much lower risk than a fully identified data set, thus reducing the level of difficulty in meeting this mandate. An organization can still effectively use tokenized/pseudonymized data sets in business processes, something that is not always possible when using encryption alone.

It’s important to understand that not all tokenization and encryption platforms are the same, so the type of pseudonymization platform you employ will also play into how GDPR determines if your organization is in or out of compliance. For example, if you are storing pseudonymized data along with personal identifiers within the same on-premises solution, you could very well find yourself out of GDPR compliance. The same would be true of a third party that shares the data. 

Additionally, the GDPR requires “data protection by design and by default” and specifically mentions pseudonymization in Article 25 as an appropriate control for demonstrating this intent. However, simply pseudonymizing personal data does not guarantee compliance with the GDPR. Much like with solutions for achieving PCI DSS and ISO compliance, implementation matters.

TokenEx is Prepared for Sensitive Payment Data (PSD2), SEPA, and GDPR

Tokenization and encryption are advanced forms of pseudonymization,. TokenEx’s tokenization and encryption solutions are well-recognized and accepted forms of pseudonymization, which makes GDPR compliance more affordable and much easier to accomplish. These are the same processes TokenEx uses to protect the private data of our clients worldwide -without a single breach or exposure- for over a decade.

The TokenEx Cloud Security Platform can be used to satisfy many of the compliance requirements of GDPR. As GDPR goes into effect, it is certain to change and be amended over time, so utilizing a flexible and constantly evolving cloud tokenization platform like TokenEx will assist you in your compliance and security endeavors for years to come.