Autor: Ralf-Michael Jendro

ITIL – Zaubermittel eines regulatorikkonformen Multiprovidermanagements?

Veröffentlicht am 9. März 2023 von Ralf-Michael Jendro

Aus der Sicht des IT-Managements bringt ITIL eine notwendige Zutat mit, die für ein „Zaubermittel“ unerlässlich ist – das notwendige Alter mit einem entsprechenden Reifegrad. Hierbei darf jedoch nicht verkannt werden, dass ITIL von seinem Ursprung Ende der 80er Jahre bis heute eine erhebliche Weiterentwicklung durchlaufen hat.

Ursprünglich bestand die Neuartigkeit von ITIL in der IT darin, auf die Erfordernisse der Kunden ausgerichtet zu sein. Effektive Prozesse und klar zugeordnete Verantwortlichkeiten standen im Fokus. Erste Weiterentwicklungen ergänzten weitere Prozesse, bis in einer grundlegenden Überarbeitung der Service LifeCycle in den Mittelpunkt rückte. Hierbei wurden weitere Prozesse ergänzt und die Zielsetzung von ITIL dergestalt geschärft, dass eine messbare, positive Wertschöpfung für den Kunden im Fokus steht und diese einen relevanten Mehrwert für das Unternehmen schafft. Schwerpunkte der weiteren Entwicklungsschritte zur aktuellen Version ITIL 4 waren neue Technologien und das Service-Management, die eingebunden wurden in das ITIL Service Value System (SVS).

Neben dem SVS erfolgte im Kontext des Service-Managements die Überführung der bestehenden 4 Ps von ITIL (Personen, Produkte, Partner und Prozesse) in ein Modell mit vier Dimensionen, die über die ursprünglichen 4 Ps hinausgehen:

Organisationen und Menschen
Informationen und Technologie
Partner und Lieferanten
Wertströme und Prozesse

Auf diese Weise hat ITIL in den vergangenen 35 Jahren seinen Best-Practice-Charakter stets an den aktuellen Veränderungen und Gegebenheiten des IT-Managements ausgerichtet.

Die Veränderung der IT in Banken und die Weiterentwicklung der Best Practices von ITIL verliefen zeitlich und inhaltlich vielfach im Gleichklang. Für die Banken-IT war diese gemeinsame Entwicklung essenziell. Verantwortlich dafür sind vor Allem vier Trends:

Ohne IT sind Bankdienstleistungen kaum noch zu erbringen
Die technische Komplexität und Heterogenität sind erheblich angewachsen
IT-Prozesse sind durch ein unternehmensübergreifendes Wertschöpfungsnetzwerk gekennzeichnet
Der Bedeutung entsprechend sind die regulatorischen Anforderungen an die Bank-IT erheblich gestiegen

Der erste Punkt ist einfach nachzuvollziehen. Die weiteren drei Punkte sind stark miteinander verzahnt. So führte die wachsende Komplexität und Heterogenität der Bank-IT vielfach dazu, dass wesentliche Teile an spezialisierte Dienstleistungspartner ausgegliedert wurden. Beispielhaft seien hier der Desktop Service, der Betrieb von Kernbanksystemen, die Bereitstellung von Cloud-Services sowie spezifische IT-Security-Leistungen genannt.

Die Steuerung des sich daraus ergebenden Wertschöpfungsnetzwerkes aus internen und extern erbrachten Leistungen und Prozessanteilen ist aktuell dominierende Kernaufgabe der IT Deutscher Banken. Auch den für Regulatorik von Banken zuständigen Instanzen in Europa und Deutschland (z. B. EBA, EZB, Bundesbank) ist dieses bewusst. In der Konsequenz werden die regulatorischen Anforderungen an die IT in Banken in immer kürzeren Abständen in Breite und Tiefe ausgebaut. Für die Auslagerung von IT-Leistungen der Banken an Dienstleistungspartner gelten gleich eine Vielzahl, sich in Teilen überschneidende, regulatorische Anforderungen. Nachstehende Darstellung verdeutlicht dieses:

Die Herausforderung für die Bank-IT ist damit definiert. Das Wertschöpfungsnetzwerk der IT-Prozesse ist effizient und konform zu regulatorischen Anforderungen zu gestalten und zu steuern. Eine ausschließlich providerorientierte Strukturierung ist hierfür nicht zielführend. Zum einen entspricht diese mehrheitlich nicht der aktuellen Situation des Auslagerungsportfolios der Banken, zum anderen gestattet sie nur wenig Flexibilität für eine providerunabhängige Erweiterung des Serviceportfolios.

Es wird deutlich, dass hier nur ein ganzheitlicher Ansatz mittels mit End-to-End-Ausrichtung zur Lösung beitragen kann. Welche Rolle kann ITIL hierbei spielen, und welche Lösungen kann ITIL anbieten?

Durch die systematische Weiterentwicklung unterstützt ITIL spezifische IT-Management-Prozesse, bietet aber auch prozess- und serviceübergreifende Steuerungsansätze über das gesamte IT-Universum der Bank. Dieses schließt auch Leistungen ein, die durch Dritte erbracht werden.

Mittels ITIL kann die erforderliche Transparenz geschaffen werden, die der Bank eine regulatorikkonforme und effiziente Steuerung der Gesamt-IT ermöglicht. Unterstützung bietet hierbei die Management-Methodik des Service Integration and Management, kurz SIAM.

SIAM ist nicht Inhalt von ITIL, sondern ist ausgelegt auf die Steuerung multipler Providerstrukturen, nutzt hierzu aber die Konzepte zum IT Service Management aus ITIL. Die Strukturen eines SIAM führen in einem Multiprovidermanagement die Geschäftsprozesse und die für ihre Leistungserbringung erforderlichen IT-Services zusammen. Seitens der IT bereitgestellte Services umfassen hierbei providerübergreifend sowohl Infrastrukturkomponenten, Netzwerkkommunikation, Datenhaltung, IT-Anwendungen/Applikationen als auch deren Bereitstellung am Arbeitsplatz. Entstanden ist SIAM im Jahr 2012 mit Erscheinen des XGOV Strategic SIAM reference set der britischen Regierung und basiert auf einem Best Practice-orientierten Vorgehen.

Welche Gestaltungsfelder für eine Serviceintegration und ein Servicemanagement ergeben sich daraus für die Bank, die im Rahmen der Einführung zu berücksichtigen sind? Die folgende Abbildung skizziert die aus unserer Sicht relevanten Felder:

I. Strategie

Das providerübergreifende, integrative Management der IT-Services ist notwendigerweise Bestandteil der IT Strategie sowie der darunterliegenden Ausprägungen z. B. einer Sourcing- oder Cloud Strategie. Dieses ist aufgrund der Ausrichtung der IT-Services auf die Geschäftsprozesse erforderlich, da die IT-Strategie die Verknüpfung zur Geschäftsstrategie bildet.

II. Organisation

Wesentlicher Fokus ist hier das Scoping und damit die Identifikation der relevanten IT-Services. Hierbei sind Business- und Infrastrukturperspektive miteinander zu verbinden. Die organisatorische Verankerung des integrierten Multiprovidermanagements geschieht über spezifische Rollen, die mit dem bestehenden Rollenmodell zu verknüpfen sind. Mit diesen Rollen einhergehende Aufgaben werden verantwortlichen Personen zugeordnet. Dieses Vorgehen verbindet Rollen, Verantwortlichkeiten und Aufgaben in einer Matrix, welche wesentliche Grundlage für die quantitative Personalplanung ist.

III. Prozesse

Wesentliches Element ist die providerübergreifende Orchestrierung der IT-Serviceprozesse im Sinne eines End-to-End-Gedankens. Sie ist Voraussetzung einer Unterstützung dieser Prozesse mittels etablierter IT-Managementprozesse wie Incident‑, Problem- oder Change-Management. Entsprechend der Kritikalität der Prozesse sind Reporting- und Kontrollverfahren zu etablieren, die durch geeignete KPIs unterlegt werden müssen.

IV. Tools

Erfolgskritisch ist in erster Linie die Verfügbarkeit der für die IT-Serviceprozesse End-to-End erforderlichen Informationen. Diese müssen an einer zentralen Stelle gebündelt sein, an die jeder Provider seine Daten zuliefert und aktuell hält. Dieser Datenpool wird im Rahmen der IT-Managementprozesse genutzt und ist Basis für eine workfloworientierte Prozessbearbeitung unter Einbindung der Provider. Hierfür bietet es sich an, eine marktgängige Plattform zu verwenden, die sowohl die Datenhaltung als auch die prozessualen Workflows unterstützt. Offene Standardschnittstellen ermöglichen die flexible Einbindung weiterer Provider und Assets.

V. Verträge

Idealerweise sind die Vertragsinformationen in der obigen Plattform hinterlegt und stehen als Information zur Verfügung. Neben dem Informationscharakter ist jedoch vor allem sicherzustellen, dass die für ein Multiprovidermanagement erforderlichen technischen, prozessualen und regulatorischen Sachverhalte Inhalt der Vertragswerke von Bank und Provider sind. Besonders sei an dieser Stelle darauf hingewiesen, dass ein flexibles Multiprovidermanagement nicht nur ein Onboarding von Leistungen des Providers erfordert, sondern auch die Häufigkeit eines Offboarding erhöht ist. Dafür erforderliche Exit-Vereinbarungen sind aus diesem Grund eine Komponente, die vertraglich geregelt sein muss.

Bietet ITIL nun das Wundermittel für ein regulatorikkonformes Providermanagement, gegebenenfalls unter Hinzufügen einer „Prise“ SIAM?

Obige Ausführungen machen deutlich: Der Zaubertrank für ein regulatorikkonformes Multiprovidermanagement ist ITIL nicht. Aber ITIL enthält die dafür erforderlichen Zutaten. Diese sind in der IT der Bank unter Zusammenwirken mit weiteren relevanten Stakeholdern wie z. B. Einkauf oder Compliance zusammenzustellen und mit erforderlichen Tools zu etablieren. ITIL bildet eine Art Rezeptbuch und wird damit seinem Best-Practice-Ansatz gerecht. Die Bank hat aber entsprechend der individuellen Ausgangssituation aus IT-Komplexität, End-to-End-Reifegrad der IT-Prozesse, Ausgestaltung des IT-Auslagerungsportfolios sowie regulatorischem Status quo das Multiprovidermanagement auszugestalten. Hier unterstützt der Managementansatz SIAM und bietet Hilfestellung in der bedarfsgerechten Konzeption und Etablierung.

Expertise bankon Management Consulting

Die Expertise der bankon-Berater aus mehr als fünfzehn Jahren Erfahrung mit Projekten im Kontext IT-Management (ITIL), Providermanagement, IT-Services sichert praxiserprobtes Wissen. Umfangreiche Kenntnis von Organisations- und Providerstrukturen, Prozessen und IT-Systemen deutscher Banken und Sparkassen gewährleisten den erforderlichen fachlichen und technischen Hintergrund.

Erfahrungen aus der Vorbereitung, Begleitung und Nachbereitung von Prüfungen der Bankenaufsicht ergänzen diese Praxiserfahrung um regulatorische Kompetenz.

Nutzen Sie unsere umfangreichen Erfahrungen und sprechen Sie mit uns:

bankon Management Consulting GmbH & Co. KG
Max-Planck-Str. 8
85609 Aschheim/München
Tel.: (089) 99 90 97 90
Fax: (089) 99 90 97 99
Web: https://www.bankon.de
E‑Mail: research@bankon.de

DORA – Neue regulatorische Anforderungen für europäische Banken

Veröffentlicht am 27. September 202227. September 2022 von Ralf-Michael Jendro

Zielsetzung und Inhalt von DORA:

DORA (Digital Operational Resilience Act) ist der europäische Verordnungsentwurf zur digitalen operationalen Resilienz im Finanzsektor. Es ist einer von vier regulatorischen Bausteinen zu dessen Digitalisierung. 2020 wurde DORA von der Europäischen Kommission vorgelegt. Das Inkrafttreten der Verordnung ist um den Jahreswechsel 2022/2023 zu erwarten.

Im Fokus von DORA steht die digitale Betriebsstabilität als Fähigkeit von Finanzunternehmen, IT-Systeme aufzubauen, deren Betrieb sicherzustellen und zu überprüfen. Eingesetzte Informations- und Kommunikationstechnologien dürfen nicht durch betriebliche Störungen, wie z. B. technische Ausfälle oder Cyberangriffe, die Erbringung von Finanzdienstleistungen gefährden. Diese Anforderung schließt auch die direkt oder indirekt von Drittanbietern genutzten Dienste ein. Finanzunternehmen haben, insbesondere auch im Zusammenwirken mit ihren Dienstgebern, die erforderlichen Vorkehrungen zu treffen, um auf alle denkbaren Beeinträchtigungen und Bedrohungen in der IT vorbereitet zu sein und Zwischenfälle zu überstehen.

Mit DORA verfolgt die europäische Union drei Kernziele:

