Aufrufe
vor 6 Jahren

RISIKO MANAGER 06.2016

  • Text
  • Zugang
  • Risiko
  • Ausfallmuster
  • Restlaufzeit
  • Definition
  • Variablen
  • Gleichung
  • Risikomanagement
  • Portfolio
  • Prozesse
RISIKO MANAGER ist das führende Medium für alle Experten des Financial Risk Managements in Banken, Sparkassen und Versicherungen. Mit Themen aus den Bereichen Kreditrisiko, Marktrisiko, OpRisk, ERM und Regulierung vermittelt RISIKO MANAGER seinen Lesern hochkarätige Einschätzungen und umfassendes Wissen für fortschrittliches Risikomanagement.

24

24 RISIKO MANAGER 06|2016 präventiven Charakter. U. a. sollen Key Controls die gesamte Prozesskette zur Erstellung der durch den Service-Provider erbrachten Leistungen prüfen und sichern, so dass damit i. d. R. mehrere Risiken abgedeckt werden. So sind sie äußerst wirksam und effizient. Um diesen Prüfungsanforderungen gerecht zu werden, sind in den SLAs bereits zentrale Endprodukte, wie Datenqualitätsreports, spezifiziert. Über die Prüfung der Korrektheit dieser Endprodukte hinaus werden implizit die Prozesse auf Angemessenheit und Qualität so gut wie möglich geprüft. Key Controls stellen somit unverzichtbare Kontrollziele dar. Entscheidend für die risikoadäquate Bestimmung der Key Controls sind das Verständnis der Prozesse und die Identifizierung der maßgeblichen risikobehafteten „Knotenpunkte“. Die Aufsicht hat für die Überwachung der ausgelagerten Tätigkeiten weder konkrete Vorgaben noch einen festen Turnus bestimmt. Das IKS eines Instituts ist derart zu gestalten, dass die ausgelagerten Prozesse integriert werden können. Dabei soll den infolge der Auslagerung geänderten Kontrollabläufen bzw. Überwachungspflichten Rechnung getragen werden. Das Institut der Wirtschaftsprüfer in Deutschland e.V. (IDW) gibt mit seiner Verlautbarung IDW 340 indirekt die Mindestanforderungen an ein solches Risikofrüherkennungssystem vor. Einschränkungen von Key Controls Aufgrund fehlender Zugriffsberechtigungen auf Middle- und Back-Office-Systeme sowie fehlender Detailkenntnisse in Bezug auf die Systemlandschaft und den Datenhaushalt des Servicedienstleisters beschränken sich die Prüfungshandlungen der Key Controls im Wesentlichen auf Stichproben und manuelle Vergleiche der Key-Control-spezifischen Endprodukte. Daher lässt eine stichprobenbasierte Prüfung, auch wenn sie keine Unstimmigkeiten aufgedeckt hat, keine verlässliche Aussage über Vollständigkeit und Korrektheit der einzelnen Reports zu. Einzelne Endprodukte und die diesen Endprodukten zugrunde liegenden Prozesse können somit nur mit einer eingeschränkten Qualität in den verschiedenen Fachbereichen geprüft werden. Dabei handelt es sich u. a. um fachbereichsabhängige Reports, denen spezifische Daten und Prozesse zugrunde liegen. Daher beruhen sie i. d. R. nicht auf einer – wenn überhaupt existierenden – zentralen übergreifenden Datenhaltungsschicht als Single-Point-of-Truth [vgl. Golla, G./Hoppe, T./Pastwa, A., 2014c]. Nichtsdestotrotz müssen die Fachbereiche für ihre Analysen und die Weiterverarbeitung der bereitgestellten Informationen auf die Korrektheit der Daten vertrauen. Neben dieser Prüfung der einzelnen Endprodukte ist zusätzlich sicherzustellen, dass die verschiedenen Endprodukte auch fachbereichsübergreifend untereinander konform sind oder sich entsprechen. Diese Herausforderung ist insbesondere von Bedeutung, wenn Dienstleister keine zentrale Datenbank oder einheitlichen Prozesse verwenden. Bei der Durchführung notwendiger Kontroll- und Plausibilisierungshandlungen zur Prüfung der Prozesse eines Dienstleisters Abb. 02 werden somit verschiedene Datenquellen herangezogen, wie » Endproduktreports, die auf unterschiedlichen Lieferrhythmen beruhen können; » Wochenreports, die sich im Monatsreport, Quartalsreport oder/und Jahresreport kumulieren; » Berichte und Datenreports von Töchtern im Rahmen des Risikomanagements auf Gruppenebene. Implikationen für Datenqualitätsprozesse und Steuerung des fachlichen Dienstleisters im Rahmen der Wahrnehmung der Prinzipalverantwortung Für eine effiziente Möglichkeit zur Durchführung von übergreifenden Prüfungsmöglichkeiten bieten sich Prozesse an, die durch Business Intelligence-Werkzeuge unterstützt werden Abb. 02. Hier können die verschiedenen Quellen geprüft oder gegeneinander abgeglichen werden. BI-Tools verfügen über die Regulatorische und gesetzliche Anforderungen beim Outsourcing Um den Anforderungen gerecht zu werden, sind effiziente, zielgerichtete und präventive Prüfungsprozesse erforderlich, die die Prozessund Datenqualität nachhaltig sichern, um den Anforderungen gerecht zu werden. Datenbasis (Spezifische Reports, unterschiedlichen Datenquellen etc.) Prinzipal (Per SLAs ausgelagerte Leistungen sind zu überwachen und zu steuern) Ganzheitliche, übergreifende Prüfungsprozesse (Key Controls, BI-Toolunterstützt, BCBS #239-konform) Überwachungs- und Steuerungspflicht (Verantwortung liegt im auslagernden Institut) Zur Überwachung und Steuerung stehen dem Prinzipal i. d. R. nicht alle Detaildaten, sondern nur aggregierte Informationen zur Verfügung. Die prozessuale Gesamtverantwortung liegt gemäß KWG und MaRisk beim Prinzipal.

ERM 25 notwendige Flexibilität, um aufkommende Prüfungs- und Reportinganforderungen schnell und flexibel bedienen zu können. Ein BI-basiertes Vorgehen bildet die Basis für einen „Leitstand“ mit dem Ziel » einer lückenlosen, konstanten und gleichmäßigen Qualitätsmessung; » vernetzte Prüfungen der unterschiedlichen Datenquellen durchzuführen und somit optimale Reconciliation- Möglichkeiten zu nutzen; » die verschiedenen Reports untereinander zu plausibilisieren. Dieses Vorgehen stellt einen bedeutenden Vorteil im Vergleich zu stichprobenartigen Prüfungen dar. Der präventive Charakter der Prüfungshandlungen wird hier deutlich erhöht, sodass Datenqualitätsprobleme frühzeitig erkannt und damit deutlich vor der Reportdeadline bereinigt werden können. Zudem lassen sich Prozessschwächen über identifizierte Inplausibilitäten und fehlende Datenqualitätsmaßnahmen beim Service-Provider aufdecken. So wird die Datenqualität permanent auf konstant hohem Level gehalten. Die Risiken werden übergreifend minimiert. Die Praxiserfahrung zeigt, dass zur Plausibilisierung der definierten Endprodukte und zur Sicherstellung der ausgelagerten Fachprozesse über Key Controls detailliertes Know-how der Architektur und des Datenhaushalts des Service-Providers erforderlich ist. Die notwendigen Einblicke in die Prozesse des Dienstleisters stellen jedoch oftmals Hürden dar. Die in den SLAs vereinbarten Endprodukte bieten zum Teil keine angemessene Flexibilität, da das auslagernde Institut bei Definition der entsprechenden Endprodukte und Reports i. d. R. noch keine ausreichenden Detailkenntnisse über die Prozesslandschaft und den Datenhaushalt des Service-Providers besitzt. Anpassungen und nachträgliche Ausgestaltungen, die im Laufe der Plausibilisierung und damit zur Prozessqualitätssicherung notwendig werden, lassen sich nur mit Zustimmung des Dienstleisters vornehmen, was zu einer gewissen Abhängigkeit gegenüber dem Service-Provider führt. Zusammenfassung und Ausblick Zusammenfassend lässt sich festhalten, dass endproduktspezifisch detailliert abzuwägen ist, ob ein Outsourcing den gewünschten Optimierungseffekt realisiert – speziell vor dem Hintergrund der erforderlichen Risikofrüherkennungsprozesse. Neben personalwirtschaftlichen Themen sind dabei auch die Abhängigkeit vom Service-Provider und die Möglichkeiten zur Kontrolle des Dienstleisters zu berücksichtigen. In der Praxis hat sich gezeigt, dass es sinnvoll ist, definierte Datenqualitätskontrollen und Teile des Berichtswesens nicht auszulagern. Anstelle der Prüfung und Plausibilisierung von Endprodukten ermöglichen eigene Datenqualitätsmaßnahmen und Berichterstattungen sowohl die Steuerung „inhouse“ als auch die Steuerung des Dienstleisters. Damit liegen effizientere Prozesse vor, und die Abhängigkeit vom Dienstleister wird deutlich reduziert. Diese Erfahrungen decken sich mit denen der Aufsichtspraxis. In dem von der Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) veröffentlichten Konsultationspapier zum Entwurf der MaRisk (in der Fassung vom 18. Februar 2016) werden die Anforderungen an Auslagerungslösungen und insbesondere an die Überwachung von ausgelagerten Aktivitäten und Prozessen durch das auslagernde Institut dahingehend konkretisiert. Für die zeitlich aufwändigen und komplexen Plausibilisierungen im Fall eines Outsourcings, die beim auslagernden Unternehmen anfallen, können marktgängige BI-Tools Abhilfe schaffen. Zudem bieten sie ausreichend Flexibilität in der effizienten Auswertung und ermöglichen effektive „Querprüfungen“ zwischen verschiedenen Reports. Ein umfassendes Verständnis des Datenhaushalts beim Dienstleister ist jedoch eine Grundvoraussetzung. Die Erfüllung der Anforderungen gemäß BCBS #239 [vgl. Golla, G./Hoppe, T./Pastwa, A. et al., 2014] beim Dienstleiter kann hierfür eine fundierte Basis bilden. Zur Überwachung können beim auslagernden Institut ein Chief Data und ein Process Officer etabliert werden (siehe auch Konsultationspapier zum Entwurf der MaRisk in der Fassung vom 18.02.2016). Hier liegt jedoch der Fokus weniger auf detaillierten Beschreibungen der einzelnen Systeme, sondern vielmehr auf dem Verständnis der Datenaggregation unter fachspezifischen und prozessualen Gesichtspunkten. In einem nächsten Artikel werden die Möglichkeiten zur Herstellung und Aufrechterhaltung von Datenqualität näher beschrieben. Hierbei wird untersucht, wie Datenqualität vor dem Hintergrund der MaRisk messbar gemacht und risikorelevante Daten im Zeitablauf zur Steuerung des Unternehmens eingesetzt werden können. Quellenverzeichnis und weiterführende Literatur Baseler Ausschuss für Bankenaufsicht (2013): Grundsätze für die effektive Aggregation von Risikodaten, Januar 2013. Baseler Ausschuss für Bankenaufsicht (2013b): Progress in adopting the principles for effective risk data aggregation and risk reporting, Dezember 2013. Baseler Ausschuss für Bankenaufsicht (2015): Progress in adopting the principles for effective risk data aggregation and risk reporting, Januar 2015. Golla, G. (2010): http://de.wikipedia.org/wiki/Offenlegung_(Marktdisziplin). Golla, G./Hoppe, T./Pastwa, A. et al. (2014): Risk Data Aggregation (RDA). Umsetzung auf Basis von Business Intelligence (BI), in: RISIKO MANAGER, Nr. 8 / 2014, S. 14-19. Golla, G./Hoppe, T./Pastwa, A. (2014b): Risk Data Aggregation (RDA). RDA-Umsetzung auf Basis von Business Intelligence (BI), in: BCBS 239. Regulatorische Anforderungen und effiziente Umsetzung, hrsg. von Wilhelm Niehoff / Stefan Hirschmann, Köln 2014, S. 29-41. Golla, G./Hoppe, T./Pastwa, A. (2014c): Umsetzung einer leistungsfähigen Reportingplattform und künftige Aufgaben für das Datenmanagement, in: RISIKO MANAGER, Nr. 25-26 / 2014, S. 35-38. Golla, G./Hoppe, T./Pastwa, A. (2015): Risk Data Aggregation (RDA) – Teil III: BCBS #239 – Datenqualitätssicherung und Frühwarnung, in: RISIKO MANAGER, Nr. 6 / 2015. S. 12-16. Golla, G./Pastwa, A./Rosenbauer, K. (2015): Risk Data Aggregation (RDA) – Teil IV: BCBS #239 – Umsetzung und Anwendung der Prinzipien 2015/2016, in: RISIKO MANAGER, Nr. 22 / 2015, S. 15-17. Autoren Dr. Guido Golla, Director, Deloitte & Touche GmbH Wirtschaftsprüfungsgesellschaft. Dr. Alexander Pastwa, Senior Manager, Deloitte & Touche GmbH Wirtschaftsprüfungsgesellschaft. Dr. Konrad Rosenbauer, Senior Manager, Erste Abwicklungsanstalt EAA.

RISIKO MANAGER

 

Copyright Risiko Manager © 2004-2017. All Rights Reserved.