Deutsche Bundesbank, BMF TIBER-DE macht deutsches Finanzsystem sicherer/ IT-Sicherheit, MaRisk BAIT, Cyber-Sicherheit


Ihr Account ist nicht für das Rechtsmonitoring freigeschaltet


Um die Rechtsmonitoring-Funktionalitäten nutzen zu können, müssen Sie erst einen Zugang erwerben!


Wenn Sie einen Probemonat erwerben möchten schicken Sie uns eine E-Mail mit dem Betreff: "Probemonat Rechts- und Regulatorikmonitoring" an info@fc-heidelberg.de

BaFin-Tech 2019-Veranstaltung, IT-Aufsicht bei Banken/ Risikomanagement, Digitalisierung


Ihr Account ist nicht für das Rechtsmonitoring freigeschaltet


Um die Rechtsmonitoring-Funktionalitäten nutzen zu können, müssen Sie erst einen Zugang erwerben!


Wenn Sie einen Probemonat erwerben möchten schicken Sie uns eine E-Mail mit dem Betreff: "Probemonat Rechts- und Regulatorikmonitoring" an info@fc-heidelberg.de

BaFin Journal September 2019/ IT-Aufsicht bei Banken, EZB-Besuch der BaFin, BaFin-Tech 2018, Verbraucherschutzpaket


Ihr Account ist nicht für das Rechtsmonitoring freigeschaltet


Um die Rechtsmonitoring-Funktionalitäten nutzen zu können, müssen Sie erst einen Zugang erwerben!


Wenn Sie einen Probemonat erwerben möchten schicken Sie uns eine E-Mail mit dem Betreff: "Probemonat Rechts- und Regulatorikmonitoring" an info@fc-heidelberg.de

BaFin Merkblatt für Cloud Anbieter/ MaRisk BAIT, Outsourcing, Auslagerungscontrolling


Ihr Account ist nicht für das Rechtsmonitoring freigeschaltet


Um die Rechtsmonitoring-Funktionalitäten nutzen zu können, müssen Sie erst einen Zugang erwerben!


Wenn Sie einen Probemonat erwerben möchten schicken Sie uns eine E-Mail mit dem Betreff: "Probemonat Rechts- und Regulatorikmonitoring" an info@fc-heidelberg.de

Prozessprüfung und agree21Vorgang



Michael Claaßen, Bereichsleiter, Interne Revision, Volksbank Marl-Recklinghausen eG.

I. Grundlagen

Innerhalb des genossenschaftlichen Bereiches werden seit einiger Zeit die Banken, die in der Vergangenheit das Kernbankverfahren bank21 genutzt haben, auf das Kernbankverfahren agree21 migriert. Das Kernbankverfahren führt zur Implementierung neuer Prozesse. Die risikomanagementgestaltenden Softwarelösungen für die aufsichtsrechtlichen Anforderungen werden in den betroffenen Banken somit neugestaltet. So werden nach AT 4.3.1 Tz. 2 der MaRisk die Prozesse und die damit verbundenen Aufgaben, Kompetenzen, Kontrollen und teils auch Kommunikationswege softwarebasiert neu geordnet. Berechtigungen und Kompetenzen sind dabei nach dem Sparsamkeitsgrundsatz (Need-to-know-Prinzip) in agree21 neu zu vergeben. Zur Administration gehört weiterhin der Institutskennsatz (IKESA), der die Parametrisierung wesentlicher Vorgaben beinhaltet.

Eine der wesentlichen Stärken des Kernbankverfahrens stellt die Vorgangssteuerung dar. Für die einzelnen Geschäftsaktivitäten können Vorgänge genutzt werden. Diese können einen Standard definieren. Es ergibt sich ein Workflow, der die einzelnen Prozessschritte mit teils unterschiedlichen Aufgabenträgern, der Nutzung von Formularen und Checklisten sowie systembasierten Kontrollroutinen beinhalten kann. Notwendige Aufgaben können in der Aufgabenliste eines Mitarbeiters erzeugt werden. Ein Eskalationsverfahren und ein Prozesscontrolling sind wichtige Komponenten im Rahmen dieses Prozessmanagements. Vorgänge werden über eine bankindividuelle Menüstruktur (BIM) aufgerufen. Diese BIM kann für unterschiedliche Verteiler, wie Markt oder Marktfolge ...


Weiterlesen?


Dies ist ein kostenpflichtiger Beitrag aus unseren Fachzeitschriften.

Um alle Beiträge lesen zu können, müssen Sie sich bei meinFCH anmelden oder registrieren und danach eines unserer Abonnements abschließen!

Anmeldung/Registrierung

Wenn Sie angemeldet oder registriert sind, können Sie unter dem Menüpunkt "meinABO" Ihr aktives Abonnement anschauen oder ein neues Abonnement abschließen.

Wozu braucht man einen IKS-Beauftragten?

Michael Helfer, Geschäftsführer, FCH Consult GmbH

I. Noch ein Beauftragter: Sinn oder Unsinn?

Es vergeht keine Woche, in der nicht eine wesentliche aufsichtsrechtliche Neuerung die Institute erreicht. Diese wird dann zumeist intern verteilt und im besten Fall einem Prozessverantwortlichen zugeordnet. Darüber hinaus müssen für wesentliche Prozessänderungen bestimmte Mechanismen vorhanden sein (z. B. MaRisk AT 8.2: Einbindung der diversen Compliance-Beauftragten, des Risikocontrollings und der Internen Revision). Oftmals funktionieren diese Prozeduren nur auf dem Papier (welches als Umlaufzettel durch die Bank geleitet wird), nicht aber materiell. In der Praxis ist auch zu beobachten, dass vielfach (auch aus der schieren Not der Vielzahl der Neuerungen) sogenannte Potemkinsche Dörfer errichtet werden (d. h. es werden Arbeitsrichtlinien und Arbeitsanweisungen erstellt, die jedoch materiell nicht greifen bzw. gelebt werden).

Ferner ist seit Einführung der MaRisk im Jahre 2005 eine wahre Inflation von entstandenen Kontrollen zu beobachten. Eine klassische Regionalbank hat in der Regel ca. 600–1.000 manuelle Kontrollen, welche mehr oder weniger regelmäßig ausgeführt werden. Da es keine zentrale Verantwortung für dieses Thema gibt, versuchen die verantwortlichen Fachbereiche die ihnen zugeordneten Kontrollen nach besten Wissen und Gewissen (in der zur Verfügung stehenden Zeit) zu managen. Die Problematik bei manuellen Kontrollen ist, dass diese händig ausgeführt werden müssen und damit Zeit (und Geld) kosten. Zudem ist die Fehleranfälligkeit für diese Kontrollprozesse, durch den Faktor Mensch bedingt, recht hoch. Bei in der Praxis durchgeführten Projekten ist regelmäßig zu beobachten, dass Hunderte von Kontrollen bestehen, welche nicht auf Risiken oder konkrete gesetzliche Vorgaben einzahlen (im Ergebnis also abgeschafft werden könnten).

SEMINARTIPPS

Zertifizierung

Zertifizierter IKS-Beauftragter, 04.–07.05.2020, Berlin.

IKS-Seminare

IKS KOMPAKT: Aufbau & Management einer IKS-Organisation, 04.05.2020, Berlin.

Praktische Vorgehensweisen zur Implementierung eines IKS, 05.05.2020, Berlin.

Der (zukünftige) IKS-Beauftragte, 06.05.2020, Berlin.

IKS-Bewertung & Festlegung wesentlicher Prozesse, 07.05.2020, Berlin.

(Neue) IKS-Kontrolltests im (LSI-)SREP, 25.06.2020, Frankfurt/M.

IKS Kompakt: Aufbau & Prüfung von Schlüsselkontrollen, 07.10.2020, Frankfurt/M.

Weitere Seminarempfehlungen

Prozesse/Orga-Handbuch & IKS, 25.–26.03.2020, Köln.

Schlüsselkontrollen Spezial: Kreditprozesse, 18.06.2020, Frankfurt/M.

Im Prüfungsfokus: Wesentliche Prozesse & AT 8.2, 08.10.2020, Frankfurt/M.

Erschwerend kommt hinzu, dass es zahlreiche Bereiche in einer Bank gibt, die am Design und Test von Kontrollen bis hin zur Berichterstattung mitwirken, aber jeder aus seinem eigenen Blickwinkel bzw. auf der Basis seines Aufgabenprofils (z. B. Compliance-MaRisk, Compliance-WpHG, Geldwäschebeauftragter/Zentrale Stelle, Auslagerungsbeauftragter, Informationssicherheitsbeauftragter, Datenschutzbeauftragter etc.). Und hier besteht eine weitere Herausforderung: Im Kern geht es darum, welche Funktion (Rolle) innerhalb eines Instituts welche konkreten Aufgaben insbesondere innerhalb des IKS wahrnimmt und das dies auf einer transparenten Basis passiert (als wesentliche Voraussetzung dafür, dass keine Doppelarbeiten oder gar Kontrolllücken entstehen).

Neben einer ohnehin sinnvollen Überlegung, das Beauftragtenwesen besser zu koordinieren bzw. sogar zu zentralisieren, kann hier die Funktion des IKS-Beauftragten einen wesentlichen Mehrwert leisten, um sicherzustellen, dass für die Geschäftsleitung und den Aufsichtsrat eine proaktive Steuerung des internen Kontrollsystems (und damit des Managements der prozessinhärenten Risiken erfolgt).

II. Zentrale Koordinierung & Steuerung der IKS-Anforderungen

Grundvoraussetzung für eine schlanke Umsetzung der Regulatorik ist, wie zuvor ausgeführt, ein abgestimmtes und dokumentiertes Rollenverständnis aller Beteiligten der sog. „ersten, zweiten und dritten Verteidigungslinie“ (sog. „Three-Lines-of-Defence-Modell“ oder auch „3 LoD“). Die Bereiche der ersten Verteidigungslinie sind nach den MaRisk für die Implementierung und Durchführung des IKS im zugeordneten Prozess verantwortlich. Dazu gehören u. a. die Bewertung der operationellen Risiken, das Sicherstellen einer angemessenen Implementierung von Kontrollen im Prozess (diese müssen auf die Risiken „einzahlen“) nebst der erforderlichen aufbauorganisatorischen Kontrollen, die Verantwortung für Durchführung und Qualität der der angewiesenen Kontrollen, die Verantwortung für die Richtigkeit und Vollständigkeit der Daten, das Initiieren und Mitwirken an Verbesserungen der Kontrollen sowie die Verantwortung für die Umsetzung von regulatorischen Änderungen und Neuerungen (insbesondere der wesentlichen) in der Aufbau- und Ablauforganisation (inkl. IT). Zu den Bereichen der zweiten Verteidigungslinie gehören u. a. Compliance, Geldwäsche, Organisation, Prozessmanagement, IKS-Steuerung, Auslagerungsstelle, IT-Sicherheit, Datenschutz, FRAUD-Prävention, Marktfolge aktiv (risikorelevantes Kreditgeschäft), Risikocontrolling. Ihre Aufgabe besteht im Wesentlichen darin, die ordnungsgemäße Aufgabenwahrnehmung der ersten Verteidigungslinie zu überwachen sowie gegebenenfalls qualitätssichernden Maßnahmen durchzuführen. Die dritte Verteidigungslinie wird durch die Interne Revision wahrgenommen, welche das IKS risikoorientiert zu prüfen hat.

FILMTIPPS

IKS 2.0 Schlüsselkontrollkonzept

Auswirkungen der neuen Fit & Proper-Anforderungen

Film: OpRisk – Neue MaRisk & Neuer Standardansatz

Neuer AT 9 – Handlungsbedarf für die Orga

Risikokultur & Unternehmensethik

Vorstandshaftung

Der IKS-Beauftragte hat in diesem System die Aufgabe, die internen Kontrollen zu managen, d. h. einen wirksamen Managementkreislauf zu implementieren, angefangen bei einer vollständigen Kontrollinventarisierung, der Initiierung regelmäßiger Kontrolltests bis hin zur Berichterstattung an die Geschäftsleitung und gegebenenfalls das Monitoren etwaiger Verbesserungspotenziale (vgl. Schaubild).

3. Fachliches Know-how für den IKS-Beauftragten

