Sechs Alternativen zur Realisierung einer PSD II-Schnittstelle – Ein Vorschlag für Zyniker

PSD II ist die Novelle der Payment Services Directive (PSD II) der EU zur “Erhöhung des Wettbewerbs“, die zum 1.1.2018 auch in deut­sches Recht über­nom­men wur­de. Er­gän­zend zu die­ser gibt es so­ge­nann­te “re­gu­la­to­risch tech­ni­sche Stan­dard­s“ (RTS). Die­se darf die Eu­ro­päi­sche Ban­ken­auf­sichts­be­hör­de (EBA) in Ko­ope­ra­ti­on mit den na­tio­na­len Auf­sichts­be­hör­den und der Eu­ro­päi­schen Zen­tral­bank (EZB) de­fi­nie­ren; sie wer­den  dann der EU-Kom­mis­si­on vor­ge­legt und mit­tels ei­nes de­le­gier­ten Rechts­ak­tes an­ge­nom­men. Nun gibt es wohl mindesten sechs Möglichkeiten, die Regulierung zu interpretieren. Der Pra­xis-Kom­men­tar mit Au­gen­zwin­kern.

von Dr. Peter Bohnenkamp

Wir wollen hier nicht die Sinnhaftigkeit der Regelung an sich und in den speziellen Details diskutieren und auch nicht die Wege, auf denen sie entstehen. Aber als Kunde einer Bank mag der Autor es gar nicht, wenn „irgendwelche Dritten“ – wer immer dies auch sein mag, Behörden, aber auch kommerzielle Datenanalyse-Zwischenhändler oder sonst wer – seine Kundendaten sehen können, ja nur ein bekannter technischer Zugangsweg dazu existiert.

Deswegen würde er auch die „Credentials“ für das eBanking nie weitergeben; ja, er hat gar keine (ungeöffnet vernichtet, als er sie ungefragt von der Bank zugesandt bekommen hat) und dazu inzwischen auch eine Bestätigung der Bank (schriftlich, nach viel Mühen erreicht), dass sein Konto nicht <onlinefähig> ist.

Er hat also persönlich keine Probleme mehr mit dem Thema PSDII-Schnittstellen, über die (bei einer Behörde, in Deutschland der BaFin) gemeldete „Dritte“ (a) Die Kontenumsätze abfragen oder (b) Überweisungen tätigen dürfen im Namen des Kunden auf seinen „onlinefähigen“ Konten (wenn die Endkunden zustimmen / naiv genug sind, den Dritten Credentials – also Benutzername und Password ihres eBanking-Zugangs – zu überlassen / oder einzugeben auf Seiten der Dritten und dazu ggf. auch eine (einmal) „TAN“ je Transaktion, die sie von der Bank erhalten haben).

Der sog. RTS zur PSDII ist nun in der finalen Abstimmung in Brüssel; dieser regelt, wie denn die Banken diese Abfragen (kostenlos, man beachte!) zulassen, ja unterstützen müssen.”

Durch die EU-Kommission ist er noch nicht. Aber man muss davon ausgehen, dass er im Februar Wirklichkeit wird, Dann muss man in 12 Monaten als Bank etwas zum Testen durch die Dritten anbieten… Sie dürfen – vereinfacht gesagt – die Dritten dabei nicht „diskriminieren“, d.h. schlechter stellen, als wenn der Kunde es im eBanking seiner Bank selbst durchführen würde.

Als Bank verliert man hier den direkten Zugang zu den Kunden (mal ganz von den Sicherheits-problemen abgesehen, die damit für das eBanking produziert werden); bekanntlich sind Daten im Zeitalter der Digitalisierung ein „kommerzieller Schatz“; den Schatz anderer Leute verschenken, konnten und können Politiker immer schon gut…. Wenn Sie dies als Bank nicht so sehen und es ihnen egal ist, was die Kunden „so treiben“ – ok, dann haben sie nur noch das Problem, wie man das Thema elegant im Sinne von minimiertem Aufwand abwickelt, denn wie gesagt, Geld bekommen Sie keines für die Herausgabe der Daten.

