„Digital Identity”: Der dritte Schlüsselfaktor bei der Gestaltung der „User Experience” aus Sicht von Kundenkontrolle

Diese Blogreihe basiert auf der Analyse des Papers “Open Banking: advancing customer-centricity“, das Innopay in enger Zusammenarbeit mit der EBA Association Open Banking Working Group erstellt hat. Das vollständige Dokument ist unter folgendem Link in englischer Sprache abrufbar (Link - ab Kapitel 3.4). Außerdem verweisen wir gerne auf die Website der EBA Association Open Banking Working Group, auf welcher Sie das neueste Video zu diesem Thema sehen können (Website).

Im dritten Blog haben wir bereits die ersten beiden Schlüsselfaktoren des „Open Bankings“, nämlich einerseits die Kundenrelevanz und Regulierung („= Driver“), andererseits die „Open-API“-Technologie („=Enabler“) kennengelernt, in diesem Blog werden wir nun die dritte Schlüsseldimension vorstellen - die „Digital Identity“.

Sicherheit und Compliance sind essentiell notwendige Voraussetzungen, damit Banken operieren können. „Know-Your-Costumer” (KYC) ist essentiell für das Kerngeschäft der Banken. Es gehört zu den Grundvoraussetzungen für einen sicheren Bankbetrieb über Möglichkeiten zu verfügen, Kunden zu identifizieren und ihre Identität zu verifizieren, wenn Banking-Dienstleistungen angeboten werden. Durch die zunehmende Digitalisierung haben sich auch die Identitäten immer weiter digitalisiert, sodass daraus das Konzept der „Digital Identity” resultierte.

„Digital Identity” kann als ein Service betrachtet werden, den Banken historisch schon innerhalb des eigenen Tätigkeitsbereiches verwendet haben, der im digitalen Zeitalter aber weit über den Bankenbereich hinaus Anwendung findet. Diese Entwicklung bietet den Banken die Chance, bereits bekannte Identitäten der Kunden wiederzuverwenden und diese digitale Identität als ein Service für autorisierte Dritte anzubieten. Bankkunden haben dadurch die Möglichkeit, ihre Anmeldedaten zur Wiederverwendung für eine Anmeldung zu benutzen, können diese aber auch gleichzeitig zur sicheren Verbindung mit autorisierten Drittanbietern verwenden, wenn sie eine Genehmigung erteilen, mit der der Drittanbieter im Auftrag des Kunden agieren darf.

Einführung zur „Digital Identity”

Im Rahmen der „Digital Identity” gibt es zwei Hauptakteure: den „User” und die „Relying Party”. Der User möchte seine digitale Identität mit einem Dritten teilen, welcher dann auf die vom User übermittelte digitale Identität vertraut (=rely) - somit „Relying Party”.

„Digital Identity” hat drei Kernfunktionalitäten:

  1. Identifikation: Diese läuft über die Attribute einer Person oder Einheit ab. Darunter fällt der Name, die Sozialversicherungsnummer, das Kennzeichen, die Adresse, das Alter, die IP-Nummer, die MAC-Adresse etc. Die Eigenschaften können fast alles sein, sie müssen nur mit einer natürlichen Person, juristischen Instanz oder dessen Gerät verknüpft sein und die Nutzung der jeweiligen Attribute hängt vom Verwendungskontext ab. Die jeweilige Identität ist nichts anderes als ein Bündel von Attributen, welche diesen in einem bestimmten Kontext eindeutig definiert, d.h. im Falle der Bank wäre dies z.B. die Konto- oder Kundenummer, im Zusammenhang mit dem Staat wäre dies die Sozialversicherungsnummer.
  2. Authentifizierung: Dies ist der Prozess, um die jeweilige Identität zu verifizieren. Oftmals fällt hierbei der Begriff der „Strong Customer Authentication” (SCA). Dabei werden Elemente genutzt, welche wir kennen (d.h. Passwörter), Elemente die wir besitzen (d.h. ein zugehöriger Token oder ein Handy) und/oder Elemente, die inhärent mit uns verbunden sind (d.h. Biometrie und Verhalten), um das erforderliche Maß an Sicherheit zu gewährleisten. Eine solche Sicherheit erfolgt über mehrere Stufen, sodass diese manchmal negativ mit der Benutzerfreundlichkeit und dem Anmeldungsprozess korreliert. Weniger Sicherheiten bedeuten für den Kunden oftmals mehr Bedienkomfort.
  3. Autorisierung: Hierbei wird definiert, was man tun und/oder worauf man zugreifen kann, nachdem die Identifikation und die Authentifizierung erfolgt ist. So könnte man die Bank dazu autorisieren, eine Zahlung im eigenen Namen zu initiieren oder Zugriffsrechte auf bestimmte Informationen zu vergeben.