Die mittlerweile zahlreichen IKS-Vorgaben, wie z. B. eine geforderte IKS-Wirksamkeits-Überwachung und drohende Konsequenzen, wie z. B. Kapitalzuschläge bei IKS-Mängeln, erfordern daher eine Systematisierung und Dokumentation des IKS, damit die Geschäftsleitung in regelmäßigen Abständen einen Bericht über den Zustand des internen Kontrollsystems erhalten kann. Diesbezüglich wird eine Koordinierungsfunktion im Institut benötigt, welche sich um die zuvor beschriebenen Erfordernisse kümmert. Je nach Größe des Hauses kann diese Funktion als separate Stelle oder auch angedockt an andere Beauftragten-Funktionen (oder auch dem Organisations-/Prozessmanagementbereich) zugeordnet werden.

Damit der IKS-Beauftragte die zugeordneten Aufgaben angemessen (und pragmatisch) umsetzen kann, empfiehlt sich der Erwerb bzw. das Update zu folgenden Themenbereichen:

  • Aufbau & Management einer IKS-Organisation (regulatorische Grundlagen, praxiserprobte Modelle, Aufgaben und Kompetenzen der jeweiligen Beauftragten, etc.)
  • Praktische Vorgehensweisen zur Implementierung eines professionalisierten IKS (prozessorientierte Ausrichtung, Verschlankung des Anweisungswesens, Schärfung der unterschiedlichen Rollenprofile im Institut)
  • Aufgaben, Kompetenzen und Verantwortlichkeiten eines IKS-Beauftragten (regelmäßige Aktivitäten und Abstimmungen mit anderen Beauftragten, Einbindung in interne Entscheidungsprozesse, Berichterstattung an die Geschäftsleitung)
  • Modelle zur IKS-Bewertung und Festlegung wesentlicher Prozesse (Einbindung der Methodik operationeller Risiken, Initiierung der Vereinheitlichung der im Institut unterschiedlichen Risikoanalysen).

BERATUNGSANGEBOTE

IKS Kompakt: Aufbau & Prüfung von Schlüsselkontrollen

Prozessmanagement im Fokus von MaRisk & BAIT: Aufbau/Bewertung & Auditierung

Quick Check „Entschlacktes Organisationshandbuch“

Starter-Kit Risikokultur

Fit für die Sonderprüfung nach § 44 KWG

Fit für MaRisk-Prüfung Gesamtbanksteuerung

Fit für die BAIT und die Sonderprüfung-IT

Quality Assessment & Performance-Analyse der Internen Revision

Effektives & effizientes Zusammenspiel von Compliance & Interner Revision

Implementierung eines effizienten & wirksamen Auslagerungsmanagements

Quick-Check Beauftragtenwesen

Prüfung MaRisk-Compliance

Sie haben Fragen? Sprechen Sie mich gerne an:

Michael Helfer, Geschäftsführer

Tel.: +49 6221 99 89 8 – 0

E-Mail: Michael.Helfer@FC-Heidelberg.de

www.fchconsult.de

FCH Consult GmbH

Im Bosseldorn 30

D-69126 Heidelberg

Beitragsnummer: 84063

Fremdbezug softwarebezogener IT-Dienstleistungen

Aufsichtsrechtliche Einstufung und resultierende Anforderungen

Prof. Dr. Dirk Heithecker, Professur für Quantitative Methoden und Corporate Finance, Hochschule Hannover, und Fachreferent, Kredit- und Restwertrisikomanagement, Volkswagen Bank GmbH (Der Beitrag gibt ausschließlich die persönliche Auffassung und Einschätzung des Autors wieder)

Die Neuerungen und Konkretisierungen im Umgang mit Auslagerungen sind eine der wesentlichen inhaltlichen Anpassungen der 5. Novelle der Mindestanforderungen an das Risikomanagement (MaRisk), deren Frist zur Umsetzung im Oktober endet. Im Zusammenhang mit dem Bezug von Software gelten zudem seit November 2017 die Bankaufsichtlichen Anforderungen an die IT (BAIT). Im vorliegenden Beitrag wird die inhaltliche Abhängigkeit beider Vorgaben erörtert.

Software als Fremdbezug von IT-Dienstleistungen

Vor dem Hintergrund der Vorgaben des § 25a (1) und § 25b KWG gelten besondere Anforderungen im Umgang mit dem Fremdbezug von Leistungen in Kreditinstituten. Zu diesen Leistungen zählen auch IT-Dienstleistungen, die besondere, auf die IT bezogene Aktivitäten darstellen. Dies schließt die Bereitstellung von IT-Systemen, von Projekten und Gewerken oder auch die Personalgestellung im IT-Bereich ein. Die Implementierung von Software dürfte aufsichtsrechtlich auch als Fremdbezug von IT-Dienstleistungen einzustufen sein (vgl. MaRisk, AT 9, Tz. 1, Erläuterungen und auch BAIT, Tz. 52, Satz 3), wenngleich durch Bankenverbände während der Konsultation andere Auffassungen vertreten wurden (vgl. DK, Konsultation des Rundschreibens BAIT, S. 15 und DK, Stellungnahme 5. MaRisk-Novelle, S. 28 ff.). Sogar der isolierte Bezug von Software, aber auch softwarebezogener IT-Dienstleistungen im Rahmen der Implementierung und Nutzung – so genannte Unterstützungstätigkeiten, vgl. Tabelle – gelten per se als Fremdbezug.

 

 

 

 

 

 

Software und Unterstützungsleistung als Auslagerung oder sonstigem Fremdbezug

Die MaRisk unterscheiden beim Fremdbezug von Leistungen zwischen Auslagerungen und sonstigem Fremdbezug (vgl. MaRisk, AT 9, Tz. 1), entsprechend gilt diese Unterscheidung auch für den Fremdbezug von Software. Nach Wortlaut der MaRisk können in der Regel aber nur Unterstützungstätigkeiten beim Fremdbezug von Software den Tatbestand der Auslagerung erfüllen. Im Fokus stehen dabei nur Leistungen für Software, die im Rahmen von Kontrollfunktionen (Risikocontrolling etc.) oder in Kernbankbereichen eingesetzt werden (vgl. MaRisk, AT 9, Tz. 1, Erläuterungen). Liegt eine Auslagerung vor, so sind umfassende MaRisk-Vorgaben an die Organisation, Risikoanalyse und Risikosteuerung, Kontinuität der Geschäftsprozesse und Vertragsgestaltungen zu erfüllen (vgl. Heithecker, Risikokonzentrationen bei Auslagerungen, BankPraktiker, demnächst). Der isolierte Bezug von Software (und deren Implementierung, Testen und Freigabe durch das Kreditinstitut selbst) sollte hingegen nicht als Auslagerung eingestuft werden – unabhängig vom Einsatz.

 SEMINARTIPPS:

Auslagerungsverträge auf dem Prüfstand, 15.11.2018, Frankfurt/M.

Prüfung Auslagerungsprozesse, 22.11.2018, Köln.

Auslagerungen im Fokus neuer MaRisk & BAIT, 10.12.–11.12.2018, Frankfurt/M.

 

Entsprechend der bisherigen Abgrenzung ist der isolierte Fremdbezug von Software einschließlich der Unterstützungsleistungen, die nicht den Tatbestand der Auslagerung erfüllen, ein sonstiger Fremdbezug. Hier sind „lediglich“ die allgemeinen Anforderungen an die Ordnungsmäßigkeit der Geschäftsorganisation zu erfüllen, die jedoch in den BAIT konkretisiert werden (vgl. BAIT, Tz. 53 bis 56). So muss vorab eine Risikobewertung vorgenommen werden, zudem ist der Fremdbezug risikoorientiert zu steuern und die Leistungserfüllung zu überwachen. Ferner sind Vereinbarungen zum Notfallmanagement einschließlich von Exit- und Alternativstrategien festzulegen. So mögen diese Vorgaben in regelmäßig üblichen Fällen, etwa beim Bezug von Standardsoftware, durch übliche Vorkehrungen eines Instituts (Programmeinsatzverfahren einschließlich Costumizing, Testdurchführung, Freigabe), einfach umzusetzen sein. Dennoch ergeben sich strukturell zur Auslagerung gleiche Anforderungen, die jedoch inhaltlich weniger anspruchsvoll und umfassend einzustufen sind.

 BUCHTIPPS:

Auslagerung nach MaRisk, 2018.

Riediger (Hrsg.): Auslagerungen & Dienstleister-Steuerung, 2018.

 

 

Fazit

Durch die augenscheinliche Einstufung als Fremdbezug und aufgrund der zusätzlich in den BAIT formulierten Vorgaben zur Umsetzung einer ordnungsgemäßen Geschäftsorganisation gleichen sich die Umsetzungsbedarfe bei softwarebasierten IT-Dienstleistungen unabhängig einer weiteren Kategorisierung als Auslagerung oder sonstiger Fremdbezug an. Die Vorgaben an den sonstigen Fremdbezug sind unter Proportionalitätsgesichtspunkten im Vergleich zur Auslagerung sicherlich weniger umfassend, müssen jedoch weitestgehend gleiche Themenstellung abdecken. Es empfiehlt sich somit, die Erfüllung der Vorgaben an den sonstigen Fremdbezug und an die Auslagerung bei softwarenahen IT-Dienstleistungen (Softwarebezug einschließlich Unterstützungstätigkeiten) aus einer Hand zu steuern.

PRAXISTIPPS

  • Erstellen Sie eine vollständige, strukturierte Vertragsübersicht ihrer eingesetzten Software und damit zusammenhängender Unterstützungsleistungen.
  • Legen Sie für die Steuerung fest, welche dieser Leistungen gebündelt und identisch betrachtet werden können.
  • Nutzen Sie Ihre Prozesse und Kenntnisse des Auslagerungsmanagements zur adäquaten Einstufung und vereinfachten Steuerung softwarebezogenen IT-Dienstleistungen im sonstigen Fremdbezug.

Beitragsnummer: 43384

Datenqualität: Herausforderungen für die Interne Revision

Andreas Freßmann, Leiter Produktions- und Steuerungsrevision, Sparkasse Münsterland Ost

Externe und interne Motivation zur Gewährleistung einer hohen Datenqualität

Die stetige Weiterentwicklung der bankaufsichtlichen Anforderungen im Bereich der quantitativen Regulierung sowie auch die immer anspruchsvolleren Rahmenbedingungen im Wettbewerb fordern die Institute im Bereich der Datenqualität weiterhin an mehreren Fronten zu erheblichen Anstrengungen heraus:

Eine hohe Qualität der melderelevanten Daten ist zu gewährleisten, um anforderungskonforme Meldungen abgeben zu können.
Mangelhafte Datenqualität führt zu ungenauem Berichtswesen, Fehlentscheidungen, Sanktionierung, Minderung der Effizienz und Wirtschaftlichkeit (Fehlerbereinigung), Vertrauens- und Imageverlust. Datenqualität ist deshalb ein wichtiger Wettbewerbsfaktor. Die Datenerfassungs- und Qualitätssicherungsprozesse sind regelmäßig zu evaluieren. Die Kontrollen sind proportional zur Bedeutung des Prozessschrittes bzw. Datenfeldes so auszugestalten, dass Fehler vermieden bzw. identifiziert werden (Risiko-Kontroll-Matrix). Dabei wird seitens der Aufsicht die Einrichtung eines Systems von Kontrollen und Plausibilitätsprüfungen sowohl innerhalb des Datenkranzes einer Meldung als auch Kontrollen und Plausibilitätsprüfungen zwischen den verschiedenen Meldungen erwartet.

Das Zusammenspiel von Finanz- und Risikofunktionen, insbesondere in den Bereichen Risikosteuerung, Risikocontrolling, Rechnungswesen und Meldewesen muss immer wieder hinsichtlich der Effizienz justiert werden. Dabei schaffen immer komplexere Datenaggregationen und verschärfte zeitliche Anforderungen Einfallstore für Qualitätsmängel und erhöhen das Fehlerrisiko.

Beiträge der Internen Revision zur Gewährleistung und Sicherung der Datenqualität

