IAPP CIPT – GDPR and Payment Services Directive (PSD2) Part 3

9. Other challenges – GDPR and PSD2

Hi guys. In this lesson, we’ll discuss again about other challenges between PSD Two and GDPR. Seemingly unconnected, these two regulatory initiatives do in fact share two common aims putting customers in control of their own data and keeping that data safe. Both GDPR and PSD Two are built on the principle that individuals own their personal data and should therefore be able will to choose how it is used and with whom it is shared. However, once one moves from the high level principles to implementation, the challenges of reconciling the details of each regulation quickly become apparent. In our view, if left unattended, these challenges have the potential to jeopardize the successful implementation of PSD Two.

This lesson focuses on two key issues determining who is responsible for obtaining consent from customers to allow banks to share their permit data with third party providers TPPs under PSD Two and determining what constitutes sensitive payment data. Customer Consent as explained previously in the course, under PSD Two, TPPs will be able to access customer’s payment account information directly, provided they have the customer’s explicit consent and use banks infrastructure to facilitate provision of payment initiation or account information services.

In principle, this maries perfectly with the right to data portability introduced by GDPR. But in practice, the key question about which party should obtain the customer’s consent is currently unanswered. Under data protection regulations, banks are the data controllers of their customers ‘information and are responsible for the purposes and the manner in which personal data is processed and shared. Under GDPR’s guidance on portability, data controllers are responsible for implementing safeguards to ensure that they genuinely act on the data subject’s behalf.

PSD Two adds additional data protection requirements by stating that TPPs are only permitted to access information for the specific purpose explicitly requested by the customer relating to the provision of the account information or payment initiation services. Considering these interactive requirements, we believe that while TPPs will likely initiate the process of securing customers consent, including consent for their own activities and use of the data, once obtained, banks will ultimately remain responsible for confirming or otherwise separately obtaining the consent directly with their customers. This will probably include confirming details such as the identity of the TPP customers wish to share data with, what data they wish to share, how frequently, and when such consent will expire.

Such a two part process, first to obtain and then to confirm consent, has the potential to provide greater protection to TPPs banks and customers than banks relying solely on the consent provided by the TPPs. Sensitive Payment Data the current draft Regulatory Technical Standards RTS on Strong Customer Authentication SCA and Common and Secure Communication SC under PSD Two states that banks will have to provide account information service providers with the same information available to customers when directly accessing their account information, provided that this information does not include sensitive payment data and helpfully.

Neither the RTS nor PSD Two primary legislation defines sensitive payment data. The RTS states only that it includes all data, including personalized security credentials, which can be used to carry out fraud, but leaves it at the bank’s discretion to determine which data they consider sensitive. GDPR defines personal data and therefore protects as any information relating to an identified or identifiable natural person who can be identified directly or indirectly, including by reference to an Identifier, such as a name, identification number, location data, online Identifier, or other factors, including the economic identity of natural person. This lack of clarity on what constitutes sensitive payment data creates challenges for interpretation and implementation and increases the risks of noncompliance.

Without further guidance, banks may need to take a very risk averse approach and redact all data that could possibly fall into the sensitive data category. In order to avoid breaching rules around data protection both under PSD Two and GDPR. Further guidance is urgently needed from both European Union and national regulators on how firms can reconcile the requirements under PSD Two and GDPR, both in the interim period and thereafter, with GDPR introducing a new maximum monetary penalty of 4% of annual global turnover for breaches.

The continued lack of such guidance may lead some banks to give GDPR compliance greater priority over PSD Two. In all likelihood, this would lead to severe limitations on TPP’s access to data and very strict interpretations of consent. This, in turn, would make third party services more difficult to use and less beneficial to consumers. It would also put a dampener on the open banking movement and reduce the effectiveness of regulators efforts to increase competition and innovation in the payments market. In the meantime, firms should avoid considering GDPR and PSD Two implementation programs in Silos, but instead ensure they are coordinated and take into account each other requirements.

10. What is Open Banking Consent Model

