Strong customer authentication via apps - who takes responsibility for personal data?

On 14 September 2019, the second act to implement the Payment Services Directive PSD2 entered into force. In this context, the provisions in the ZAG were adjusted, in particular. The changes are intended to contribute to greater security in online payment transactions and counter new fraud methods. As a corresponding measure, the act provides for payment service providers to be obliged to provide "strong customer authentication". A strong customer authentication was meant to be mandatory for all online payments upon entry into force of the implementation act. However, in a press release dated 17 October 2019 , BaFin announced that a grace period until 31 December 2020 would apply to payment service providers domiciled in the Federal Republic of Germany, during which there was initially no reason to fear a complaint by BaFin.

The end of this grace period is now approaching, and uncertainty is increasing among companies affected by the PSD2. For example, when implementing strong customer authentication, not only the requirements specific to the financial sector must be taken into account, but also other legal regulations, such as the provisions of the EU General Data Protection Regulation (EU GDRP). This concerns in particular and also the cooperation between payment service providers and providers of other services in order to make the second factor available in the context of two-factor authentication (2FA). For example, if responsibilities are not properly recorded and communicated to data subjects, the consequence may be substantial fines imposed by data protection supervisory authorities.

The ZAG does not contain any regulations on data protection responsibility in the processing of personal data, so that the general data protection regulations apply. With regard to data transfers, the EU GDPR essentially distinguishes between three case constellations: transfer between two separate controllers (controller-controller), commissioned data processing under Art. 28 EU GDPR (controller-processor) and joint responsibility under Art. 26 EU GDPR (joint controllers).

Art. 4 (7) EU GDPR defines the term ‘controller’ as the natural or legal person [...] or other body which [...] determines the purposes and means of the processing of personal data. If a controller determines the purposes and means jointly with other, these are joint controllers. In contrast, the processor processes the data only on behalf of the controller and has no power to decide on the purposes, but is bound by the instructions of the controller. However, it is often difficult to draw the line between the different roles under data protection law, so that in principle each transfer of data must be assessed individually and in detail.

The agreement between the parties can be used as an indication, but the actual circumstances, i.e. the actual technical design of the processing operations, are decisive. This means that, even if the parties conclude a data processing agreement, but in fact the 'processor' has his own purposes for processing the data, there is no commissioned data processing, but rather the parties are joint or separate controllers. This assessment is particularly important for the obligations towards the data subjects regulated in the EU GDPR, such as information obligations.

Once the grace period is over, strong customer authentication will be required for all online transactions. According to Section 55 (1) sentence 1 ZAG, online transactions are defined as online access to a payment account, the initiation of an electronic payment transaction and any action carried out through a remote channel that may imply a risk of payment fraud or other abuses.

Strong customer authentication, also known as two-factor authentication, means that online and card payments generally need to be confirmed by two independent factors. Elements categorised as knowledge (e.g. PIN, password), possession (e.g. mobile phone, card, TAN generator) or inherence (e.g. fingerprint) are conceivable.

When triggering an electronic payment transaction, there is the particularity that the authentication must include a dynamic factor. If, for example, a TAN (transaction number) is required as an authentication factor, it is necessary for the TAN to be generated using a dynamic TAN procedure - i.e. a procedure in which a new TAN is generated for each transaction.

Payment service providers are increasingly using apps for this purpose, although different authentication methods are offered. With TAN apps, the calculation algorithm for the TAN is included in the software. If the customer receives two separate apps, one for online banking and one for strong customer authentication, the TAN for the transactions to be authorised must be transferred to the other app, which is usually done via App2App communication. However, this does not work for multibanking apps. Therefore, with newer apps, you receive a push message via the smartphone as a separate channel and release the action via a biometric feature such as a fingerprint or type in a PIN. With newer smartphones, the Consumer Device Cardholder Verification Method (CDCVM) can also be used to access the device and authenticate payments - especially for mobile Near Field Communication (NFC) payments. For this purpose, the device and the CDCVM must be pre-registered for the owner.