Die folgende Abbildung zeigt mehrere Attribute sowie die drei Aspekte der „Digital Identity” im Kontext mit verschiedenen User- und „Relying Party” – Segmenten: Personen (Kunden/Bürger), Unternehmen und der öffentlichen Verwaltung.

DE4 1Abbildung 1: Die drei Aspekte der „Digital Identity“: Identifizierung, Authentifizierung und Autorisierung

Die Kombination dieser drei Aspekte der „Digital Identity” ist entscheidend für die Realisierung des „Open Bankings”. Damit die Kunden autorisierten Dritten einen kontrollierten Zugang zu ihren Konten gewähren, um z.B. Zahlungen auszulösen oder Kontodaten preiszugeben, braucht es einen gründlichen Sicherheitsprozess entlang der oben beschriebenen Prinzipien. Gleichzeitig unterstützen Banken ihre Kunden, damit diese mehr Kontrolle erlangen können, indem sie z.B. deren verifizierte Identitäten „FinTech-Playern” als eine Serviceleistung anbieten, bspw. für Onboarding-und Kontoeinrichtungsprozesse.

„Digital Identity” definiert die „User Experience” des „Open Bankings”

Damit „Open Banking” zur Realität wird, müssen Kunden die Möglichkeit haben, bei der Bank eine offizielle Zustimmung einzureichen, damit diese bestimmten Apps oder Online-Services Zugang zu den Kontodaten ermöglichen kann. Die Bank sollte zu jeder Zeit in der Lage sein, diese Zustimmung verifizieren zu können und der Kunde sollte jederzeit in der Lage sein, seine Zustimmung (d.h. seine Autorisierung) unverzüglich wiederrufen zu können. Wenn die App oder der Service dann genutzt wird, so sollte die Bank im Stande sein zu überprüfen, ob auch wirklich der tatsächliche Kunde über die jeweilige App eine Transaktion abwickelt. Daher ist eine Authentifizierung von Seiten der Bank zwingend notwendig.

Die „User Experience” des „Open Bankings” ist stark von der „User Experience” der „Digital Identity” beeinflusst, z.B. durch SMS oder Einmal-Codes (z.B. eine „Transaction Authentication Number (TAN)).

Die gesamte „User Experience” könnte dann stark in die Richtung der vertrauten Anwendungen von Identitäten aus dem nicht-finanziellen Kontext hinauslaufen, z.B. wenn man sich bei Twitter, Facebook oder Google anmeldet. Diese Dienste bieten ebenfalls die Möglichkeit, schon bereits vergebene Autorisierungen erneut zu überprüfen oder bei Bedarf diese zu widerrufen. Die APIs hinter diesem Standard („Open standard for Authorisation” – OAuth) sind die wohl mit am häufigsten im Alltag verwendeten.

Ein Bereich, in dem Banken bereits eine ähnliche Infrastruktur aufweisen, ist das Mandate-Management für Lastschriften. Der Schuldner verfügt dabei über eine Grundform des Zustimmungsmanagements, d.h. die Option, eine „Blacklist” und „Whitelist” für Gläubiger zu pflegen. Eine solche Lastschrift (und generell auch Karten) kann als eine Form von „Access to Account” betrachtet werden, jedoch als eine Version der ersten Generation, mit einem klaren Schema und Rechtsrahmen bezüglich der Funktionsweise. 

„Digital Identity” und „Regulatory Technical Standards” (RTS) unter PSD2