Vereinheitlichung bestehender nationaler und europäischer Standards und Vorgaben
Gewährleistung, dass alle erforderlichen Maßnahmen zur Absicherung gegen Cyberrisiken und ‑angriffe getroffen werden
Schaffung eines Rechtsrahmens zur direkten Überwachung von IT-Drittanbietern durch die Aufsichtsbehörden, sobald diese für Finanzunternehmen tätig sind

Inhaltlich umfasst DORA sechs Schwerpunkte

IKT-Risikomanagement – Finanzunternehmen sollen über einen „geeigneten Rahmen“ an Risikomanagementwerkzeugen für ihre Informations- und Kommunikationstechnik (IKT), ausreichend Kapazitäten und Ressourcen verfügen. Diese sind zu dokumentieren sowie deren Aktivitäten zu protokollieren, um den Aufsichtsbehörden darüber zu berichten. Dafür muss im Unternehmen eine eigene verantwortliche Stelle eingerichtet sein.
Berichterstattung – Die durchgeführten Tests sind zu protokollieren. Die Berichterstattung hat bereits vorzusehen, dass mögliche Vorfälle bzw. Störungen zu klassifizieren und zu clustern sind (wie viele Betroffene, in welchem Gebiet, welche Daten betroffen, etc.). Für die Durchführung der Dokumentation und Berichterstattung sollen Standards vorgegeben werden.
Regelungen für Tests – In regelmäßigen Abständen – mindestens einmal pro Jahr – müssen die Systeme einem Test unterzogen werden. Grundlage sind die Regelwerke der Bank. Im Rahmen der Tests sind unterschiedliche Bedrohungsszenarien zu berücksichtigen und anhand von Testfällen zu simulieren. Auf Grundlage der Erkenntnisse aus der Testdurchführung sind institutsindividuelle Präventionsmaßnahmen zu spezifizieren. Diese setzen bereits im Erkennen von Bedrohungen an und reichen bis zu Regelungen von Backupmaßnahmen.
IKT-Drittanbieter – Das Risikomanagement von Dienstleistungspartnern in der IT steht hier im Mittelpunkt. Der Scope geht aber über die vertraglichen Regelungen zur Auslagerung hinaus. Eine besondere Regelung erfahren sogenannte kritische Dienstleister, die ausgelagerte digitale Leistungen für Institute erbringen. Abgezielt wird hier z. B. auf die Angebote von „Big Techs“ im Kontext Cloud-Computing-Leistungen. Hier ist für die europäischen Aufsichtsorgane die Berechtigung vorgesehen, auf Dokumente zuzugreifen, Vor-Ort-Prüfungen durchzuführen, Empfehlungen oder Anweisungen auszusprechen sowie Maßnahmen zur Abhilfe zu fordern. Hierfür ist die Breitstellung eines Mechanismus vorgesehen, der die Kritikalität von Dienstleistungsanbietern bestimmt.
Informationsaustausch – Regelungen zum Informationsaustausch über Cyberbedrohungen inklusive der Regelung, wie Vereinbarungen dazu gestaltet sein müssen.
Governance - Für die Durchsetzung des geplanten Regelwerks sind die Aufsichtsbehörden vorgesehen, die bereits jetzt für die Aufsicht der im Anwendungsbereich befindlichen Unternehmen zuständig sind.

Zur Erreichung dieser sechs Zielvorgaben der Aufsicht stehen für die Finanzinstitute folgende Themen im Fokus der Umsetzung, da sie in Teilen über die bestehenden regulatorischen Anforderungen herausgehen:

Stärkung der operationellen digitalen Resilienz der Banken mittels Vorgaben zum Digital Operational Resilience Testing (inklusive Penetrationstests)
Sicherstellung einer stringenten und konsequenten Überwachung ausgelagerter Dienstleistungserbringung in der Informations- und Kommunikationstechnik
Ausweitung von Meldepflichten zu schwerwiegenden IKT-Incidents auf den gesamten Finanzsektor
Erweiterung der Anforderungen an das Management von Informationsrisiken und Informationssicherheit

DORA für Banken in Deutschland:

Diese auf die IT-Sicherheit einzahlenden Schwerpunkte werden mit DORA detaillierter beschrieben als in bestehenden regulatorischen Regelungen wie BAIT oder ISO 27xxx und darüber hinaus auf eine europäische Ebene gehoben, um einen einheitlichen Standard zu forcieren.

Besonders die geforderten Maßnahmen zur Steuerung des mit der Auslagerung von ITK-Leistungen an Dritte verbundenen Risikos sind deutlich spezifischer. Dazu wird die Fokussierung auf eine geringe Anzahl von Schlüssel-Dienstleistern als kritisch betrachtet. Dieses gilt sowohl für das einzelne Institut als auch für die Branche insgesamt.

Im Hinblick auf eine Umsetzung der Vorgaben von DORA ist jedoch zu berücksichtigen, dass in Deutschland bereits in jüngster Vergangenheit wesentliche Verschärfungen der Anforderungen mittels aufsichtsrechtlicher Vorgaben umgesetzt wurden.

Beispielhaft genannt sei das Handlungsfeld der Auslagerungen von Dienstleistungen der Banken an Dritte. Im Mittelpunkt stehen hier die aus der Erweiterung der BAIT sowie dem Finanzmarktintegritätsstärkungsgesetz (FISG) resultierenden Vorgaben.

Banken sind auf dieser Basis nicht mehr nur verpflichtet, inhaltliche, vertragliche oder steuernde Prozesse zu ihren Dienstleistungspartnern zu etablieren, sondern ebenso dazu, wesentliche Auslagerungen bei der Aufsicht anzuzeigen (Auslagerungsregister). So führt die BaFin an, dass die Konzentration auf sogenannte Mehrmandantendienstleister (MMDLs), die für mehrere Banken tätig sind, Risiken für den Gesamtmarkt implizieren. Über das Auslagerungsregister hinaus besteht auch eine Verpflichtung zur Meldung schwerwiegender Vorfälle in der Auslagerungsbeziehung zwischen Bank und Dienstleistungspartner.

Der durch die Meldungen der Institute geschaffene Überblick über die Auslagerungsbeziehungen deutscher Banken ermöglicht der Bankenaufsicht, diese MMDLs zu identifizieren, hinsichtlich des Risikos zu bewerten und zu überwachen.

Darüber hinaus gibt der gesetzliche Rahmen der Aufsicht die Möglichkeit, direkt auf den Auslagerungspartner der Bank zuzugehen, um einen Missstand zu vermeiden oder zu beheben.

Diese Anforderung trägt der zunehmenden, branchenweiten Bedeutung einzelner Dienstleistungsanbieter und dem damit verbundenen Risiko Rechnung.

Spezifische Aspekte für Verbundstrukturen:

Die in DORA formulierten Regelungen für IT-Dienstleister von Banken basieren wahrscheinlich auf Überlegungen, die z. B. Anbieter von Cloudlösungen wie Amazon, Google oder Microsoft im Fokus hatten. Im Hinblick auf Cybersicherheit und die Kritikalität einzelner Anbieter für den gesamten Bankensektor ist dieses sicherlich ein sachgerechtes Vorgehen.

Das Universum der Banken in Deutschland ist jedoch in starkem Maße von Sparkassen und Genossenschaftsbanken geprägt. Hier bestehen Verbundstrukturen.

Diese Strukturen sind durch zwei Komponenten gekennzeichnet:

Eine inhaltliche Komponente, in der tendenziell eher kleineren Instituten zentrale Dienstleistungen und digitale Angebote ebenso zur Verfügung gestellt werden wie stabile Governance-Prozesse
Eine rechtliche Komponente, in der sich die zentralen Anbieter dieser Institutsgruppen in deren Besitz befinden und durch diese kontrolliert werden. Die einzelnen Institute, welche die Leistungen nutzen, sind gleichzeitig Eigentümer des Leistungserbringers

Durch diese Strukturen ist die Gefahr konkurrierender Interessen zwischen Bank und Dienstleister nahezu ausgeschlossen.

Das bedeutet auch, dass regulatorische Anforderungen aus DORA an die Institute (Darlegung, wie sie mit den Gefahren von Abhängigkeiten umgehen, die bei der Auslagerung von Dienstleistungen entstehen) im Falle von Verbundstrukturen auf vollständig andere Voraussetzungen treffen als bei Instituten außerhalb der Verbünde.

Im Handlungsfeld der Auslagerungen haben bestehende regulatorische Vorgaben wie die MaRisk auf Basis der EBA-Leitlinien für Sourcing Erleichterungen für die IT-Auslagerung auf Verbundebene vorgesehen, die in DORA so nicht enthalten sind.

In diesem Kontext besteht noch abschließender Klärungsbedarf durch die Verbände mit der Aufsicht, um für die Verbundinstitute Handlungssicherheit sicherzustellen.

Unabhängig von diesem verbundspezifischen Aspekt, besteht für die Banken in Deutschland die Erfordernis, sich der Umsetzung von DORA zu widmen.

Aber was heißt das im „Dschungel“ der regulatorischen Vorgaben denn genau?

Umsetzungsempfehlungen

Für Banken, die regulatorische Anforderungen in der Vergangenheit bereits kontinuierlich umgesetzt haben, heißt es auch bei DORA – kein Grund zur Panik.

Für Institute, die eine Umsetzung der Anforderungen der BAIT 2017 und 2021 nur homöopathisch begonnen haben und wesentliche Dienstleistungen an Dritte ausgelagert haben, steigt durch DORA der Handlungsdruck noch einmal.

Gerade in Bezug auf das Management von Auslagerungen kann sich eine „Bugwelle“ erforderlicher Umsetzungsaktivitäten aufbauen, die sich finanziell und kapazitativ zu einer kritischen Herausforderung entwickelt und unmittelbaren Handlungsbedarf erfordert.

In diesem Kontext gilt es, die bereits bestehenden Anforderungen Dokumentations- und Meldepflichten sowie das Risikomanagement in den besonderen Fokus zu rücken.

Bestehende Verträge mit Dienstleistungspartnern, an die speziell IT-Leistungen ausgelagert wurden, gilt es zu prüfen, ob diese den bestehenden und zukünftigen Anforderungen genügen. So sind beispielsweise Prüfungen durch die Bank erforderlich, ob die Dienstleister im Bereich Business Continuity oder Notfallmanagement die relevanten Vorgaben eingehalten haben. In vielen Fällen sind diese Prüfungen in den bestehenden Verträgen nicht vorgesehen. Da Anpassungen in der Regel zeitaufwändig sind, ist hier ein relevanter Ansatzpunkt, der nicht aufgeschoben werden sollte.

Generell gilt bei DORA, wie auch bei den vorangegangenen regulatorischen Veränderungen und Verschärfungen, eine GAP-Analyse des Status quo gegen die Vorgaben als probates Mittel. Praxisbewährte und risikoorientierte Checklisten, die auch die Prüfungsschwerpunkte der Bankenaufsicht in ihrer Priorisierung berücksichtigen, sind hier ein empfohlenes Hilfsmittel zur Ermittlung des Handlungsbedarfs und der Ableitung einer Umsetzungsroadmap.

Expertise bankon Management Consulting

Die Expertise der bankon-Berater aus mehr als fünfzehn Jahren Erfahrung mit Projekten im Kontext IT-Regulatorik sichert praxiserprobtes Wissen. Umfangreiche Kenntnis von Organisationsstrukturen, Prozessen und IT-Systemen deutscher Banken und Sparkassen gewährleisten den erforderlichen fachlichen und technischen Hintergrund.

Aus der Vorbereitung, Begleitung und Nachbereitung von Prüfungen der Bankenaufsicht verfügt bankon über eine umfangreiche Praxiserfahrung, die in Best Practices und Checklisten eingeflossen sind und den Kunden von bankon in der effizienten Umsetzung einer regulatorikkonformen IT helfen.

Nutzen Sie unsere umfangreichen Erfahrungen und sprechen Sie mit uns:

bankon Management Consulting GmbH & Co. KG
Max-Planck-Str. 8
85609 Aschheim/München
Tel.: (089) 99 90 97 90
Fax: (089) 99 90 97 99
Web: https://www.bankon.de
E‑Mail: research@bankon.de

Transformationsprojekte in Banken – agil gedacht, hybrid gemacht

Veröffentlicht am 6. Juni 20227. Juni 2022 von Ralf-Michael Jendro

Die von innen und außen gestellten Anforderungen an Projekte in Banken kennen eigentlich nur eine Richtung – „von allem mehr“:

Mehr Komplexität
Mehr Zeitdruck
Mehr Kosten und auch Zwang zu mehr Kosteneinsparung
Mehr regulatorische Rahmenbedingungen
Mehr Volatilität des Anforderungsportfolios

Eine Handhabung dieser Anforderungen mit den bewährten, „traditionellen“ Projektmanagementmethoden ist keine Option, da diese hier an ihre Grenzen stoßen und in Teilen darüber hinausgehen.

Zielsetzungen