Hi, guys. In this lesson, we’ll discuss about open banking consent model. In response to the Competition and Markets Authority’s order, the open banking implementation entity called Obie has developed application programming interfaces APIs to support services that will be offered by account servicing payment service providers ASP PSPS and third party. Providers TPPs these APIs underpin the open banking consent model, the process by which a payment service user PSU also referred to as the customer, gives their consent to a TPP to initiate payments or access account information and transaction data. In order to engage in open banking through the use of the Banking Read Write APIs, participants are required to follow a common three step process of consent, authentication and authorization known as the Open Banking Consent Model.

This model was created through extensive research on preferences of the PSU, relevant regulation, and existing practices between PSU and payment service providers. The three step consent model can be summarized as follows consent is the process by which a PSU gives a TPP permission to approach their ASPSP. In order that the TPP can be granted access to the PSU’s account to provide the service to the PSU, the TPP will request explicit consent from the PSU in order to initiate payments or access information from the PSU’s account. There could be a number of elements associated with this consent request depending on the service being offered. At this stage, the PSU will be required to identify their ASPSP that they want to use for the service offered by the TPP.

Once the TPP has gained the PSU’s consent, the TPP will send a message to the ASPSP confirming the elements of the consent that has been obtained from the PSU and requesting access to the PSU’s account. The PSU will then be redirected to the ASPSP for the authentication step. Authentication is the process by which an ASPSP verifies the identity of the PSU. For example, when the PSU logs into their online account with the ASPSP, the authentication step takes place in the ASPSP domain and allows them to verify the identity so that the TPS’s request can be serviced appropriately. The ASPSP will choose the method by which they authenticate the PSU.

Authorization is the process by which the PSU confirms that the ASPSP may respond to the request from the TPP to whom the PSU has given consent. Once the PSU has verified their identity via authentication, the ASPSP will then present the PSU with a description of the access request, confirming all elements of the consent that the PSU previously provided to the TPP. The PSU will then authorize the ASPSP to fulfill the request from the TPP. Once the PSU has authorized the ASPSP, the PSU will be redirected back to the TPP’s domain and their connection to the SPSP will be closed. Once back in the TPP’s domain, the PSU will continue with the service that TPP is offering. Depending on the products or services provided by the TPP, they may need access to a number of the PSU’s accounts. In the event the PSU has accounts at multiple ASPs, the authentication and authorization steps will be repeated for each ASPSP.

11. Consent Step

Hi guys. In this lesson, we’ll discuss about the consent step. Overall, the customer preference is to explicitly opt in, avoiding the option of having to explicitly opt out. It should also be made clear at the point of requesting consent how consent may be revoked by the customer account information. Consent Request The customer research has indicated that customers are concerned about the level of data a TPP might request and whether it is absolutely necessary in order to provide a product or service.

Therefore, TPPs should request the minimum data they require to provide a service to the customer. TPPs should explain for what purpose the data is needed and how it will be used. The use of standardized data clusters at the consent step AIDS trust and familiarity and is discussed later. Payment Initiation Consent Request It is recommended that when consent is requested, it explicitly mentions that the payment is a single one-off payment and it will be submitted to the bank for execution after authorization. Combined Consent Request A TPP may also want to use the consent step to request additional consents.

They may be needed to support their business model. The TPP may choose to request all the consents in one combined consent request. The challenge for a TPP using a combined consent request when requesting data from multiple data sources is striking the balance between the level of information provided to obtain the required consent and the good customer experience. Regardless of the complexity of the combined consent request, the elements that relate to the Open Banking API enabled product or service must be explicit, informed, and time bound.

There are some guidance on how a combined consent request may be structured. Group together similar elements to make it easy for customers to understand present only the grouping titles for readability and avoiding clutter. Provide explicit antique opt in checkboxes per grouping title to ensure customers consent to each grouping. Allow individual groupings to lead to more detail through expandable sections or other overlay popups that provide more information. Provide two choices of equal prominence at the end cancel and confirm.

• Category: Uncategorized