Der Kongress ist in seiner ersten Durchführung insofern interessant, weil er tiefer geht als vergleichbare Veranstaltungen. Tiefer in Bezug auf Compliance, Integration und damit auch Technik. Unser Korrespondent, Oscar Neira, war in London mit dabei und teilt seine Notizen.
PSD2 Implementation Congress
Auf den Wegen durch London und zum Kongress sticht vieles ins Auge, eines ganz besonders: Brexit hin oder her, was da insbesondere im Gebiet der Canary Wharf an Betriebsamkeit und Baukränen sichtbar ist und Neues entstehen lässt, ist einfach imposant. Man hat das Gefühl, die ganze Stadt ist in Aufbruchstimmung.
Es gibt offensichtlich viele Investoren, die an eine erfolgreiche Zukunft von London und von UK glauben.
Regulation und Security
Der Tag startet direkt mit dem Thema Regulation: Rui Pimentel, Head of Unit Payment Systems bei Banco de Portugal und Corinna Scatena, Legal and Compliance Officer bei Ferratum Bank in Malta, präsentieren die wichtigsten Punkte, welche bei der PSD2 eingehalten werden müssen.
Die Direktive muss in den EU- und EWR-Mitgliedsländer bis 13. Januar 2018 in nationales Recht umgesetzt werden. Die technischen Massnahmen nach Artikel 65, 66, 67 und 95, welche von der EBA als Regulatory Technical Standards (RTS) herausgegeben wurden, haben Zeit bis November 2018 für die Einführung. Die Schweiz kann, muss aber diese Direktive nicht übernehmen.
Warum wurde diese Direktive geschaffen? Das Europäische Parlament will damit folgende Ziele erreichen:
- Wettbewerb erleichtern (indem Barrieren aufgehoben werden)
- Innovation ermöglichen
- Zusätzlicher Beitrag zu einem einzigen EU-Zahlungsverkehr-Markt
- Verbraucherfreundlichkeit erhöhen
- Kosten im Zahlungsverkehr reduzieren
- Konsumentenschutz verbessern
- Sicherheit erhöhen
Die neuen Akronyme
Durch PSD2 entstehen neue Namen und Akronyme oder bereits bestehende werden in einen zusätzlichen Kontext gesetzt. Hier eine Übersicht:
- AIS: Account Information Services
Ein Service, meistens eines Drittanbieters, der dem Konsument elektronisch die aktuellsten Kontostände aller seiner Bankkonten bekannt gibt. - AISP: Account Information Service Provider
So nennt sich der regulierte Drittanbieter (PSP) der Zugriff auf die Kontoinformationen, bekommt um diese dem Kunden in einer Kundenfreundlichen Form bekannt zu machen. - API: Application Programming Interface
Das Wort API wird bei PSD2 nicht direkt erwähnt. Eine API kann als Bankenservice verstanden werden, der den Programmierern dieser neuen Produkte zur Verfügung gestellt wird. - ASPSP: Account Servicing Payment Service Provider
Vertragspartner des Endkunden, welcher dem Kunden die technischen Möglichkeiten gibt um seine Kontoinformationen zu beziehen. Kann auch einem TPP Zugang geben. - PIS: Payment Initiation Service
Ein Service, meistens eines Drittanbieters, welcher über Direktzugriff auf das Konto des Konsumenten eine Zahlung ausführen kann. - PISP: Payment Initiation Service Provider
So nennt sich der regulierte Drittanbieter, der Zugriff auf die Kontodaten bekommt, um auf dem Kundenkonto eine Zahlung auszuführen. - PSP: Payment Service Provider
Vertragspartner des Endkunden, welcher dem Kunden die technischen Möglichkeiten schafft, um seine Zahlungsaufträge direkt elektronisch auf seinem Konto aufzugeben. Kann auch einem TPP Zugang geben. - RTS: Regulatory Technical Standards
Eine Rechtsinterpretation und Spezifikation der PSD2, welche durch die EBA erarbeitet wurde und durch den Europäischen Kongress abgesegnet worden ist. Im Gegensatz zu anderen Dokumenten, wie Guidelines oder Recommendations, sind die RTS rechtsbindend und müssen so eingeführt werden. - SCA: Strong Customer Authentication
Die Anmeldung an die Services muss mindestens zwei Elemente beinhalten. Diese werden wie folgt kategorisiert:
- Kenntnis (etwas, was nur der Benutzer wissen kann)
- Besitz (etwas, was bloss der Benutzer besitzt)
- Inhärenz (etwas, was der Benutzer ist oder ihn einzigartig macht) - TPP: Third Party Provider
Die “Drittpartei” welche durch die Kundenfreigabe Zugriff auf die Kundenkonten bekommt um einen Zahlungsauftrag auf dem Konto zu platzieren oder die aktuellen Kontoinformationen bekommt um diese dem Kunden bekannt zu geben. - XS2A: Access to Account
Beschreibt die beiden neuen Dienstleistungen (AIS und PIS).
Im Kontext dieser Akronyme schreibt die EU also vor, dass ein Online-Zugriff auf die Konten (Anbieter-) neutral, sicher und benutzerfreundlich sein soll. Sie will damit die Konkurenz unter den Banken und neuen Anbietern fördern.
Elektronische Identifikation, Authentifizierung und Fraud
Ein riesiges Thema ist die elektronische Identifikation (also ist es wirklich diese Person, welche sie vorgibt zu sein, vor allem beim erstmaligen Nutzen des Services, sprich onboarding) und danach jeweils die Authentifizierung der Person (also wie kann ich mich nachher beim Dienst anmelden).
Kannan Rasappan, IT Architekt und Developer bei HSBC, referiert äusserst ausführlich und detailliert über die Standards-Based Security und dass man natürlich die Implementation up to date halten muss.
Ein wichtiger Punkt der RTS ist die Strong Customer Authentication (SCA). Diese Anforderung stellt eine grössere Hürde für Startups dar, ist jedoch für die Sicherheit der Kunden wichtig. Dies reduziert die Fraud-Möglichkeiten. Natürlich müsse man sich auch hier Gedanken machen über die richtige Methode, denn zum Beispiel ein einmalig zugestellter Code per SMS ist online in Ordnung, für eine POS-Zahlung im Laden jedoch überhaupt nicht tauglich.
Neben den technischen Herausforderungen sieht Rasappan beim Kunden-Onboarding und bei der Ausbildung der Kunden und involvierten Parteien die grössten Hürden.
Die nationale elektronische Identität
Was die nordischen Länder dem Rest von Europa voraus haben, ist eine nationale elektronische Identität. In Norwegen hat sich die Finanzindustrie nicht nur auf ein gemeinsames Identifizierungssystem geeinigt, freut sich Ole Petter Aasen, Head of Intergration and Trust Services von Spare Bank 1, die Gemeinsamkeiten gehen noch weiter. Zum Beispiel besteht ein gemeinsamer Anforderungskatalog mit der Auswirkung: Egal welche Bank die elektronische ID herausgibt, diese ist dann überall gültig. Das System ist sogar für "Nicht-Banken"-Implementationspartner offen und wird teilweise auch von Behörden genutzt und akzeptiert. Der Einsatzbereich bei den Banken ist breit: Zahlungsverkehr, Kreditkarten, Verhinderung von Betrug und Erhöhung der Sicherheit (Fraud and Security).
Wie Aasen demonstriert, existieren unzählige Bereiche, für die eine schnelle und einfache Identifizierung der Person und die Auslösung einer Zahlung Zeitgewinne und Vereinfachungen bringen. Zum Beispiel in Solarien. In Norwegen besteht eine Alterslimite für das Solarium. Da die Solarien meist im Self Service funktionieren und unbedient sind, ist solch eine Funktion natürlich optimal.
Der KYC-Prozess gehört in Norwegen durch die Digital Identity schon seit längerem nicht mehr zu den "Painful"-Prozessen.
GDPR vs. PSD2
Sailesh Panchal, Head Of Regulatory Technology bei Lloyds Banking Group, empfiehlt, die GDPR, sprich General Data Protect Regulation, nicht zu vergessen. Darin liegen Widersprüche, die es zu bewältigen gilt. Data Protection vs. Open Banking. Consent, Data Control und Pseudonymised Data heissen die Zauberworte in diesem Kontext. Weiter erklärt Panchal die Wechselwirkungen zwischen einem PSP und TPP und dass ein neues Geschäftsmodell eines PSP auch TPP-as-a-Service sein könnte. Interessanter Gedanke.
Gefragt: Schnell skalierbare Systeme
Den Weg von einem Legacy System aus dem 20. Jahrhundert zu einem 21. Jahrhundert-System mit API Layer, demonstriert Tim Vincent, Solution Engineering Team Lead bei Datastax. Wichtig deshalb, weil dank PSD2 nicht nur Kunden im eigenen Land als potenzielle Nutzer infrage kommen, vielmehr können Kunden in ganz Europa gewonnen werden. Das heisst für die Bank, sie braucht ein schnell skalierbares System. Die Verwaltung grosser neuer Datenmengen stellt Anforderungen und Kunden wollen ein schnelles System.
Dem IT-Architekten, der neben dem Schreiber sass, sah man das Interesse und vielleicht auch Bewunderung im Gesicht an. Er meinte, dass er es auf diese Art noch nie gesehen hätte, es aber durchaus Sinn mache und er die neuen Erkenntnisse auf jeden Fall in die Überlegungen einfliessen lassen werde.
Open Banking und erweiterte Geschäftsfelder
Generelles Thema und breit in der Diskussion: Wieso die Geschäftsfelder mit Open Banking nicht ausweiten, zum Beispiel auf das Kreditwesen? Mit massgeschneiderten Lösungen, die für jeden Bereich angeboten werden, wie Auto-Finanzierung, Motorrad- oder Wohnmobil-Finanzierung. Allein Lloyds Banking Group hat im Jahr 2015 über 300’000 Kunden finanziert, insgesamt mit einem Volumen von rund 4 Milliarden Pfund.
Open Banking öffnet die Türen für Onboarding, Kredit-Screening, Angebot und Abschluss – alles in einer App, welche den Kunden mit der Bank verbindet. Und bindet.
Kunden in der Verantwortung
Ein weiterer wichtiger Punkt, der ein Umdenken in der Bank erfordert, ist für Saqhib Ali, Former Head of Business Data Infrastructure, Consumer Finance Division, dass die Bank an den Kunden die Verantwortung über den Grad der Intensität des Kontaktes abgibt. Es finde also eine Veränderung statt, findet Ali.
"Taking bank information" against "Sharing customer’s information" wird zu "How to use customer information through PSD2 methodologies to serve customers better".
Der Kunde bekommt mehr Verantwortung und muss sich bewusst sein, welche Daten über ihn vorhanden sind und wie er diese Daten in welcher Form im Zusammenhang mit Open Banking für zusätzliche Dienstleistungen zur Verfügung stellen möchte.
Und nochmals: Tempo im Vordergrund
Francis Chlarie, Co-Gründer von iXendar, macht ebenfalls nochmals auf die Wichtigkeit von GDPR (General Data Protect Regulation) aufmerksam. Und auch auf die Tatsache, dass in einem alten IT Legacy Umfeld oftmals sehr "schwere Server-Farmen" operieren, die schlecht in einem schnellen Umfeld mit neuen Anforderungen eingesetzt werden können. Er rät davon ab, einen Omni Channel Layer über die Services zu stellen, empfiehlt vielmehr zuerst einen Daten Hub und danach den Layer einzuführen. Eine Möglichkeit alles viel schneller zu machen.
Einführung und Use Cases
David Rimmer, Driver of Strategy for Financial Services in the UK von Hewlett Packard Enterprise, bringt Analogien aus der Geschichte der Menschheit und zeigt damit, das es immer schon schwierig war, Altes durch Neues zu ersetzen.
Seine Empfehlung: Man sollte sich schnellstmöglich mit den neuen Marktanforderungen beschäftigen und das Thema nicht zwischen der einen und der anderen Abteilung hin- und herschieben. Auch Rimmer vertritt die Haltung: "Tomorrow’s digital bank is an API-based bank".
Die API als Produkt
Welches ist die richtige API? Krzysztof Trojan, Head of Banking and Finance Solutions bei Intive, zum Thema: Es ist wichtig, eine API als ein Produkt zu behandeln und nicht bloss als Schnittstelle zu sehen. Denn für die Entwickler muss es ein bestmögliches Erlebnis sein, sich bei der Bank zu verbinden und eine gute Kundenschnittstelle anzubieten.
Sehr eindrücklich waren Trojans Einblicke in aktuell laufende Entwicklungsprojekte.
Nadine McKoene, Head of Payment Products bei Allied Irish Bank, erwähnt die irischen Einsichten der EY Global Consumer Banking Survey und dass sich die Allied Irish Bank sehr stark hat leiten lassen von diesen Erkenntnissen.
Zum Beispiel: Nur 33 Prozent der Irländer haben komplettes Vertrauen in ihre Hausbank. 40 Prozent sind weder besonders Finanz- noch Digital-orientiert. Aber die Dienstleistungen müssen günstig sein. Und schliesslich haben 4 von 10 Kunden in den letzten 12 Monaten eine Nicht-Bank App benutzt und 6 von 10 planen das auch in naher Zukunft zu tun. Das vor allem auch aufgrund der guten User Experience der Dritt-Applikationen.
Basierend auf diesen Erkenntnissen, ist die Allied Irish Bank sicher, dass ihr API-Programm sich erfolgreich durchsetzen wird.
Speziell erwähnt McKoene, dass am Ende, gesetzlich vorgeschrieben, auch gute Testmöglichkeiten zur Verfügung gestellt werden müssen.
Spezielle "globale" Herausforderungen
Wo die besonderen Herausforderungen eines solchen Projektes liegen, das über verschiedene Ländergesellschaften hinweg eingeführt werden soll, präsentiert Jurate Straupiene, Payment Product Manager bei Swedbank. Sie betont, eine genaue Analyse der jeweiligen Märkte wäre fundamental.
Nicht nur die Anforderungen der Kunden stehen im Vordergrund, führt Straupiene weiter aus, auch die Unterschiede der IT und Prozesse in den jeweiligen Ländergesellschaften müssen beachtet werden. Zudem spielen auch die kleinen "Königreiche" der jeweiligen Leiter eine Rolle, die nicht durchwegs und motiviert mit anderen Länderkollegen zusammenarbeiten wollen – aus Angst, der eigene Job könnte in Gefahr geraten und obsolet werden.
Betrachtungen zum Schluss
Antoine Larmanjat, Gründer von Payconiq, der sich zwei Kongresstage lang Tage als hervorragender Moderator und top Experte für PSD2 bewiesen hat, beleuchtet die Sicht der PSPs, welche aus einer sehr interessanten und gleichzeitig herausfordernden Position heraus operieren.
Interessant, weil sie die Gewinner der PSD2 sind und vermutlich mehr Kunden gewinnen werden. Herausfordernd, weil die Sicherheit gewährleistet werden muss und PSPs diese auch überwachen müssen, was sich sehr schwierig und kompliziert gestalten kann.
Der PSD2 Implementation Congress in London war und ist eine Perle unter den Events zum Thema. Die Vielzahl der Referenten, die unterschiedlichen Betrachtungen aus verschiedenen Positionen sowie die Tiefe der Beiträge und Diskussionen hat zahlreiche Teilnehmer weitergebracht im Thema PSD2. So weit, dass Open Banking motiviert getestet und praktiziert werden kann, weil mit intelligenten Konzepten und bei einer professionellen Implementierung am Schluss auf allen Seiten Gewinner zu finden sind.
Details zum Kongress: PSD2 Implementation Congress
Stichworte zum Thema im Lexikon: PSD2 | API | Open Banking | KYC | Digital Identity