Gerade bei Transformationsprojekten (z. B. Einführung Kernbanksysteme, Neustrukturierung Geschäftsfelder, Umsetzung regulatorischer Anforderungen), die durch lange Projektzeiträume gekennzeichnet sind, steht die Welt nicht still, sondern das Anforderungsportfolio ist im Zeitablauf regelmäßig intern oder extern induzierten Anpassungen unterworfen. Vor diesem Hintergrund sind das Anforderungsmanagement sowie die Projektsteuerung die wichtigsten inhaltlichen und methodischen Gestaltungsfelder zur Sicherstellung des Projekterfolgs.

Diese beiden Gestaltungsfelder sind an den spezifischen Rahmenbedingungen auszurichten. Ein „One fits all“ kann es nicht geben. Folgende vier Handlungsfelder sind zu berücksichtigen:

Variabilität des Projektumfangs (wie klar und festgefügt ist zu Beginn des Projektes Umfang und Ausprägung des angestrebten Zielportfolios?)
Unternehmenskultur (wie hierarchisch oder dynamisch ist die Bank unabhängig von Projekten in ihrem Aufbau und ihren Abläufen?)
Projektkultur (welche Bedeutung haben Projektstrukturen in der Leistungserbringung und wie stark werden Veränderungen aus Projekten heraus initiiert?)
Interne Ressourcen und Skills (wie ist die Situation hinsichtlich Quantität und Qualität interner Spezialistinnen und Spezialisten auch im Verhältnis zu externen Dienstleistern?)

Im Kontext dieser Handlungsfelder sowie der spezifischen Projektzielsetzung das geeignetste Projektvorgehen zu wählen, ist von essenzieller Bedeutung für den Projekterfolg.

Vorgehensoptionen

In Transformationsprojekten von Banken ist aufgrund ihrer Zeitdauer das „traditionelle“ Projektmanagement im Wasserfall in der Bewältigung der Projektanforderungen nicht empfehlenswert. Eine rein agile Vorgehensweise mittels Scrum ist für Transformationsprojekte aufgrund ihrer Größe und Komplexität ebenfalls keine Option. Die Ausrichtung an agilen Verfahren für das Management großer Projekte, z. B. mittels SAFe ist gerade in den hier betrachteten Projekten ein denkbarer Ansatz. Die methodische Komplexität derartiger Ansätze darf hierbei jedoch nicht außer Acht gelassen werden.

Sinnvoll ist es vor diesem Hintergrund, Projektkontext und unternehmensindividuelle Situation für die Wahl des Vorgehens heranzuziehen. Im Ergebnis ergeben sich daraus hybride Vorgehensoptionen, die ähnlich eines Methodenbaukasten für die konkrete Situation ausgewählt werden können.

Handlungsempfehlungen aus der Praxis

In den von bankon verantworteten Transformationsprojekten hat es sich bewährt, genau diese situationsindividuellen Aspekte für die Ausgestaltung des Projektvorgehens zu berücksichtigen. Hieraus entsteht eine spezifische Individualisierung des Vorgehens unter Nutzung von Methodenbausteinen. Folgende Darstellung illustriert den „Einstieg“ in das hierfür von bankon entwickelte Analysewerkzeug mit der Ermittlung des unternehmensindividuellen Agilitätsscores. Spezifische Projektinhalte können durch eine ergänzende Gewichtung der Handlungsfelder Berücksichtigung erfahren.

Eine „methodenreine“ Vorgehensweise ist in Transformationsprojekten schon aufgrund der Komplexität von Anforderungen und Struktur in der Regel kundenseitig nicht anzutreffen und zur Zielerreichung auch nicht zu empfehlen.

Vielmehr ist es sinnvoll, Projektindividuell und abhängig vom ermittelten Agilitätsscore methodische Bausteine einzufügen, mit denen der projektspezifische Hybridansatz ausgestaltet wird.

Klassisches Projektumfeld mit niedrigem Agilitätsscore:

In Unternehmen mit einem niedrigen Agilitätsscore und einem klassischen Projektumfeld ist es empfehlenswert, agile Elemente bereichernd neben die klassischen Strukturen zu stellen. Es kann sich sogar anbieten, beide Strukturen an Punkten wie einem gemeinsamen Backlog zusammenzuführen. Sinnvoll ist eine Aufsplittung in Komponenten, die aufgrund ihrer inhaltlichen Determiniertheit eher fixen Charakter haben und weiterhin klassisch bearbeitet werden und solche, die aufgrund Unsicherheiten zum angestrebten Ziel sinnvollerweise agil bearbeitet werden können. Folgende agile Methoden bieten sich für eine Nutzung in diesem Projektumfeld an:

Projektweiter Backlog mit der Möglichkeit, Sprintbacklogs für agile Projektelemente zu extrahieren und zu bearbeiten
Etablierung von Daily-Scrums zur Förderung der Vernetzung zwischen den Projektteilen und dem Management von Abhängigkeiten
Der Einsatz von Kanban-Boards zur Unterstützung der Kommunikation
Einführung von Verfahren des Reviews und der Retrospektive, um die Orchestrierung und Zielfokussierung der einzelnen Projektstränge zu fördern
Rolle eines Product Owners als fachlich/technologische Evidenz- und Konsistenzstelle etablieren

Die oben genannten agilen Elemente schaffen eine Klammerfunktion zwischen den in agiler und klassischer Form aufgesetzten Projektbestandteilen. Sie etablieren ein gemeinsames Verständnis und zahlen in eine Verbesserung des Agilitätsscores ein. Dadurch werden die zukünftigen Möglichkeiten zum Einsatz agiler Methodiken im Projekt deutlich verbessert.

Agiles Projektumfeld mit hohem Agilitätsscore:

In Unternehmen mit einem hohen Agilitätsscore und einem agilen Projektumfeld ist das Zusammenwirken der einzelnen agilen Projekte im Hinblick auf Ziele oder die Nutzung personeller und technischer Ressourcen sicherzustellen. Darüber hinaus sind langfristige Ausrichtungen und das Erreichen strategischer Ziele zu gewährleisten, was in der agilen, sprintorientierten Vorgehensweise durch die kurze Zeitdauer von Sprints und der häufig vorherrschenden zeitlichen Limitierung des Planungshorizonts auf Halbjahre oder Quartale nicht immer gegeben ist. Methodisch werden diese Aspekte in der Regel in skalierten agilen Vorgehensformen, z. B. SAFe berücksichtigt, in der Praxis aber nicht immer gelebt. Erfahrungen von bankon zeigten, dass durch die Einbindung ausgewählter klassischer Projektmanagementbausteine in das agile Vorgehen diese Schwächen kompensiert werden können, ohne den agilen Charakter zu beeinträchtigen. Aus der Praxiserfahrung von bankon bieten sich für eine Nutzung in diesem Projektumfeld an:

Verknüpfung themenspezifischer Backlogs mit einem übergreifenden Anforderungsmanagement, das eine Priorisierung und Ausstattung der Projekte mit personellen und technischen Ressourcen über einen Zeitraum von mehr als drei Monaten ermöglicht
Etablierung eines systematischen, gesteuerten, und zentralen inhaltlichen Abhängigkeitsmanagements im Projekt und in thematischen Projektbündeln
Ergänzung um eine projektübergreifende Ressourcensteuerung im Hinblick auf personelle Expertise (in Abstimmung mit den Linieneinheiten) und technische Erfordernisse (z. B. in Form eines Test- und Releasemanagements)
Ausbau der dezentralen Risikoerfassung, z. B. in Jira zu einem ganzheitlichen Risiko- und Issue Management, das eine Bewertung von Risiken und Issues enthält und ein systematisches Controlling der hinterlegten Maßnahmen sicherstellt
Verlängerung der Planungshorizonte durch Ausdehnung der Planung auf mittel- und langfristige Zeitachsen. Vom Ziel des Transformationsprojektes ausgehend werden die zur Erreichung des Ziels erforderlichen Leistungsbausteine identifiziert und beplant. Hierbei kann es sehr wohl zu unterschiedlichen Detaillierungsständen und Unsicherheiten in der Planung kommen
Einführung zentraler Qualitätssicherungsmaßnahmen über die in Jira und Confluence hinterlegten Projektdokumentationen. Hierdurch wird ein gemeinsamer Qualitätsstandard projektintern und projektübergreifend sichergestellt, der auch durch regulatorische Anforderungen vorgegeben ist
Unterstützung der Qualitätssicherung durch den Einsatz eines inhaltlichen PMO, welches sich explizit um diese verbindenden Methoden kümmert und eine Entlastung der operativen Projektteams sicherstellt

Nachstehendes Prinzipbild stellt Teile des verfügbaren bankon Methodenportfolios dar, mit dem Transformationsprojekte situationsgerecht zum Erfolg geführt werden und Maßnahmen zur Steigerung des Agilitätsscores im Unternehmen umgesetzt werden.

Expertise bankon Management Consulting

Die Expertise der bankon-Berater aus mehr als fünfzehn Jahren Erfahrung in Transformations-Großprojekten sichert praxiserprobtes Wissen. Die Erfahrung in der Durchführung dieser Art von komplexen Projekten hat gezeigt, dass ein alleiniges agiles oder klassisches Vorgehen den Anforderungen des Projektes nicht optimal Rechnung trägt. Vielmehr ist ein geeigneter Mix aus Methoden und Toolbausteinen erforderlich, um den Projekterfolg bestmöglich zu unterstützen. In Form eines Best Practice-Ansatzes hat bankon einen Methodenbaukasten erarbeitet, der eine bedarfsgerechte Auswahl zur Verfügung stellt. Die verfügbaren Methoden und Tools sind verknüpft mit einem Agilitätsscore, der zu dem projekt- und unternehmensindividuellen Score gemappt wird, der für das Transformationsvorhaben der Bank ermittelt wird.

Darüber hinaus wird durch dieses Vorgehen eine Weiterentwicklung der Agilität in Projekten, aber auch in Veränderungsprozessen der Bank generell gefördert.

Profitieren Sie von der langjährigen Erfahrung der bankon-Berater in agilen und klassischen Transformationsprojekten auf Ihrem Weg zur agilen Bank und zur erfolgreichen Durchführung von Transformationsprojekten.

Nutzen Sie unsere umfangreichen Erfahrungen und sprechen Sie mit uns:

bankon Management Consulting GmbH & Co. KG
Max-Planck-Str. 8
85609 Aschheim/München
Tel.: (089) 99 90 97 90
Fax: (089) 99 90 97 99
Web: https://www.bankon.de
E‑Mail: research@bankon.de

CoOpetition 2.0 – Banken müssen Ihre IT-Wertschöpfungsketten neu denken

Veröffentlicht am 23. August 20215. August 2021 von Ralf-Michael Jendro

Banken sehen sich nicht erst durch die Corona-Pandemie einer „stürmischen Wetterlage“ gegenüber. Bereits vor dem Virus standen Geschäftsmodelle und ihre Veränderung in Prozessen und Technik im Fokus der Aktivitäten in den Instituten.

Blicken wir vor diesem Hintergrund auf die Informationstechnik der Banken, dann wird folgendes deutlich:

Die technischen Bedrohungssituationen von außerhalb, aber auch von innerhalb der Bank, werden quantitativ und qualitativ spürbarer
Hierbei kann die Bedrohungssituation sowohl mittels krimineller Energie hergestellt worden sein als auch durch Unachtsamkeit befördert werden
Die Technologisierung der betroffenen Prozesse nimmt hierbei ständig zu – beispielhaft seien hier Blockchain oder Bitcoin genannt
Staat und Bankenaufsicht greifen mittels Vorgaben zur Eindämmung der Risiken regulatorisch ein

Zusammengefasst ergibt sich für die IT in Banken folgendes Bild:

Zwei potenzielle Missverständnisse gilt es hierbei von vorneherein zu vermeiden:

Unter Innovationskraft ist hier nicht zu verstehen, dass neben den Run-Aktivitäten noch ein Restanteil von Kapazität und Budget für Change-Aktivitäten verbleibt
Unter Management von Wertschöpfungsketten ist nicht die Erfüllung der Anforderungen aus den EBA-Guidelines zum Sourcing gemeint

Vielmehr ist es für die IT in Banken von essenzieller Bedeutung, neben der Gestaltung des Spannungsfeldes regulatorischer Anforderungen und der Abwehr technischer Angriffe von innen und außen parallel die Innovationskraft von Prozessen und Technik in der IT erheblich zu stärken. Hierzu ist es erforderlich, die bestehenden Wertschöpfungsketten grundlegend zu überdenken – Stichwort CoOpetition 2.0. Dieses kann keinesfalls unabhängig voneinander geschehen, da in der Neugestaltung der Make-or-Buy-Struktur für die Banken-IT der größte Hebel liegt, Innovationsfreiräume zu generieren.

CoOpetition 1.0

Der Begriff CoOpetition beschreibt die Dualität von Konkurrenz und Kooperation. Wesentlicher Inhalt von CoOpetition 1.0 war die Positionierung der Bank im Markt und in ihrer Funktion. In den Institutsgruppen der Genossenschaften und der Sparkassen lässt sich die Umsetzung gut identifizieren.

