Am 17. Januar lud Hogan Lovells gemeinsam mit innopay und dem Fraunhofer IESE in den Räumen von Hogan Lovells in Frankfurt zu einer Veranstaltung über PSD2, RTS und DSGVO ein. Thema: Aktuelle neue Richtlinien und Verordnungen der EU zu Finanzmarkt und Datenschutz. Durch die Vortragsreihe von Nils Jung und Karl Illing (innopay), Ruth Maria Bousonville (Hogan Lovells) und Michael Ochs (Fraunhofer IESE) führte Dr. Nils Rauer (Hogan Lovells). Anhand von zwei konkreten Use Cases zeigten die Referenten den ca. 35 interessierten Zuhörern aus dem Bereich Financial Services verschiedene Aspekte von PSD2 und DSGVO auf.
Auf Ebene der europäischen Union treten dieser Tage eine Reihe von neuen Regelungen und Verordnungen in Kraft oder werden bald in Kraft treten. Hierzu zählen die Payment Services Directive 2 (PSD2, 2015/2366/EU), die seit dem 13. Januar 2018 in Kraft ist und auf nationaler Ebene als ZAG in die deutsche Gesetzgebung überführt wurde. Am 25. Mai 2018 endet die Übergangsfrist der Datenschutzgrundverordnung (DSGVO, 2016/679/EU) – sie tritt vollständig in Kraft und löst dabei die in die Jahre gekommene Datenschutzrichtlinie (1995/46/EG) ab. Gleichzeitig tritt auch das neue Bundesdatenschutzgesetzt (BDSG neu) in Kraft, welches Detaillierungen und Ergänzungen zur DSGVO in der nationalen Gesetzgebung vornimmt. Am Horizont steht bereits die ePrivacy Verordnung (COM(2017)10) in den Startlöchern für voraussichtlich 2019.
Use Case 1: Identity Services und PSD2
Nils Jung und Karl Illing präsentierten in ihrem Vortrag die Nutzung von Identity Services im Banking. Beispielsweise kann so ein Kunde, der ein Konto bei seiner Hausbank hat und seine dort liegenden personenbezogenen Daten Nutzen möchte, bei einer Zweitbank ein Tagesgeldkonto eröffnen. Dazu autorisiert der Kunde einen spezialisierten Identity Broker, die Daten von der Hausbank abzurufen und auf dieser Basis eine zum Geldwäschegesetz (GWG) konforme Identifizierung bei der Zweitbank durchzuführen. So kann der Kontoantrag für ein Tagesgeldkonto und dessen Einrichtung komplett online und digital ermöglicht werden – medienbruchfrei und praktisch direkt. Vergleicht man dies mit dem analogen PostIdent Verfahren, das, wenn es beispielsweise bei der Eröffnung eines Tagesgeldkontos zur Anwendung kommt, den gesamten Prozess um mehrere Tage verzögert, liegen die Vorteile klar auf der Hand.
Die juristische Seite: PSD2 vs. DSGVO mit Blick auf beide Use Cases
Ruth-Maria Bousonville ging in ihrem Vortrag auf die Unstimmigkeiten und Konfliktthemen zwischen PSD2 und DSGVO ein. Dabei wurden in zwei Spotlights die Themen Identity Broker und DSGVO sowie Kontoinformationsdienste mit Mehrwertangeboten aus Sicht PSD2 und DSGVO beleuchtet.
Im Spotlight „Datenschutz und Identity Broker“ (Use Case 1) ergeben sich die beiden zentralen Fragen (1) „Darf der Identity Broker die Daten bei der Hausbank abrufen?“ und (2) „Darf die Hausbank dem Identity Broker Zugriff geben?“. Zu beantworten war dies mit der Einschätzung, dass die Zweitbank Daten nach Art. 6(1)c DSGVO in Verbindung mit §58 GWG erhebt. Der Identity Broker wäre so Auftragsdatenverarbeiter für die Zweitbank (Art. 28 DSGVO). Die Hausbank wiederum darf Daten nur auf Grund von Einwilligung durch den Kunden zur Verfügung stellen (Art. 6(1)a DSGVO).
Im Spotlight „Datenschutz und Kontoinformationsdienste“ (Use Case 2, siehe folgender Abschnitt) ergeben sich die zentralen Fragen „(1) Darf KID Finanztransaktionsdaten bei der Bank des Kunden abrufen?“, „(2) Darf die Bank des Kunden dem KID die Daten zur Verfügung stellen?“ und mit Blick auf Mehrwertdienste innerhalb des Angebots des KID „(3) Darf der KID die Daten benutzen, um dem Kunden Vorschläge zur Optimierung beispielsweise seiner TK-Kosten zu machen?“. Zu beantworten war dies mit der Einschätzung, dass Leistungsbestandteil „Optimierung von Telekommunikationskosten“ (Mehrwert) kein Kontoinformationsdienst ist und auch nicht anderweitig in der PSD2 geregelt ist. Die Nutzung der Kontodaten für die Optimierung von Telekommunikationskosten kann nicht auf PSD2 gestützt werden. Dies würde in den Geltungsbereich der DSGVO fallen. Die damit verbundene Frage ist, ob sich somit eine Verpflichtung der Bank zu einer Filterung sensitiver personenbezogener Daten ergibt. Dies ist nicht der Fall. Andererseits aber ergibt sich auch kein Verbot, dem Kunden die Möglichkeit zum Filtern zu geben. Würde eine Bank also dem Kunden die Datenhoheit geben, selbst zu entscheiden, welche Daten bei einer Übertragung an den Kontoinformationsdienst beispielsweise anonymisiert oder entfernt werden, wäre der Kunde der Souverän über seine Daten. Bedenkt man, dass das nach Art. 20(1),(2) DSGVO bestehende Recht auf Datenübertragbarkeit gemäß Art. 20(4) DSGVO „die Rechte und Freiheiten anderer Personen nicht beeinträchtigen“ darf und zieht man die Aspekte Privacy by Design und Privacy by Default (Art. 25 DSGVO) hinzu, könnte sich möglicherweise eine Pflicht der Bank zum Filtern ergeben. Jedoch ist auch hier kein klares Verbot für eine Filterung zu erkennen.
Use Case 2: Technische Umsetzung Datenschutz bei Kontoinformationsdiensten
Michael Ochs zeigte in seinem Vortrag Möglichkeiten zur technischen Umsetzung von Datenschutz bei Kontoinformationsdiensten mit Mehrwertangeboten, z.B. Optimierung von Kostenkategorien wie Telekommunikation oder auf Profiling basierende Freizeitvorschläge. Generell können in den Transaktionsdaten eines Kontos auch personenbezogene Daten zu finden sein, die nicht unter einen Vertrag mit einem Kontoinformationsdienst fallen würden, z.B. Girocard Zahlungen eines Lebenspartners, der Name eines Arbeitgebers bei der Gehaltszahlung, obwohl im Arbeitsvertrag Stillschweigen über den Arbeitgeber vereinbart wurde, von Lebenspartnern getätigte Überweisungen, Arztrechnungen oder Unterhaltszahlungen für Kinder. Oder eben einfach sehr sensible Daten des Kunden selbst, wie z.B. politische Überzeugung, die sich direkt aus der Zahlung von Mitgliedsbeiträgen an eine Partei ableitet, eine Gewerkschaftsmitgliedschaft (auch über Beiträge), chronische Erkrankungen im Fall von regelmäßigen Medikamentenzahlungen bei privatversicherten Patienten. Den Möglichkeiten sind hier nahezu keine Grenzen gesetzt.
Die Abbildung zeigt das Konzept eines Angebots für ein Ende-zu-Ende Privacy Enforcement, das dem Kunden die Möglichkeit gibt selbst zu bestimmen, welche Daten im Klartext en, welche (teil)anonymisiert und welche gegebenenfalls gar nicht an einen KID transferiert werden dürfen. Die Umsetzung eines Ende-zu-Ende Privacy Management und Enforcement (vom Privacy Cockpit direkte Steuerung der Datenverarbeitung in den verschiedenen Systemen) kann mit IND²UCE umgesetzt werden.
Ausblick – Platform Economy in Financial Services
Mit dem Inkrafttreten von PSD2 ist nun auch „offiziell“ der Startschuss im Kampf um die Kundendaten im Bereich Financial Services gefallen. Was können Banken tun, um in Zukunft vom Wert der Daten ihrer Kunden zu profitieren, an diesem Geschäft zu partizipieren und es nicht zur Gänze anderen zu überlassen? PSD2 erlaubt den Zugriff von Kontoinformationsdienstleistern (KID) auf Kundenkonten, wenn die Kunden explizite Zustimmung dazu geben. Wie in der Veranstaltung im Vortrag von Ruth Maria Bousonville deutlich wurde, ist die aktuelle Einschätzung PSD2 vs. DSGVO so, dass Banken Kunden die Möglichkeit einer Filterung von sensitiven Kontotransaktionen anbieten dürfen, ohne jedoch dazu verpflichtet zu sein – eine technische Möglichkeit zum Selbstdatenschutz also. Datenschutz-indifferente Kunden werden diese Möglichkeit voraussichtlich nicht nutzen, sensible Kunden werden sie jedoch begrüßen. Ein Ende-zu-Ende Privacy Cockpit mit unmittelbarem Privacy Enforcement an der PSD2-Schnittstelle für KID wäre jedoch nur ein erster Schritt im Kampf um die Kundendaten. Der eigentliche und noch zukunftsweisendere Aspekt wäre der Einstieg von Banken in das Feld Platform Economy unter Wahrung der Datensouveränität von Kunden. Das schafft Vertrauen und öffnet ein nahezu riesiges Feld für innovative Mehrwertdienste auf der Plattform von Banken.
Die Abbildung zeigt das grundsätzliche Konzept einer „Banking & Data Services Platform“:
Dienstanbieter könnten Applikationen on premise der Bank – und vor allem innerhalb des Compliance Perimeters der Bank – betreiben und müssten dabei voraussichtlich als Unternehmen selbst geringere Compliance Anforderungen erfüllen, was im Vergleich zu einem TPP (links im Bild) ein Vorteil sein kann. Andererseits wäre für die Bank das Tor geöffnet, die immensen Kosten zur Erfüllung von Compliance zum Teil auch auf die Dienstanbieter umzulegen, also schrittweise hier sogar einen ROI zu erreichen. Andererseits könnten Dienstanbieter wiederum davon profitieren, dass PSD2 und RTS in diesem Szenario keine Anwendung finden würden, somit also zum Beispiel die Grenze von 90 Tagen Rückschau bei Kontoinformationsdiensten – wie sie in den RTS festgelegt ist – fallen würde. Dies hätte das Potenzial, deutlich bessere Modelle z.B. für Scoring entwickeln zu können und würde aus aktueller Perspektive zu einer echten Win-Win-Situation führen. Wenn zudem bei der Nutzung der Dienste die Datensouveränität der Kunden durch Zweckbezug und Privacy Enforcement an der Daten-Dienste-Schnittstelle gewahrt bleibt, sind dies weitere Benefits gegenüber dem Ansatz, der mit PSD2 verfolgt wird.
Wir werden dieses spannende Thema weiterverfolgen.