The General Data Protection Regulation, also known as GDPR, was created to give EU citizens more control over their personal data. As with many EU regulations, it has a worldwide reach, as any company doing business in Europe or with Europeans can be hit with massive fines if the company is found to be non-compliant.

GDPR is quite relevant for SCA, as the SCA process itself often (but not always) involves personal information, such as transaction data and account numbers.

With the Okay SCA solution, we have been adapting to the GDPR since before the EU passed the regulation. Some fundamental implementation choices were made that makes it easier for us to comply:

• With Okay we don’t operate with users, but with devices, which makes the stored data at least semi-anonymous.
• Essential data, such as entered PIN codes, is encrypted locally on the device before being transferred with a key that Okay usually won’t have access to.
• We try to store a minimal amount of data.

Of course, while the data is stored anonymously, there might still be some information used to perform the SCA operation which could identify the user. One example are the account numbers that pass through the Okay system. One way this happens is by a feature that takes a screenshot of the screen the user sees, which can then be analysed and stored, server-side. Such a screenshot can include an account number or similar personal information.

When running in “normal” mode, information displayed to the user such as transaction data is not logged by Okay in any way. In other words, the only stored information is non-identifiable. But, if you run Okay on-premise, it is possible to enable a special “debug mode” that logs much more, including data communication with the SDK. Usually, this mode is never enabled on a production system, and if you use Okay as a Software as a Service (SaaS), we never enable this mode. Thus, the stored data is not sensitive, but it can still fall under the “right to be forgotten”.

When it comes to screenshots, you can select if the screenshots should be analysed client-side, in which case the GDPR is not relevant, or sent to the Okay back-end for analysis and storage. If sent to the back-end, the images are stored securely, and only available to authorised users.

As mentioned earlier, there is “the right to be forgotten”, but that might not always apply. Whether or not it applies in a specific situation depends on what the screenshot is related to. If the screenshots are of transactions, there is most likely regulation outside of the GDPR, such as anti-money laundering that can require you to keep data for 10 years. With Okay, the data retention period can be configured on the back-end, but the exact period depends on which regulation applies. We of course also support deleting data for a user (by deleting the device), and if required, you can export any stored data for a device as well.

With the GDPR, you’re required to have a full view of all your processes and systems dealing with data. Each individual piece of data can also have different retention requirements, and your customers need to consent to any data being retained. That can make the work of your data protection officer quite complicated. We have tried to make our solutions flexible enough to fulfil any kind of requirements, but as we’ve described it is not possible to offer a “one size fits all” solution. Feel free to get in touch with us if this is a topic you’re interested in discussing further.