Beide Institutsgruppen haben viele Tätigkeiten für die Primärinstitute zentralisiert und auf einen oder wenige Anbieter verdichtet. So gibt es in beiden Gruppen jeweils nur noch einen Rechenzentrumsanbieter mit einem Kernbanksystem. Die Genossen haben nur noch ein Spitzeninstitut. Die Sparkassen haben nur noch zwei bedeutende Backoffice-Anbieter. Leistungsangebote, wie z. B. das Konsumentenkreditgeschäft, werden institutsübergreifend bereitgestellt – siehe S‑Kreditpartner GmbH.

Im Ergebnis fokussieren sich die Institute deutlich stärker auf Ihre Kernkompetenz und zwar den Verkauf von Bankprodukten einhergehend mit erforderlichen Beratungsleistungen.

CoOpetition 2.0

In der Weiterentwicklung zur CoOpetition 2.0 liegt der Schwerpunkt auf der IT. Sie ist der Enabler, um Verkaufs‑, Beratungs‑, Abwicklungs- und Steuerungsprozesse effizient zu gestalten.

Da es nicht die Kernkompetenz einer Bank ist, ein Rechenzentrum zu betreiben oder Software zu entwickeln, werden wesentliche IT-Leistungen von Drittanbietern bezogen. Strategische Partnerschaft versus Best-of-Breed ist hierbei die dominierende Frage. Die zentralen IT-Dienstleister der beiden großen Bankengruppen Deutschlands haben um den Betrieb des Kernbanksystems in ihren Rechenzentren hinaus ein umfangreiches Software- und Dienstleistungsangebot geschaffen, das sie obligatorisch zu strategischen Partnern der Institute macht.

Drei Handlungsoptionen haben sich in der Praxis als zielführend herausgestellt:

Option 1 (Standard):

Die Nutzung der Leistungsangebote des Rechenzentrums im Standard minimiert sowohl die Steuerungsaufwände als auch die Run-Kosten. Freie Kapazitäten und Budgets für technische und prozessuale Innovationen sind das Resultat. Eine Nutzung hierfür stünde aber im Widerspruch zu dem auf Standard gesetzten Fokus.

Andererseits kann der Schwerpunkt so verstärkt auf die Bereiche der Bank gelegt werden, in denen das Institut die Kernkompetenz besitzt – Beratung und Verkauf.

Darüber hinaus kann aus dem reichhaltigen Angebot von Standardleistungen und Tools das für das Institut bestmögliche Portfolio ausgewählt werden. Dieses kann aufgrund der standardisierten Nutzung umfangreicher ausfallen.

Bei einer Entscheidung für diese Option sind die IT-Prozesse inklusive des Anforderungsmanagements sowie die übergeordnete IT-Strategie entsprechend auszurichten.

Option 2 (Individualität im Standard):

Mit der Ergänzung des Standards um durch das Rechenzentrum angebotene Individualleistungen lassen sich prozessuale und technische Innovationen stärker umsetzen als in einer ausschließlichen Ausrichtung am Standard. Beispielhaft für Individualität kann der Einsatz leistungsstärkerer Analysetools für Datenauswertungen sein oder Software, welche die Abbildung komplexerer Produkte und Dienstleistungen ermöglicht.

Die zusätzlichen, individuellen Leistungen erlauben eine Unterscheidung vom Leistungsangebot des Wettbewerbs. Freiheitsgrade wie die Einbindung von Partnerprodukten außerhalb der Institutsgruppe oder das Angebot institutsindividueller, digitaler Leistungen sind hier aber nur eingeschränkt möglich.

Es bleibt der Fokus auf die Kernkompetenzen Beratung und Verkauf. Da die Individualleistungen separat bepreist werden, ist die Nutzung dieser Möglichkeiten Bestandteil einer institutsspezifischen Kalkulation. In diese fließen neben den höheren Run-Kosten gegenüber der Option 1 auch erhöhte Aufwände für die Administration, Steuerung und Kontrolle der Individualleistungen ein.

Die Individualität im Standard muss somit einen messbaren ökonomischen Vorteil gegenüber dem reinen Standard aufweisen, um für die Bank sinnvoll zu sein.

Entsprechend ist auch bei einer Entscheidung für diese Option die IT-Strategie entsprechend zu formulieren und die IT-Prozesse strategiekonform auszurichten.

Option 3 (Individualität zusätzlich zum Standard):

Für Institute, die Ihr Produkt- und Dienstleistungsangebot um Leistungen von Drittpartnern oder FinTechs ergänzen wollen, ist die Erweiterung des Standards um individuelle Leistungen, die nicht durch das Rechenzentrum angeboten werden, eine Option.

Beispielhaft für eine solche Erweiterung sei hier die Einführung leistungsbezogener Produktökosysteme genannt. Diese können unter anderem im Kontext Bau (z. B. Angebote von Handwerkern, Architekten oder Behörden) oder Senioren (z. B. Angebote zu Pflegediensten, zur Freizeitgestaltung sowie Einkaufsservices) konzipiert werden.

Gleiches gilt aber z. B. auch im Kontext des Wertpapiergeschäftes. Schrittweise eingeführte institutsgruppenspezifische Angebote wie z. B. der Bevestor der DekaBank stehen hier neben Eigenentwicklungen von Instituten wie Smavesto der Sparkasse Bremen und Angeboten außerhalb der Institutsgruppe.

Für alle gemeinsam gilt jedoch, dass die Individualität dieser Angebote erheblich in die Gestaltung technischer und organisatorischer Prozesse in der IT ausstrahlt.

Institute, die solche Leistungen nutzen, benötigen personelle und technische Kapazitäten, um diese Angebote abbilden zu können. Steuerungs- und Betriebsprozesse sind inhaltlich und regulatorisch entsprechend auszugestalten. Sie sind in einer IT-Strategie zusammenzuführen sowie durch Vorgaben der IT-Architektur und ein Target Operating Model zu operationalisieren.

Eine Entscheidung für diesen Weg erfordert darüber hinaus, dass dadurch ein nachhaltig messbarer ökonomischer Mehrwert generiert werden kann.

Zusammenfassung:

Es gibt keine richtige oder falsche Entscheidung. Ausschlaggebend sind vor allem nachstehende fünf Handlungsfelder:

Die Geschäftsstrategie der Bank (wie positioniere ich mich gegenüber meinen Wettbewerbern)
Die Sourcingstrategie der Bank (wie affin bin ich für eine Auslagerung von Leistungen an Dritte und wie etabliert sind meine Prozesse für eine regulatorikkonforme Steuerung)
Größe und Wettbewerbsintensität des Instituts
Personelle Ausstattung (quantitativ und skillspezifisch)
Institutsindividuelle Governance

Aus diesen Handlungsfeldern ist die für das Institut optimale Option zur Gestaltung der CoOpetition 2.0 auszuwählen und auszugestalten.

Expertise bankon Management Consulting

Die Expertise der bankon-Berater aus mehr als fünfzehn Jahren Erfahrung aus Projekten im Kontext der Banken-IT sichert praxiserprobtes Wissen. Erfahrungen aus Strategie- und Transformationsprojekten, der Einführung neuer Geschäftsfelder und Produkte sowie der Sicherstellung von Governance- und Regulatorik-Anforderungen gewährleisten den erforderlichen fachlichen, prozessualen und technischen Hintergrund.

Nutzen Sie unsere umfangreichen Erfahrungen und sprechen Sie mit uns:

bankon Management Consulting GmbH & Co. KG
Max-Planck-Str. 8
85609 Aschheim/München
Tel.: (089) 99 90 97 90
Fax: (089) 99 90 97 99
Web: https://www.bankon.de
E‑Mail: research@bankon.de

ZAIT – Regulatorik für Zahlungsinstitute und E‑Geld-Institute

Veröffentlicht am 15. Juni 202116. Juni 2021 von Ralf-Michael Jendro

„Früher oder später kriegen wir Euch alle“ mag die Finanzaufsicht (flapsig formuliert) gedacht haben, als sie mit den Zahlungsdienstaufsichtlichen Anforderungen an die IT (ZAIT) ihre aufsichtsrechtlichen Vorgaben auch auf Zahlungsinstitute und E‑Geld-Institute ausgedehnt hat.

Derzeit befinden sich die ZAIT in der Konsultation – jedoch ist nach Abschluss dieser unmittelbar mit einer Gültigkeit der ZAIT zu rechnen.

Unterstützt wird diese Annahme durch die Tatsache, dass die ZAIT das Kapitel „Kundenbeziehungen mit Zahlungsdienstnutzern“ formuliert, das nach der Konsultation auch Bestandteil der Bankenaufsichtlichen Anforderungen an die IT (BAIT) wird.

Die Begründung für die plakative Einleitung dieses Artikels gibt die Übersicht der aufsichtsrechtlichen Anforderungen, die seitens der Finanzaufsicht bisher vorgegeben wurden.

Wurden zu Beginn Banken und Versicherungen in den Mittelpunkt gerückt und entsprechende aufsichtsrechtliche Anforderungen für die sichere Ausgestaltung der IT-Systeme sowie der zugehörigen Prozesse und die Umsetzung der IT-Governance eingeführt, folgten bereits 2019 spezifische Anforderungen für Kapitalverwaltungsgesellschaften. Dazwischen wurde für besonders kritische IT-Systeme das KRITIS-Modul eingeführt. Im Jahr 2020 erfuhren die BAIT eine deutliche Erweiterung, die vor allem den Informationsverbund in den Mittelpunkt rückte und seine Definition gegenüber den bisher gültigen BAIT deutlich ausbaute.

Im Jahr 2021 befinden sich nun die ZAIT in der Konsultationsphase. Zunächst behandeln wir in diesem Artikel zwei Fragen:

Wen betreffen die ZAIT?
Wie unterscheiden sich die ZAIT von den anderen aufsichtsrechtlichen Anforderungen an die IT?

Wen betreffen die ZAIT?

Betroffen von den ZAIT sind Zahlungsinstitute und E‑Geld-Institute:

Zahlungsinstitute:
- Derzeit sind etwa 70 Zahlungsinstitute bei der Finanzaufsicht registriert
- Zahlungsinstitute betreiben gewerbsmäßig Zahlungsdienste wie z. B. Einzahlungs- oder Auszahlungsgeschäft, Lastschrift‑, Überweisungs- oder Zahlungskartengeschäft ohne Kreditgewährung oder Zahlungsgeschäft mit Kreditgewährung
- Auch Anbieter von Zahlungsauslösediensten oder Kontoinformationsdiensten zählen zu den Zahlungsinstituten
E‑Geld-Institute:
- Derzeit sind neun E‑Geld-Institute bei der Finanzaufsicht registriert
- E‑Geld-Institute begeben E‑Geld
- E‑Geld ist der elektronisch, darunter auch magnetisch, gespeicherte monetäre Wert in Form einer Forderung an den Emittenten, der gegen Zahlung eines Geldbetrags ausgestellt wird, um damit Zahlungsvorgänge im Sinne des BGB durchzuführen

Somit handelt es sich quantitativ um eine eher kleine Zahl betroffener Institute, für diese erfahren die vorgegebenen Anforderungen aber eine deutliche Anspruchssteigerung.

Was sind die Gemeinsamkeiten und Unterschiede der ZAIT zu anderen aufsichtsrechtlichen Anforderungen?

Auch der grundsätzliche Aufbau beider Dokumente ist in seiner Struktur nahezu identisch. Ebenso steht der Informationsverbund bei den ZAIT im Mittelpunkt der Betrachtungen. Aus beiden Anforderungsdokumenten heraus gilt für die Institute das Proportionalitätsprinzip in der Umsetzung der geforderten Maßnahmen.

Was unterscheidet die ZAIT von anderen regulatorischen Vorgaben wie z. B. den BAIT? Fünf Punkte fallen hier auf und sollen kurz betrachtet werden. Sie betreffen folgende Kapitel:

IT-Governance
Informationssicherheitsmanagement
IT-Projekte und Anwendungsentwicklung
Auslagerung und sonstiger Fremdbezug
Notfallmanagement

Im Zusammenhang mit der IT-Governance liegt die wesentliche Unterscheidung darin, dass eine Ausrichtung der IT an etablierten Standards zu erfolgen hat. Hier werden drei Standards explizit genannt (IT-Grundschutz des Bundesamts für Sicherheit in der Informationstechnik (BSI), die internationalen Sicherheitsstandards ISO/IEC 270XX der International Organization for Standardization und der Payment Card Industry Data Security Standard (PCIDSS)).

Im Informationssicherheitsmanagement besteht die Möglichkeit, die Funktion des Informationssicherheitsbeauftragten mit anderen Funktionen im Unternehmen zu kombinieren oder, in besonderen Fällen, auch außerhalb des Unternehmens anzusiedeln.

Für IT-Projekte und Anwendungsentwicklung gibt es explizite Anforderungen an die durchzuführende Auswirkungsanalyse und die Nutzung des Begriffs „wesentliche Veränderung“ im Zusammenhang mit Vorgaben für die Testdurchführung.

