Schlagwort: Regulatorik

Transformationsprojekte in Banken – agil gedacht, hybrid gemacht

Veröffentlicht am 19. Mai 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
http://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
http://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
http://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

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.

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
http://www .bankon.de
E‑Mail: research@bankon.de

Cloudcomputing für Banken – Eine gute Vorbereitung ist entscheidend

Veröffentlicht am 2. März 20213. März 2021 von Steffen Rummel

Die richtige Cloud Strategie als Erfolgsbasis

Die hohe Geschwindigkeit des Wandels setzt Banken aller Größenordnungen unter Druck, die Agilität zu erhöhen, die Digitalisierung voranzutreiben und Innovationen zu beschleunigen. Aufgrund dieser Entwicklungen stellt sich nicht mehr die Frage, “ob“, sondern „wann“ und in welchem Umfang die Cloudnutzung für ein Finanzinstitut ein echtes Thema sein wird.

Einhergehend mit der Cloudnutzung wird u. a. eine Verringerung von Kosten, eine stets moderne Infrastruktur und die Einhaltung von strengen Sicherheits‑, Compliance– sowie regulatorischen Anforderungen in Aussicht gestellt. Selbst den Zweiflern ist nun klar, dass eine „digitalisierte Bank“ eine Menge zu bieten hat. Innovationen ermöglichen immer mehr neue Produkte, Prozesse oder neue bzw. erweiterte Geschäftsmodelle. Innovationszyklen werden kürzer und offener. Zudem werden die Daten zusammen mit der IT-Infrastruktur immer mehr zu einem Innovationstreiber.

Wie geht man ein derartiges Vorhaben richtig an, welche Entscheidungen und Vorbereitungen sind notwendig und was sind die kritischen Erfolgsfaktoren?

Grundsätzlich braucht ein derartiges Vorhaben zu Beginn die Bereitschaft, sich auf Veränderungen einzulassen. Es handelt sich dabei erstmal um ein Vorhaben, das mit konkreten fachlich-funktionalen und prozessualen Anforderungen unterlegt werden sollte. Im Grunde geht es um die Definition einer individuell auszuarbeitenden Cloud Strategie. Ein Me-too-Ansatz, d. h. die Imitation bereits definierter Strategien ist nicht zwangsläufig erfolgreich.

Die folgende Abbildung gibt einen ersten Überblick, welche Stakeholder Anforderungen an die Cloudnutzung definieren, welcher Nutzen ermöglicht werden kann und welche Angebote grundsätzlich in Frage kommen:

Abbildung 1: Bei der Cloud Strategie sind unterschiedliche „Anforderer“ mit einzubeziehen

Insgesamt handelt es im Rahmen der Cloud Strategie um eine konstruktive Konversation, in der es um prozessuale, funktionale und architektonische Entscheidungen geht. Die Basis des geschäftlichen Erfolgs bilden mit hoher Wahrscheinlichkeit architektonisch gute Systeme mit dem richtig definierten Serviceangebot. Die Cloudanbieter bieten entsprechende Frameworks an, um sich mit den relevanten grundlegenden Fragen auseinanderzusetzen. Ein gutes Verständnis der nutzbaren IT-Services eines Cloudanbieters sind für eine Ersteinschätzung und deren Realisierbarkeit hilfreich.

Die Themen einer Cloud Strategie bekommen je Institut sicherlich eine unterschiedliche Gewichtung. Die folgende Aufstellung kann jedoch für eine erste Einordnung dienen.

1. Prüfung bzgl. nutzbarer Cloud-Modelle

Im ersten Schritt sollte es darum gehen, die in Frage kommenden Cloudmodelle zu verstehen und seine Anwendungslandschaft entsprechend zu clustern, welche Teile der IT in die Cloud verlagert werden können und welches Modell in Frage kommt.
Die Unterscheidung nach Privat Cloud, Public Cloud, Hybrid Cloud usw. ist hierbei zu bewerten. Dabei sollten die unterschiedlichen Vorteile der Modelle abgewogen werden.
Grundlegende und wesentliche Charakteristika der Bereitstellung und der Bedienung sind näher zu betrachten.
Definition der Cloudbausteine sowie der grundlegenden globalen Infrastruktur
Identifizieren von Quellen für Dokumentation oder technische Unterstützung (zum Beispiel Whitepaper oder Support-Tickets des Cloudanbieters)

