So funktioniert Consent Management bei Embedded Finance

Wenn Banken und andere Finanzinstitute ihre Produkte über Drittanbieter bereitstellen, sprechen wir von „Embedded Finance“. Dies können beispielsweise Einzelhändler sein, die eine Finanzierung ihrer Waren anbieten, oder Finanzmanagement-Apps, die die Banktransaktionen der Nutzer*innen erfassen, um die Ausgaben zu analysieren. Dabei werden die Finanzfunktionen – also das Geldmanagement – in die Benutzeroberfläche des Einzelhändlers oder der Finanzsoftware eingebettet.

Ein Datenaustausch im Rahmen der Embedded Finance, wie in dem genannten Beispiel, wird auch als Open Banking bezeichnet. In vielen Ländern ist dieser aktive Datenaustausch sogar gesetzlich vorgeschrieben und für alle Finanzinstitute verpflichtend durch Open-Banking-Standards geregelt. Entsprechende Gesetze sind bereits in 37 Ländern in Kraft oder in Vorbereitung.

An einer Embedded Finance-Transaktion sind drei Parteien beteiligt: das Finanzinstitut mit seinen Produkten und Diensten, ein Drittanbieter, der diese Produkte oder Dienste nutzt, und eine Person, die als Kund*in des Finanzinstituts mit dem Drittanbieter interagiert.

Vertrauen ist die wichtigste Voraussetzung für solche Transaktionen: Verbraucher*innen brauchen Gewissheit, dass ihre Daten entsprechend geschützt an den Drittanbieter weitergegeben werden; dass sie die Bedingungen, denen sie zustimmen, wirklich verstehen und dass sie die Weitergabe ihrer Daten jederzeit wieder untersagen können. Wenn die Verbraucher*innen der Weitergabe ihrer Daten zustimmen, wird dies als „Consent“ bezeichnet.

Welche Komponenten brauche ich für eine erfolgreiche Embedded Finance-Lösung?

Da die Produkte und Dienste der Banken über APIs bereitgestellt werden, basiert die gesamte Lösung auf einer API-Management-Plattform. Diese sorgt für Transparenz und Steuerungsmöglichkeiten, die für die Entwicklung, Sicherung, Analyse und Skalierung von APIs notwendig sind.

Als nächstes wird eine Komponente benötigt, die die Zustimmung der Endnutzer*innen verwaltet. Sie ist für das „Consent Management“ zuständig und prüft, ob die Endnutzer*innen einer bestimmten Aktion des Drittanbieters (z. B. dem Zugriff auf den Kontostand) zugestimmt haben. Außerdem stellt sie die Tools bereit, mit denen die Endnutzer*innen ihre Zustimmung prüfen, ändern oder widerrufen oder Finanzinstitute dies im Namen ihrer Kund*innen tun können.

Zu guter Letzt ist noch eine Identitätsplattform notwendig, die die Endnutzer*innen authentifizieren und deren Identität feststellen kann.

Eine Google Cloud-basierte Embedded Finance-Lösung nutzt die API-Management-Plattform Apigee sowie die Identity Platform – oder eine beliebige andere Identitätsplattform – sowie einen Consent Management Service (CMS). Google Cloud arbeitet eng mit zwei führenden Consent Management-Anbietern zusammen: Clarip und CloudEntity.

Wie arbeiten diese Komponenten miteinander? 

Die wesentlichen Funktionen und Zuständigkeiten dieser drei Komponenten sind klar. Ihre Interaktionen untereinander lassen sich aber in einem gewissen Rahmen flexibel koordinieren und einzelne Aufgaben an den Schnittstellen in vielen Fällen jeweils der einen oder der anderen Komponente zuweisen.

Google Cloud hat folgende Interaktionsmuster getestet: 

• Interaktionsmuster 1: Apigee als Koordinator 

