07 2018 | SECURITY
Mission to Mars
Christian Cachee and Natasa Jeremic from the Paysafe Data Governance Team tell PIN how they have made paysafecard ready for the new EU General Data Protection Regulation (GDPR) and why the new “Privacy by Design” motto still means plenty of work for both of them.
GDPR and the new Payment Service Directive (PSD 2) have already attracted considerable attention this year. How do you see all the excitement now that both laws have entered into force?
Natasa: PSD 2 has applied since January. It has little impact on our payment solution, since our product has almost nothing to do with bank notes. All that was needed was recertification of our licence. However, that was no problem at all and was done a long time ago.
Christian: Natasa is right. PSD 2 is more about “Open Banking,” in other words better access to data by third party providers and more competition. GDPR is much more relevant to us at paysafecard.
This new EU law has been in force since May 25th.Were there surprises?
Christian: No, it all went smoothly. We were, after all, well-prepared.
»The whole procedure of Data Subject Access Requests is now part of the existing Customer Care and Intake process.«
- Natasa Jeremic
Paysafe Data Governance Team
What did the preparations involve?
Natasa:The Paysafe Group had already started a programme in the middle of last year which greatly simplified the transition. There is a separate Data Privacy department in London with an officer responsible who assembled a core team of 10 people, which was extended for the occasion by additional staff and contractors from other departments. This team initially carried out a risk analysis and looked at where the main change requirements were.
What were the conclusions?
Christian: We defined 13 work streams on a risk basis to address the individual aspects of the changes required for the GDPR. One of the most important of these was “Data Subject Rights,” because the largest number of changes caused by the GDPR affected this area.
Natasa: Some people believe that rights such as the “Right to be forgotten,” the “Right to Data Portability” and the “Right to Restriction of Processing” do not play a major role for us at paysafecard, as we are an anonymous means of payment. But the definition of personal data now goes much further under the GDPR. This is a central point of the regulation. It now also includes device IDs and other data patterns. In addition, there is now also the “my paysafecard” account solution, in which name and address are also stored.
How do the specific paysafecard approaches now work in the cases described?
Natasa: Data Subject Access Requests (“DSARs”) are currently the decisive topic for us. Our customers have always been able to look at their data. We have now standardised it and made it more transparent. The processes have also now been even better documented. The whole procedure is part of the existing Customer Care and Intake process. The Customer Care Team was therefore given extra training and new tools and is supported by the IT team. The 30-day limit to respond to queries should therefore not be a problem.
And if customers want to export and take data away?
Christian: Also not a problem. We just occasionally ask ourselves whether, with this product, anyone will ever actually do it. (laughs)
»We defined 13 work streams on a risk basis to address the individual aspects of the changes required for the GDPR«
- Christian Cachee
Paysafe Data Governance Team
It presumably does happen that data is sometimes requested to be deleted. Is that so easy?
Christian: That is indeed more complicated than people think. Firstly, physical deletion is not that easy. Secondly, there are other laws which impact the GDPR principle that data should not be stored for longer than is necessary for the agreed purpose. The Anti-Money Laundering Act is just one example. This requires that transaction data must be stored for between five and seven years.
This means that I need a system that deletes automatically after the respective time limit expires?
Christian: Or it needs to be so pseudonymised and anonymised that the person behind the transaction can no longer be identified. This brings us to the subject of changes in IT architecture and approaches to technical solutions, which we have to look at entirely afresh on the basis of the GDPR. This is because the Act requires “Privacy by Design”. If one really takes that seriously, it is almost as demanding and cost-intensive as flying to Mars. It is therefore necessary to keep the GDPR in mind when new IT systems are constructed. In addition, the existing processes need to be adjusted.
Is the task actually possible?
Christian: We’ll get to Mars one day, too! (laughs) But seriously: We will need to work intensively on these processes for even longer.
Might it lead to problems, because these adjustments are taking longer?
Natasa: No, as long as the data is adequately anonymised/pseudonymised and protected. The Government also recognises that the technical conversion to physically delete data is only possible over the long term. However, one needs to be able to show that the company is actively tackling the problem. There should be a roadmap which shows exactly what will happen when. There is, however, a myth around this so-called “right to be forgotten” and which has not been helped by incorrect Press coverage. An organisation, known as a “Controller” in GDPR terms, can keep data for as long as it is necessary to defend or initiate any legal claims. So, financial services organisations who have provided money services to individuals will not simply delete all the transactions and the customer’s details, as they will need such information as a record of the transactions and to defend themselves in the event of legal action, e.g. claiming the transaction was not made. They will normally keep such information for as long as a legal claim can be made in law, under what is often termed the “statute of limitations”. Member States have different time periods, but often they are around 6/7 years.
What is the position with regard to marketing campaigns on the basis of customer data? Have the regulations on this become clearer?
Christian: Not yet. GDPR itself does not require consent for an organisation’s own marketing to its customers. However, a separate law requires consent for the use of electronic marketing (e.g. emails, SMS) and this law sits additional to GDPR. The future framework for the use of personal data for marketing campaigns, however, is to be set by the new “e-Privacy Regulation”. However, the Member States have not yet been able to reach agreement on this. The new law will probably not arrive until the autumn.
How will the issue be handled up to then?
Natasa: Some companies assume that more restrictive provisions are coming and are converting their marketing campaigns to use an opt-in process. paysafecard, however, already works with a double opt-in system, which is recognised as the highest level of opt-in consent.
The concept of a “Controller” was just mentioned. How does this differ from a “Processor” and what effect does this have on the business relationship between merchants and paysafecard?
Christian: This sometimes gives rise to misunderstandings, as a few of our merchants assume that we act similar to the providers of credit card authorisation services. These are unambiguously “Processors,” processing data at the request of a “Controller”. paysafecard is, however, a “Controller,” since the company alone determines what happens to the personal data related to the individual, known as a “Data Subject”.
What does that mean in practice?
Christian: The merchant and paysafecard are both “Controllers”. The responsibility of the data processing is therefore clearly separated and it is not essential to have new contracts to regulate the business relationship from the GDPR viewpoint afresh. The position is different for “Processors”. If the processing of personal data is being carried out by a “Processor” on behalf of a “Controller,” the “Controller” and “Processor” must define in a contract how the processing by the supplier or service provider (“Processor”) is to be carried out, and must ensure that this corresponds to the GDPR regulations. The “Controller” must also carry out adequate “due diligence” on the “Processor”. paysafecard is currently in the middle of this process with a few hundred service providers. For those for which the GDPR is most relevant, which is less than 10% of the total, this has been already completed.
This brings us to the final area of discussion. What happens if one of paysafecard’s service providers experiences a data breach?
Natasa: This is also part of the clarifying discussions that we are currently having with our service providers. Just like paysafecard, they must be able to ensure and prove that the data are protected from access by unauthorised persons and that in the event of a data leak the authorities are informed as quickly as possible. In the case of paysafecard itself, the IT security is so strong that no changes were needed as a result of the GDPR. The only change is that in the event of a data breach we have faster notification response times. Compliance with the GDPR requirement of a time window of 72 hours for risk assessment and notification to the authorities is therefore not a problem.
The transition to the new regulation seems in many cases to be going smoothly. Do you think the fear of greater penalties is justified?
Christian: For minor and medium-sized infractions, penalties in the millions should not be expected. It does after all say in the Act that proportionality should be observed. To this extent, there will undoubtedly be a multi-step process in which a company has the chance to improve its regulations before a massive penalty is imposed.
Natasa: I think that early notification of the penalties was also intended to be a driver for the prioritisation and provision of resources. As a result, most affected companies decided long before May 25th what needed to be done. Certainly, at paysafecard, we were fully prepared for the new legal framework before that date.
Natasa and Christian, many thanks for the discussion!