2. Festlegung von Infrastruktur Prinzipien für einen effizienten Betrieb

Im zweiten Schritt werden Anforderungen definiert, die sich an die Bereitstellung und den Betrieb der Infrastruktur in der Cloud ergeben.
Es sind Möglichkeiten zu prüfen, welche Preismodelle und Monitoring-Services angeboten werden. Es sind Services zu wählen, die:
die Entwicklung unterstützen und Workloads effektiv ausführen
Einblicke in die Betriebsabläufe gewähren und
den geschäftlichen Mehrwert unterstützende Prozesse und Verfahren fortlaufend verbessern.
Zu betrachten sind ebenfalls Services für die Nutzung technischer Komponenten der Infrastruktur (Server, Datenbanken, Speicher, Netzwerk usw.). Hierbei geht um die Identifikation von Services, die den technischen Betrieb, die Lastverteilung, Skalierung usw. betreffen.

3. Festlegung von Anforderungen an die Sicherheit, Definition von Schutzmaßnahmen

Bei den Prinzipien zur Sicherheit wird beschrieben, wie Daten, Systeme und Komponenten geschützt werden können.
Es geht hier darum, wie Cloud-Technologien genutzt werden können, um die Sicherheitslage zu verbessern, bzw. um regulatorische Anforderungen mit Services in der Cloud abzudecken. Die klassischen Themen sind das Benutzermanagement für die Organisation, Authentifizierungsverfahren, Identifizierungs- und Zugriffsverfahren, Einsatz automatisierter Sicherheitsverfahren, Schutz der Daten sowie die Trennung von Daten und Nutzern.
Zu definieren sind Hauptaspekte für Sicherheit und Compliance der Cloud-Plattform und des Sicherheitsmodells.

4. Festlegung von Prinzipien zur Erreichung einer zuverlässigen und effizienten Infrastruktur

Durch die Vorgabe von KPIs oder beim Überschreiten von Schwellwerten können automatisierte Reaktionen ausgelöst werden. Hierbei geht es nicht nur um technische KPIs, sondern auch um Kennzahlen von Geschäftsabläufen.
Eine „temporäre“ Testumgebung kann effizient und flexibel konfiguriert werden, um festzustellen, welche Ereignisse zu Fehlern führen. Kosten fallen dann lediglich für die Nutzung der Testumgebung an.
Die Messung von Kapazitätsauslastungen, Skalierungen, Elastizitäten sowie die Nutzung steuernder Services vereinfacht das technische Design erheblich.
Zusätzliche Services, wie automatisierte Benachrichtigungen, ergänzen das Serviceangebot. Servicekontingente und die Netzwerktopologie müssen für die zu erbringenden Geschäftsabläufe angemessen definiert sein. Je nach Preismodell können durch gezielte Buchung von Kapazitäten oder Volumina Kosten deutlich reduziert werden.

5. Prüfung Kostenmanagement und Preismodelle

Im Rahmen der angebotenen Preismodelle geht es um den kostenoptimierten Betrieb der definierten Infrastruktur. Für die Optimierung der Kosten werden im Rahmen der Kontoverwaltung und im Preismanagement von den Cloudanbietern Services zur Reduzierung der Kosten angeboten.

6. Einleitung des Transformationsprozesses

Durch den Umzug in die Cloud ergeben sich strukturelle, prozessuale, organisatorische sowie wirtschaftliche Veränderungen.
Verantwortungen und Zuständigkeiten verlagern sich, Anforderungsprofile ändern sich. So könnte beispielweise ein IT-Mitarbeiter statt einer operativen Verantwortung für den Betrieb einer Plattform in die Rolle eines Dienstleistersteuerers für Plattformen wechseln.
Veränderungen sind bereits im Rahmen der Cloud Strategie auf Prozessebene zu identifizieren und deren Umsetzbarkeit in der Cloud zu verifizieren.
Da sich durch die Cloudnutzung v. a. auch das Risikoprofil des Instituts verändert, sind in der folgenden Abbildung Auszüge wesentlicher Risiken aufgeführt, die von Änderungen betroffen sind.

Abbildung 2: Verändertes Risikoprofil durch Cloudnutzung

Was sind nun die Gewinner bzw. Verlierer?