Die Interne Revision kann durch ihr Prüfungshandeln und die Prozesskompetenz Mehrwerte zur Gewährleistung und dauerhaften Sicherung der Datenqualität liefern. Dabei sind in einem ersten Schritt Aufbau- und Prozessprüfungen im Zuge der Etablierung bzw. Optimierung der Datenerfassungs- und Qualitätssicherungsprozesse angezeigt, bevor zeitlich danach durch Funktionsprüfungen und Datenchecks Feinsteuerungsbedarf identifiziert werden kann. Ein aus den gesetzlichen Regelungen auf das Institut angepasster und dauerhaft wirksamer Ordnungsrahmen incl. IKS ist wiederholten „Datenbereinigungsaktionen“ vorzuziehen.

In den folgenden Handlungsfeldern ist die Interne Revision besonders herausgefordert:

Prozesstransparenz und Organisationsrichtlinien

Die Erstellung effizienter Organisationsrichtlinien setzt in der Regel Prozesstransparenz voraus. Diese ist häufig noch zu erhöhen. Basis für die Erstellung einer Organisationsrichtlinie mit entsprechendem Nutzwert ist eine Prozesslandkarte, die alle in die Prozesse involvierten Stellen einschließlich der dabei eingesetzten DV-Anwendungen aufzeigt. Zudem müssen die an der jeweiligen Meldung beteiligten Stellen und ihre Verantwortlichkeiten im Sinne einer Schnittstellenmatrix bekannt sein. Auf dieser Basis können dann zügig mögliche Fehlerquellen sowohl im Zusammenhang mit der Datenbasis als auch mit der Datenverarbeitung identifiziert werden. Daneben ist zur Fundierung einer ausreichenden Prozessstabilität besonderes Augenmerk auf die angemessene (inhaltliche) Ausgestaltung und Aktualität der Organisationsrichtlinien zu legen.

BUCHTIPPS

Bearbeitungs- und Prüfungsleitfaden: Meldewesen, 2017.

IT im Fokus der Bankenaufsicht, 2. Aufl. 2015.

 

 

Abstimm- und Plausibilisierungshandlungen

Im Vorfeld der Meldungsabgabe kommt den verschiedenen Abstimm- und Plausibilisierungshandlungen hohe Bedeutung zu. Revisionsseitig ist neben der Auswahl sinnvoller Abstimmgrößen sowohl innerhalb der Meldung als auch meldungsübergreifend und der konsequenten Durchführung auch die geeignete Dokumentation dieser Arbeitsschritte zur Nachverfolgung von Differenzen zu bewerten.

Kontrollen und Kontrollqualität

Die prozessintegrierten Kontrollhandlungen sollten so effizient wie möglich gestaltet werden. Hierzu sind vom Fachbereich unter Berücksichtigung der inhärenten Risiken und der Kontrollrisiken auch die notwendigen Schlüsselkontrollen und deren erforderliche qualitative Ausgestaltung nachvollziehbar abzuleiten. Um durchzuführende Kontrollhandlungen einerseits zu rechtfertigen und andererseits ausreichend zu operationalisieren, sollten zu jeder Kontrolle ein Kontrollverantwortlicher, ein eindeutiges Kontrollkriterium, das Kontrollintervall und das verfolgte Kontrollziel festgelegt werden. Diese sind dann im Prüfungsverlauf auf ihr Vorhandensein bzw. ihre Wirksamkeit hin zu überprüfen.

SEMINARTIPPS

Externe Daten & Ratings nach neuen MaRisk: eigene Plausibilisierungen – Dokumentation – Verwendung, 16.10.2018, Frankfurt/M.

Verlustdaten & Erlösquoten, 17.10.2018, Frankfurt/M.

§ 44er Sonderprüfungen im Meldewesen, 03.12.2018, Frankfurt/M.

Neues einheitliches Schema der Aufsicht zur Prüfung der Institute, 04.12.2018, Frankfurt/M.

Aktuelle Offenlegung von Finanz- & Risikodaten, 06.12.2018, Frankfurt/M.

Technische Anforderungen

Insbesondere vor dem Hintergrund der weiter steigenden Anforderungen an die Qualität und Stabilität der in den Prozessen und insbesondere zu Abstimm- und Kontrollzwecken eingesetzten IT-Anwendungen ist die Einhaltung der diesbezüglichen, betrieblichen Anforderungen (Durchführung einer sachgerechten Schutzbedarfsanalyse; ggf. Durchführung eines Programmeinsatzverfahrens) selbstverständlich.

PRAXISTIPPS

  • Die Gewährleistung einer hohen Datenqualität liegt sowohl im institutsinternen als auch im bankaufsichtlichen Interesse.
  • Folgende Handlungsfelder können von der Internen Revision im Rahmen von Prozess- und Funktionsprüfungen beleuchtet werden:
    • Prozesstransparenz und Organisationsrichtlinien
    • Abstimm- und Plausibilisierungshandlungen
    • Kontrollen und Kontrollqualität
    • Technische Anforderungen.

Beitragsnummer: 42597

Die „Regulatory Sandbox“ – Ein Modell auch für das deutsche Bankaufsichtsrecht?

Tobias Gronemann, Rechtsanwalt, Thümmel, Schütze & Partner, Berlin

Die Anforderungen an Kreditinstitute und Finanzinstitute im Rahmen der aufsichtsrechtlichen Regulierung durch gesetzgeberische Vorgaben auf nationaler wie auch auf Ebene der EU wachsen täglich. Alleine die MiFID II hat mit ihren delegierten Verordnungen sowie unterschiedlichen Leitlinien einen Umfang von mehreren tausend Seiten. Dementsprechend kompliziert ist die Anwendung aufsichtsrechtlicher Regelung in der Praxis bereits schon für große Banken. Ungleich größer ist die Herausforderung aber für Unternehmen aus der Fintech-Branche, die meist über keine eigene Rechtsabteilung verfügen, die die für das Unternehmen relevanten aufsichtsrechtlichen Regelungen und Entwicklungen im Blick behält. Diese Unternehmen stehen meist am Anfang ihrer Entwicklung, die durch zu hohe aufsichtsrechtliche Anforderungen im Keim erstickt werden kann. Um dies zu verhindern, hat die Aufsichtsbehörde in Großbritannien, die Financial Conduct Authority (FCA), das Konzept der „Regulatory Sandbox“ entwickelt.

Bei der „Regulatory Sandbox“ handelt es sich um eine Konstruktion, die es einem Unternehmen der Fintech-Branche ermöglicht, sein Geschäftsmodell zunächst für einen begrenzten Zeitraum und einen begrenzten Kundenkreis unter der Aufsicht und Anleitung der FCA zu testen, ohne bereits sämtliche aufsichtsrechtliche Anforderungen erfüllen zu müssen.

Ein Fintech muss sich um einen Platz in der „Regulatory Sandbox“ bewerben und dazu bestimmte Voraussetzungen aufweisen. So muss das Unternehmen nachweisen, dass es sich bei dem Geschäftsmodell um eine echte Innovation handelt und Vorteile für die Verbraucher bietet. Darüber hinaus muss das Unternehmen auch darlegen, dass es auf die „Regulatory Sandbox“ überhaupt angewiesen ist und einen Testplan einreichen. Der Testplan muss Einzelheiten zur Dauer, Leistungskennzahlen, geplante Etappenziele, eine Risikoanalyse, Hinweise zu den Auswirkungen auf die Verbraucher sowie einen Ausstiegsplan enthalten.

Sobald ein Fintech diese Voraussetzungen erfüllt und von der FCA in der „Regulatory Sandbox“ angenommen worden ist, stehen der Behörde unterschiedliche Instrumente zur praktischen Umsetzung der „Regulatory Sandbox“ zur Verfügung. So kann die FCA eine begrenzte Zulassung erteilen, die ausreichend ist, damit das Unternehmen sein Geschäftsmodell testen kann. Das Unternehmen erhält eine individuelle Anleitung durch die FCA, die so weitgehend sein kann, dass die FCA erklärt, wie es bestimmte Regelungen auslegen würde.

Das Fintech muss in der Regel nun wöchentlich über erreichte Ziele, gewonnene Erkenntnisse und das Risikomanagement berichten. Am Ende der vorher vereinbarten Laufzeit muss ein schriftlicher Abschlussbericht vorgelegt werden.

Kritik hat das Modell der „Regulatory Sandbox“ insbesondere vor dem Hintergrund der freien Marktwirtschaft erfahren. So sei zu befürchten, dass Verbraucher diejenigen Fintechs bevorzugen, die im Rahmen der „Regulatory Sandbox“ tätig sind. Problematisch sei dies, da die Plätze begrenzt seien und auch nicht immer nachvollzogen werden kann, warum andere Unternehmen nicht die Voraussetzungen erfüllen und dementsprechend nicht die Vorzüge der „Regulatory Sanbox“ nutzen können.

Überwiegend gab es national und international aber positive Rückmeldungen an die FCA für das Konzept der „Regulatory Sandbox“, sodass Nachahmer nicht lange auf sich warten lassen werden. So findet sich das Konzept in den Fintech-Strategien der EZB und EBA wieder.

In Deutschland steht die BaFin der „Regulatory Sandbox“ dem Vernehmen nach eher skeptisch gegenüber, da die Wirtschaftsförderung nicht vom Mandat der BaFin umfasst sei. Darüber hinaus hätten Fintechs bereits jetzt die Möglichkeit, mittels unverbindlicher Anfragen an die BaFin Anhaltspunkte hinsichtlich aufsichtsrechtlicher Fragen im Zusammenhang mit dem jeweiligen Geschäftsmodell zu erhalten.

Dies kann man – nicht nur aus der Perspektive der Fintechs – kritisch sehen. Mit der ablehnenden Haltung nimmt man sich die Möglichkeit, den Standort Deutschland für Fintechs weiterhin attraktiv und zukunftsorientiert zu gestalten. Auch wäre der rechtliche Rahmen für eine deutsche regulatorische Sandkiste gegeben, da der Verbraucherschutz vom Mandat der BaFin umfasst ist. An diesem Punkt könnte eine regulatorische Sandkiste ansetzen und Verbraucherschutz sowie die Förderung von Fintechs miteinander verbinden.

Fazit:

Solange es in Deutschland keine „Regulatory Sandbox“ gibt, sind Fintechs gehalten, sämtliche aufsichtsrechtlichen Anforderungen zu erfüllen, da ansonsten neben der Einstellung der Geschäftstätigkeit auch strafrechtliche Sanktionen drohen. Ggf. sollten sich Fintechs von Anfang an zu Fragen des Bankaufsichtsrecht rechtlich beraten lassen, um hier Probleme frühzeitig zu erkennen und beheben zu können. Sinnvoll kann es auch sein – sollte es für das Fintech auf den Standort nicht ankommen – seinen Sitz in einem Land mit einer „Regulatory Sandabox“ zu wählen.

 

 

Beitragsnummer: 41315

Outsourcing im Zuge der neuen Regulierung

Was bedeuten die neuen Anforderungen der MaRisk / BAIT für das Outsourcing

Thomas Wildenauer, IT-Auditor, AWADO Deutsche Audit GmbH Wirtschaftsprüfungsgesellschaft Steuerberatungsgesellschaft

I. Grundsätzliches zum Outsourcing

Der Begriff Outsourcing ist ein Kunstwort, der sich ausgehend vom Wortstamm, aus den drei englischen Wörtern „Outside“, „Ressource“ und „Using“ zusammensetzt. Wörtlich übersetzt bedeutet er in erster Linie „Nutzung externer Ressourcen“. Eine IT-Auslagerung (Outsourcing) liegt vor, wenn ein anderes Unternehmen mit der Wahrnehmung solcher IT-Aktivitäten und IT-Prozesse im Zusammenhang mit der Durchführung von Bankgeschäften, Finanzdienstleistungen oder sonstigen institutstypischen Dienstleistungen beauftragt wird, die ansonsten vom Institut selbst erbracht würden. Im Sprachgebrauch der Aufsicht des Kreditgewerbes handelt es sich dabei um den Begriff der „Auslagerung“ (AT 9 MaRisk). Der sonstige Fremdbezug von Leistungen wird sich aber mit der Novellierung der MaRisk und der Neueinführung der BAIT in 2017 ändern. Aus dem Konsultationsentwurf zur Überarbeitung der Mindestanforderungen an das Risikomanagement (MaRisk) ergibt sich eine Reihe von bislang noch nicht normierten Organisationspflichten, die die Institute je nach Komplexität und Umfang der Auslagerung in unterschiedlichem Ausmaß betreffen. Die Überarbeitung zielt zum einen auf die Umsetzung weiterentwickelter internationaler und europäischer Vorgaben ab. Zudem sind Erkenntnisse der vergangenen Jahre aus der Aufsichtspraxis eingeflossen. Derartige bisher nicht normierte Organisationspflichten sind dabei vielfach bereits in der Vergangenheit als Prüfungsfeststellungen in Prüfungen etwa nach § 44 KWG ausgesprochen worden. Es handelt sich also vielfach um Klarstellungen aufsichtsrechtlicher Sichtweisen, nicht um Neuregelungen im engeren Sinn. Der Begriff der Auslagerung wird in den MaRisk näher definiert. Die BaFin verschärft die Regeln für das Auslagerungswesen deutscher Banken. Kreditinstitute müssen künftig ausgelagerte Aktivitäten und Prozesse stärker überwachen. Dies geht einher mit einem einheitlichen Risikobewusstsein, das die Aufsicht von Finanzunternehmen auch für diese Tätigkeiten erwartet. Viele Banken müssen deshalb umdenken.