Das Kapitel Auslagerung und sonstiger Fremdbezug enthält deutlich umfangreichere Anforderungen in den ZAIT als in den BAIT, die es zu berücksichtigen gilt.

Im Notfallmanagement wird die Notwendigkeit zur Durchführung von Auswirkungsanalysen und Risikoanalysen gefordert.

Erste Schritte für Zahlungsinstitute mit den ZAIT:

In einem ersten Schritt gilt es für die Zahlungsinstitute und die E‑Geld-Institute, ihre individuelle Ausgangssituation vor dem Hintergrund der ZAIT zu kennen. Nur dann lässt sich der erforderliche Handlungsbedarf identifizieren.

Vorrangig gilt es, einen Überblick über das eigene Institut, die genutzten Auslagerungen sowie die Zahlungsdienstnutzer zu erhalten. Dieses schließt auch den Informationsverbund ein, der ein Nukleus der ZAIT ist.

Inhaltlich stehen fünf Handlungsfelder im Mittelpunkt der Erhebung.

In welchem Umfang sind bereits Vorbefassungen zu Regulatorikanforderungen im Institut erfolgt, z. B. durch eine interne Erstanalyse oder die Jahresabschlussprüfung des Wirtschaftsprüfers?
Wie steht es um die Governance des Instituts, z. B. in Bezug auf eine durchgängige und dokumentierte strategische Ausrichtung oder ein etabliertes internes Kontroll- und Prüfungswesen?
Wird heute bereits auf etablierte Standards zurückgegriffen, auch über die in der ZAIT genannten hinaus, z. B. ITIL oder Cobit?
Wie transparent sind die bestehenden Auslagerungen technisch und organisatorisch und in welcher Form sind diese in Kontrollprozesse eingebunden?
Welchen Stand hat die personelle und technische Ausstattung des Instituts quantitativ und qualitativ?

Die Ermittlung der Ausgangssituation kann mittels eines Quick-Checks erfolgen, um auf Grundlage dieser Informationen einen Überblick über den erforderlichen Handlungsbedarf zu erhalten und eine Indikation für die Ausgestaltung des Proportionalitätsprinzips zu gewinnen.

In einer Ausbaustufe kann sich eine Reifegradanalyse anschließen, für die es sich empfiehlt, diese bereits an einen etablierten Standard auszurichten, z. B. der ISO 27000-Reihe.

Neben der inhaltlichen Analyse zu den Kriterien des Standards ermöglicht ein solches Vorgehen auch eine Visualisierung für das Management.

Expertise bankon Management Consulting

Die Expertise der bankon-Berater aus mehr als fünfzehn Jahren Erfahrung aus Projekten im Kontext der Banken-IT sichert praxiserprobtes Wissen. Erfahrungen aus einer Vielzahl von Regulatorikprojekten bei Finanzdienstleistern gewährleisten die Sicherstellung von Governance- und Regulatorik-Anforderungen. Langjährige Praxisexpertise aus Projekt- und Linientätigkeit bei Zahlungsinstituten schaffen den erforderlichen fachlichen, prozessualen und technischen Hintergrund.

Nutzen Sie unsere umfangreichen Erfahrungen und sprechen Sie mit uns:

bankon Management Consulting GmbH & Co. KG
Max-Planck-Str. 8
85609 Aschheim/München
Tel.: (089) 99 90 97 90
Fax: (089) 99 90 97 99
Web: https://www.bankon.de
E‑Mail: research@bankon.de

„Agilität in Regulatorikprojekten – Widerspruch oder Chance?“

Veröffentlicht am 19. April 202119. April 2021 von Ralf-Michael Jendro

Anzahl und Komplexität von Regulatorikprojekten in Banken steigen ständig. Immer mehr Ressourcen, personell und finanziell, werden mit der Sicherstellung einer regulatorikkonformen Governance gebunden. Leider ist der Beitrag zur unternehmerischen Wertschöpfung von Regulatorikprojekten nahezu „Null“. Aus diesem Grund kommt der effektiven Bearbeitung regulatorischer Anforderungen sowie dem effizienten Management von Regulatorikprojekten eine hohe Bedeutung zu. Können hier agile Methoden oder gar Scrum helfen?

Zur Klärung einer Eignung von Scrum für die Durchführung regulatorischer Projekte in Banken empfiehlt sich ein Blick auf die Charakteristika von Projekten, bei denen Scrum idealtypisch eingesetzt wird.

Kennzeichen von Projekten Scrum vs. Wasserfall

Aufgrund der gesetzlichen oder aufsichtsrechtlichen Vorgaben, an denen Regulatorikprojekte ausgerichtet sind, wird auf den ersten Blick deutlich, dass diese Art von Projekten nicht die Kennzeichen aufweisen, die ein Projekt charakterisieren, das sich gut für die Anwendung von Scrum eignet. Selbstverständlich lässt sich einwenden, dass Methodiken immer auch eine individuelle Interpretation oder Ausprägung aufweisen. Scrum lebt aber gerade von der Einhaltung des Methodenkanons, um seine Wirkung entfalten zu können. Methodische „Eingriffe“ stellen hier den Erfolg eines Scrum-Projektes schnell in Frage – die Anwendung von Scrum wird mit diesen Eingriffen abgebrochen.

Lösen wir uns vor diesem Hintergrund einmal von dem Begriff Scrum und rücken stattdessen Agilität in den Mittelpunkt der Betrachtung. Unter der Fragestellung, ob und wenn ja welche agilen Methoden für Regulatorikprojekte geeignet sind, ist eine Entkopplung von der Strenge der durch Scrum determinierten Vorgaben möglich.

Welche agilen Methoden gibt es, die in Scrum genutzt werden, und gibt es darüber hinaus geeignete Ergänzungen dieses agilen Toolsets – diese Frage soll im Folgenden betrachtet werden, um danach die Eignung für einen Einsatz in Regulatorikprojekten zu bewerten.

Die aus Scrum bekannten agilen Methoden lassen sich aus meiner Erfahrung grob in drei Schwerpunkte aufteilen. Sie unterstützen eine inhaltliche Strukturierung, eine zeitliche Strukturierung oder stellen die Interaktion der Beteiligten in den Mittelpunkt. Nachstehende Übersicht ordnet die in Scrum genutzten Methodenbausteine diesen drei Schwerpunkten zu.

Agile Methoden - Schwerpunkt Interaktion

Zu 1 – Inhaltliche Strukturierung

Mittels eines Backlogs können Anforderungen in unterschiedlicher Ausprägung und Dokumentationsform verwaltet werden
Neben der Beschreibung erfolgt für die Inhalte eines Backlogs eine Darstellung von Aufwand und Nutzen sowie eine Priorisierung
Entsprechend der Priorisierung wird die Beschreibung detaillierter spezifiziert
Das Kanban-Board visualisiert Arbeitsfortschritte
Aufgaben durchlaufen nach Arbeitsfortschritt gegliederte Rubriken, die je nach Einsatzzweck unterschiedlich gegliedert werden, z. B.:
- Zu tun | In Arbeit | Erledigt
- Backlog | Konzeption | Umsetzung | Test | Freigabe | Erledigt

Eignung für Regulatorikprojekte:

Eine strukturierte Sammlung von Anforderungen ist Inhalt jedes Projektes und damit auch für Regulatorikprojekte essenziell. User Stories werden sicherlich nicht die dominierende Bedeutung in der Zusammensetzung des Backlogs haben. Ebenso wenig wird die Summe der Anforderungen mittels eines Fachkonzepts und eines DV-Konzepts beschrieben, um dann mit dem Label Backlog versehen zu werden.

Unter Berücksichtigung eines modularen Aufbaus der Grundgesamtheit von Anforderungen in Regulatorikprojekten ist ein Backlog gut geeignet, um diese als Summe zu verwalten. Aus ihm lassen sich dann zusammenhängende Einzelanforderungen herausziehen und in einen Sprint-Backlog zusammenfassen. Denkbar sind hier beispielsweise Use-Cases zur Anbindung von Anwendungssystemen oder Infrastrukturkomponenten an ein SIEM (Security Incident and Event Management).

Zu 2 – Zeitliche Strukturierung

Sich für einen kurzen Arbeitszeitraum definierte Arbeitsinhalte vorzunehmen, die aus der Grundgesamtheit aller Anforderungen ausgewählt werden, ist unabhängig von Scrum ein sinnvolles Vorgehen zur Handhabung eines komplexen Anforderungsuniversums. Voraussetzung ist jedoch, dass die Inhalte eines Sprints keine zu feste Kopplung zu anderen Anforderungen außerhalb des Sprits aufweisen und damit eine unabhängige Bearbeitung ermöglichen.

Eignung für Regulatorikprojekte:

Folgende Beispiele aus Regulatorikprojekten seien zur Verdeutlichung genannt:

Anbindung von Anwendungen an ein PAM-Tool (privileged access management) zum Handling privilegierter Berechtigungen
Durchführung einer Business-Impact-Analyse für einen Kernprozess
Umsetzung gemeinsamer Schwachstellenscans mit einem IT-Provider

Gemeinsames Charakteristikum obiger Tätigkeiten ist, dass sie nicht durch eine Person allein durchgeführt werden, sondern nur personen‑, abteilungs‑, bereichs- oder firmenübergreifend bewältigt werden können. Mit ihrer losen Kopplung zu anderen Themen sind sie jedoch gut für eine Bearbeitung in Form eines Sprints geeignet.

Deutlich wird anhand dieser Aufgaben jedoch die Notwendigkeit zur Interaktion in der Bearbeitung. Und genau hier liegt der dritte Schwerpunkt agiler Methodiken.

Zu 3 – Interaktion

„Miteinander reden“ hießen nicht nur die vier Standardwerke von Friedemann Schulz von Thun zur Kommunikationspsychologie, sondern auch in Projekten gilt dieser Leitsatz. Aus diesem Grund wurden in der Scrum-Methodik Vorgaben zum strukturierten Austausch umgesetzt, sei es der tägliche Standup oder Sprint-Review und Sprint-Retrospektive. Strukturelle und zeitliche Vorgaben stellen die Effizienz und Effektivität dieser Termine sicher.

Eignung für Regulatorikprojekte:

Die Eignung eines täglichen Standup für Regulatorikprojekte steht außer Zweifel, hat sich doch dieses kurze Meeting inzwischen weit über Scrum hinaus in den beruflichen Alltag ausgebreitet. Wichtig im Kontext von Regulatorikprojekten ist hier jedoch die Einhaltung der strukturellen und zeitlichen Vorgaben aus Scrum, um einen diffusen Informationsaustausch zu vermeiden. Das Ergebnis eines Sprints im Review zu betrachten und Verbesserungen daraus abzuleiten (Retrospektive), ist grundsätzlich auch außerhalb von Scrum wichtig. Die eng gefassten methodischen Vorgaben verlieren jedoch ein Stück weit an Bedeutung, wenn in Regulatorikprojekten nicht wie bei Scrum das Ergebnis eines Sprints produktiv gesetzt wird.

Zusammenfassung:

Zusammenfassend lässt sich sagen, dass Scrum als geschlossene Methodik sicherlich nicht geeignet ist für die Durchführung von Regulatorikprojekten. Aber eine Vielzahl von Elementen aus dem agilen Methodenbaukasten, den Scrum nutzt, lassen sich übertragen. Sie zahlen ein auf die schnelle Erzeugung verwertbarer Ergebnisse im Projekt, die Sicherstellung der Kommunikation sowie die Umsetzung der ganzheitlichen Zielsetzung des Projektes.

Hier haben Erfahrungen gezeigt, dass sich einzelne Elemente auch sehr gut miteinander kombinieren lassen. Explizit sei hier auf die Methodik des Scrumban hingewiesen, in der die Visualisierung mittels Kanban-Board um prozessuale Elemente erweitert wird. So informiert es über die Anzahl der Objekte, an denen das Team gerade arbeitet, sowie die Anzahl an Aufgaben, welche schon abgeschossen sind. Ziel ist hier die Stärkung von Verantwortungsbewusstsein und Kommunikation sowie die Visualisierung der bereits erzielten Leistungsergebnisse.

In einer fortgeschrittenen Ausbaustufe kann ein solches Scrumban-Board durch die inkrementelle Arbeitsplanung Sprints obsolet machen. Jedoch hat sich im praktischen Einsatz die Kombination von Sprints und Scrumban-Boards bewährt. Das Prinzipbild eines Scrumban-Boards zeigt nachstehende Abbildung.

Expertise bankon Management Consulting

Auf dieser Grundlage sowie mittels unseres langjährigen Erfahrungsschatzes in der erfolgreichen Anwendung traditioneller und agiler Methoden im Projekt wählen wir gemeinsam mit Ihnen den für Ihr Institut geeigneten Methodenmix aus.

Nutzen Sie unsere umfangreichen Erfahrungen und sprechen Sie mit uns:

bankon Management Consulting GmbH & Co. KG
Max-Planck-Str. 8
85609 Aschheim/München
Tel.: (089) 99 90 97 90
Fax: (089) 99 90 97 99
Web: https://www.bankon.de
E‑Mail: research@bankon.de

„Handlungsdruck für Banken – BAIT-Neuerungen 2021“

Veröffentlicht am 11. Januar 202118. Februar 2021 von Ralf-Michael Jendro

Als 2017 die Bankaufsichtlichen Anforderungen an die IT, kurz BAIT, als Konkretisierung der in den MaRisk geregelten regulatorischen Anforderungen an die Informationstechnik von Banken eingeführt wurden, ging ein Raunen durch die Community. In der BAIT wurde erstmals konkret vorgegeben, wie die Aufsicht sich die regulatorikkonforme Ausgestaltung der Banken IT vorstellt. Zwar galt für die BAIT das Proportionalitätsprinzip, das eine Ausgestaltung anhand der konkreten Situation des jeweiligen Instituts zuließ. Prüfungserfahrungen von EZB, Bundesbank, BaFin, aber auch der hauseigenen Revisionsabteilungen haben jedoch gezeigt, dass die BAIT nicht als gestaltungsfreier „Papiertiger“ verstanden, sondern als „umzusetzen“ vorgegeben werden. Die spezifischen Anforderungen für kritische IT-Strukturen in dem im Jahr 2018 ergänzten KRITS-Modul machten deutlich, dass der mit der BAIT eingeschlagene Weg seitens der BaFin konsequent fortgeführt wird.

Zwei Jahre sind seitdem vergangen. Viele Institute sind auch heute noch damit beschäftigt, die auf Grundlage der BAIT erfolgten Feststellungen aus internen und externen Prüfungen zu bearbeiten und ihre IT compliant zu gestalten. Da steht auch bereits eine signifikante Erweiterung der Anforderungen aus der BAIT in den Startblöcken. 2020 erfolgte die Konsultationsphase mit den Instituten. Für das kommende Jahr 2021 ist vom Go-live der neuen Ansprüche auszugehen.

Drei neue Kapitel ergänzen die bestehenden Anforderungen, von denen die operative IT-Sicherheit und das IT-Notfallmanagement die beiden bedeutsameren sind im Vergleich zum Kapitel Kundenbeziehungen zu Zahlungsdienstleistern.

Mit dem neuen Kapitel „operative IT-Sicherheit“ werden die bisherigen Anforderungen an Netzwerksicherheit, Systemhärtung, Penetrations- und Schwachstellentest geschärft und in einem eigenen Kapitel gebündelt.

Das neue Kapitel IT-Notfallmanagement trägt der Tatsache Rechnung, dass sich die EBA-Guidelines explizit mit diesem Handlungsfeld befassen und ergänzt die BAIT um Inhalte des IT-Notfallmanagements sowie des Business-Continuity-Managements. Neben der Identifikation der für Notfälle relevanten Ressourcen und Prozesse stehen Maßnahmen zur Gewährleistung der Fortführung des Geschäftsbetriebs im Falle von Notfällen im Fokus dieses Kapitels. Hinzu kommen Anforderungen an die Durchfügung von Tests und Übungen zur Sicherstellung der Wirksamkeit der definierten Vorkehrungen.

Über die neuen Kapitel hinaus wurden auch bestehende Stellen konkretisiert oder erweitert. Eine wesentliche Veränderung im Vergleich zu der bestehenden BAIT liegt im prozessualen Betrachtungsgegenstand.

Standen bisher die IT-Prozesse sowie die IT-Systeme als Informationsverbund im Mittelpunkt der Betrachtung, sind jetzt sämtliche Geschäftsprozesse im Fokus, und zwar hinsichtlich ihrer Unterstützung mittels IT-Anwendungen, Infrastrukturen und Daten. Dieses ist neu und erweitert den Scope nachhaltig. Vor allem auch deshalb, weil die Einbindung von externen Dienstleistungspartnern nicht mehr primär auf das Handlungsfeld Sourcing/Dienstleistersteuerung beschränkt ist. Vielmehr sind die IT-relevanten Elemente ihrer Leistungsunterstützung im Prozess relevante Scopes. Der Informationsverbund als Betrachtungsgegenstand erhält so eine andere Komplexität, die es in der Bank regulatorisch zu managen gilt.

Ebenso eine Ausweitung erfahren die Anforderungen an IT-Serviceprozesse. So sind mit der Erweiterung der BAIT die beiden ITIL-Prozesse Capacity-Management und Availability-Management in den Instituten zu etablieren.

Das Capacity-Management sichert die Kapazität der IT-Services sowie der IT-Infrastruktur. Ziel ist, dass alle Komponenten der IT-Services die vereinbarten Kapazitäts- und Performanceziele erreichen, auch unter Berücksichtigung zukünftiger Anforderungen.

Das Availability-Management stellt die Verfügbarkeit der IT-Services sicher, in dem alle Komponenten der IT-Services die vereinbarten Verfügbarkeitsziele erreichen.

Wichtig ist hierbei der Bezug zu den oben beschriebenen Ausweitungen in der Definition des Informationsverbundes. Dadurch wird deutlich, dass eine bankinterne Betrachtung der beiden neuen Prozesse zu kurz greift und die beteiligten Dienstleistungspartner einzubinden sind.

Nachstehende Abbildung fasst diese neuen, respektive verschärften Ansprüche der BAIT-Anforderung zusammen und zeigt, welche Effekte diese auf die Institute erwarten lassen.

Schon auf den ersten Blick wird deutlich, dass die neuen ebenso wie die erweiterten Anforderungen der BAIT nicht mittels eines „Quick Hit“ zu bewältigen sind. Zu umfangreich waren und sind die Herausforderungen aus den 2017 und 2018 formulierten Anforderungen der BAIT für die Banken.

Entsprechend der individuellen Ausgangssituation des Instituts und dem Grad der für die eigene IT gewählten Standardisierung gibt es hinsichtlich des Umsetzungshorizonts kurzfristige Aspekte, grundsätzlich aber eher eine langfristige Perspektive. Durch die Ausweitung des Informationsverbundes sind die BAIT kein ausschließliches IT-Thema mehr, sondern ein Prozessthema, das die IT-Unterstützung des jeweiligen Prozesses im Fokus hat. Damit sind neben den Spezialisten des eigenen IT-Bereichs zunehmend solche der relevanten Dienstleistungspartner einzubinden. Darüber hinaus sind auch Experten aus den Fachbereichen der Bank zu involvieren.

Damit wird deutlich, dass insgesamt ein hoher Aufwand für die Institute mit der Umsetzung der Neuerungen in der BAIT verbunden ist.

Vor diesem Hintergrund sind zwei Tätigkeiten von herausgehobener Bedeutung. Erstens die Identifikation des Informationsverbunds für die betroffenen Geschäftsprozesse, um den Handlungsrahmen und die einzubindenden Parteien transparent und vollständig zu identifizieren. Zweitens die darauf aufbauende Ableitung einer Umsetzungsroadmap, die auch den aktuellen Status quo des Instituts berücksichtigt.

Um dieses so zielgerichtet wie möglich zu tun, ist nicht nur die Kenntnis der regulatorischen Anforderungen entscheidend. Wesentlich bedeutsamer ist die umfangreiche Praxisexpertise zu Bankprozessen sowie der in den Prozessen eingesetzten IT-Systeme und ihrer Schnittstellen untereinander. In Kombination mit Erfahrungen aus Audit- und Umsetzungsprojekten im Kontext Bankenregulatorik stellen sie die kritischen Erfolgsfaktoren dar, eine effiziente Umsetzung der BAIT-Neuerungen zu planen und durchzuführen.

Expertise bankon Management Consulting

Auf dieser Grundlage unterstützt bankon effizient und zielgerichtet in der Identifikation aller beteiligten Assets am Informationsverbund, der effizienten Erstellung einer Umsetzungsroadmap für die BAIT-Neuerungen sowie der Umsetzung selbst.

Nutzen Sie unsere umfangreichen Erfahrungen und sprechen Sie mit uns:

bankon Management Consulting GmbH & Co. KG
Max-Planck-Str. 8
85609 Aschheim/München
Tel.: (089) 99 90 97 90
Fax: (089) 99 90 97 99
Web: https://www.bankon.de
E‑Mail: research@bankon.de

„IT-Regulatorik 2021“ – Wieviel Regulatorik vertragen die deutschen Banken?

Veröffentlicht am 26. November 202012. Februar 2021 von Ralf-Michael Jendro

EBA-ICT, MaRisk 6. Novelle, BAIT – von allen Seiten werden die IT- und Governance-Spezialisten der Banken im Moment mit neuen oder teilweise verschärften regulatorischen Anforderungen konfrontiert. In keiner Weise soll die positive Absicht hinter diesen Maßnahmen in Abrede gestellt werden. Aber es stellt sich dennoch die Frage, wieviel dieser regulatorischen Vorgaben durch die deutschen Banken bewältigt werden können und wie. Verschärft wird diese Frage durch die Tatsache, dass viele Institute aktuell Projekte und Vorhaben durchführen, die noch vorangegangene Anforderungen umsetzen oder die Etablierung im Linienbetrieb sicherstellen.

Regulatorik - Neue Anforderungen RJO — Regulatorik – Neue Anforderungen

Erschwerend kommt ebenfalls noch hinzu, dass die Umsetzung durch die Aufsichtsgremien in zunehmend engerer Taktung kontrolliert wird. EZB, Bundesbank und BaFin sind umfangreich in den Instituten vor Ort, um die erfolgreiche Umsetzung zu verproben. Erfolgreich heißt hierbei jedoch nicht nur die Dokumentation eines abgeschlossenen Projektes, sondern die operative Nachweisführung, dass die eingeführten oder veränderten Prozesse in der Linie etabliert sind und konsequent durchlaufen werden. Darauf aufbauende KVP- oder Lessons-Learned-Prozesse werden dabei als obligatorisch implementiert vorausgesetzt.

Die Prüfungen manifestieren damit eine deutlich gestiegene Anforderungsqualität an den in den Instituten verankerten regulatorischen Reifegrad.

Nun lässt sich zwar feststellen, dass viele der regulatorischen Vorgaben aufeinander aufbauen. Anforderungen aus der europäischen Perspektive (EBA-ICT) werden im Rahmen der 6. MaRisk-Novelle in nationale Vorgaben überführt und in den BAIT konkretisiert. Diese potenzielle Synergie gilt aber nicht in aller Vollständigkeit für Institute jeder Größenklasse. Darüber hinaus bleiben auch unter Berücksichtigung dieser Faktoren erhebliche Umsetzungsanforderungen für die Banken. Die Herausforderungen, die sich für die Institute daraus ergeben, sind unterschiedlich:

Größere Institute, vor allem mit internationaler Ausrichtung, erreicht die „volle Wucht“ der regulatorischen Anforderungen. Diese treffen aber auch auf Zentralbereiche der IT, Governance oder Compliance, die grundsätzlich über die zur Bewältigung dieser Anforderungen erforderliche Qualifikation und quantitative Ausprägung verfügen.

Kleinere Institute mit eher regionaler Ausrichtung sind von regulatorischen Anforderungen unterschiedlich betroffen. Eine wesentliche Unterscheidungskomponente ist hier der Umfang ausgelagerter Tätigkeiten. Je höher und je individueller der Auslagerungsgrad, umso stärker die regulatorischen Berührungspunkte. Verstärkend kommt hier jedoch hinzu, dass gerade bei einer weitgehenden Auslagerung das Expertenwissen dadurch abgebaut wurde. Vielfach ist das zur Bewältigung der regulatorischen Anforderungen erforderliche Know-how nicht mehr in ausreichender Quantität in den Instituten vorhanden.

Die Schlussfolgerung, dass in diesen Fällen die erforderliche Expertise durch Einstellung neuer Mitarbeiterinnen und Mitarbeiter zugeführt werden muss, vernachlässigt eine wesentliche Komponente – den Fachkräftemangel.

Experten in IT-Regulatorik, Governance oder Compliance sind am Markt stark gesucht und nicht in ausreichender Quantität vorhanden. Die Weiterbildung eigener Mitarbeiterinnen und Mitarbeiter in diesen Themen ist eine eher langfristig ausgerichtete Lösung. Das Wissen extern einzukaufen ist aus Kostengründen auch nicht ohne Weiteres möglich.

Welche Möglichkeiten gibt es aber, aus diesem Dilemma zu entkommen und den steigenden regulatorischen Anforderungen als Institut gerecht zu werden?

Aus Sicht von bankon hat sich die Einrichtung eines zentralen Regulatorik-Office bewährt. Dieses koordiniert institutsweit die Aktivitäten zu regulatorischen Veränderungen sowie der Vorbereitung und Begleitung regulatorischer Prüfungen. In seiner Ausgestaltung ermöglicht es institutsindividuelle Anpassungen vor dem Hintergrund der Größe sowie der Geschäfts- und Risikostruktur der Bank. Es ist damit der Single-Point-of-Truth für regulatorische Themen in der Bank.

Die Abbildung der aktuellen regulatorischen Situation der Bank erfolgt über ein zentrales Regulatorik-Backlog. Dessen Inhalt sind die institutsindividuell bewerteten regulatorischen Themen sowie die im regulatorischen Kontext identifizierten bankspezifischen Defizite.

Owner dieses Backlogs ist das Regulatorik-Office, das auch für die inhaltliche Befüllung verantwortlich ist. Im Rahmen von internen und externen Prüfungshandlungen identifizierte Defizite werden hier zentral abgelegt. Sie sind die relevante Informationsquelle für das Aufsetzen regulatorischer Vorhaben oder Projekte im Rahmen des Projektplanungsprozesses.

Die Vorteile dieser organisatorischen und informatorischen Bündelung liegen auf der Hand:

Förderung der bankinternen Verzahnung von Bereichen, die mit regulatorischen Themen befasst sind, z. B. Unternehmenssteuerung, IT, Informationssicherheit, Organisation, Projektportfoliosteuerung, Notfallmanagement oder Dienstleistersteuerung
Mitwirkung bei übergreifenden Initiativen, z. B. zum institutsgruppenspezifischen Umgang mit regulatorischen Anforderungen im Kontext Sourcing
Effiziente Unterstützung interner und vor allem externer Prüfungen durch die Wahrnehmung der Funktion eines zentralen Prüfungs-Offices
Voraussetzung einer systematischen, priorisierten Bearbeitung regulatorischer Defizite mittels Vorhaben und Projekten
Sicherstellung bankinterner Vertretungsmöglichkeiten im Kontext Regulatorik
Unterstützung der Ausbildung bankinternen Wissens zu regulatorischen Themen

Die Synergien und Vorteile sichern den Instituten die Fähigkeit, regulatorische Anforderungen bewältigen zu können. Die Bündelung der Kräfte ermöglicht den Banken, und hier besonders mittelgroßen und kleineren Instituten, die Sicherstellung der erforderlichen regulatorischen Governance.

Denn unabhängig von der Frage, wieviel Regulatorik deutsche Banken vertragen, lässt sich die Tendenz zur Ausweitung regulatorischer Anforderungen zumindest auf Ebene von Einzelinstituten nicht aufhalten. Es können aber sehr wohl die Voraussetzungen geschaffen und optimiert werden, mit diesen Anforderungen umzugehen.

Expertise bankon Management Consulting

Auf dieser Grundlage unterstützt bankon effizient und zielgerichtet im Setup zentraler Regulatorik-Offices und der erforderlichen Überführung in einen Regelbetrieb. Bei Bedarf unterstützt bankon auch operativ im Betrieb des Regulatorik-Office z. B. in der Vorbereitung und Begleitung regulatorischer Prüfungen.

Nutzen Sie unsere umfangreichen Erfahrungen und sprechen Sie mit uns:

bankon Management Consulting GmbH & Co. KG
Max-Planck-Str. 8
85609 Aschheim/München
Tel.: (089) 99 90 97 90
Fax: (089) 99 90 97 99
Web: https://www.bankon.de
E‑Mail: research@bankon.de

„Tiber-EU und Tiber-DE“ – Die europäische Antwort auf Cyberkriminalität in Banken?

Veröffentlicht am 30. Juni 202012. Februar 2021 von Ralf-Michael Jendro

Angriffe von Hackern auf Kreditinstitute sind kein lokales oder nationales Phänomen. Vielmehr ist es ein weltweites Thema, dessen Auftreten nicht mehr nur „hinter vorgehaltener Hand“ diskutiert wird, sondern beinahe im Wochenturnus Schlagzeilen in der Presse erzeugt.

In Deutschland waren bisher im Jahr 2020 viele relevante Banken und Institutsgruppen betroffen. Sei es mittelbar, weil Kreditkarteninformationen unberechtigten Personen zugänglich wurden oder unmittelbar, weil Bankfunktionalitäten für Kunden nicht mehr zugänglich waren. Der Glaube, dass vor allem FinTechs oder Banken mit Internet- oder Mobilgerät-Schwerpunkt Ziel von Cyberkriminalität sind, hat sich als Irrglaube herausgestellt.

Neben wirtschaftlichen Schäden ist es vor allem der Reputationsschaden in Form von Vertrauensverlust, der für die betroffenen Institute relevante Auswirkungen haben kann.

Begrifflich werden ganz allgemein Straftaten, bei denen die Täter moderne Informationstechnik nutzen, als Cyberkriminalität bezeichnet. Fasst man diesen Begriff etwas enger, so werden darunter Straftaten verstanden, die auf Computersysteme und Netzwerke zielen. Hierunter werden auch Aktivitäten der Cyberspionage subsummiert. Die bekannteste Form von Cyberkriminalität ist das Phishing. Zielsetzung ist hier, z. B. Passwörter, Zugangsinformationen oder persönliche Daten mittels gefälschter E‑Mails oder Websites in Erfahrung zu bringen.

Der Gegenpart zur Cyberkriminalität ist für die Banken die Cybersecurity. Ziel ist der Schutz vor technischen und organisatorischen Bedrohungen, die die Sicherheit von IT-Infrastrukturen und die Datensicherheit gefährden. Unter diesem Begriff werden alle Konzepte und Maßnahmen zusammengefasst, mit denen Banken Gefährdungen erkennen, bewerten, verfolgen und vorbeugen mit der Zielsetzung, die Handlungs- und Funktionsfähigkeit schnellstmöglich wiederherzustellen.

Das in diesem Kontext zu gestaltende Maßnahmenbündel setzt sich aus einer Vielzahl unterschiedlicher Komponenten zusammen, wie nachstehendes Prinzipbild zeigt.

Tiber; Regulatorik Grafik 1 — Prinzipbild mit Maßnahmenbündel

Für die Banken stellt sich in diesem Zusammenhang die Frage einer regulatorischen Orientierung, für große, systemrelevante oder international agierende Institute auch die eines europäischen Rahmens für Cybersecurity.

Das Tiber-EU-Framework ist hier ein erster Schritt. Es ist ein Europäisches Rahmenwerk für ein kontrolliertes und institutsindividuelles Testen in Bezug auf Cyberangriffe auf den Finanzmarkt. Die Anwendung ist freiwillig und liegt in der Entscheidungsverantwortung des einzelnen Kreditinstitutes.

Sechs Zielsetzungen werden durch das Tiber-EU-Framework angestrebt:

Europaweite Stärkung der Fähigkeit zur Abwehr von Cyberangriffen bei Finanzdienstleistungsunternehmen
Standardisierung und Harmonisierung im Vorgehen mit der Möglichkeit für nationale Anpassungen
Leitfaden für Behörden zur nationalen Etablierung und Orientierung zur länderübergreifenden Vergleichbarkeit
Unterstützung eines länderübergreifenden Vorgehens für internationale Institute
Regulatorische Entlastung einzelner EU-Mitgliedsstaaten
Gemeinsame Dokumentationsrichtlinien zum internationalen Ergebnisaustausch

Unter dem Fokus Informations- und Erkenntnisgewinnung werden kritische Banksysteme mit realen Angriffsszenarien (Taktiken, Techniken und Prozessen) konfrontiert. Simuliert werden in Form eines ethischen Hackings praxisnahe Angriffe auf bankfachliche Funktionen und die zugrundeliegenden IT-Systeme und IT-Infrastrukturen.

Diese Zielsetzung spiegelt sich in der Namensgebung Tiber (Threat Intelligence-based Ehtical Red Teaming) wieder. Wobei unter Threat Intelligence die aufbereitete Bereitstellung aktueller Informationen zur Bedrohungslage der IT-Sicherheit durch Cyberangriffe und andere Gefahren aus unterschiedlichen Quellen verstanden wird.

Die Testdurchführung gliedert sich in drei Phasen:

Vorbereitung mit der Skizzierung der Bedrohungssituation und Risken im nationalen Finanzsektor sowie dem formalen Start des Tests mit Festlegung der konkreten Zielsetzung, dem Staffing des eigenen Teams und der Beauftragung der Dienstleistungspartner für Threat Intelligence (TI) und Red-Team (RT)
Testdurchführung durch die Dienstleistungspartner für TI und RT. Der TI-Partner erstellt Zielsetzung und Bedrohungsszenario für den „Angriff“ durch das RT
In der Abschlussphase erstellen Angreifer (RT) und auch die Verteidiger einen Abschlussreport, der in gemeinsamen 360°-Workshops zusammengefasst wird und in einen Maßnahmenplan mündet

Für das Institut, das einen Tiber-EU-Test durchführt, stehen sechs Ziele im Vordergrund.

Realitätsnahe Prüfung der eigenen Sicherheit
Gewinnung von Erkenntnissen und Informationen zu Schwachstellen
Praxisbasierte Veranschaulichung der Tragweite von Cyberrisiken
Sensibilisierung der Geschäftsleitung
Erkenntnis über die Notwendigkeit von Schutzmaßnahmen
Ein „Durchfallen“ oder Nichtbestehen ist nicht möglich

Die Durchführung eines solchen ethischen Hackerangriffs erfordert durch das „angegriffene“ Institut, auch wenn dieser Angriff explizit beauftragt wird, vorbereitende und begleitende Maßnahmen. Die gewünschte Realitätsnähe kann zu Beeinträchtigungen des realen Geschäftsablaufs kommen, denen sich das Institut bewusst sein muss.

Aus diesem Grund sind folgende Aspekte explizit in der Vorbereitung und Durchführung zu berücksichtigen:

Sorgfältige Auswahl der Dienstleistungspartner für Threat Intelligence und Red Team
Begrenzung des Scopes und Abstimmung innerhalb des Instituts sowie mit der Aufsicht.
Vorabregelung des Umgangs mit Daten und deren Aufbewahrung im Falle eines erfolgreichen Hackerangriffs
Die vertragliche Situation zwischen Bank und bestehenden IT-Dienstleistungspartnern ist zu prüfen, ob sie die Durchführung eines Tiber-EU-Tests ermöglichen
Prozessuale Abschätzung der Risiken des Angriffsszenarios
Ausgestaltung der Testdurchführung in der Form, dass Auswirkungen auftretender Servicebeeinträchtigungen gering bleiben und durch vorbereitete Maßnahmen zügig behoben werden können
Umgang mit den dokumentierten Ergebnissen des Tests im Spannungsfeld zwischen Offenlegung und Vertraulichkeit

Expertise bankon Management Consulting

Die Expertise der bankon-Berater aus mehr als zehn Jahren Erfahrung mit Projekten im Kontext IT-Regulatorik sichert praxiserprobtes Wissen. Umfangreiche Kenntnis von Organisationsstrukturen, Prozessen und IT-Systemen deutscher Banken und Sparkassen gewährleisten den erforderlichen fachlichen und technischen Hintergrund.

Auf dieser Grundlage unterstützt bankon effizient und zielgerichtet die Vorbereitung und Durchführung von Tiber-EU-Tests von der Zielsetzung bis zur Maßnahmenplanung.

Nutzen Sie unsere umfangreichen Erfahrungen und sprechen Sie mit uns:

bankon Management Consulting GmbH & Co. KG
Max-Planck-Str. 8
85609 Aschheim/München
Tel.: (089) 99 90 97 90
Fax: (089) 99 90 97 99
Web: https://www.bankon.de
E‑Mail: research@bankon.de

„Disruption“ – Neues Schreckensszenario für Banken oder natürliche Entwicklung?

Veröffentlicht am 24. Oktober 201912. Februar 2021 von Ralf-Michael Jendro

Kaum ein anderes Wort wird derzeit für Veränderungen bei Banken häufiger verwendet als „Disruption“. Doch müssen Banken bei diesem Wort vor Angst zusammenzucken, oder wird hier nur eine seit Jahren beobachtbare organische Entwicklung des Marktes beschrieben?

Was verbirgt sich eigentlich hinter „Disruption“, diesem von der Frankfurter Allgemeinen Zeitung bereits 2015 zum Wirtschaftswort des Jahres ernannten Begriff?

„To disrupt“ bezeichnet aus dem Englischen abgeleitet so viel wie stören, unterbrechen, zerreißen. In der Startup-Szene wird der Begriff für Ideen verwendet, die nicht lediglich eine Weiterentwicklung (Evolution) darstellen, sondern eine Neuentwicklung (Revolution). Alte Strukturen werden durch völlig neue ersetzt.

Doch wie stellt es sich in der Realität dar? Wirkt jedes Startup, jede technologische Entwicklung, jede prozessuale Verbesserung wirklich disruptiv und revolutioniert den Markt?

Oder ist nicht gesunder Pragmatismus zielführender, so wie es Amazon-Chef Jeff Bezos formuliert hat, der sagte:

Alles, was die Kunden lieber mögen als das, was sie vorher gekannt haben, ist disruptiv.
Jeff Bezos

Unstrittig ist, der Bankenmarkt in Deutschland steht vor erheblichen Herausforderungen.

Herausforderungen für den deutschen Bankenmarkt

Niedrigzinsphase und Regulatorik, Veränderungen der Kundenbedürfnisse, Wettbewerb durch FinTechs sowie technologische Trends sind nur vier relevante Entwicklungen, denen sich Banken gegenübersehen. Doch wirken diese Trends wirklich disruptiv? Und gilt diese Einschätzung auch für unterschiedliche Institutsgruppen des Banken-Marktes?