Durch eine Vielzahl erfolgreicher Projekte kennen wir die kritischen Erfolgsfaktoren auf der strategischen und der operativen Ebene und verfügen über umfangreiche Erfahrungen bei der Ausrichtung des Geschäftsmodells bzw. der Erreichung der gewünschten Positionierung durch eine individuell definierte Cloud Strategie.

Gerne sichern wir Ihren Projekterfolg mit unserer Methoden- und Umsetzungskompetenz in diesem komplexen Themenumfeld.

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
http://www .bankon.de
E‑Mail: research@bankon.de

6. MaRisk-Novelle Änderungen AT 9 wesentliche Auslagerung für Sparkassen

Veröffentlicht am 16. Februar 202116. Februar 2021 von Alexander Gniewkowski

Herausforderungen für nicht systemrelevante Kreditinstitute

bankon berät seit Jahren seine Kunden in Banken und Sparkassen bei der Bewältigung von regulatorischen Herausforderungen, die weiterhin mit einer nicht endenden Dynamik die Organisations- und Prozessstrukturen der Häuser treffen. Wir beobachten für unsere Kunden die regulatorischen Entwicklungen und sind zu einem frühen Zeitpunkt nah an den Aufsichtsbehörden und deren Anforderungsentwicklungen dran. Aktuell sind die Arbeiten der BaFin und der Sparkassen zum Thema der 6. MaRisk-Novelle Änderungen AT 9 ‑Auslagerung- in vollem Gange. So bewerten wir für die Sparkassen die sich nunmehr konkretisierenden Anforderungen an das Outsourcing- und Auslagerungsmanagement, die Providersteuerung sowie das Risikomanagement.

Für die Sparkassen, die nicht der europäischen Bankenaufsicht unterliegen, treten die EBA-Leitlinien/neuen Outsourcing-Standards erst mit Überführung in nationales Recht in Kraft. Die Überführung erfolgt seitens der BaFin über die Novelle des Moduls AT 9 der MaRisk (6. MaRisk-Novelle). Dieser Prozess startete im Herbst 2020 und wird im Jahr 2021 mit Hochdruck weiterverfolgt.

Sich verändernde Themen und Rahmenbedingungen für die Sparkassen werden hier von bankon nur exemplarisch benannt:

Ausdifferenzierung in der Kategorisierung von großen/komplexen vs. kleinerer/weniger komplexer Institute im Sinne der MaRisk-Novellierung
Parameter zur Gestaltung Risikoanalyse und Ergänzung einer Szenarioanalyse (qualitative Ansätze vs. interne und externe Verlustdatensammlung)
Konkretisierung Rolle zentraler Auslagerungsbeauftragter und weiterer Rollen wie z. B. Revision
Gestaltungsspielräume für zentrale Erleichterungen nutzbar gestalten (gemeinsame Notfallpläne, Auslagerungsregister, etc.)
Gestaltung und Nutzung von Auslagerungsmusterverträgen

Die deutschen Sparkassen haben unter der Regie des Spitzenverbandes DSGV und der Regionalverbände reagiert und haben Ende 2020 ein Projekt mit dem Ziel aufgesetzt, Rahmenbedingungen, Vorgaben und Hilfsmittel zur Umsetzung der Vorgaben aus der 6. Novelle für ihre Mitgliedsinstitute zu entwickeln und diese in der Folge nutzbar für die Häuser zu gestalten.

Der DGSV und die Regionalverbände stellen bereits heute und in überarbeiteter Form zukünftig den Sparkassen zentral Handbücher, Instrumente/Tools zum Auslagerungsmanagement sowie einen Auslagerungsmustervertrag über die Kanäle wie z. B. InDok+ und den Umsetzungsbaukasten zur Verfügung. Darüber hinaus können die Sparkassen im Rahmen eines indirekten Steuerungsansatzes sog. „Wertungshilfen“ für Dienstleister über die Regionalverbände in Anspruch nehmen.

Die Sparkassen müssen heute und auch nach der Novellierung in Eigenverantwortung die Maßnahmen und Aktivitäten zum Auslagerungsmanagement umsetzen.

Dabei werden die Sparkassen autark entscheiden müssen, in welchem Umfang sie auf die zentralen Empfehlungen und Instrumente/Tools der Verbandsseite zurückgreifen. Juristische und kaufmännische Bewertungen sowie Risikoaspekte werden von den Sparkassen weiterhin individuell verantwortet werden müssen.