Bei diesem Interaktionsmuster koordiniert Apigee die Authentifizierung der Endnutzer*innen mit der Identitätsplattform und ihre Autorisierung und Zustimmung mit dem Consent Management Service. Apigee dient also als Vermittler zwischen den Nutzer*innen, ihrer Identität und ihrer Zustimmungsentscheidung. 

• Interaktionsmuster 2: Der Consent Management Service abstrahiert die Identitätsplattform 

In diesem Fall verwaltet der Consent Management Service alle Interaktionen mit der Identitätsplattform, die hier als Vermittler dient. Apigee interagiert nur mit dem Consent Management Service.

Die drei Komponenten arbeiten mit einem gemeinsamen Pool von Client-Apps und Endnutzer*innen. Eine dieser Komponenten wird zur Informationsquelle bestimmt, mit der die anderen die benötigten Informationen synchronisieren. 

Dabei stellt zumeist die Identitätsplattform die Informationen zu den Identitäten der Endnutzer*innen bereit, während der Consent Management Service sie abruft und synchronisiert.

Der Consent Management Service dient wiederum als Informationsquelle für den Opt-in- und Consent-Status der Nutzer*innen. Apigee überprüft bei jeder eingehenden Anfrage entweder die auf dem Server hinterlegte Zustimmung oder – was effizienter ist – die wesentlichen Consent-Attribute anhand der in Apigee selbst gespeicherten Informationen. Um die Konsistenz zu wahren, sollte der Consent Management Service beim Widerruf einer Zustimmung beispielsweise über ein Consent Dashboard veranlassen, dass Apigee die mit ihr verknüpften Tokens für ungültig erklärt.

Für Client-Apps kann entweder Apigee oder der Consent Management als Single Source of Truth dienen und die jeweils andere Komponente die Informationen synchronisieren. Insbesondere im Zusammenhang mit Open Banking müssen Finanzinstitute nach den geltenden Standards häufig die dynamische Client-Registrierung unterstützen. Dies bedeutet, dass Endpunkte vorhanden sein müssen, über die sich neue Clients selbstständig bei der Open-Banking-API registrieren können. In diesem Fall kann die Synchronisierung der Clients problemlos in die dynamische Client-Registrierung eingebunden werden.

Sehen wir uns nun die Interaktion der drei Komponenten genauer an. Hier sind insbesondere zwei Abläufe relevant:

Ablauf Eins: Authentifizierung, Autorisierung, Zustimmung

Dies ist der typische Ablauf, wenn die Client-App eines Drittanbieters genutzt wird, die Zugriff auf die Daten der Nutzer*innen benötigt. Die Drittanbieter-App muss sich authentifizieren und die Genehmigung für den Zugriff auf die Daten der Nutzer*innen anfordern. Daraufhin wird die Nutzerin oder der Nutzer authentifiziert und die Zustimmung eingeholt. Mit dieser Zustimmung werden dann weitere Operationen der App im Namen der Nutzerin oder des Nutzers autorisiert und die betreffenden Konten aufgelistet. Als Beleg für die Zustimmung dient ein Zugriffstoken, das die App zusammen mit allen weiteren Anforderungen übermitteln muss.

Dieser Ablauf ist ziemlich komplex und umfasst viele Schritte, die seiner Sicherheit dienen. Um ihn verständlicher zu machen, werden wir einige dieser Schritte vereinfachen – die OIDC/FAPI-Expert*innen unter unseren Leser*innen mögen uns das bitte verzeihen. 

Der Ablauf umfasst folgende Schritte:

1. Die Nutzerin oder der Nutzer ruft eine App auf.
2. Die App fragt einen Zugriff auf die Daten der Nutzerin oder des Nutzers an.
3. Die Identitätsplattform (kurz: IdP) authentifiziert die Nutzerin oder den Nutzer.
4. Der Consent Management Service holt die Zustimmung der Nutzerin oder des Nutzers ein.
5. Der App wird ein Zugriffstoken mit den autorisierten Berechtigungen, Konten usw. sowie ein Aktualisierungstoken ausgestellt. Dieses Aktualisierungstoken ist deutlich länger gültig (mehrere Tage oder Monate) als das Zugriffstoken (wenige Minuten). Mit seiner Hilfe kann die App ein neues Zugriffstoken erhalten, ohne den Authentifizierungs-, Autorisierungs- und Zustimmungsprozess erneut durchlaufen zu müssen.