Eine Auslagerung liegt dann vor, wenn ein Institut einen Dienstleister mit der Wahrnehmung von Prozessen im Zusammenhang mit der Durchführung von Bankgeschäften, Finanzdienstleistungen oder sonstigen institutstypischen Dienstleistungen beauftragt, die ansonsten vom Institut selbst erbracht würden. Das Risiko besteht eindeutig in der Abhängigkeit zu einem Drittunternehmen. Im Rahmen ihrer Aufgaben ist auch zwingend die Interne Revision zu beteiligen. Soweit sich wesentliche Änderungen der Risikosituation ergeben, ist die Risikoanalyse anzupassen (MaRisk AT 9 Tz. 2). Neu ist, dass die Risikoanalyse auf der Grundlage von institutsweit oder gruppenweit einheitlichen Vorgaben sowohl regelmäßig als auch anlassbezogen durchgeführt werden muss. Dies betrifft Risikocontrolling, Compliance und Interne Revision. Bereits bei der Risikoanalyse sollen mögliche Risiken aus Weiterverlagerungen berücksichtigt werden. Es stellt sich die Frage, wie dies sichergestellt werden soll, ohne bereits vor Auslagerung eine vollständige Transparenz über alle Subauslagerungen des Dienstleisters zu haben. Insbesondere vor dem Hintergrund, dass bei wesentlichen Auslagerungen im Auslagerungsvertrag auch Regelungen über die Möglichkeit und über die Modalitäten einer Weiterverlagerung zu vereinbaren sind. Eine Vollauslagerungen der Risikocontrolling-Funktion ist gar nicht, Vollauslagerungen der Compliance-Funktion und der Internen Revision sind nur bei kleinen Instituten möglich, bei denen die Einrichtung letztgenannter Funktionen vor dem Hintergrund der Institutsgröße und der betriebenen Geschäfte unverhältnismäßig wäre. Eine Vergabe von bisher im eigenen Haus durchgeführten Prozessen kann die Geschäftstätigkeit eines Kreditinstituts grundlegend verändern. Die MaRisk schließen dies nicht aus – sofern nicht die Geschäftsleitung und die Ordnungsmäßigkeit der Geschäftsorganisation gem. § 25a Abs. 1 KWG davon betroffen sind bzw. beeinträchtigt werden. Festgehalten werden muss, dass die Leistungsverlagerungen nie zu einer Übertragung der Risikoverantwortung führen dürfen (AT 9 Tz. 4 MaRisk). Das vergebende Unternehmen trägt immer die Gesamtverantwortung. Eine verbesserte Risikokultur in Finanzunternehmen zu schaffen, ist eines der erklärten Ziele für die aktuelle Regulierungswelle im Bereich Risikomanagement. Tatsächlich übernimmt der Gesetzgeber dabei zahlreiche Vorgaben aus internationalen Vereinbarungen, die das deutsche Aufsichtsrecht seit der letzten MaRisk-Novelle 2012 noch nicht explizit abdeckt. Beispielsweise schreibt die Europäische Union den Instituten vor, Grundsätze und Standards einzuführen, die eine wirksame Kontrolle von Risiken durch Leitungsorgane gewährleisten (vgl. Bankenrichtlinie 2013/36/EU, CRD IV). Zudem bezieht sich die BaFin auf das Baseler Papier BCBS 239, das die Risikoberichterstattung und die Risikodatenaggregation behandelt. Damit rücken auch IT-technische Aspekte und mögliche Auslagerungen in den Fokus der Aufsicht.

II. Vertragsgestaltung und Service Level Agreements

1. Vertragliche Grundlagen

Hat man sich für ein IT-Outsourcing mit geeignetem IT-Dienstleister entschieden, müssen die bei der Partnerwahl in einem Pflichtenheft beschriebenen Anforderungen in einem nächsten Schritt vertraglich festgehalten werden. Für den Outsourcing-Vertrag gibt es keine gesetzlichen Vorgaben. Es gibt aber aufsichtsrechtliche Anforderungen (§ 25a KWG, MaRisk usw.). Für die Vereinbarung der Leistungen gibt es Dienstleistungsverträge, Werkverträge, Werklieferverträge usw., die sich an den Grundtypen im BGB orientieren und auch bestimmte Regelungen z.B. § 613a BGB, die zu beachten sind. Dadurch gibt es auch keine verbindlichen Regeln, wie der Vertrag aufgebaut sein und welchen Inhalt er haben soll. Durch die Komplexität, die ein Outsourcing-Projekt annehmen kann, ist eine möglichst klare Abgrenzung von Rechten und Pflichten zwischen den Vertragsparteien wichtig. Ein eindeutiges und kontrollierbares Verhalten der Vertragspartner kann erst dadurch gewährleistet werden. Eine detaillierte Regelung im Vorhinein kann darüber hinaus auf beiden Seiten Klarheit schaffen, welche Voraussetzungen erfüllt werden müssen, um die Zusammenarbeit zum Erfolg zu führen. In diesem Zusammenhang ist die Gestaltung der Service-Level- Agreements (SLA) im Auslagerungsprozess essenziell. Die in AT 9 Tz. 6 MaRisk genannten Mindestanforderungen sollten hierbei wirklich nur den unteren Level darstellen. Je genauer die Auftragsinhalte und deren gewünschte Durchführung vereinbart wurden, umso genauer lassen sich quantitative sowie qualitative Abweichungen feststellen. Hierzu bedarf es, ähnlich wie in den Übernahmeverträgen zu Beginn des Outsourcing-Vorhabens, vertraglicher Vereinbarungen über die (Rück)Übertragung bestimmter Vermögensgegenstände (Hard- und Software) und Verträge vom Auftragnehmer auf den Auftraggeber, wobei in manchen Fällen sogar Personalübernahme stattfindet. Regelungen über das Change Management finden sich in der Regel im Rahmenvertrag. Sie betreffen die Behandlung von Änderungswünschen (Change Requests) des Auftraggebers oder des Auftragnehmers gegenüber den ursprünglich vereinbarten Leistungen. Hier muss ein Prozess definiert werden, der sicherstellt, dass solche Änderungswünsche kurzfristig bearbeitet und gegebenenfalls auch umgesetzt werden können. Dabei ist insbesondere auch eine Regelung über die Anpassung der für die betreffenden Leistungen vereinbarten Vergütung aufzunehmen.

Die Leistungsverpflichtungen und Rahmenbedingungen werden schließlich im Vertrag konkretisiert und ausgestaltet. Der Vertrag sollte deshalb sowohl flexible Variablen (z.B. Einführung neuer Technologien, verschlechterte wirtschaftliche Lage) zulassen, als auch stabile Vorgaben aufweisen. Ein Punkt, der bei der Gestaltung von einem Rahmenvertrag zum IT-Outsourcing ebenfalls berücksichtigt werden muss, ist die Informationssicherheit. Durch das Outsourcing können sich Verantwortlichkeiten im Unternehmen verschieben und ändern. Auch können zusätzliche Schnittstellen entstehen. Jedes Institut muss für die Steuerung und Überwachung wesentlicher Auslagerungen klare Verantwortlichkeiten festlegen. Bei Vollauslagerungen hat die Bank ohnehin jeweils einen Beauftragten zu benennen, der eine ordnungsgemäße Durchführung der jeweiligen Aufgaben gewährleistet. Zusätzlich fordert der Gesetzgeber bei Instituten mit umfangreichen Auslagerungslösungen ein zentrales Auslagerungsmanagement. Dieses stellt sicher, dass eine Stelle im Institut einen Gesamtüberblick über ausgelagerte Prozesse und Aktivitäten hat und so ein möglichst einheitlicher Umgang mit den besonderen Risiken aus Auslagerungen und deren Überwachung sichergestellt wird. Unter solchen Voraussetzungen sollte der Sicherheit von Daten und Informationen auch im Rahmenvertrag eine hohe Aufmerksamkeit gewidmet werden. Auf diese Weise kann ein Rahmenvertrag so gestaltet sein, dass Aufgaben, Kompetenzen und Verantwortlichkeiten für beispielsweise Zutritts- und Zugriffssicherheit, Berichterstattung und Releaseplanung mitberücksichtigt werden. Der Leitungsebene kommt eine hohe Verantwortung für die Informationssicherheit zu. Fehlende Steuerung, eine ungeeignete Sicherheitsstrategie oder falsche Entscheidungen können durch Sicherheitsvorfälle weitreichende negative Auswirkungen haben.

2. Service Level Management