Die EBA in London hat ihren lange erwarteten RTS-Entwurf zu „Strong Customer Authentication and Secure Communication” im Februar 2017 veröffentlicht. Nachdem die europäische Kommission ihre Ergänzungen (im Mai 2017) vorgeschlagen und die EBA darauf geantwortet hat (Juni 2017), wird eine finale Version seitens der Kommission für Anfang Oktober 2017 erwartet. Die RTS als solches, können als „Anleitung“ zur Frage, wie man „Customer Control“ aus regulatorischer Sicht erfüllen kann, da sie die Ausgangslage für die „User Experience“, durch das Vorschreiben von Prinzipien einer soliden Kundenauthentifizierung definieren.

Die RTS gelten als Schlüsselvoraussetzung zur Vollendung der PSD2-Ziele zum verstärkten Verbraucherschutz. Zusätzlich fördern sie Innovationen durch neuen Wettbewerb und verbessern die Sicherheit von Zahlungsdiensten innerhalb der EU.

Die folgende Abbildung stellt die Herausforderungen bzgl. Sicherheit und Authentifizierung dar, welche durch „Third Party Provider” (TPP) entstehen, wenn diese einen autorisierten Zugang zu Zahlungskonten haben. Diese Zahlungskonten fallen im Kontext von „Payment Initiation Services” (PIS) und „Account Information Services” (AIS) unter PSD2 unter „Account Servicing Payment Service Providers” (AS-PSPs, normalerweise Banken).

DE4 2Abbildung 2: RTS Anforderungen für den Interaktionsrahmen XS2A

Die RTS sollen die Beziehungen zwischen den Akteuren, die an einer XS2A-Transaktion beteiligt sind (d.h. PIS und AIS) sowie involvierten, autorisierten TPPs durch angemessene Sicherheitsmaßnahmen regeln. Allerdings wollen unterschiedliche Marktakteure (TPPs, AS-PSPs) oft auch unterschiedliche Sicherheitstechnologien (statisch/dynamisch, klassisch/modern, risikoabhängig, elektronischer Fingerabdruck etc.) einsetzen. Die Kunden werden dann frei zwischen den Akteuren wählen können, die ihre Bedürfnisse am ehesten erfüllen. In jedem Szenario müssen die Sicherheits-und Authentifizierungsprozesse aber im Einklang mit den RTS der EBA sein.

Der RTS-Entwurf besagt, dass autorisierte TPPs das Recht besitzen, sich auf die von den AS-PSP bereitgestellten Authentifizierungsverfahren für die Kunden verlassen und auch darauf vertrauen zu können. In solchen Fällen wird das Authentifizierungsverfahren voll und ganz im Kompetenzbereich der AS-PSP bestehen bleiben. Somit wird auch die Erfahrung der Kundenkontrolle klar durch die AS-PSP definiert.

Die einzige Ausnahme, in der die Transaktion im Kompetenzbereich der PISP authentifiziert werden sollte, liegt dann vor, wenn ein PISP selbst personalisierte Berechtigungsnachweise herausgibt. Dies würde jedoch eine zuvor getroffene vertragliche Vereinbarung zwischen dem PISP und dem AS-PSP erfordern, bei der die Akzeptanz solcher Nachweise geregelt und festgehalten ist. Eine solche Vereinbarung befände sich dann auch nicht mehr im Anwendungsbereich der PSD2. Die RTS implizieren zudem, dass die von den Banken ausgestellten, digitalen Identitäten für Kunden im Rahmen von XS2A wiederverwendet werden können, sodass die Kunden mehr Kontrolle über TPPs und PISPs hinsichtlich Transaktionsautorisierungen haben.

In diesem und dem vorherigen Blog haben wir nun die drei Schlüsselfaktoren des „Open Bankings” beschrieben. Die Kombination aus Kundenanforderungen, APIs und der „Digital Identity“ ermöglichen es dem Kunden schlussendlich, mehr Kontrolle über seine Finanzen und persönlichen Daten im Umgang mit „Third Party Service Providern” auszuüben. Die „Digital Identity“ nimmt dabei eine entscheidende Rolle ein, wenn es um die „User Experience” geht.

Im fünften und letzten Blog dieser Reihe werden wir die strategischen Auswirkungsbereiche des „Open Bankings” ausführlich behandeln.

〈  Back to overview