Die Koordination dieser Schritte hängt vom Interaktionsmuster der Komponenten ab.

Muster Eins: Apigee koordiniert alle Interaktionen

Apigee erfasst die Zugriffsanfrage des Clients und leitet die Client-App an die IdP-Anmeldeseite weiter. Nachdem sich die Nutzerin oder der Nutzer angemeldet hat, gibt die IdP einen Autorisierungscode an die Callback-URL zurück, die Apigee in der IdP-Konfiguration registriert hat.

Anschließend leitet Apigee die Client-App an den Consent Management Service weiter, der das Zustimmungsformular anzeigt. Sobald die Nutzerin oder der Nutzer die notwendigen Berechtigungen erteilt und die betreffenden Konten ausgewählt hat, übermittelt der Consent Management Service den aktualisierten Consent-Status über die in der Consent-Konfiguration registrierte Callback-URL an Apigee.

Nachdem die Endnutzerin oder der Endnutzer sich authentifiziert und die Zustimmung erteilt hat, kann Apigee nun einen Autorisierungscode ausstellen und diesem alle benötigten Informationen zuordnen. Dies sind beispielsweise Details zur Zustimmung, der Autorisierungscode der Identitätsplattform (IdP) und die Identifikation der Nutzerin oder des Nutzers in der IdP. Diesen Autorisierungscode gibt Apigee dann über einen Callback-Endpunkt an die Client-App zurück, den diese bei der Registrierung in Apigee bereitgestellt hat.

Anschließend tauscht die App den Autorisierungscode gegen ein Zugriffstoken ein. Von der IdP erhält auch Apigee ein Zugriffstoken und aktualisiert den Consent-Status, bevor es dem Client seinerseits ein Zugriffstoken ausstellt.

Muster Zwei: Der Consent Management Service als Zentrum der Architektur

Bei Muster Zwei kommuniziert Apigee nur mit dem Consent Management Service, der als Autorisierungsserver für die App dient und die gesamte Interaktion mit der IdP koordiniert.

Wenn der Client eine Zugriffsanfrage stellt, übergibt Apigee diese an den CMS. Der CMS erfasst die Anfrage und leitet die Client-App an die IdP-Anmeldeseite weiter. Nachdem sich die Nutzerin oder der Nutzer angemeldet hat, gibt die IdP einen Autorisierungscode an die Callback-URL zurück, die der CMS in der IdP-Konfiguration registriert hat.

Daraufhin zeigt der CMS das Zustimmungsformular an. Sobald die Nutzerin oder der Nutzer die Zustimmung erteilt und die gewünschten Berechtigungen und Konten ausgewählt hat, gibt der Consent Management Service über die in der CMS-Konfiguration registrierte Callback-URL einen Autorisierungscode an Apigee zurück.

Der weitere Ablauf ist derselbe wie oben beschrieben: Apigee stellt einen Autorisierungscode aus, ordnet ihm alle nötigen Informationen zu und gibt ihn über einen Callback-Endpunkt an die Client-App zurück. Anschließend tauscht die App den Autorisierungscode gegen ein Zugriffstoken ein. Apigee erhält ein Zugriffstoken vom CMS und stellt dem Client anschließend seinerseits ein Zugriffstoken aus.

Sehen wir uns nun den anderen Ablauf an:

Ablauf Zwei: Zugriff auf freigegebene Daten 

Nachdem die Drittanbieter-App autorisiert wurde, fordert sie die Daten der Nutzerin oder des Nutzers an – beispielsweise die Liste der Konten oder der Saldo eines bestimmten Kontos. 