Die nachfolgend beschriebenen Aspekte werden im Service Level Management (SLM) gesteuert. Das SLM beschreibt den Prozess von der Erstellung und Verhandlung der Service Levels, über das Monitoring der Leistungserfüllung, das Reporting an zuständige Personen, bis hin zum kontinuierlichen Verbessern der Vertragsbestandteile und der Leistungsbeziehung. Oftmals kommuniziert ein Dienstleistungsgeber mit dem Auftraggeber nur über zwei Wege: die SLA-Reports und die Rechnungsstellung. Die Service Level sind vertraglich vereinbart. Der Dienstleistungsgeber kann in der Regelkommunikation, wie sie heute mehrheitlich praktiziert wird, überdurchschnittliche Leistungen nicht darstellen. Damit gerät er schnell in einen Jo-Jo-Effekt: Das Topmanagement des Kunden wird immer nur im Eskalationsfall – bei größerer SLA-Verletzung – einbezogen. Der Name des Dienstleisters fällt auf dieser Ebene stets zusammen mit “Negativschlagzeilen”. Dabei gründen auf den Reports wichtige Entscheidungen zum Controlling, zur Anpassung der Qualitätsanforderungen (etwa an neue Geschäftsprozesse und
-modelle) sowie im schlimmsten Fall über die Nutzung von Exit-Klauseln bei Schlechtleistung. Was sollte ein Reporting leisten, das einerseits den Kunden zufrieden stimmt, andererseits dem Dienstleister die Chance eröffnet, seinen Beitrag in der Outsourcing-Beziehung angemessen darzustellen? Zunächst muss es eine grundlegende Anforderung erfüllen: Die Berichte müssen alle Governance-Ebenen des Kunden – operativ, taktisch und strategisch – mit den für sie jeweils relevanten Informationen versorgen, und zwar durchgängig. Das heißt: Die Daten, die diese verschiedenen Sichten unterstützen, müssen von unten nach oben generiert werden. Die operative Ebene erhält technische Informationen. Erfüllt das Reporting die Governance-Anforderungen, sollte es außerdem drei Inhalte abdecken. Erstens: Die Leistung transparent machen. Zum “Pflichtteil” des Reportings gehört es, den Zusammenhang zwischen den Servicebeschreibungen und Qualitätsvereinbarungen, den erbrachten Leistungen sowie der Rechnung herzustellen. Dazu ist es sinnvoll, nochmals die verschiedenen Etappen einer Beziehung beim Outsourcing anzuschauen. Ausgangspunkt ist die Sourcing-Strategie. Aus ihr werden die Serviceschritte abgeleitet, und auf dieser Grundlage wird die Qualität der einzelnen Services festgelegt. Beides hat Einfluss auf das Preismodell, das zusammen mit dem Verbrauch des Kunden im betrachteten Zeitraum die Rechnungsstellung bestimmt. Das Reporting muss diesen Prozess spiegeln. Zweitens muss man dem Kunden weitere Perspektiven aufzeigen. Neben dem “Pflichtteil” sollte ein Report darüber informieren, inwieweit die Ziele, die ursprünglich die Outsourcing-Entscheidung bestimmt haben, erreicht wurden. Für eine Auslagerung kann es viele Gründe geben. Neben Kostensenkung und Qualitätssteigerung sind dies oft strategische Ziele: beispielsweise zufriedenere Anwender, technische Weiterentwicklung oder ein höherer Wertbeitrag der IT, indem diese Business-Prozesse optimiert oder die Voraussetzungen für neue Geschäftsmodelle schafft. Sie sind meist in der Präambel der Outsourcing-Verträge beschrieben. Dort ruhen sie, geraten oft in Vergessenheit und fehlen in den Berichten der Dienstleister. Ein nachhaltiges Reporting sollte die Entwicklung dieser Größen dokumentieren. Dazu müssen geeignete KPI (Key Performance Indicators / Leistungskennzahlen) entwickelt werden. Als Drittes sollte die Zielerreichung dokumentiert werden. Diese Messgröße ist für den Kunden vor allem in der Anfangszeit der Vertragsbeziehung sehr wichtig. Das Reporting sollte dokumentieren, ob der vertragliche Übergang wie geplant voranschreitet, ob die Kosten den Erwartungen entsprechen und die Qualität beim Wechsel vom alten auf den neuen Provider (oder aus der unternehmensintern in die externe Verantwortung) gehalten wird. Ein nachhaltiges Reporting hängt nicht nur vom Dienstleister ab, sondern auch von der Vorgehensweise des Kunden. Der Auftraggeber sollte zunächst seine Anforderungen klar und verbindlich definieren und sie dem Dienstleister mitteilen. Gemeinsam sollten beide Parteien dann festlegen, wie diese Ziele gemessen werden. Auf dieser Grundlage können sie das Reporting aufbauen und in der Governance verankern. In den SLA wird die Leistung definiert. Beispielsweise wird Verfügbarkeit in einem SLA definiert (Messung, Ausfallzeiten, Bezugsgrößen z.B. übliche Geschäftszeiten, Toleranzgrenzen usw.). Die Messung selbst ist ein Report. Dazu werden die Serviceleistungen des Outsourcingnehmers in Bezug gesetzt zu den Anforderungen des Auftraggebers. Zielsetzung bei der Beschreibung von SLAs ist es, eine Kosten-, Leistungs- und Qualitätstransparenz zu schaffen. Im Allgemeinen wird zwischen Rahmen-SLAs und Leistungsscheinen unterschieden. Dies wird in der Praxis sehr unterschiedlich gehandhabt. SLA sind nicht normiert, können auch Teile von Leistungsscheinen sein oder in Verträge eingearbeitet sein. Rahmen-SLAs treffen dabei Aussagen zu den qualitativen und quantitativen Aspekten der ausgelagerten Leistungen, Leistungsscheine bestimmen detailliert die bereits oben dargestellten Merkmale der Leistungen. Bei Rahmen-SLAs, die durch eine Mehrzahl an Leistungsscheinen spezifiziert werden, vereinbaren die Parteien üblicherweise einheitliche Bewertungsmaßstäbe für alle Leistungen, anhand derer die Qualität der Dienstleistung gemessen werden kann. Leistungsstörungen können einerseits vom Dienstleistungsnehmer gemeldet werden, wenn sich Ungereimtheiten im Abgleich der erbrachten Leistungen gegen die entsprechenden Soll-Werte zeigen, andererseits durch den Dienstleister, indem er nach MaRisk AT 9 auf Verfehlungen hinweist, die in seinem Verschulden oder in mangelhafter Qualität der Vorleistung des Dienstleistungsnehmers liegen.

III. Dienstleistersteuerung

Es lässt sich die Notwendigkeit der Anwendung eines ganzheitlichen integrierten Risikomanagementansatzes ableiten, welcher die mit der Auslagerung in Verbindung stehenden Risiken in der Bank adressieren muss. Dies kann durch die adäquate Einbindung des Outsourcing-Managements in das bankweite Risikomanagement gelingen und stellt die vielfältigen Gestaltungsmöglichkeiten für einen ganzheitlichen wert- und risikoorientierten Managementansatz (Outsourcing Governance) vor. Viele der dargestellten Erkenntnisse ergaben sich im Rahmen der externen IT-Revision. Besonders wichtig ist im Rahmen der Beziehungspflege, dass alle Informationen, die zur Auftragserfüllung nötig oder hilfreich sind, dem Dienstleister zeitnah zur Verfügung gestellt werden. Notwendige interne Erklärungen müssen vorgenommen werden. Eine vertrauensvolle Zusammenarbeit ist die Basis des Outsourcings. Nicht zuletzt ist es Ziel aller Beteiligten, den Kunden (Mitarbeitern und Führungskräften) eine Dienstleistung anzubieten, die einen geräuschlosen Wechsel zwischen Bank und Dienstleister ermöglicht. Es ist insbesondere über die Problemfälle ausführlich quartalsweise zu berichten. Der Dienstleister erstellt hierfür eine detaillierte Fehlerstatistik. Gemeinsam werden Risiken vermieden. Die erfolgreiche Umsetzung der Outsourcing Governance umfasst dabei u. a. die Identifikation und Analyse von Wertschöpfungspotenzialen innerhalb der Bank, das effektive Management der zentralen Aufgaben in allen Phasen sowie die Verankerung der wichtigsten Outsourcing-Steuerungsinstrumente im Unternehmen. Der Einbezug des Outsourcings in das unternehmensweite Risikomanagement geht somit über die historische Form des operativen Risiko-managements, deren Fokus primär auf die Risikovermeidung und -minderung ausgelegt war, hinaus. Hauptziel ist das effiziente und effektive Management der ausgelagerten Bereiche, welches alle wesentlichen Einzelrisiken und deren Abhängigkeiten umfasst. Das risikoorientierte Management der ausgelagerten Bereiche hat das Ziel, eine ausgewogene Sichtweise von Risiken und Wertschöpfung über die gesamte Laufzeit des Outsourcing-Verhältnisses hinweg zu etablieren. Ein moderner chancen- und risikoorientierter Outsourcing-Management-Ansatz integriert die Organisation, die Aufgaben und die Instrumente in ein ganzheitliches Rahmenwerk. Die Analyse der Risiken ist wesentlich für die erfolgreiche Umsetzung des Outsourcings. Diese Risikobetrachtung besteht in der Analyse der veränderten Risikosituation der Bank nach einer möglichen Auslagerung von Prozessen und Funktionen. Voraussetzung für die Durchführung einer solchen Analyse ist die Existenz eines für die Bank angemessenen, bankweiten Risikomanagementsystems. Die Analyse kann als ein durch das Management sowie die jeweiligen Prozessverantwortlichen beeinflusster, fortlaufender Prozess beschrieben werden, der im Zuge der Strategiefindung definiert und unternehmensweit angewendet werden sollte. Potenzielle Gefahren für das Unternehmen sollen damit identifiziert und unter Berücksichtigung eines bankspezifischen Risikoappetits gesteuert werden, um die festgelegten Bankziele mit angemessener Sicherheit erreichen zu können. Das unternehmensweite Risikomanagement selbst lässt sich konzeptionell in die drei Komponenten Risikoumfeld, Risikomanagement und Risikocontrolling aufteilen. Dabei ist wesentlich, dass der Bereich Risikoumfeld auf Unternehmensebene und Risikomanagement sowie Risikocontrolling auf Prozessebene stattfinden. Die Kommunikation und Informationsverbreitung ist das notwendige Bindeglied zwischen Risikoumfeld, Risikomanagement und Risikocontrolling. Im Zusammenhang mit dem Outsourcing sind bei der Betrachtung von Risiken innerhalb einer Risikoanalyse (und damit innerhalb des unternehmensweiten Risikomanagements) zwei Risikodimensionen relevant: Risiken aufgrund externer Unsicherheiten und inhärente Risiken der Auslagerung. Der laufende Betrieb umfasst die Erbringung der vertraglich vereinbarten Leistung durch den Insourcer und ihre Steuerung und Kontrolle durch das Kreditinstitut. Ein mehrschichtiges Governance-Modell ermöglicht eine Differenzierung unterschiedlicher Ebenen der Zusammenarbeit. Kernaufgabe dieser Aktivität ist die risikominimale Zielerreichung unter Anwendung kosteneffizienter laufender Überwachungsmaßnahmen gemäß einem vollständigen Managementzyklus. Das Ziel der Dienstleistersteuerung sollte sein, durch Kontroll- und Koordinationsmaßnahmen eine regelmäßige Beurteilung der Leistungen des Dienstleisters vorzunehmen, um ggf. geeignete Maßnahmen ergreifen zu können. Die Steuerung erfolgt auf Basis der SLA’s sowie der Berichte des externen Dienstleisters oder aufgrund sonstiger Auffälligkeiten. Hierfür sollten klare Verantwortlichkeiten festgelegt und eine regelmäßige Berichterstattung sichergestellt werden. Zur risikoorientierten Dienstleistersteuerung ist eine einheitliche Methodik festzulegen. Hierbei macht es Sinn, den Steuerungsaufwand einerseits an der Wesentlichkeit des Geschäftsprozesses auszurichten und andererseits weitere Faktoren mit zu berücksichtigen. Abhängig vom Auslagerungsumfang können sich auch bei nicht als „wesentlich“ eingestuften Auslagerungen ggf. datenschutzrechtliche oder GuV-relevante Sachverhalte für die Dienstleistersteuerung ergeben. Meist erreicht der Gesamtaufwand für weitere Auslagerungen und Vergaben (nicht wesentliche, sonstiger Fremdbezug und nicht i. S. d. MaRisk zu klassifizierende Auslagerungen) ebenfalls sehr namhafte Beträge. Da solche vergebenen Leistungen oft nicht zentral gesteuert werden, benötigen die betreuenden Fachbereiche Hilfestellungen zur Steuerung ihrer Dienstleistungspartner. Bei dieser Dezentralisierung ist es wichtig, dass ein einheitliches Verständnis für die Aufgabenstellungen der vielen Prozesse oder Schnittstellenbeteiligten besteht. Eine besondere Herausforderung liegt hierbei vor allem beim rechtzeitigen Erkennen von Auffälligkeiten in der Leistungserbringung, der Ableitung und Umsetzung geeigneter Maßnahmen sowie dem gegenseitigen zeitgerechten Informationsaustausch. Die Funktionalität der Prozesse der Dienstleistersteuerung in Verbindung mit den übrigen Prozessen des Unternehmens, die auf Informationen aus der Dienstleistersteuerung angewiesen sind, z.B. Risikomanagement, Datenschutzbeauftragter oder Notfallmanagement, ist im Wesentlichen von der Qualität dieses Informationsaustausches abhängig. Perspektivisch werden die Anforderungen an die Ausgestaltung und Besetzung der Dienstleistersteuerung steigen. Die damit verbundenen hohen Etats und die Aufgabenvielfältigkeit bedingen auch Anforderungen an die stetige Weiterentwicklung der Dienstleistersteuerungsmethodik sowie Mitarbeiterquantität und -qualität. Der entscheidende Ansatz für eine nach AT 9 Tz. 7 der MaRisk angemessenen Überwachung der Aktivitäten des Dienstleisters beginnt mit der klaren systematischen Funktionstrennung auf Ebene der Internen Kontrollverfahren mit den beiden Teilen des Internen Kontrollsystems und der Internen Revision. Die Überwachung und Steuerung des Dienstleisters ist eine Aufgabe des Risikomanagements, die dem Internen Kontrollsystem zuzuordnen ist, da es sich um eine geschäfts- bzw. prozessbezogene Überwachungstätigkeit handelt. Die unternehmensinterne Methodik zur Dienstleistersteuerung spielt dabei eine wesentliche Rolle, da diese auch für die in den Fachbereichen nicht zentral gesteuerten Dienstleister den Handlungsrahmen vorgibt, um die mit der Auslagerung verbundenen Risiken angemessen zu steuern.