Zyniker könnten sagen: Was will er eigentlich – es ist heute / seit Jahren in Deutschland doch schon so? Da nutzen clevere Dritte auch die FINTS-Schnittstelle, die die meisten dt. Banken freiwillig aufgemacht haben, damit „offline Clients“ (also Programme auf den Rechnern der Kunden) an Daten kommen, oder sie gehen mit den Credentials der Kunden in die eBanking-Oberflächen der Banken und lesen die Daten mittels „Screenscraping“ aus. Stimmt.

Deswegen sind i.Ü. auch die erfolgreichen „Dritten“ am Markt gegen die Regelung, denn damit müssen sie auf eine (oder gar viele – siehe unten) neue Schnittstelle(n) gehen und dürfen Screenscraping nur nutzen, wenn erstere nicht funktioniert („5x in 30 Sekunden“ steht im RTS – was immer das dann praktisch auch heißen mag, ist offen).

Selbst die Banken sind schizophren, denn wenn sie in ihren eBanking-Lösungen selbst „Multi-Banking“ anbieten, dann machen sie nichts anders als die Dritten (d.h. saugen die Daten von anderen Banken ab).”

Soweit die Ausgangslage… Kommen wir jetzt damit zum  Kern. Was kann man als Bank nun machen? Wir bieten im Folgenden sechs Ansätze, mit dem Thema umzugehen… von anarchistisch bis gutgläubig. Wie man sehen wird, sind alle – weniger eine technische – viel mehr eine geschäftspolitische Frage:

1. Keine gesonderte Schnittstelle bauen, die „Die Dritten sollen doch Screenscraping auf dem normalen eBanking machen“
Nein, so stimmt dies natürlich nicht. Der offizielle Text lautet:  „Die Schnittstelle der xx-Bank ist das Kunden-eBanking. Als Dritte können sie sich hier auch anmelden und Daten mit entsprechenden technischen Hilfsmitteln auslesen.  Wie unsere Kunden auch, müssen sie dabei eine TAN eingeben, um z.B. auf die Kontenumsatzanzeige zu gelangen (diese wird auf das vom Kunden gewünschte Endgerät bei Eingabe der Credentials ausgeliefert; er kann sie dann z.B. auf einer ihrer Webseiten eingeben)“.

Nein, letzteres ist keine Diskriminierung. Die Kunden müssen es auch. Ja, auch in der Nacht  (wenn sie versuchen, dann automatisierte Abfragen laufen zu lassen….)

Ja, wir sind hier „netter“ als die PSDII-Regelung, da wir nicht versuchen, von Ihnen als „Dritter“ ein Zertifikat zu erlangen, um zu prüfen, ob Sie denn zugreifen dürfen… Wir gehend davon aus, dass unsere Kunden ihre Credentials schon nicht an unseriöse Firmen geben (Da kann man als Bank-Manager entspannt sein, die Dritten werden sich deswegen wohl kaum beschweren…)

Das kostet bisher gar nichts – wenn Sie als Manager gelaunt sind, können sie ja noch ein wenig Geld darin investieren, dass sich leider das Bildschirm-Layout unmerklich für den normalen Nutzer (Aber auch für ihn! Keine Diskrimierung also!) gelegentlich leicht verschiebt oder mal die Feldnamen ändern oder die Feldreihenfolge… das macht doch Spaß…

Der Nachteil der Lösung: Die Dritten sehen alles im eBanking und könnten sich unbemerkt auch z.B. Depot-Daten auslesen: Dies ist daher die „Zyniker“ Variante für Spezial-Banken, deren Kunden „Ihren Haupt-Zahlungsverkehr sowieso bei der Sparkasse machen“ (und deren Laune daher nicht davon abhängig Ist, ob sie die Daten der xx-Bank in Dritt-Apps einfach sehen können).