Beim Eingang dieser Anfrage müssen eine Reihe von Prüfungen vorgenommen werden: Ist diese Drittanbieter-App noch autorisiert? Wurde ihr die Berechtigung für die angeforderte Operation erteilt? Ist das betreffende Konto in der Liste der autorisierten Endnutzerkonten verzeichnet? Alle diese Punkte kann Apigee anhand des von der Drittanbieter-App vorgelegten Zugriffstokens überprüfen. 

Es gibt aber eine weitere Prüfung, für die mehr als eine Untersuchung des Tokens notwendig ist: Was ist, wenn die Nutzerin oder der Nutzer die ursprünglich erteilte Zustimmung zwischenzeitlich widerrufen hat? Das ist nämlich nicht nur in der App selbst, sondern beispielsweise auch bei einer Überprüfung der allen Apps erteilten Zustimmungen in einem Consent Dashboard möglich, das über eine Online-Banking-Website oder andere Kanäle aufgerufen werden kann. In dem Fall ist das Token bei der Anfrage der Daten von Nutzer*innen durch die App noch gültig, obwohl die Zustimmung bereits widerrufen wurde. Deshalb fragt Apigee bei diesem Ablauf beim Consent Management Service nach, ob die Zustimmung noch gilt. Häufig wird dieser Vorgang optimiert, beispielsweise indem der Consent Management Service beim Widerruf einer Zustimmung über andere Kanäle veranlasst, dass Apigee die mit ihr verknüpften Zugriffs- oder Aktualisierungstoken für ungültig erklärt. Wenn dieser Sicherheitsmechanismus aktiviert ist, muss Apigee lediglich das Zugriffstoken validieren, um anhand der gespeicherten Consent-Informationen festzustellen, ob eine Anfrage zulässig ist.

Das folgende Schaubild zeigt einen Überblick der erforderlichen Interaktionen zwischen Apigee und dem Consent Management Service. Die Interaktion an sich ist bei beiden Mustern grundsätzlich gleich.

Die nächsten Schritte?

In diesem Beitrag haben wir Apigee, den Consent Management Service und die Identitätsplattform als grundlegende Komponenten einer erfolgreichen und sicheren Embedded Finance-Lösung beschrieben. Außerdem haben wir uns angesehen, wie diese Komponenten gemeinsam für die Konsistenz und Verfügbarkeit der Consent-Informationen der Nutzer*innen sorgen. Beide hier beschriebenen Interaktionsmuster wurden geprüft und haben sich in der Praxis bewährt. Doch welches ist das Richtige für Sie? Das hängt letztlich von Ihren individuellen Anforderungen, Ihrem Consent Management Service und Ihrer Identitätsplattform ab.  

Als Faustregel gilt: Falls Sie mehrere Anwendungen, Identitätssysteme und Consent-Informationsquellen nutzen, sind Sie mit einer Architektur, bei der Apigee im Mittelpunkt steht, bestens bedient. Wenn Sie einen Consent Management Service für ein Open-Banking-System nach behördlichen Vorschriften suchen, bietet CloudEntity eine gute Lösung, die als Certified Financial-grade API (FAPI) OpenID Provider auch über Profile für die verschiedenen Open Banking-Standards verfügt. Die Integration von CloudEntity mit Apigee folgt Muster Zwei.

Weitere Einzelheiten zu den Angeboten von Clarip und CloudEntity sowie zu ihrer Zusammenarbeit mit der GCP finden Sie hier:

• Clarip: Universelle Consent-Management-Plattform – GDPR

• CloudEntity: Zertifizierte OpenBanking- & Consent-Lösung (UK, Brasilien und Australien) für Großunternehmen

Weitere Informationen zum Apigee API Management finden Sie unter https://cloud.google.com/apigee. Informieren Sie sich auch über unsere Banking-Lösungen für das Privatkundengeschäft, oder wenden Sie sich an unseren Vertrieb.