Die Gesamtverantwortung für das Auslagerungsmanagement verbleibt auch nach er 6. Novelle der MaRisk AT 9 bei der jeweiligen Sparkasse. Eine vollständige Verlagerung der Verantwortung auf eine zentrale Steuerungseinheit ist mit großer Wahrscheinlichkeit nicht möglich.

Demnach müssen alle Sparkassen in Deutschland nach der Beendigung der vorbereitenden Verbandsprojekte, die Umsetzung der 6. MaRisk-Novelle Änderungen AT 9 aktiv gestalten, die zentral vorgegebenen Empfehlungen ihres Spitzenverbands bewerten und mit Blick auf die Individualität ihres Hauses die Nutzung jeweils umsetzen.

Gerne helfen wir Ihnen bei der Bewertung, der Umsetzungsentscheidung und der operativen Implementierung der notwendigen Methoden und Prozesse und schaffen somit gemeinsam die optimale Ausrichtung Ihres Hauses auf die regulatorischen Anforderungen.

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

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
http://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
http://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
http://www .bankon.de
E‑Mail: research@bankon.de

Deutscher Bankensektor: Quo vadis? – Gewinner oder Verlierer

Veröffentlicht am 27. Oktober 202012. Februar 2021 von Steffen Rummel

Veränderungen im Bankenmarkt – Status quo

Immer mehr regulatorische Vorschriften (BAIT, EBA, ISO, MaRisk, BSI, Basel usw.), technologische Trends (FinTechs, Digitalisierung …) und der Wandel in ein branchenübergreifendes Ökosystem sind wesentliche Treiber aktueller Veränderungen im Bankenmarkt. Die Grundsatzfrage nach der zukünftigen Rolle von Banken in einer digitalen Welt beeinflusst die Ausrichtung des Geschäftsmodells gleichermaßen wie Investitionen in die Bankenarchitektur. Dabei wird darauf zu achten sein, dass der Fokus nicht nur im „RUN the bank“ liegt, sondern vor allem im „CHANGE the bank“. Das zukünftige Angebot orientiert sich hierbei sehr stark an den Bedürfnissen von Kunden, Mitarbeitern/Mitarbeiterinnen, Partnern und Wettbewerbern. Die Erfüllung der Erwartungen unterschiedlicher Zielgruppen (v. a. Firmenkunden und Privatkunden) stehen hierbei im Mittelpunkt.

Was sind nun wichtige Erfolgsfaktoren?

Die zukünftigen Geschäftsmodelle der Banken sollten auf folgende Themen entsprechende Antworten haben:

Bedürfnisse der Kunden kennen, verstehen und die passenden Produkte und Services anbieten. Ein sensibler Umgang mit Daten, der Mut zur Nutzung von Innovationen und die Zusammenarbeit mit FinTechs sind dabei wichtige Erfolgsfaktoren. Das Angebot in der Filiale wird dabei immer mehr durch Funktionen in der Smartphone App abgelöst.
Neben der Umsetzung von regulatorischen Vorgaben geht es immer mehr um die Öffnung der Banken nach außen. Die Nutzung der Innovationskraft neuer Anbieter im Markt durch FinTechs oder GAFAs kann sich durchaus positiv auswirken. Neue Anbieter stellen die Interessen und Gewohnheiten der Kunden häufig anders in den Mittelpunkt.
Die Transformation der Banken-IT in eine modulare Innovations-IT mit immer kürzeren Updatezyklen muss mit der wachsenden Regulatorik und den zunehmenden Kundenerwartungen Schritt halten. Dies eröffnet zudem Möglichkeiten, neue Ertragsquellen zu erschließen.
Betrachtet man die operative Kostensituation der Banken, sind die Belastungen trotz unvermeidbarer regulatorischer Investitionen in den letzten Jahren nur leicht gestiegen. Die Eigenkapitalrendite deutscher Banken liegt im internationalen Vergleich dagegen auf einem sehr niedrigen Niveau. Der aktuelle Konsolidierungskurs im Bankensektor wird sich weiter verstärken. Dabei werden sich zentrale Produkt- und Plattformanbieter für spezifische kunden- und marktrelevante Themen herauskristallisieren. Zusätzlich wird es eine weitere Verschmelzung von IT-Dienstleistern sowie eine Konsolidierung von Marktfolgetätigkeiten geben. Zudem lässt sich auch die Bildung von sog. Kompetenzzentren in Verbünden beobachten.
Ein weiterer wichtiger Faktor ist die Veränderungsbereitschaft. Der Kulturwandel bzw. die Veränderungen und deren Akzeptanz sollte von gestalterischem Handeln vonseiten des Bankmanagements geprägt sein.