2. Das Zertifikats-gesicherte Kunden-ebanking ist die Schnittstelle
Neben der TAN (die auch die Kunden ja eingeben müssen – siehe 1) wird hier in der eBanking-Anmeldung (über die der Dritte zum Screenscraping kommt) ein Feld ergänzen, in das der Dritte sein „Zertifikat“ eingeben/einlesen kann. Das Zertifikat wird dann ordentlich geprüft.

Damit erfüllen wir – mit wenig Aufwand – diese PSDII-Vorgabe, weil wir ja vielleicht gar nicht „netter“ sein dürfen … ansonsten sind die Nachteile wie bei 1.

Dies ist die daher die „Zyniker-light“ Variante für Spezial-Banken, deren Kunden „Ihren Haupt-Zahlungsverkehr sowieso bei der Sparkasse machen“.

3. Ein Zertifikats-gesicherter, auf die PSDII-Themen begrenzter Ausschnitt des Kunden-ebanking ist die Schnittstelle.
Anmeldung wie bei 2: TAN/Zertifikat – dann werden den Dritten allerdings nur die „Konto- Umsatzanzeige“ und das Überweisungsformular, das die Kunden sonst auch sehen, angezeigt  (mehr muss man ja nicht – damit sind die PSDII-Erfordernisse erfüllt! Dies ist keine Benachteiligung). Man löst damit gegen Einwurf von eher kleinem Geld das Problem von 1 und 2, dass der Dritte ggf. zu viel sieht; man stellt auch fest, welche Kunden eigentlich Geschäft über Dritte machen und kann ggf. darauf reagieren.

Hier kann man nun auch die Sub-Option nutzen, eine „Umsatzanzeige“ (basierend auf dem Tagesabschluss des Vortags ohne sog.  „Vormerkungen“ etc.) anzuzeigen. Damit dies keine Diskriminierung ist, muss man im eBanking der Kunden dann auch zwei Arten von Abfragen anzeigen (A) Umsatzanzeige (wie hier) und (B) eine „Liquiditätsvorschau“ (die dann mehr weiß – aber diese ist nicht PSDII-relevant…)

Das ist die „High End Trixer“ Variante – viel Nutzen mit ganz wenig Einwurf von Geld  (dies ist ein Lob aus Sicht des Autors!)

Wenn viele Banken die Lösungen 1-3 umsetzen, dann wird der Aufbau einer Multi-Banking-App ein anstrengendes Thema (denn der „Dritte“ muss dann viele Screenscraper schreiben und permanent pflegen) und kann Anfragen auch nur „Live“ zusammen mit dem Endkunden stellen (wegen der TAN-Eingabe, die wir aus Sicherheitsgründen immer benötigen, jaja). Diese können sich dann wenigstens halbwegs sicher sein, dass die Drittem ihre Daten nicht einfach so absaugen oder jemand den Zugangsweg sonst „knackt“. Da haben wir den Wettbewerb doch schön erhöht – Die Dritten müssen eben besser sein…

4. Eine einfache proprietäre „Rest“-Schnittstelle (mit selbst definierten Feldern)
… bei der dann im Workflow erfolgen:  (a) Prüfung Zertifikat des Anfragenden, (b)  Prüfung Credentials des Kunden, die mitgeliefert werden  (c) Versenden TAN an Kunden / Prüfen der Rückmeldung II des Anfragenden (TAN-Rückmeldung) (D)  Antwort an Anfragenden

Wobei für jede Anfrage – sowohl Kontostand als auch Überweisung – eine TAN verlangt wird (setzt voraus, dass der Kunde im eBanking bei Anmeldung auch eine TAN eingeben muss – damit wäre es gleich). Inhaltlich gibt es bei Umsatzanfragen nur wirklich gebuchte Sätze (keine Vormerkungen) zum Tagesabschluss des Vortages. Damit dies keine Diskriminierung ist, muss man im eBanking der Kunden auch zwei Arten von Abfragen anzeigen (siehe bereits 3).

Wenn die Schnittstelle nicht läuft, kann/muss der Anfragende auf das normale eBanking gehen (für Screenscraping).

Das ist Langweilig-Variante: „Wir müssen doch eine ordentliche API anbieten” – „auch wenn wir es nicht gern sehen/wollen“. Das kostet deutlich mehr Geld, da die Schnittstelle rund um die Uhr betrieben werden muss (Add-on zum eBanking und zur FINTS-Schnittstelle, die nicht wegfallen kann, weil sonst die wirklichen Kunden mit ihren Offline-Programmen keine Daten mehr bekommen würden). Ist aber wenigstens ein bisschen „Fun“, denn die Schnittstelle ist „proprietär“ und muss von den Dritten separat bearbeitet werden.

5. Eine Schnittstelle mit Technik-/ Feld-Struktur auf Basis einer öffentlichen Spezifikation z.B. der „Berlin Group Spezifikation“
Hier muss man sich nichts ausdenken (wie bei 4), sich dafür aber an Konventionen halten (und macht es den Dritten leichter, weil sie dann mit einer Version mehrere Banken erreichen können).

Nutzt man die Subversionen wie vorstehend  (A) TAN auch für Umsatzabfragen und  (B) Informationsmenge beschränkt bei Umsatzabfragen – dann ist es die „Wasch mich, aber mach mich nicht nass“ Variante für ängstliche Manager (die glauben, dass die EU sowieso sonst in x Jahren kommt und das Gesetz nach Gutdünken – nach Lobbying mancher (aber nicht aller, man beachte) „Dritter“ – in diese Richtung anpassen wird).

6. Eine Schnittstelle mit Technik- / Feld-Struktur auf Basis einer öffentlichen Spezifikation z.B. der „Berlin Group Spezifikation“
… also wie 5 – aber: Keine TAN bei Umsatzabfrage (damit auch keine TAN bei Anmeldung im eBanking) – oder wenigstens große Zeiträume für „Mandate“, in denen dann TAN-frei Abfragen auch in der Nacht, ohne dass der Endkunde es merkt, erfolgen können. Dazu: schöne, brandaktuelle Informationen in der Umsatzabfrage.

Ggf. sogar:  Dann auch noch andere Informationen zur Abfrage – gegen Geld allerdings hier – anbieten (insb. das Depot mit enthaltenen Werten und Umsätzen sind hier für alle am Markt interessant, oder gar auch die Kredite, die der Kunde hat, mit ihren Parametern, oder einfach „Identity-Daten“ wie Alter, Personalausweisnummer, die die Banken aus den Geldwäsche-Vorgaben haben). Da wird die Bank dann zum „Datenhändler“… Das freut dann sicher auch den letzten Endkunden der Bank, wenn seine Daten zur Ware werden (und es irgendwo im Kleingedruckten der AGBs steht, dass er zustimmt, dass diese es darf, ohne ihn einzeln zu fragen).

Wer das macht, ist (a) entweder ein Verbrecher (Verkaufsversion) oder hat (b) Angst vor seinen Endkunden, die alle gern und viel via Dritte machen (und davor dass diese die Bank wechseln, wenn die Dritten gegenüber den Kunden jammern“ sonst)  oder er glaubt (c) an das Christkind, das immer noch da ist und etwas von der Sinnhaftigkeit digital-virtualisierter Ökosysteme im Glühwein-Wahn erzählt…

Ok, machen alle 5 oder 6, werden sich einige „Dritte“ sicher ärgern, denn dann kann auch die letzte IT-Abteilung einer Bank mit wenig Aufwand selbst ein „aktives Multi-Banking“ aufbauen, das man als Bank in seinem eigenen eBanking dann anbietet. Das ist dann eine ganz besonders schöne Erhöhung von Wettbewerb, oder?

Fazit

Lassen Sie sich als Bank nicht einschüchtern – Regulationen sind dazu da, intelligent interpretiert zu werden; lassen sie sich als Kunde einer Bank aber auch nicht austricksen (weder von Dritten, die nur ihre Daten wollen, noch von Banken, die diese gern verkaufen würden).Dr. Peter Bohnenkamp