Neben dem Management der Überwachungsgrößen ist deren Kommunikation und Reporting Bestandteil dieser Aktivität. Die Reportinginformationen sollten sich an den Anforderungen orientieren und unterschiedliche Hierarchiestufen integrieren. Zur Verbesserung der Qualität der erbrachten Leistungen und der Zusammenarbeit wird ein periodischer oder dynamischer Optimierungsvorgang durchlaufen. Die Funktion „Dienstleistersteuerung” ist für die grundsätzliche Regelung der Leistungsbeziehung zwischen Institut als Abnehmer und einem dritten Dienstleister als Ersteller der Leistung verantwortlich. Im Fokus steht dabei zunächst – sofern relevant – die Erfüllung sämtlicher aufsichtsrechtlicher Anforderungen gemäß § 25a Abs. 2 KWG in Bezug auf die Auslagerung von Bank- und Finanzdienstleistungen. Eine sinnvolle Methode für eine solche Prüfung ist die regelmäßige Durchführung einer Zertifizierung nach IDW PS 951 Typ 2 durch einen Wirtschaftsprüfer. Die Berichterstattung nach IDW PS 951 ist explizit auf die Erfüllung der Anforderungen aus IDW PS 331 abgestellt. Insbesondere bei Mehrmandantendienstleistern bietet die Berichterstattung nach IDW PS 951 eine effiziente Prüfungsdurchführung, da die Abschlussprüfer der auslagernden Unternehmen i.d.R. keine eigenen Prüfungshandlungen beim Dienstleistungsunternehmen mehr durchführen müssen. Darüber hinaus kümmert sich die Dienstleistersteuerung im Sinne einer ganzheitlichen Steuerung der Leistungsbeziehung auch um die Wahrung der wirtschaftlichen Interessen bzgl. der Leistungsbeziehung.

Im Fall des § 25a Abs. 2 KWG ist sie für die Vorgabe von Bearbeitungsrichtlinien für den Dienstleister verantwortlich. Sie trägt somit die Prozessverantwortung für die Abläufe hinsichtlich des Leistungsbezugs vom Dienstleister. Fachspezifisches Know-how lässt sich die Dienstleistersteuerung aus den jeweiligen Fachbereichen im Haus zuliefern. Die strategische Dienstleistersteuerung ist zum Beispiel für Vertragsverhandlungen und sehr kritische Eskalationen wie schwere Vertragsbrüche zuständig. Auf taktischer Ebene werden beispielsweise größere Changes genehmigt und Eskalationen geklärt. Die operative Dienstleistersteuerung sorgt für den störungsfreien Betrieb und prüft die Erfüllung aller Service Level. Die Auswertung der Ergebnisse zeigt, dass die Dienstleistersteuerung weitgehend definiert, jedoch nicht durchgehend vollzogen ist. Von der strategischen hin zur operativen Ebene nimmt der Anteil standardisierter Prozesse zu. Als unterdurchschnittlich reif werden die Prozesse Service-Kataloge und Service-Portfolio-Management beurteilt. Demnach verfügen etliche Banken noch über keinen standardisierten IT-Service-Katalog und keinen Prozess für das Management ihres Service-Portfolios. Sofern unter Effizienzgesichtspunkten sinnvoll kann die Dienstleistersteuerung den Dienstleister als weiteren Kompetenzträger in die Erarbeitung von Bearbeitungsrichtlinien einbeziehen oder Vorschläge von ihm einholen. Die Dienstleistersteuerung berichtet – hinsichtlich § 25a-KWG-relevanter Dienstleistungen – direkt der Geschäftsführung.

Die BaFin geht grundsätzlich davon aus, dass bankinterne Mechanismen beispielsweise im Risikocontrolling sowie bei Compliance-Aufgaben und Interner Revision auch bei Auslagerungen und Unterauslagerungen greifen. Die von der Bankenaufsicht erwünschte Risikokultur erstreckt sich damit unmittelbar auf die Dienstleistersteuerung. Institute müssen vor diesem Hintergrund die mit wesentlichen Auslagerungen verbundenen Risiken angemessen steuern und die Ausführung der ausgelagerten Aktivitäten ordnungsgemäß überwachen. Die Ergebnisse sind über einen expliziten Auslagerungsbericht in das eigene Berichtswesen aufzunehmen. Dieser muss zudem eine Aussage darüber treffen, ob die erbrachten Dienstleistungen der Auslagerungsunternehmen den vereinbarten Leistungen entsprechen. Die mit der Durchführung ausgelagerter Aktivitäten einhergehende Verantwortung lässt sich, vereinfacht gesagt, also nicht einfach mit auslagern. Das stellt die Aufsicht unmissverständlich klar: Sie bewertet die Frage des Auslagerungstatbestands unabhängig von möglichen zivilrechtlichen Verträgen. Das Reporting der Dienstleister ist die Grundlage für Entscheidungen im Rahmen der Anbietersteuerung. Exit-Klauseln für den Fall der Schlechtleistung, Controlling und Anpassung der Qualitätsanforderungen bauen auf ein aussagekräftiges Reporting auf. Einige IT-Führungskräfte be-klagten weiterhin ungenaue Berichte sowie SLA-Werte, die immer nur knapp über den Schwellenwerten liegen und dadurch Misstrauen hervorrufen. Zusammenfassend vermissen die Unternehmen bezüglich der Umsetzung des Berichtswesens bei ihrem IT-Dienstleister häufig Nachvollziehbarkeit, Zuverlässigkeit und Zweckmäßigkeit. Viele sind mit dem Berichtswesen ihrer IT-Dienstleister nicht zufrieden oder sehen lediglich die Minimalanforderungen als erfüllt an. Zu häufig werden Tätigkeiten, die eindeutig anderen Teilen des Internen Kontrollsystems zugeordnet sind, von der Internen Revision ausgeführt. Hierzu gehört auch die Auswertung von Risikoberichten von Mehrmandantendienstleistern. In diesen Fällen ist es nicht die Aufgabe der Internen Revision diese auszuwerten‚ sondern sie muss im Rahmen von Prüfungstätigkeiten feststellen, ob die Überwachung angemessen ist. Die Überwachungseinheiten der Auslagerung (z.B. die auslagernde Fachabteilung, der IT-Sicherheitsbeauftragte und/oder Risikomanager) müssen die erhaltenen Berichte/Informationen auswerten und vor dem Hintergrund der institutsinternen Risikokennziffer beurteilen. Es muss sich ein eigenes Urteil von der Leistung und den Risiken des Dienstleisters gebildet werden, welches anschließend in die institutsweite Betrachtung einfließt. Es sollte darauf geachtet werden, dass sich die Interne Revision nicht in diese Funktion drängen lässt und damit die nach MaRisk geforderte Funktionstrennung aufgehoben wird.

Die zentrale Norm für einen mindestens vierteljährlichen Risikobericht findet sich in AT 4.3.2 Tz. 3 der MaRisk. An dieser Stelle erwarten die MaRisk eine mindestens vierteljährliche Beschäftigung mit den wesentlichen Risiken und fordern ebenso in AT 4.3.2 Tz. 6 das vierteljährliche Reporting an den Aufsichtsrat über deren Entwicklung. Insbesondere die Risiken aus IT-Auslagerungen werden bei den meisten Banken, sofern sie nicht als eigene Risikoart eingestuft werden, in der Risikoinventur unter den operationellen Risiken aufgeführt. Alle mandantenrelevanten Mängel müssen der Bank offengelegt werden. Hierbei darf keine Filterung durch den Dienstleister erfolgen.

>>> Überleitung zum 2. Artikel: Im zweiten Teil des Artikels werden neue Alternativen betrachtet sowie konkrete Änderungen im IT-Risikomanagement berücksichtigt. Weiterhin werden verschiedene Aspekte von Softwarebezug, der künftig Outsourcing sein kann, beleuchtet.

IV. Software als Auslagerung

Die pauschale Auslagerungsqualifikation von Softwarebezug und diesbezüglichen Unterstützungsleistungen im Zusammenhang mit Risikoüberwachung ist neu, da diese – entgegen der Systematik des AT 9 – nicht an einen Auslagerungstatbestand anknüpft und bisher weder dem Risikogedanken der MaRisk noch den tatsächlichen Prozessen in der Bankpraxis gerecht wird. So würde sich auch eine vom Institut fremdbezogene, aber selbst betriebene Software als Auslagerung qualifizieren, ohne dass allgemeine Auslagerungselemente vorliegen. Dies träfe bei enger Auslegung sogar für den einmaligen Erwerb von in Eigenregie individuell an die Bedürfnisse der Banken angepasster Software ohne jeglichen Dienstleistungsbezug zu. Damit wurden die tatbestandlichen Voraussetzungen von § 25b KWG, AT 9 für (und nur für) das Thema Software de facto übergangen. Software ist für die Durchführung von Bankgeschäften per se von großer Bedeutung, da heutzutage jedes in § 1 KWG aufgeführte Bankgeschäft auf der Grundlage von IT-Systemen (teilweise vollständig automatisiert) durchgeführt wird. Die besondere Bedeutung von IT-Systemen führt dazu, dass klassische Unterstützungsleistungen wie Entwicklungsleistungen, IT-Consulting oder Wartung als Auslagerungstätigkeiten verstanden werden, da auch andere Risiken vertraglich geregelt und inhaltlich gesteuert werden müssen. Der Einkauf spezialisierten, qualitativ hochwertigen IT-Know-hows würde durch die neue Anforderung de facto verteuert und erschwert, was der gewünschten Konzentration auf Kernkompetenzen bei den Banken leider entgegenwirkt und außer Acht lässt, dass aufgrund einer Vielzahl an rechtlichen und marktgetriebenen Vorgaben eine spezialisierte, hoch entwickelte IT-Branche für die kostengünstige, effiziente und schnelle Massendatenverarbeitung zwingend erforderlich ist. Es kann aber nicht das Ziel sein, das Rad zurückzudrehen und die IT-Lösungen wieder inzusourcen. Nicht zuletzt ist zu berücksichtigen, dass die strengen Vorgaben der MaRisk für eine Vielzahl von kleineren Softwareanbietern, die auf bestimmte Randfunktionalitäten spezialisiert sind, aus Personal- und letztlich Kostengründen nicht umsetzbar sind. Dies engt die Banken bei der Auswahl fachlich geeigneter Dienstleister in diesem Bereich zusätzlich ein. Gleichzeitig wird indirekt in bestehende Marktstrukturen eingegriffen und letztlich ein Verdrängungswettbewerb gefördert. In den Banken wird Standardsoftware regelmäßig für einen bestimmten Zeitraum inkl. der Standard-Updates gekauft. Häufig erfolgt zusätzlich ein Customizing nach den Vorgaben der nutzungsberechtigten Bank, wobei die Vorgaben von der Bank selbst kommen, dessen Mitarbeiter regelmäßig projekthaft in die Umsetzungstätigkeiten des Softwareanbieters eingebunden sind, die Tests (mit-)durchgeführt werden und auch die Freigabe zur Produktion erteilt wird. Unter Risikogesichtspunkten sind diese individuellen Leistungen des Softwareanbieters über den gesamten Prozess in der Hand der jeweiligen Auftrag gebenden Banken. Aktivitäten und Prozesse werden also keinesfalls ausgelagert, vielmehr wird ein klar definierter, einmaliger Auftrag an den Softwareanbieter erteilt, der zudem institutsseitig noch eng begleitet wird. Zudem werden bei der Mehrzahl der Banken Programmeinsatzverfahren angewandt, die die mit der Software einhergehenden Risiken einer Beurteilung unterziehen. Eine solch erhebliche Ausweitung der Dienstleistersteuerung steht in keinem Verhältnis zu dem damit verbundenen Risiko. Mir sind bis dato keine besonderen Schadensfälle in dieser Hinsicht bekannt. Spezialisierte IT-Anbieter werden kaum den Source-Code, der Grundlage ihrer Geschäftstätigkeit ist, offenlegen.

V. Robotic Process Automation (RPA)

Bankenvorstände sind heutzutage nicht zu beneiden. Sie müssen immer mehr Prozesseffizienz schaffen, haben es aber mit wachsenden IT-Landschaften zu tun. Um in so einem Umfeld Prozesse zu vereinfachen, sind komplexe IT-Transformationsvorhaben wie die Modernisierung der Kernsysteme oder eine Implementierung von BPM-Systemen nötig. Will man ohne diese Projekte mehr Effizienz rausholen, bleibt oft nur noch das Outsourcing. Und doch sind Transformations- und BPM-Vorhaben oft schwierig: lange Umsetzungszyklen und ein hoher Integrationsaufwand. Oft sind diese Projekte komplex und risikoreich und amortisieren sich erst sehr spät. Outsourcing auf der anderen Seite büßt nach und nach an Effizienzeffekten ein. Dort wo es bereits seit langem im Einsatz ist, hat das Potenzial bereits ein Maximum erreicht. Auch das Lohnkostenargument wird zunehmend obsolet, wenn Löhne steigen. In diese Lücke springt nun die Robotic Process Automation (RPA), also die Automatisierung via Software-Roboter. Die Hersteller versprechen Einsparungen von bis zu 60 Prozent und eine schnelle und risikoarme Implementierung. Die wird vor allem dadurch möglich, dass kein Integrationsaufwand auf Seiten der bestehenden Systemlandschaft anfällt. Warum? Weil Robotics Automation außerhalb der bestehenden Systeme sitzt. Die Schnittstelle ist das User Interface. Die Konfiguration erfolgt durch „vormachen“ am System. Das kann durch den Fachexperten erfolgen und bindet dadurch kaum Ressourcen auf Seiten der IT – „Code free“ sozusagen. Einmal konfiguriert, werden Prozesse hochskalierbar. Hunderte Roboter können gleichzeitig das tun, was sonst einzelne Mitarbeiter seriell abarbeiten müssen. Glücklicherweise sind diese Roboter keine physisch existenten maschinellen Gestalten mit Armen, Beinen oder Rädern so wie wir sie aus der Fertigungsindustrie kennen – wo sollten wir so viele von ihnen auch unterbringen? RPA-Roboter sind reine Software und brauchen keine Schreibtische. Aber sie könnten einen ähnlichen Einfluss auf die Arbeitswelt im Backoffice haben wie ihre physischen Vorgänger auf die Fertigung. Automatisierung von Geschäftsprozessen ist nichts Neues. Unternehmen haben immer nach Möglichkeiten gesucht, um die Effizienz zu steigern und Wachstum zu fördern. Bisher haben Unternehmen dies oft über Investitionen in Enterprise-Systeme (ERP), Business Process Management-Lösungen oder in Shared Services/Outsourcing realisiert. Trotz starker Investitionen in diese Lösungen sind Prozesse immer noch nicht voll automatisiert und sehen häufig eher aus wie ein Flickenteppich. Das liegt oft daran, dass traditionelle Lösungen häufig sehr kostenintensiv sind, viele Ressourcen beanspruchen und zusätzlich nicht schnell auf veränderte Marktsituationen reagieren können.

Beispielfunktionen, welche RPA durchführen kann:

  • Daten extrahieren, verändern und Berichte erstellen
  • Formulare ausfüllen
  • Daten kopieren, einfügen und verschieben
  • In Systeme einloggen und diese bedienen bspw. ERP- und Kundenmanagementsysteme
  • Informationen aus mehreren Systemen lesen und verarbeiten
  • Informationen aus strukturierten Dokumenten lesen
  • Berechnungen durchführen
  • „Wenn/Dann“ Befehle ausführen
  • E-Mails öffnen und Anhänge verarbeiten

Robotic Process Automation kann auch als virtueller Mitarbeiter betrachtet werden. RPA greift dazu auf Ihre bestehenden Applikationen zu und führt so strukturierte Prozesse automatisch aus. Es müssen keine Veränderungen an bestehenden Systemen durchgeführt werden, da RPA darauf genauso zugreift wie Ihre Mitarbeiter. Somit kann RPA eine Vielzahl von Prozessen automatisieren wie beispielsweise Rechnungsbearbeitung, Report-Erstellung oder Mitarbeiter-Onboarding. Durch Robotic Process Automation werden Geschäftsprozesse schnell, fehlerfrei und automatisch erledigt. Bei dieser Art von Prozessautomatisierung setzt ein Software-Roboter Aufgaben in einem System oder einer Anwendung in der gleichen Weise um, wie es ein Mensch tun würde. Der Roboter wird zum virtuellen Angestellten, der manuelle und sich ständig wiederholende Teilprozesse oder Aufgaben ausführt, die ein hohes Maß an Genauigkeit erfordern. Die Vorteile der Prozessautomatisierung via Roboter bestehen darin, dass Mitarbeiter von ermüdenden und immer wiederkehrenden Routinetätigkeiten entlastet werden, die Roboter wesentlich schneller erledigen können. Automatisierung durch Softwareroboter entdecken viele Banken aktuell für sich. Neun von zehn Instituten in Deutschland planen laut einer Studie, bis 2019 so viele Abläufe wie möglich zu standardisieren, sodass diese von Algorithmen übernommen werden können. Der Softwareroboter bildet dabei die Aktivitäten eines Menschen an Bildschirm und Tastatur nach. Möglichkeiten für den Einsatz sind etwa Tätigkeiten nach der Kontoeröffnung oder die Bearbeitung von Fehlerlisten.

VI. IT-Risikomanagement

Das KWG verlangt von der Bank eine ordnungsgemäße Geschäftsorganisation. Die ordnungsgemäße Geschäftsorganisation einer Bank muss insbesondere ein angemessenes und wirksames Risikomanagement umfassen, auf dessen Basis die Bank die Risikotragfähigkeit laufend sicherzustellen hat. Eine Auslagerung darf weder die Ordnungsmäßigkeit dieser Geschäfte und Dienstleistungen noch die Geschäftsorganisation im Sinne des § 25a Abs. 1 KWG beeinträchtigen. Insbesondere muss ein angemessenes und wirksames Risikomanagement durch das Institut gewährleistet bleiben, welches die ausgelagerten Aktivitäten und Prozesse einbezieht. Zuerst stellt sich die Frage, was eigentlich unter dem Begriff Risiko zu verstehen ist. An dieser Stelle soll deshalb der Risikobegriff erläutert werden und ein Überblick über die Risiken des IT-Outsourcings gegeben werden. Das Wort Risiko hat seinen Ursprung im frühitalienischen Wort „risicare“, das übersetzt „etwas wagen“ bedeutet. Obwohl sich zahlreiche Veröffentlichungen mit der Risikoproblematik wirtschaftlichen Handelns beschäftigen, gibt es trotz der Fülle keine einheitlich allgemeingültige Definition des Risikobegriffs. Bevor nun auf die Methoden des Risikomanagements eingegangen wird, soll zunächst geklärt werden, was unter dem Begriff des „Risikomanagements“ zu verstehen ist. Ähnlich wie beim Risikobegriff, gibt es in der Literatur auch zum Begriff des “Risikomanagements” eine Vielzahl an Definitionen. Prinzipiell ist Risikomanagement eine systematische Vorgehensweise im Umgang mit Risiken. Für ein besseres Verständnis helfen allgemeine Definitionen. In einer allgemeineren Definition werden unter Risiko- Management “alle erforderlichen Aufgaben und Maßnahmen zur Risikobekämpfung“ verstanden. Aufgabe des Risikomanagements ist es also, die wesentlichen Risiken, die den Unternehmenserfolg oder -bestand gefährden, frühzeitig zu erkennen und Gegenmaßnahmen zu treffen. Risiken können dabei in sehr zahlreichen Erscheinungsformen auftreten. Das IT-Risikomanagement ist ein Teil des Information Security Management Systems (ISMS) und befasst sich mit der Analyse und Bewertung von Risiken. Dieses Vorgehen generiert einen Mehrwert für das Unternehmen und seine Kunden, indem es die Umsetzung von Schutzmaßnahmen abhängig von der Höhe des Risikos macht. Dadurch wird es leichter, ein angemessenes Sicherheitsniveau zu finden, zu erreichen und zu halten. Dieses Vorgehen ist wirtschaftlich sinnvoller als starre Vorgaben in Form von komplett umzusetzenden Maßnahmenkatalogen. Im Rahmen des IT-Risikomanagements werden nur Risiken betrachtet, die die vier Schutzziele der IT (Verfügbarkeit, Integrität, Vertraulichkeit und Authentizität) bedrohen. Risikomanagement hat zum Ziel, fatale, sprich existenzgefährdende, Schäden für das Unternehmen möglichst zu verhindern. Die Steuerung von IT-Risiken muss in Übereinstimmung mit der Unternehmensstrategie erfolgen. Dazu müssen bestehende Risiken für die Unternehmensführung transparent sein. Mit den MaRisk werden die Anforderungen aus § 25a KWG weiter konkretisiert. Ziele der MaRisk (AT 2) sind u.a. der Schutz der anvertrauten Vermögenswerte, die häufig als Daten in IT-Systemen technisch repräsentiert werden, und die ordnungsgemäße Durchführung der Bankgeschäfte oder Finanzdienstleistungen. Die Risikoidentifikation als Teil des Gesamtrisikoprofils der Bank auf der einen und die Festlegung des bestehenden Risikodeckungspotenzials (AT 4.1) der Bank auf der anderen Seite ist der erste wesentliche Schritt bei allen Risikomanagement-Prozessen der IT-Risiken. Sie ist dabei einer der schwierigsten Teile des Risikomanagement-Prozesses, da alle weiteren Maßnahmen auf ihr beruhen. Schließlich können nur die Risiken bewertet und gesteuert werden, die im Vorfeld erkannt wurden. Es gilt die Regel, dass ein Risiko, das nicht im Vorfeld erkannt werden konnte, beim Eintreten auch nicht mit entsprechenden Maßnahmen in den Griff bekommen werden kann. Als Mindestanforderungskriterien an die Phase der Risikoidentifikation können dementsprechend Vollständigkeit, Aktualität und regelmäßige Überprüfungen genannt werden. Vollständigkeit bedeutet dabei eine vollständige Erfassung von Risiken eines Projekts. Unter Aktualität wird eine zeitnahe Erfassung von Risiken verstanden. Da sich Risiken durch z.B. veränderte Rahmenbedingungen auch ändern können, muss, um die Kriterien der Vollständigkeit und Aktualität erfüllen zu können, das Kriterium der regelmäßigen Überprüfung herangezogen werden. Auf dieser Grundlage wird die Geschäftsstrategie definieret und daraus ableitbare Teilstrategien (AT 4.2), zu denen auch die IT-Strategie gemäß IDW RS FAIT 1 als Funktionalstrategie gehört. Die Auswirkungen der Risiken lassen sich mindern, jedoch nie gänzlich ausschließen. Aus meiner Sicht gibt es konkret folgende wesentliche Risiken:

  1. Die Bank hat keinen Einfluss auf die Wirtschaftlichkeit und eine eventuelle Insolvenz des Dienstleisters.
  2. Die Bank hat keinen Einfluss und keinen direkten Zugriff mehr auf die handelnden Mitarbeiter.
  3. Der Service für die Mitarbeiter wird von ‘Externen’ erbracht.
  4. Business-Know-how geht auf Dauer verloren. Die Abhängigkeit von den allgemeinen Dienstleistern wird mit den Jahren größer.
  5. Der Dienstleister erbringt seine Leistungen nicht nur für die Bank. Mit der Zeit könnte die Bank nicht mehr an erster Priorität stehen.

Die nachfolgenden Maßnahmen könnten die Auswirkung der Risiken mindern:

  1. Außerordentliches Kündigungsrecht der Bank mit der Möglichkeit, im Insolvenzfall Mitarbeiter ohne Zustimmung des Dienstleisters zu übernehmen.
  2. Monatliche Kopie der Personalsysteme und der Daten wird dem IT-Bereich der Bank übergeben. Im Havariefall kann eine eigene Plattform erstellt werden.
  3. Partnerschaftlicher und professioneller Umgang mit dem Dienstleister, ohne sich gegenseitig zu übervorteilen.
  4. Schaffung von Stellen in der Bank zur Überwachung und Steuerung der Dienstleistung.
  5. Optimierung der Prozesse beim Dienstleister, gemeinsame Einrichtung der Schnittstellen und Festlegen der Prozesse.

Unter Risikosteuerung versteht man die aktive Beeinflussung der im Rahmen der Risikoidentifikation und Risikobewertung ermittelten Risiken entsprechend ihrer Risikoposition. Voraussetzung für eine effektive Risikosteuerung ist eine regelmäßige Erfassung der Analyseergebnisse und eine sachgerechte Information der Entscheidungsträger. Die Maßnahmen, die für die Steuerung getroffen werden, haben dabei eine Verringerung der Eintrittswahrscheinlichkeit und/oder eine Begrenzung der Auswirkungen zum Ziel. Die Steuerungs- und
-controllingprozesse müssen gewährleisten, dass die wesentlichen IT-Risiken – auch aus ausgelagerten Aktivitäten und Prozessen (z.B. an die Rechenzentrale) – frühzeitig erkannt, vollständig erfasst und in angemessener Weise dargestellt werden können. Die Steuerungs- und
-controllingprozesse für IT-Risiken sind zeitnah an sich ändernde Bedingungen anzupassen. Es muss gewährleistet sein, dass wesentliche IT-Risiken zumindest jährlich identifiziert und beurteilt werden (BTR 4 Tz. 2). Bedeutende Schadensfälle (z.B. längerer Ausfall von IT-Systemen) sind unverzüglich hinsichtlich ihrer Ursachen zu analysieren (BTR 4 Tz. 3). Die Umsetzung der zu treffenden Maßnahmen ist zu überwachen (BTR 4 Tz. 5). Der Vorstand hat sich in angemessenen Abständen über die IT-Risikosituation berichten zu lassen. Die IT-Risikoberichterstattung ist in nachvollziehbarer, aussagefähiger Art und Weise zu verfassen. Sie hat neben einer Darstellung auch eine Beurteilung der Risikosituation zu enthalten. In die Berichterstattung sind bei Bedarf auch Handlungsvorschläge, z.B. zur Risikoreduzierung, aufzunehmen. Die IT-Risikoberichterstattung an den Vorstand kann – soweit dies aus Sicht des Vorstandes als sinnvoll erachtet wird – durch prägnante Darstellungen ergänzt werden (z.B. ein Management Summary). Soweit sich keine relevanten Änderungen ergeben haben, kann im Rahmen der aktuellen Berichterstattung auf diese Informationen verwiesen werden. Auch eine Diskussion der Handlungsvorschläge mit den jeweils verantwortlichen Bereichen ist grundsätzlich unproblematisch, solange sichergestellt ist, dass der Informationsgehalt der Berichterstattung beziehungsweise der Handlungsvorschläge nicht auf eine unsachgerechte Weise verzerrt wird. In den Risikoberichten sind insbesondere auch die Ergebnisse der Stresstests von IT-Risiken sowie ggf. die Ergebnisse der Notfalltests (AT 7.3 Tz. 1) und deren potenzielle Auswirkungen auf die Risikosituation und das Risikodeckungspotenzial darzustellen. Ebenfalls darzustellen sind die den Stresstests zugrunde liegenden wesentlichen Annahmen. Darüber hinaus ist auch auf Risikokonzentrationen und deren potenzielle Auswirkungen gesondert einzugehen. Der Vorstand ist mindestens jährlich über bedeutende IT-Schadensfälle und wesentliche IT-Risiken als Teil der operationellen Risiken zu unterrichten. Die Berichterstattung hat die Art des Schadens beziehungsweise IT-Risikos, die Ursachen, das Ausmaß des Schadens beziehungsweise IT-Risikos und gegebenenfalls bereits getroffene Gegenmaßnahmen zu umfassen (BTR 4 Tz. 4). Auf Basis der Berichterstattung ist zu entscheiden, ob und welche Maßnahmen zur Beseitigung der Ursachen zu treffen oder welche Risikosteuerungsmaßnahmen (z.B. Versicherungen, Ersatzverfahren, Neuausrichtung von Geschäftsaktivitäten, Katastrophenschutzmaßnahmen) zu ergreifen sind (BTR 4 Tz. 5). Unter Risikogesichtspunkten wesentliche Informationen sind unverzüglich an den Vorstand, die jeweiligen Verantwortlichen und gegebenenfalls die Interne Revision weiterzuleiten, sodass geeignete Maßnahmen beziehungsweise Prüfungshandlungen frühzeitig eingeleitet werden können. Hierfür ist ein geeignetes Verfahren festzulegen. IT-Risiken sollten in angemessener Weise bei der Berichterstattung des Vorstandes an den Aufsichtsrat berücksichtigt werden. Der Ausdruck „Stresstests für IT-Risiken“ wird im Folgenden als Oberbegriff für die unterschiedlichen Methoden gebraucht, mit denen die Bank ihr individuelles Gefährdungspotenzial auch bezüglich außergewöhnlicher, aber plausibel möglicher Ereignisse im Umfeld der IT-Risiken auf den jeweils relevanten Ebenen der Bank überprüfen. Sollte die Bank IT-Risiken als wesentliche Risiken festgelegt haben, sind regelmäßig angemessene Stresstests für die IT-Risiken durchzuführen, die Art, Umfang, Komplexität und den Risikogehalt der Geschäftsaktivitäten widerspiegeln. Ein wichtiger Faktor zur erfolgreichen Umsetzung des Risikomanagements ist deshalb eine gelebte Risikokultur. Sie bildet das Fundament der einzelnen Risikomaßnahmen, die im Rahmen des Risikomanagements getroffen werden. Eine Risikokultur beinhaltet die Bereitschaft zur Wahrnehmung von Risiken, die Sensibilisierung der Mitarbeiter und die Kommunikation der Risiken. Die Geschäftsleitung erfüllt also eine wichtige Vorbildfunktion. Nicht vergessen darf man natürlich die Compliance-Aspekte. Die Bestimmungen zur Jahresabschlussprüfung wurden z.B. in Deutschland durch das Gesetz über Kontrolle und Transparenz im Unternehmensbereich und für an US-Börsen notierte Gesellschaften im SOX verschärft. Darüber hinaus existieren viele weitere Vorschriften mit teilweise nur lokaler oder bankspezifischer Bedeutung (MaRisk) sowie weitere Regulierungen wie Basel II, Solvency II oder die EU-Richtlinie MiFID („Markets in Financial Instruments Directive“). Banken können sich nicht durch Auslagerung ihren Nachweispflichten entziehen. Das auslagernde Unternehmen muss sicherstellen, dass die Vorgehensweisen des Dienstleisters den Ansprüchen des Gesetzgebers und der Regulatoren entsprechen.

Nach der MaRisk AT 9 hat eine regelmäßige Auswertung von Informationen und Berichten im Rahmen des internen Kontrollsystems für ausgelagerte Aktivitäten und Prozesse zu erfolgen. Hierbei sind grundsätzlich folgende Fragestellungen zu beachten:

  1. Wer ist bankintern für die Überwachung und Steuerung der Auslagerungsdienstleitung verantwortlich?
  2. Handelt es sich um einen Bericht über die Durchführung von Tätigkeiten der Internen Revision beim Auslagerungsunternehmen?
  3. Erfolgt die Berichterstattung außerhalb eines regelmäßigen Turnus?
  4. Ergeben sich Lücken bei den geprüften Zeiträumen?
  5. Wurden wesentliche, schwerwiegende oder besonders schwerwiegende Mängel festgestellt?
  6. Handelt es sich um Mängel, die bereits in vorangegangenen Berichten festgestellt wurden?
  7. Sind Maßnahmen beim Insourcer erforderlich?
  8. Müssen von der Bank Maßnahmen ergriffen werden?

In der Praxis ergibt sich in vielen Banken ein kompliziertes Geflecht aus Auslagerungen, die eine zentrale Instanz notwendig machen, um den Überblick über die Steuerung von Auslagerungen zu behalten. Denn häufig haben es die Institute nicht mit einfachen 1:1-Beziehungen zu nur einem Dienstleister zu tun, sondern mit 1:n-Beziehungen, falls beauftragte Dienstleister ihrerseits Auslagerungen vornehmen. Vor allem bei kleineren Instituten ist es beispielsweise verbreitet, den Zahlungsverkehr an einen gemeinsamen Dienstleister auszulagern. Angesichts des beschränkten Geschäftsauftrags lagert dieser dann häufig die Interne Revision zumindest teilweise aus. Das entlastet jedoch die erstauslagernden Institute nicht von der Verantwortung, für einen ordnungsgemäßen Informationsfluss zu sorgen. Dies ist in den Bedingungen für Weiterauslagerungen festzuhalten und durch das erstauslagernde Institut nachzuhalten.

VII. Konsistenz von Sicherheitsmanagement und Notfallplanung

Durch den IT-Outsourcing-Vertrag wird mittels der SLA festgelegt, welche Dienstleistungen vom Service Anbieter in welchem Umfang erbracht werden müssen. Dabei ist die Verantwortlichkeitsverteilung klar geregelt und die Konsequenzen bei Nicht-Erfüllung sind entsprechend definiert. Bei der IT-Sicherheit hingegen sind die Verantwortlichkeiten nicht mittels der SLA geregelt. Damit gewährleistet werden kann, dass mit Anwendungen oder Kundendaten auch beim Service Anbieter sicher umgegangen wird, wird zwischen den Outsourcing-Parteien ein sogenanntes IT-Sicherheitskonzept erstellt. In diesem Sicherheitskonzept sind die verschiedenen Verantwortlichkeiten und die relevanten Themen geregelt. Die zentrale Frage bei der Erstellung eines IT-Sicherheitskonzeptes lautet: Welchen Schutz benötigen welche IT-Systeme? Es ist zu beachten, was genau geschützt werden muss und wogegen die Systeme geschützt werden müssen. Wurde eine entsprechende Risikoanalyse vorgenommen, so muss man sich mit der Frage auseinandersetzen, wie ein wirksamer Schutz erreicht werden kann und ob der Nutzen des Schutzes einen potentiellen Schaden übersteigt. Damit sind die Kernbestandteile eines IT-Sicherheitskonzeptes umriussen. Der Service Anbieter schließt mit jedem einzelnen Kunden ein separates Konzept ab. Ein IT-Sicherheitskonzept ist wesentlicher Bestandteil zwischen Service Anbieter und Outsourcingnehmer, die Themen des Sicherheitskonzeptes sind nicht verhandelbar. Dies gilt auch für Kunden, die z.B. einem „geteilten Service“ angehören. Das sind Kunden, die sich beim Service Anbieter im gleichen Netzwerk oder Rechenzentrum wie andere Kunden befinden. Die Erstellung des IT-Sicherheitskonzeptes ist im Idealfall eine Zusammenarbeit zwischen dem Outsourcingnehmer und dem Service Anbieter. Diese Vorgehensweise wird in der Praxis auch so gehandhabt. Bei nicht wesentlichen Geschäftsprozessen ist eine gemeinsame Erarbeitung des Sicherheitskonzepts nicht zwingend. Die IT-Sicherheits-Verantwortlichen der Bank haben zu beachten, dass die eigenen internen Sicherheitsrichtlinien in das Sicherheitskonzept integriert werden. Die Praxis hat gezeigt, dass die Service Anbieter Vorlagen der Sicherheitskonzepte besitzen, die an die jeweiligen Kunden angepasst werden. Diese Vorlagen sind mit den Richtlinien und Weisungen des Service Anbieters bezüglich der IT-Sicherheit versehen. Die Einbringung der Richtlinien des Outsourcingnehmers gehört zu den Pflichten des IT-Sicherheit-Verantwortlichen des Outsourcingnehmers. Das Informationssicherheitskonzept ist in jedem IT-Projekt sowie in Projekten mit IT-Anteil zu erstellen. Das projektbezogene Informationssicherheitskonzept enthält alle an das zu entwickelnde System verbindlich gestellten Informationssicherheitsanforderungen und die Informationssicherheitsmaßnahmen zum Schutz der Informationen vor Verlust der Integrität, Verbindlichkeit, Vertraulichkeit und Verfügbarkeit sowie die Informationssicherheitsanforderungen und Informationssicherheitsmaßnahmen zum Schutz der technischen Anlagen zur Informationsverarbeitung und Informationsübermittlung. Im Rahmen der Erstellung und Fortschreibung des Informationssicherheitskonzepts sind seine Inhalte auf Korrektheit, Konsistenz und Vollständigkeit zu überprüfen und ggf. anzupassen.

PRAXISTIPPS

  • Identifizieren Sie die Software in ihrer Bank, die zukünftig als Auslagerung gelten könnte
  • Gestaltet Sie die Prozesse durch eine zentrale Dienstleistersteuerung effizient
  • Auswertung der Berichterstattung ist zentraler Baustein der Dienstleistesteuerung
  • Führen Sie Stresstests zu IT-Risiken durch
  • Stimmen Sie Sicherheitsmanagement und Notfallplanung mit ihrem Dienstleister auch unterjährig ab

Beitragsnummer: 39063