Sicherlich gibt es noch weitere Faktoren, die hier genannt werden können. Der eingesetzte Trend lässt sich jedoch eindeutig erkennen. Dieser wird auch noch deutlich an Fahrt zunehmen.

Wer sind nun die Gewinner bzw. Verlierer?

Betrachtet man die Möglichkeiten der Marktpositionierung, bilden sich unterschiedliche Entwicklungsszenarien heraus. Ein Schwerpunkt liegt hier bei der Fokussierung auf eine bestimmte Region oder in der Konzentration auf ein spezielles Produkt. Bei diesem Szenario werden die Geschäftsmodelle adaptiert. Lokalen Banken steht hier die Möglichkeit offen, die geographische Nähe zum Kunden auszuspielen. Durch die regionale Verankerung bieten Sie ein umfassendes Produktangebot an. Die Bank besetzt hier die wichtige Kundenschnittstelle und bindet andere Dienstleister und Anbieter an. Daneben bleibt die Möglichkeit, sich über ein spezifisches Produkt oder Dienstleistungsangebot am Markt zu positionieren. Lokale und überregionale Banken haben hier vergleichbare Ansätze und treten in eine Konkurrenzsituation. Banken ohne regionale Verankerung oder eine entsprechende Positionierung als Anbieter werden im Wettbewerb früher oder später der fortschreitenden Konsolidierung zum Opfer fallen.

Betrachten wir nun die Beziehung zwischen der traditionellen Bank und den Kunden. Hier kommt es zu einem schnellen und nachhaltigen Durchbruch neuer Technologien, die von Kundenseite genutzt werden. Ein nachhaltiger Nutzen wird erreicht, wenn ein Anbieter einem Kunden ein optimales Angebot erstellt, erklärt und liefert. Je besser die technologischen Möglichkeiten genutzt werden, umso einfacher kann es für den Kunden sein. So ist bei vielen Dienstleistungen, z. B. im Zahlungsverkehr, kein Kundenkontakt notwendig. Alternativ kann sich die Bank als Anbieter für Produkte positionieren, die aus Risikosicht nicht über Plattformen angeboten werden (z. B. Finanzierungen). Die Rolle der Bank als Risikopartner ist vor allem für überregionale Banken aufgrund der Diversifizierung interessant. Wenn es dann noch gelingt, Skalenvorteile nutzen zu können, sind die Voraussetzungen schon vielversprechend. Wichtig hierbei wird jedoch sein, das Produktangebot weiter zu erneuern und den Kundennutzen weiterhin im Blick zu haben. Die Kundennähe, die nach traditioneller Art immer durch eine vor Ort-Präsenz definiert wurde, wird immer mehr durch die Digitalisierung zurückgedrängt.

Gerne sichern wir Ihren Projekterfolg mit unserer Methoden- und Umsetzungskompetenz in diesem komplexen Themenumfeld, damit die Bewertung der Zukunftstrends wieder ausgeglichen ist.

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
http://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
http://www .bankon.de
E‑Mail: research@bankon.de

Schlagwort: Regulatorik

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?“

6. MaRisk-Novelle Änderungen AT 9 wesentliche Auslagerung für Sparkassen

Herausforderungen für nicht systemrelevante Kreditinstitute

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

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

Deutscher Bankensektor: Quo vadis? – Gewinner oder Verlierer

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

Neueste News und Artikel

Archiv

Sie finden uns auch hier:

1. Prüfung bzgl. nutzbarer Cloud-Modelle

2. Festlegung von Infrastruktur Prinzipien für einen effizienten Betrieb

3. Festlegung von Anforderungen an die Sicherheit, Definition von Schutzmaßnahmen

4. Festlegung von Prinzipien zur Erreichung einer zuverlässigen und effizienten Infrastruktur

5. Prüfung Kostenmanagement und Preismodelle

6. Einleitung des Transformationsprozesses

Was sind nun die Gewinner bzw. Verlierer?

Herausforderungen für nicht systemrelevante Kreditinstitute

Neueste News und Artikel

Archiv

Schlagwörter

Sie finden uns auch hier: