Home » Archieven voor Gert-Jan Kroese

Auteur: Gert-Jan Kroese

PART 1 – XS2A and Consent

Is your organization reluctantly getting ready for PSD2? Or, are you jumping with excitement ready to dot the I’s on your Fintech/PSD2 business plans? Either way, if you’re in the financial services industry, it’s likely your organization is going to introduce, or face, new and innovative services that require the use and exchange of personal data. Services that are governed not only by PSD2 but also by GDPR, the EU privacy framework.


If you’re aware of the key motives of PSD2 and GDPR you can skip right to the next bit. For a bit of a refresher, here’s a 2 penny summary.

PSD2 is an EU directive that aims to promote safer and innovative digital payment services, reduce cost of financial transactions and strengthen consumer rights. The two sections of PSD2 that have attracted most debate are the obligation for banks to grant third parties access to transactional information otherwise known as XS2A (access2accounts) and strong authentication requirements for payments. These two parts of PSD2 introduce obligations for financial institutions that require the handling of personal data.reconciling PSD2 and GDPR in 5 easy steps

This is where the General Data Protection Regulation (GDPR) comes in. Its the new, and very strict, EU data protection framework that also applies to handling of personal data as required by PSD2. The key motives of the GDPR are to keep personal data safe and to reinforce the rights of data subjects by giving them control over their own data. All organizations that are active in the EU or are in the business of processing personal data of EU citizens, have to comply with the GDPR. Non- compliance can lead to fines of up to 4% of an organization’s annual worldwide turnover, or 20 Mio EUR, whichever is more.

GDPR and PSD2 both aim for better consumer protection. But at the same time as PSD2 requires open access to transactional data, GDPR introduces increasingly strict obligations to keep these data safe and ensure that consumer rights are met. In short, if you’re getting ready for PSD2, make sure that whenever you’re dealing with personal data, you also comply with the GDPR.

XS2A & Consent

Banks and payment service providers hold transactional data. Data that are carefully shielded as business assets, and are kept safe in accordance with regulatory requirements such as privacy laws. Following XS2A, third party service providers will gain access to these sensitive personal data. PSD2 however also provides that Payment Service Providers (PSPs) may gain access, process and store personal data only with the “explicit consent” of the customer. To understand what “Explicit Consent” means, and how PSPs can obtain valid consent from their users, we have to turn to the GDPR. The GDPR lists the following requirements for valid consent:

1 - active consent

The GDPR requires “a statement or a clear affirmative action” that signals the customer’s agreement to a certain data processing. Meaning, the customer has to actively do something to let you know they agree to what you are about to do with their data. Good examples are ticking a box stating they agree with the processing, or choosing technical standards for a service (e.g. cookie settings). “Opt-out” mechanisms, pre-ticked opt-ins, or implicit consent deducted from silence, are not allowed.

step 2 - freely given

Consent must be freely given. If the customer has no genuine or free choice or is unable to refuse or withdraw consent without detriment, consent is not considered “free”. For example, as a condition to use a payment service, the PSP requires a customer to agree that their personal data may be used for purposes completely unrelated to the delivery of that service. Any such “bundled” consent is considered to be given under undue pressure, meaning, not free. Also, any consent given in the context of an interaction where there is a clear imbalance of power (e.g. employer/employee, doctor/patient, public authority/citizen) is not free.

3 - granular

The PSP must provide granular options for obtaining consent separately for different processing operations and different purposes. This means that if a PSP wishes to use personal data for purposes other than those necessary for the execution of the payment service, it should get separate consent for each of those purposes.

step 4 - specific & informed

Prior to the processing of personal data, you should provide the customer with sufficient information that enables them to understand what they are consenting to. This means that the purposes, the scope and the consequences of the data processing as well as the identity of the data processor and the rights of the customer (see part III of these series) should be specifically described and communicated to the customer. The communication should be done in an easily accessible form –don’t hide it in general terms and conditions-, and in plain and clear language that can be understood by your target audience. Consent cannot be given for vague, or open ended processing activities. For example “we will share your data with carefully selected partners for marketing purposes”.

step 5 - compatibility original purpose

Once you’ve communicated your purposes of personal data processing and received consent, you may not use these data for other purposes that are not compatible with the original purpose. To understand if your original purpose and your new purposes are “compatible” you may ask yourself: based on my communication, would the customer expect me to use their data in this way?  If not, you will need separate consent (see: granular consent).

step 6 - demonstrate consent

The GDPR does not prescribe any specific way in which consent must be obtained, or administered, but it does put the burden of proof on the PSP. The PSP must be able to demonstrate consent. This means that the PSP will have to keep records of their own communications, as well as the obtained consent. As there is a clear potential  for disagreement on whether or not valid consent for payment was obtained, you may have to think about double opt-in (e.g. via e-mail confirmation of the consent) or other technical mechanisms that provide such proof.

step 7 - children

Personal data of children are especially protected. They may be less aware of the risks and consequences of the processing of their personal data. Ensure that you amend your language in communications to children so they can understand what they consent to. Depending on national legislation on the age limit for “children” (13-15 years), you need to get the consent of the parents as well.

step 8 - consent withdrawal

Customer’s have the right to withdraw consent at any time. PSPs must inform customer’s on how they can withdraw consent.  Unless there is some other legal basis for the data processing, organizations must discontinue the data processing going forward.

For a full self-assessment of your organizations compliance with all requirements under the GDPR and practical tips on how to remedy any privacy non-compliance, please check out our Accelerator software tooling. Accelerator privacy softwareFor more information or a complimentary Accelerator demo, please contact us at: info@privacyvalley.com.


This contribution has been made in conjunction with competition attorney Emilie van Hasselt of Van Hasselt Law who can be reached at  emilie@vanhasseltlaw.eu.

Kinderen op TV en de BSN berg

Stel, je kind mag na jaren zeuren als publiek meedoen aan een populair kinderprogramma, het is nog live ook. De weken vooraf meldt de redactie zich. De omroep selecteert streng op naam, leeftijd en Burgerservicenummer (BSN). Wat doe je? Geef je het BSN af terwijl je weleens gehoord hebt dat dit niet zo maar gebruikt mag worden?

Gebruik van BSN is maar beperkt toegestaan, er moet volgens de Nederlandse privacywet een wettelijke reden zijn. De Inspectie SZW (voorheen de Arbeidsinspectie) handhaaft de Arbeidstijdenwet die zegt dat kinderen onder de 13 jaar niet mogen werken tenzij er een ontheffing is van de Inspectie, en dan alleen als er sprake is van ‘cultureel werk’. Een goede verificatie van de kinderleeftijd kan alleen via het Burgerservicenummer. De Arbeidstijdenwet geeft de Inspectie expliciet de bevoegdheid om het BSN op te vragen en te gebruiken. So far, so good!

Maar hoe zit het met die omroepredacties die regelmatig een lijstje deelnemers moeten uploaden bij de Inspectie? Waar bewaren zij al die kinderdata en gebeurt dat veilig? Kan het zijn dat er “ergens in een map” e-mails en printjes bewaard worden met data van duizenden kinderen die ooit een keer in het publiek hebben gezeten van een televisieprogramma? Wordt die data ooit opgeschoond, wie controleert dat? Of bewaren de redacties dit liever “voor het geval dat”? Dat zijn allemaal privacyvraagstukken.

Het uitzoeken en controleren van deze vragen is een taaie administratieve klus. Toch zijn organisaties verplicht dit te weten en registreren. Organisaties die met kinderdata werken worden geacht extra zorgvuldig hiermee om te gaan. Een goed bedoelende freelancer met Excel op de laptop zal niet een passende oplossing zijn. Privacy compliance (aantoonbaar voldoen aan de wet) vraagt om slimme software die actief helpt de juiste antwoorden te vinden.

Privacy Valley specialiseert zich in het aanbieden van dergelijke software met de Accelerator; een gebruiksvriendelijke, online oplossing waarmee organisaties zelf hun privacy in kaart kunnen brengen en actief beheren. De Accelerator biedt kleine en grote organisaties zoals omroepen de mogelijkheid om binnen twee maanden een interne scan te doen om te zien hoe ze voldoen aan de minimale eisen van de huidige privacywet en de nieuwe EU Privacyverordening, waaronder het gebruik van kinderdata en BSN.

Gebruikt uw organisatie data van kinderen of BSN, en wilt u weten hoe u er voor staat, klik dan op de demoknop hiernaast of mail ons op feedback@privacyvalley.com



[wysija_form id=”1″]