Anhand der Sparkassenorganisation soll die Frage detaillierter betrachtet werden, ob und gegebenenfalls welche disruptiven Tendenzen vorliegen oder auf die Institute zukommen.

Niedrigzins und Regulatorik

Die Phase der Niedrigzinsen dauert nun bereits nahezu ein Jahrzehnt an. Ein Ende ist nicht absehbar. Das Kundengeschäft, aber auch die Anlage eigener Vermögenswerte haben in dieser Zeit erhebliche Veränderungen erfahren. Der Zeitraum für Anpassungsmaßnahmen war lang und ist auch heute noch nicht abgeschlossen.

Regulatorische Anforderungen betrafen in letzter Konsequenz auch die einzelne Sparkasse, wurden in erheblichen Teilen aber durch zentrale Akteure der Sparkassen-Finanzgruppe übernommen oder gemildert (z. B. Sparkassenverbände oder zentrale IT-Dienstleister). Dieses gilt für die MaRisk als Ganzes ebenso wie für spezifische Detaillierungen wie die BAIT. Eine Auslagerung von Tätigkeiten an Dienstleister innerhalb der Sparkassen-Finanzgruppe war hier vielfach ein geeignetes Vorgehen.

In beiden Fällen kann nicht wirklich von Disruption gesprochen werden, sondern von der Notwendigkeit einer Anpassung an sich verändernde Rahmenbedingungen.

Potenziell eher disruptive Auswirkungen können die regulatorischen Anforderungen der neuen, noch nicht final verabschiedeten EBA-Leitlinie zum Outsourcing der European Banking Authority entwickeln. Je nach Auslegung droht bestehenden Auslagerungsmodellen massiver Anpassungsbedarf, da die Verantwortung für die Kontrolle der Durchführung technischer und prozessualer Leistungen durch Dritte erheblich umfangreicher wird. Für den Fall einer strikten Interpretation der Leitlinie bestehen für die Institute grundlegende personelle und prozessuale Anpassungserfordernisse.

Neue Wettbewerber

Veränderungen der Wettbewerbssituation hat es immer gegeben. Waren es in den 90er Jahren Direktbanken, die, neu gegründet, den Sparkassen Kundengeschäft wegnahmen, sind es heute FinTechs, die mit Spezialangeboten um die Sparkassenkunden werben.

Bemerkenswert ist weniger die Anzahl neuer Wettbewerber, sondern die Abnahme der Loyalität der Sparkassenkunden. Die Affinität der Kunden, Ihre Bankverbindung vollständig oder in Teilen zu wechseln, ist stetig wachsend und gerade hier leisten neue Wettbewerber einen Beitrag, dieses „Cherry Picking“ der Kunden zu forcieren.

Disruptiven Charakter besitzt diese Entwicklung jedoch nicht.

Kundenbedürfnisse

Das Anlageuniversum deutscher Sparer ist sehr traditionell geprägt. Aktien oder vergleichbare Anlagen haben nicht die Bedeutung wie in anderen Ländern. Innerhalb dieses Portfolios sind die Kundenbedürfnisse jedoch in den letzten Jahren erheblich gestiegen. Individualität, Schnelligkeit und Flexibilität sind Grundanforderungen der Kunden an Ihre Bank.

Sparkassen verfügen durch historisch lange Kundenbeziehungen und ihre lokale Präsenz über eine umfangreiche Datenbasis zur Lebenssituation Ihrer Kunden. Diese geht in der Regel weit über das hinaus, was relevante Wettbewerber zurzeit über ihre Kunden wissen.

Oft ist dieses Wissen jedoch nur in den Köpfen der Berater und steht damit für eine vertriebskanalübergreifende Nutzung nicht zur Verfügung. Eine proaktive Ansprache der Kunden auf Grundlage dieser Informationen ist nur eingeschränkt möglich. Individuelle Prozessauslegung durch Berater oder Standorte erscheinen auf den ersten Blick sehr kundenorientiert, generieren jedoch in der Regel an der Schnittstelle zu Folgebearbeitungen erhebliche Probleme. Die durch den Kunden erwartete Schnelligkeit wird so nicht erfüllt.

Auch dieses Phänomen ist nicht neu und keinesfalls disruptiv. Einheitliche IT-Systeme und dort abgebildete standardisierte Prozesse haben bisher nicht flächendeckend positiv gewirkt.

Technologie

Die Entstehung des Internets und die damit verbundenen Möglichkeiten haben sicherlich disruptive Auswirkungen auf Banken und Sparkassen gehabt. Die Bedeutung der Filiale als nahezu einziger Point of Sale wurde massiv tangiert. Fortgesetzt wurde diese Entwicklung durch die Übertragung des Internets auf mobile Endgeräte, aber auch diese begann bereits vor nahezu zwanzig Jahren mit dem UMTS-Standard.

Die Entwicklung sozialer Netzwerke und ihre flächendeckende Verbreitung waren ein weiterer, bedeutsamer Schritt. Neben der Anpassung des Nutzerverhaltens ermöglichten soziale Netzwerke ihren Betreibern die Möglichkeit, Finanzdienstleistungen selbst oder über Partner anzubieten. Heute jedoch noch von disruptiven Auswirkungen zu sprechen, erscheint übertrieben.

Lässt sich vor dem Hintergrund obiger Ausführungen eine disruptive Tendenz oder gar ein aktueller Zustand von Disruption für Sparkassen in Deutschland konstatieren? Ich denke nicht. Weder die Wettbewerbssituation, noch Kundenbedürfnisse oder neue Technologien liefern aktuell dafür eine Indikation. Selbst die Niedrigzinssituation hat aufgrund der langen Zeitdauer ihrer Gültigkeit keine disruptiven Auswirkungen. Lediglich im Bereich der Regulatorik werden die Anforderungen an die Institute immer umfassender. Dieses gilt nicht mehr nur für systemrelevante Institute, sondern auch immer mehr für die Primärinstitute in ihrer Breite.

Die Problematik disruptiver Tendenzen im Bereich Regulatorik wird durch vier Faktoren verstärkt:

Langer Zeitraum bis zur finalen Ausgestaltung regulatorischer Anforderungen
Gültigkeitsbereich oft erst spät im Detail verabschiedet
Verbleibende Interpretationsspielräume für die Umsetzung
Kurze Umsetzungsfristen nach Inkraftsetzung

Ebenso kritisch sind die Auswirkungen, die daraus für die Institute entstehen:

Anpassungsbedarf an bestehende Prozesse
Erweiterte Einflüsse auf Entscheidungen zur Auslagerung von Tätigkeiten bis hin zur Notwendigkeit, umgesetzte Auslagerungen zu hinterfragen
Erfordernis spezifischer Qualifikationen bei Mitarbeitern (quantitativ und qualitativ)

Doch wo liegen die wesentlichen gestalterischen Hebel für eine Bank, sich zukunftssicher aufzustellen und diesen disruptiven Tendenzen zu begegnen? Vier Stellgrößen bieten sich hier an:

Prozesse

Stringenz und Durchgängigkeit sind die hervorstechendsten Eigenschaften, denen bei der Gestaltung der Prozesse Rechnung zu tragen ist. Wo irgend möglich, ist mittels Standardisierung und technischer Unterstützung eine gleichbleibende Prozessqualität sicher zu stellen. Dieses gilt insbesondere, wenn Prozesse oder ganze Prozessgruppen zur Durchführung an Dritte ausgelagert werden.

Ausbau Systemnutzung

Eingesetzte Systeme sind entsprechend ihres Einsatzzweckes obligatorisch zu nutzen. Darüber hinaus hat die Nutzung in der vorgegebenen Form zu erfolgen. Dieses mag sich selbstverständlich anhören, aber die Erfahrung zeigt, dass die Systemnutzung inklusive Erfassung und Ablage von Daten in der Regel eher individuell denn standardisiert erfolgt. Der mit dem Systemeinsatz erwartete Mehrwert wird so nicht erreicht.

Datenqualität (Erhebung, Erfassung, Aktualisierung)

Die vom Kunden erhobenen Daten sind systematisch (entsprechend datenschutzrechtlicher Anforderungen) zu erfassen und nutzbar zu machen. Kopfmonopole als Datensenken sind aufzulösen. Nur so ist eine vertriebskanalübergreifende Informationsbasis sicherzustellen und aktuell zu halten. Wesentlicher Erfolgsfaktor hier ist wieder die Einhaltung der Prozesskonformität und die konsequente, einheitliche Nutzung der eingesetzten IT-Systeme.

Stärkung Sourcing-Management

Sind obere Stellhebel adäquat gestaltet ist eine zielführende und regulatorikkonforme Auslagerung von Leistungen überhaupt erst möglich. Vor dem Hintergrund des Anstiegs regulatorischer Anforderungen ist in der auslagernden Bank sicherzustellen, dass das für die Steuerung des Dienstleistungspartners adäquate Personal quantitativ und qualitativ zur Verfügung steht. Dieses umfasst nicht nur die methodische, sondern auch die inhaltliche Steuerungskompetenz.

Expertise bankon Management Consulting

Auf Basis der langjährigen Erfahrung von bankon in unternehmensweiten Transformationsprojekten gliedert sich das bankon-Leistungsspektrum in folgende Module:

Gestaltung und Optimierung von Bankprozessen, Messung von Prozessqualität sowie Systemnutzung, Definition und Einhaltung von KPIs.
Messung und Förderung der Systemnutzung mittels Kennzahlen. Automatisiertes Auslesen z. B. aus dem Kernbanksystem der Sparkassen zur Ermittlung des Reifegrades von Administration und Nutzung des Systems sowie Bereitstellung von Vergleichsdaten und Best Practices.
Analyse des Qualitätsniveaus abgelegter Daten, Abgleich gegen Benchmark-Werte und Erstellung von Handlungsempfehlungen zur langfristigen Sicherung der Datenqualität.
Stärkung des Sourcing-Managements auf Grundlage erfolgreich durchgeführter Sourcing-Projekte (Prüfung, Entscheidungsfindung und Auslagerungsdurchführung) sowie mittels Expertise aus durchgeführten großen Regulatorik-Projekten zur Sicherstellung regulatorischer Adäquanz.

bankon unterstützt in allen Modulen mit bedarfsgerechten Leistungskomponenten, welche eine auf die individuelle Situation zugeschnittene Lösung für Banken und Sparkassen ermöglichen. Die Projektdurchführung kann entsprechend der Kundenwünsche in traditionellem oder auch agilem Vorgehen erfolgen. Die Expertise der bankon-Berater aus mehr als zehn Jahren Erfahrung mit Transformationsprojekten sichert praxiserprobtes Wissen, das ohne relevante Rüstzeiten implementiert werden kann. Umfangreiche Kenntnis von Organisationsstrukturen, Prozessen und IT-Systemen deutscher Banken und Sparkassen unterstützt Sie effizient im Umgang mit aktuellen und zukünftigen disruptiven Entwicklungen. Profitieren Sie von der langjährigen Praxis-Expertise unserer bankon-Berater und sprechen Sie uns an.

Nutzen Sie unsere umfangreichen Erfahrungen und sprechen Sie mit uns:

bankon Management Consulting GmbH & Co. KG
Max-Planck-Str. 8
85609 Aschheim/München
Tel.: (089) 99 90 97 90
Fax: (089) 99 90 97 99
Web: https://www.bankon.de
E‑Mail: research@bankon.de

Autor: Ralf-Michael Jendro

Transformationsprojekte in Banken – agil gedacht, hybrid gemacht

CoOpetition 2.0 – Banken müssen Ihre IT-Wertschöpfungsketten neu denken

ZAIT – Regulatorik für Zahlungsinstitute und E‑Geld-Institute

„Agilität in Regulatorikprojekten – Widerspruch oder Chance?“

„Handlungsdruck für Banken – BAIT-Neuerungen 2021“

„IT-Regulatorik 2021“ – Wieviel Regulatorik vertragen die deutschen Banken?

„Tiber-EU und Tiber-DE“ – Die europäische Antwort auf Cyberkriminalität in Banken?

„Disruption“ – Neues Schreckensszenario für Banken oder natürliche Entwicklung?

Niedrigzins und Regulatorik

Neue Wettbewerber

Kundenbedürfnisse

Technologie

Prozesse

Ausbau Systemnutzung

Datenqualität (Erhebung, Erfassung, Aktualisierung)

Stärkung Sourcing-Management

Expertise bankon Management Consulting

Neueste News und Artikel

Archiv

Sie finden uns auch hier:

I. Strategie

II. Organisation

III. Prozesse

IV. Tools

V. Verträge

Niedrigzins und Regulatorik

Neue Wettbewerber

Kundenbedürfnisse

Technologie

Prozesse

Ausbau Systemnutzung

Datenqualität (Erhebung, Erfassung, Aktualisierung)

Stärkung Sourcing-Management

Expertise bankon Management Consulting

Neueste News und Artikel

Archiv

Schlagwörter

Sie finden uns auch hier: