MiFID II war das größte regulatorische Projekt der vergangenen Jahre und hat alle Beteiligten vor große Herausforderungen gestellt. Spätestens mit Verabschiedung der MiFID-II-Richtlinie am 15. April 2014 durch das EU-Parlament kam das Thema auch auf die Agenda der Projektplanungen bei den Banken. Die folgende Darstellung macht deutlich, wie gemeinsame Lösungen durch strukturiertes Teamwork von Banken und Softwareherstellern helfen, regulatorische Anforderungen effizient umzusetzen. Dadurch können Freiräume bei Banken und Providern geschaffen werden, um die dringend notwendige Digitalisierung der Geschäftsmodelle voranzutreiben.
Gerade kleinere Banken stoßen bei der Umsetzung regulatorischer Vorgaben schnell an ihre Kapazitätsgrenzen. Da bei der Umsetzung von regulatorischen Anforderungen im Regelfall die Banken nicht im Wettbewerb stehen, lassen sich hier ganz neue Kooperationsansätze umsetzen, ohne die die Kosten für die einzelne Bank explodieren würden oder die Qualität gefährdet wäre.
Timing und Aufgabenverteilung
Wie bei jedem regulatorischen Großprojekt standen auch bei MiFID II die Banken vor der zentralen Frage, wann der richtige Startzeitpunkt für die Umsetzung ist: Zu früh ist uneffektiv, weil nicht genug Informationen vorliegen, und zu spät darf auch keiner sein. Lange waren nach Verabschiedung des Gesetzes im Jahr 2014 außer dem damals geplanten Endtermin 3. Januar 2017 praktisch keine Details bekannt. Wie soll man auf Basis dieser Informationslage mit der Analyse beginnen? Bei einem frühen Start ist die Gefahr groß, dass im Design von einer falschen Basis ausgegangen wird.
Die Privatbank Hauck & Aufhäuser hat bereits bei ihrer Vorstudie zur Umsetzung von MiFID II die Weichen gestellt: Von Anfang an war klar, dass das Projekt eine bankübergreifende Zusammenarbeit aller Anwenderbanken des genutzten Gesamtbankensystems erfordert, da alle von den gleichen regulatorischen Anforderungen betroffen waren. Gleichzeitig war eine frühzeitige Einbindung der Entwickler des Gesamtbankensystems notwendig.
Doch erst im November 2015 war die Zeit reif, das Thema zu gliedern: Welche Themen betreffen aufgrund des Geschäftsspektrums überhaupt die Anwenderbanken gesamthaft und bei welchen sind entsprechende geschäftspolitische Entscheidungen durch die Banken erst noch zu treffen? Welche Themen müssen durch die Gesamtbankensoftware abgedeckt werden und welche sind außerhalb zu lösen - wie Telefonaufzeichnung oder auch rein organisatorische Fragen?
Die Themen ließen sich schnell strukturieren, aber große Runden waren letztlich zu ineffizient für die detaillierte Projektarbeit. Deshalb wurde die eigentliche Projektarbeit in thematischen Workstreams gebündelt und vom Softwarehersteller vorangetrieben, beispielsweise als Workstream Order Record Keeping, Transaktionsmeldung und Cost Transparency. Ergänzend dazu stimmte die sogenannte Bankenrunde - das heißt die Gruppe der Projektleiter der einzelnen Banken - die Prioritäten ab und versuchte, schon in den Abstimmprozess eine einheitliche Auslegung einzubringen.
Einfache Fragen - komplexe Antworten
Größtes Problem des Prozesses war immer wieder die Frage der Auslegung. Während des gesamten Projekts bestand in sehr vielen Themen eine hohe fachliche Unsicherheit darüber, was exakt die Anforderungen der Regulatoren waren. Folgende zwei Beispiele als Erklärung:
Kostentransparenz: Bei der Pre-Trade-Kostentransparenz war von Anfang an klar, dass die Transaktionskosten aufzunehmen sind. Wie aber sollen andere laufenden Kosten wie Depotgebühren berücksichtigt werden? Zunächst scheinbar ein klarer Fall: Muss auch rein. Aber die Folgefragen ließen (und lassen) sich nur schwer beantworten. Denn wie passt die einfache Grundidee mit den gerade in Privatbanken sehr vielfältigen Gebührenmodellen zusammen?
Es gibt zum Beispiel Flat Fees unabhängig von Depotvolumen, Stufenmodelle abhängig vom Depotvolumen, Beratungsgebühren, die auch den Kontosaldo mit in die Berechnungsbasis einbeziehen (denn dann verändern sich die Kosten ja eigentlich nicht, wenn der Kunde ein Wertpapier kauft oder den Kontosaldo bestehen lässt) - um nur einige zu nennen. Aus einer eigentlich einfachen Frage werden plötzlich zahllose Detailentscheidungen nötig, ohne die keine Entwicklung sinnvoll starten kann. Ohne die entsprechende Markt- und Prüfungspraxis ist es für eine Bank extrem schwer, eine richtige Entscheidung zu treffen. Im Zweifelsfall heißt es dann Abwarten, was aber die Gefahr birgt, dass zum Schluss aus zeitlichen Gründen gar keine Lösung mehr realisiert werden kann.
Meldepflichten: Dadurch, dass auch Devisengeschäfte an als Börsen anerkannten Handelsplätzen abgeschlossen werden, sind sie für das Transaktionsreporting meldepflichtig. Doch woher kommt bei solchen klassischen OTC-Derivaten die dafür in den Schnittstellen nötige ISIN, oder reicht doch eine Produktbeschreibung aus? Viele dieser Entscheidungen mussten auf der grünen Wiese getroffen werden, denn selbst technische Schnittstellenbeschreibungen, praktisch verwendbare Beispiele oder gar konkrete Testmöglichkeiten fehlten.
Ein Projekt von furchteinflößender Größe und Komplexität
Die Hoffnung, dass durch die Verschiebung des Endtermins auf den 3. Januar 2018 vor Beginn der Realisierung klare aufsichtsrechtliche und technische Vorgaben vorliegen würden, erwies sich als falsch. Die nötigen Level-2- und Level-3-Papiere kamen viel zu spät, ohne dass sich der Endtermin geändert hätte. Obwohl auch Anfang 2017 noch bei Weitem nicht alle Fragen geklärt waren, war der Entwicklungsstart unausweichlich. Dass es sich um ein Monstervor haben handelte, war inzwischen allen Beteiligten klar. Die über 500 identifizierten Software-Changes mussten nicht nur entwickelt und getestet, sondern zu den unterschiedlichen Anwenderbanken des gemeinsamen Gesamtbankensystems ausgerollt werden. Auch wenn alle Banken die gleiche Software nutzen, so sind IT-Gesamtinfrastruktur und Geschäftsmodelle der Banken keineswegs homogen.
Trotz des verhältnismäßig späten Projektstarts stellten sich einige der Anfang 2017 getroffenen Annahmen als falsch oder zumindest unvollständig heraus. Durch sporadische Updates der Regulatoren, häufig aber auch durch die zwischen vielen Banken mit unterschiedlichen Systemen bestehenden formellen wie informellen Informationsrunden kamen neue Informationen in das Projekt. Die Komplexität erhöhte sich permanent, die Relevanz war nicht immer abschätzbar und die Auswirkungen auf das Systemdesign manchmal substanziell. Auch wenn im Nachhinein diese neuen Erkenntnisse häufig fachlich richtige Ergänzungen waren, führten sie, je näher der Einführungstermin rückte, auch zu harten Kämpfen.
Unvermeidbare Ineffizienzen
Umso wichtiger ist es, bei solchen Großprojekten unter Zeitdruck den Mut zur Lücke zu haben. Denn die Gefahr, ein Softwarerelease zu überfrachten, ist groß. Bei einer zu hohen Anzahl von Änderungen mit großer Komplexität ist es in den Banken nicht mehr möglich, qualitativ ausreichende Tests durchzuführen. In der Praxis ist nicht nur die Softwareentwicklung, sondern auch der Test der Engpass: Die Qualitätssicherung des Softwarehauses und der Projektteams in den Banken stößt an ihre Grenzen. Für ein idealtypisches Vorgehen, welches Doppelspurigkeiten vermeidet (das heißt Entwicklung, Qualitätssicherung, Pilotkunde mit Pilottests und danach Rollout der Version zu allen anderen Kunden), war im MiFID-II-Projekt keine Zeit mehr. Wenn man die Entwickler in den letzten Monaten von 2017 fragte, was sie gerade tun, war die häufige Antwort "Fehler verteilen". Natürlich war gemeint, dass Fehlerkorrekturen ausgeliefert wurden. Doch dies zeigt das große Maß an Ineffizienzen, was ein Entwicklungsmodell erzeugt, welches aus regulatorischen oder zeitlichen Gründen dazu zwingt, Software auszuliefern, bei der die fachlichen und technischen Voraussetzungen nicht wirklich gesichert sind.
Trotzdem sind alle beteiligten Anwenderbanken rechtzeitig mit dem MiFID- Release produktiv gegangen; die ersten schon im November 2017. Aus der Projektarbeit war ein Miteinander entstanden, was dabei half, die aus dem Produktionsbetrieb entstehenden neuen Gaps zusammen mit alten Wünschen neu zu priorisieren. Inzwischen haben alle an dem Projekt beteiligten Banken entschieden, das MiFID-II-Projekt zu beenden. Doch auch nach Projektabschluss sind Fragen offen, wie etwa die Behandlung von Non-ISIN-Derivaten. Aber ohne neue Informationen ist kein Projektfortschritt möglich und damit kein Projekt mehr nötig.
Das Thema MiFID II beschäftigt die Banken auch weiterhin. So sind sie von den Ex-post-Kostenreportingpflichten betroffen, die in Q1/2019 an die Kunden der Banken verschickt werden müssen. Bei Hauck & Aufhäuser hat man sich dafür entschieden, diese Anforderung im Rahmen eines Folgeprojekts umzusetzen. Genau wie das große Schwesterprojekt wird man hier wieder den Weg einer bankenübergreifenden Umsetzung mit anderen Anwenderbanken und dem Softwarehersteller gehen.
Auch der Regulator arbeitet daran, bestimmte Anforderungen weiter zu verfeinern. So wurde erst Mitte 2018 die Leitlinie zur Geeignetheit von der ESMA veröffentlicht. Es ist anzunehmen, dass die BaFin diese in die deutsche Aufsichtspraxis übernehmen wird. Eine vorläufige Analyse dieser Leitlinie ergab, dass die gerade erst überarbeiteten Beratungsprozesse, WpHG-Bögen und Geeignetheitserklärungen wahrscheinlich noch einmal angefasst werden müssen. Dieser Doppelaufwand innerhalb kurzer Zeit führt neben vielen weiteren Praxiserkenntnissen zu einer großen Verärgerung bei den deutschen Banken.
Das bankübergreifende Design hat sich für alle Beteiligten als Glücksfall erwiesen. Neben der Tatsache, dass dieses Vorgehen die einzig realistische Möglichkeit war, um die Anforderungen von MiFID II bei allen Anwenderbanken rechtzeitig umzusetzen, gab es aus Sicht der Banken auch klare Vorteile durch dieses Modell. Die Entwicklungs- und Umsetzungskosten für die verschiedenen Anpassungen konnten zwischen den Anwenderbanken geteilt werden. Zusätzlich übernahm der Entwickler einen Anteil der Kosten, da die Gesamtbankenlösung nun "MiFID II ready" war. Im Fall von Hauck & Aufhäuser betrug der Aufwand für die technische Umsetzung der Anforderungen rund 1,1 Millionen Euro. Durch die bankenübergreifende Umsetzung konnten schätzungsweise zwei Drittel der IT-Kosten, die bei einem klassischen Vorgehen angefallen wären, gespart werden. Das war eine spürbare Entlastung für das Projektbudget und fördert die Bereitschaft, auch bei künftigen regulatorischen Anforderungen gemeinsame Projekte umzusetzen.
Neben den massiven Einsparungen verbesserte das gemeinsame Vorgehen auch die Qualität des Produkts. Da sich bei der Umsetzung von regulatorischen Anforderungen im Regelfall keine Wettbewerbsvorteile erzielen lassen, war eine offene Zusammenarbeit möglich. Hier gilt es, Anforderungen, die sowieso von jeder Bank erfüllt werden müssen, möglichst effizient umzusetzen.
"Economies of Experience"
Durch die beteiligten Partner ist im Rahmen des Projekts ein breites Informationsnetzwerk entstanden. Jede Bank war Abstimmungen mit Verbänden und anderen Banken eingebunden. Der Systemanbieter arbeitete eng mit zentralen Parteien der technischen Umsetzung wie dem WM Datenservice (www.wmdaten.de) und dem Deutsche Börse Regulatory Reporting Hub zusammen. Die dadurch erreichten "Economies of Experience" sorgten dafür, dass schneller Auslegungshypothesen gebildet und somit frühzeitiger mit der technischen Umsetzung begonnen werden konnte. Auch diese hypothesenbasierte Umsetzung kann daher als Erfolgsfaktor bewertet werden, selbst wenn es sich mit diesem Ansatz nicht hundertprozentig vermeiden lässt, dass einzelne Themen noch einmal überarbeitet werden müssen. Der Zeitgewinn macht diesen Zusatzaufwand mehr als wett.
Wie inzwischen bekannt ist, haben nicht nur die Banken mit MiFID II zu kämpfen gehabt, sondern auch die Infrastrukturanbieter und letztlich der Regulator selbst. Nicht umsonst wurde deshalb die Devise ausgeben, Aufsicht mit Augenmaß zu betreiben. Daher stellt sich die Frage, ob man künftig nach dem Motto "Mut zur Lücke" bei einzelnen Dingen lieber etwas später und dafür aber ordentlicher umsetzt, oder ob man weiterhin versuchen sollte, mit aller Kraft den Stichtag zu halten und dann aufwendig nachzubessern. Gerade wenn man diesen Weg als Bankengruppe geht, gute Gründe in Form einer verbesserten Systemstabilität hat und nachweisen kann, dass man an der Umsetzung intensiv gearbeitet hat, sollte das aufsichtsrechtliche Risiko gering sein. MiFID II war in dieser Hinsicht sicherlich eine Sondersituation. Und das bewusste Inkaufnehmen von Lücken zum Einführungstermin erfordert definitiv immer eine Einzelfallprüfung. Anderseits hat aber auch der Regulator keine Blumensträuße an die Banken verteilt, die alle Anforderungen zum 3. Januar 2018 erfüllt haben.
Im Projekt MiFID II hat sich gezeigt, dass nur durch tief greifende Zusammenarbeit zwischen den Banken untereinander und mit den Softwareentwicklern so komplexe Unterfangen effizient und schnell umgesetzt werden können. Die Strukturen sind in dem Projekt organisch und manchmal auch sehr spontan gewachsen. Aus den Erfahrungen der MiFID-II-Implementierung lässt sich eine Blaupause für künftige Projekte dieser Art und Größe entwickeln.
Dabei sind vor allem zwei Aspekte wichtig: Die Governance-Strukturen einer solchen Zusammenarbeit müssen formalisiert wer den, um Doppelspurigkeiten zwischen den Banken weiter zu reduzieren und den Austausch noch effektiver zu gestalten. Zu den Herausforderungen gehört hierbei, gleichzeitig transparent zu bleiben, das Management aller Banken ausreichend zu informieren und weiter an Agilität zu gewinnen. Denn agiles Vorgehen ist der zweite entscheidende Faktor: In zukünftigen Projekten sollten Aufgaben noch früher, das heißt bereits bei der Entwicklung des ersten Grobkonzepts, an kleine Teams aus Spezialisten übergeben werden. Anstatt eines iterativen Prozesses, bei dem die eine Partei schreibt, die andere kommentiert, müssen neue, innovative Arten der Kollaboration gefunden und implementiert werden.
Wunsch nach Ansprechpartnern
Der andere Wunsch richtet sich an Regulatoren, Bankenverbände, Dienstleister und die Hubs, welche die Transaktionsmeldungen weiterleiten. Es muss auch für kleine Banken oder Bankenzusammenschlüsse Ansprechpartner geben, welche Fragen kurzfristig so beantworten können, dass sie als Umsetzungs- Guidelines dienen können, bis weitere Details zum Beispiel von der EBA veröffentlicht werden. Letztlich steht immer die Frage im Raum, wer die Verantwortung trägt. Wird alles nur auf die Banken abgewälzt, so wächst die Gefahr, dass die Regulierung die Banken auffrisst und ein Teil des Geschäfts zu nicht so stark regulierten Fintechs abwandert. Sinkende Erlöse, steigender Verwaltungsaufwand, eine gefühlt deutlich strengere Auslegung der MiFID-Anforderungen durch die BaFin als in anderen europäischen Ländern und das Unverständnis der Anleger für die neuen Änderungen sorgen für Unmut bei den heimischen Banken. Diese Entwicklung ist nicht im Sinne eines starken Finanzplatzes in Deutschland. Das sollten sich auch die Player im deutschen Bankenmarkt immer wieder vor Augen führen.
Gemeinsam mit dem Bundesverband deutscher Banken (BdB) soll daher der Dialog mit den Behörden gesucht werden, um über Erleichterungen zu sprechen. Möglich wäre hier zum Beispiel die Einführung eines sogenannten "Semiprofessionellen Kunden", der von vielen der Dokumentations- und Transparenzvorschriften ausgenommen wäre.
Konkret ist das aber noch nicht, und auch die Prüfungspraxis muss erst noch abgewartet werden. Selbst im besten Fall würde es dann noch einige Zeit dauern, bis mögliche Erleichterungen greifen, da eine Überprüfung der MiFID-II-Regeln frühestens für 2020 geplant ist.