A bank, a credit card company, Internet payment methods (such as instant bank transfer) or mobile payment methods (such as Apple and Google Pay) can be involved in an online transaction as payment service providers. In some offers, another payment service provider takes over the integration of different payment methods into the existing online shop.

When generating the TAN via apps, the app operators process authorisation data and transaction data, which raises the question of the data protection responsibility for the processing as well as the legal basis for the transfer of the transaction data. Various parties are involved in the processing of this data: the online dealer, the payment service provider(s), the developer and the provider of the authentication app in the App Store (which may or may not be identical), the operator of the app, and possibly a technical service provider.

1. Legal basis

Payment service providers may process personal data necessary for the provision of their payment services only with the explicit consent of the payment service user (Section 59(2) ZAG), unless they process such data on a legal basis necessary for the prevention, investigation and detection of fraud in payment transactions (Section 59(1) ZAG). In this context, the European Data Protection Board (EDPB) has made it clear in its Guidelines 06/2020 on the interplay of the Second Payment Services Directive and the GDPR that this consent is a contractual consent and not consent in the strict sense of the EU GDPR. Service providers commissioned by a payment service provider with the provision of authentication services may, in accordance with the general rules of the EU GDPR, receive the data for processing only if instructed to do so by the respective payment service provider on the basis of commissioned data processing or with the explicit consent of the payment service user.

2. Responsibility under data protection law and duties to provide information

Payment service providers who have their own contractual relationship with the customer beyond the specific online purchase and payment transaction process data in their role as controllers within the meaning of Art. 4 (7) EU GDPR and may fulfil their independent information duties in this context. In the case of payment service providers that are only involved in the online payment process, it must be examined in each individual case whether they collect customer data directly as the controller and how they can fulfil their information obligations - for example by supplementing the dealer's end customer data privacy statement. The extent to which providers of authentication apps enter into an independent legal relationship with customers as part of the App Store and process the data made available to them in the context of transaction authorisation as independent controllers is not always clear to customers.

In the contractual agreements of the App Stores, the App Store operators regularly transfer the data protection responsibility for Apps in full to the App providers. For example, the Google APIs Terms of Service state: “You will comply with all applicable law, regulation, and third party rights (including without limitation laws regarding the import or export of data or software, privacy, and local laws).”  Developer in this case, however, does not mean the developer in the narrower sense, but the person who assumes the role of developer by offering the app in the App Store. A similar passage is also found in the terms and conditions of Apple. However, it cannot be concluded from these formulations alone that the provider is actually the controller within the meaning of the EU GDPR, as this depends on the actual technical design of the processing. Rather, the decisive factor is therefore who can bindingly determine the means and in particular the purposes of the processing. This means that an app provider who, from a factual point of view, has no influence on the purposes and means of the processing, cannot regularly be a controller in the sense of the EU GDPR. Conversely, the provider who decides on the purposes and means of the processing must be qualified as the controller.

Thus, if the payment service provider is not the provider of the authentication app in the App Store itself, it must disclose whether the provider of the app receives and processes the data as (independent or so-called joint) controller. In this case, the payment service provider has to obtain the explicit consent of the payment service users to the transfer of transaction data. Accordingly, the payment service provider's data privacy statement and the payment service user's statements obtained by the payment service provider and the data protection information published by the app provider in the App Store must be coordinated. Alternatively, the payment service provider may involve the app provider on the basis of commissioned data processing if the payment service provider is entitled to give instructions on the purposes and means of processing by the app provider. This must also be consistently reflected in the respective data privacy statement.

If an authentication app is made available to customers in digital payment transactions, it is imperative to check which specific data processing takes place and which parties are involved and to what extent. The contractual agreements and actual circumstances are decisive. Once the parties' possibilities of influencing the data processing have been recorded, contractual agreements should be made between the parties - this may also mean a joint controller agreement or a data processing agreement. As soon as arrangements concerning the responsibilities and thus also the rights and obligations of the parties are made, the data privacy statements have to inform the data subjects accordingly.