Risikoreporting in Finanzinstituten: Anforderungen, Konzepte, Prototyping [1. Aufl.] 9783658284398, 9783658284404

Table of contents :
Front Matter ....Pages I-XV
Einführung in das Reporting von Risikodaten (Uwe Rudolf Fingerlos, Guido Golla, Alexander Pastwa, Peter Gluchowski, Roland Gabriel)....Pages 1-17
Technologische und konzeptionelle Ansätze zur Analyse und zum Reporting von Risikodaten in Kreditinstituten (Uwe Rudolf Fingerlos, Guido Golla, Alexander Pastwa, Peter Gluchowski, Roland Gabriel)....Pages 19-96
Prototypische Umsetzung einer BI-basierten Reporting-Anwendung und eines Prüfungsansatzes (Uwe Rudolf Fingerlos, Guido Golla, Alexander Pastwa, Peter Gluchowski, Roland Gabriel)....Pages 97-153
Detailliertes Fallbeispiel zur Kreditdatenanalyse auf Basis von RStudio (Uwe Rudolf Fingerlos, Guido Golla, Alexander Pastwa, Peter Gluchowski, Roland Gabriel)....Pages 155-383
Zusammenfassung und Ausblick (Uwe Rudolf Fingerlos, Guido Golla, Alexander Pastwa, Peter Gluchowski, Roland Gabriel)....Pages 385-386
Anhang (Uwe Rudolf Fingerlos, Guido Golla, Alexander Pastwa, Peter Gluchowski, Roland Gabriel)....Pages 387-401

Citation preview

Uwe Rudolf Fingerlos Guido Golla Alexander Pastwa Peter Gluchowski Roland Gabriel

Risikoreporting in Finanzinstituten Anforderungen, Konzepte, Prototyping

Risikoreporting in Finanzinstituten

Uwe Rudolf Fingerlos • Guido Golla Alexander Pastwa • Peter Gluchowski Roland Gabriel

Risikoreporting in Finanzinstituten Anforderungen, Konzepte, Prototyping

Uwe Rudolf Fingerlos Forschung und Entwicklung für die Risikomodellierung, Banco de Sabadell, S.A. Provinz Barcelona, Spanien

Guido Golla Risk Advisory, Deloitte GmbH Wirtschaftsprüfungsgesellschaft Köln, Deutschland

Alexander Pastwa Risk Advisory, Deloitte GmbH Wirtschaftsprüfungsgesellschaft Düsseldorf, Deutschland

Peter Gluchowski Lehrstuhl für Wirtschaftsinformatik Technische Universität Chemnitz Chemnitz, Deutschland

Roland Gabriel Institut für Unternehmensführung, RuhrUniversität Bochum Bochum, Deutschland

ISBN 978-3-658-28439-8    ISBN 978-3-658-28440-4  (eBook) https://doi.org/10.1007/978-3-658-28440-4 Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. Springer Gabler © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung, die nicht ausdrücklich vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen Zustimmung des Verlags. Das gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Die Wiedergabe von allgemein beschreibenden Bezeichnungen, Marken, Unternehmensnamen etc. in diesem Werk bedeutet nicht, dass diese frei durch jedermann benutzt werden dürfen. Die Berechtigung zur Benutzung unterliegt, auch ohne gesonderten Hinweis hierzu, den Regeln des Markenrechts. Die Rechte des jeweiligen Zeicheninhabers sind zu beachten. Der Verlag, die Autoren und die Herausgeber gehen davon aus, dass die Angaben und Informationen in diesem Werk zum Zeitpunkt der Veröffentlichung vollständig und korrekt sind. Weder der Verlag, noch die Autoren oder die Herausgeber übernehmen, ausdrücklich oder implizit, Gewähr für den Inhalt des Werkes, etwaige Fehler oder Äußerungen. Der Verlag bleibt im Hinblick auf geografische Zuordnungen und Gebietsbezeichnungen in veröffentlichten Karten und Institutionsadressen neutral. Springer Gabler ist ein Imprint der eingetragenen Gesellschaft Springer Fachmedien Wiesbaden GmbH und ist ein Teil von Springer Nature. Die Anschrift der Gesellschaft ist: Abraham-Lincoln-Str. 46, 65189 Wiesbaden, Germany

Vorwort

„Die globale Finanzkrise 2007/2008 traf viele Banken unvorbereitet“, lautete eine der vielen Schlagzeilen zur damaligen Situation in der Finanzwelt, die durch massive ökonomische Auswirkungen erschüttert wurde. Den Finanzinstituten war es nicht möglich, relevante Risikodaten in angemessener Zeit so zu aggregieren und zu analysieren, dass sie die Geschäftsprozesse mit ihren Risiken ordnungsgemäß hätten steuern können. Der Erfolg eines Unternehmens ist entscheidend von der Beherrschung der Risiken abhängig, die in vielfältiger Form und unterschiedlicher Stärke unerwartet auftreten und die Geschäftsprozesse stören und negativ beeinflussen können. Dies gilt vor allem für die Finanzprozesse, die durch weltweite Netze unterstützt und beschleunigt werden. Sehr schnell setzten sich Vertreter aus Wissenschaft und Praxis nach dem Schock mit der Analyse der Risiken und deren Bewältigung auseinander. Der Basler Ausschuss für Bankenaufsicht veröffentlichte 2013 eine finale Fassung der „Grundsätze für die effektive Aggregation von Risikodaten und die Risikoberichterstattung“ und legte damit den Grundstein für die Verschärfung der regulatorischen Anforderungen an Finanzinstitute. Risiken können sich im Zeitablauf verändern, sich gegenseitig verstärken und zu verheerenden Auswirkungen führen. Eine kontinuierliche Überwachung der Risiken ist deshalb ökonomisch sinnvoll und auch gesetzlich gefordert. Risikorelevante Daten stellen für Finanzinstitute wichtige unternehmerische Ressourcen dar, sie müssen zeitnah erfasst und systematisch ausgewertet werden. Ziel ist die Erstellung geeigneter Berichts- bzw. Reportinglösungen auf der Basis leistungsfähiger IT-Systeme. Voraussetzungen für ein erfolgreiches Arbeiten sind die Formulierung einer Risikopolitik und die Einrichtung eines Risikomanagements, das die relevanten Prozesse mitgestaltet und überwacht (Risikocontrolling). Big Data- und Analytics-Anwendungen stützen sich auf intelligente Softwaresysteme (Business Intelligence-Software), die mit ihren Methoden bzw. Algorithmen die Risikodaten erfassen, gruppieren bzw. aggregieren und auswerten. Das entstehende Risikoreporting bildet schließlich die Basis für Entscheidungen, sowohl im Bedarfsfall als auch bei strategischen und operativen Planungen. Das vorliegende Buch setzt sich mit dem Risikoreporting in Finanzinstituten auseinander. Ziel ist es, die Anforderungen hierzu, mögliche Konzepte und Technologien mit ihren Potenzialen auf der Grundlage von Best Practices vorzustellen und damit eine Hilfe zur V

VI

Vorwort

besseren Bewältigung der Probleme, die durch Risiken entstehen, zu leisten. Nach der Erklärung der Grundlagen werden tragfähige konzeptionelle Ansätze zur Analyse und zum Reporting von Risikodaten vorgestellt. Anschließend erfolgt die Präsentation prototypischer Umsetzungen einer BI-basierten Reporting-Anwendung sowie einer Anwendung zur Auditierung und Evaluierung von risikorelevanten Reporting-Systemen. Ein detailliertes Fallbeispiel zur Kreditdatenanalyse verschafft Einblicke in das anspruchsvolle Themenfeld der Auswertung von Risikodaten. Das hierfür verwendete Datenmaterial steht auf der Homepage des Verlages unter https://www.springer.com/de/book/9783658284398 (DOI: 10.1007/978-3-658-28440-4) gemeinsam mit den gezeigten Programmierbeispielen sowie einem Stichwortverzeichnis zum Download bereit. Am Buchprojekt haben fünf Autoren zusammengearbeitet, die sowohl durch ihre Projekte in der Praxis als auch durch ihre wissenschaftlichen Tätigkeiten an Hochschulen geeignetes Wissen und Erfahrungen über den interessanten und ökonomisch wichtigen Anwendungsbereich des Risikoreportings sammeln und nutzen konnten. Ein besonderer Dank für zahlreiche anregende Diskussionen und Hinweise geht an die Deloitte Wirtschaftsprüfungsgesellschaft, hier insbesondere an die Kolleginnen und Kollegen des Risk Advisory Teams aus Düsseldorf und Köln. Danken möchten wir auch Herrn Guido Notthoff vom Springer-Verlag für seine Unterstützung. November 2019 Düsseldorf

Die Autoren

Inhaltsverzeichnis

1 Einführung in das Reporting von Risikodaten . . . . . . . . . . . . . . . . . . . . . . . . . .   1 1.1 Allgemeine ökonomische und gesellschaftliche Entwicklungen��������������������   3 1.2 Aufsichtsrechtliche Vorgaben mit Fokus auf Risikodaten������������������������������   5 1.2.1 Basler Rahmenwerk ��������������������������������������������������������������������������   6 1.2.2 BCBS #239 ����������������������������������������������������������������������������������������   8 1.2.3 MaRisk AT 4.3.4 ��������������������������������������������������������������������������������  10 1.3 Risikomanagement������������������������������������������������������������������������������������������  12 1.3.1 Beschreibung und Notwendigkeit eines Risikomanagements������������  12 1.3.2 Vorgehensweise zum Aufbau und Einsatz eines Risikomanagements����������������������������������������������������������������������������  13 1.3.3 Ausprägungen des Reportings von Risikodaten ��������������������������������  16 Literatur ������������������������������������������������������������������������������������������������������������������  16 2 Technologische und konzeptionelle Ansätze zur Analyse und zum Reporting von Risikodaten in Kreditinstituten. . . . . . . . . . . . . . . . . . . . . . . . . .  19 2.1 Historische Herleitung������������������������������������������������������������������������������������  19 2.2 Data-Warehouse-basierte Reportingansätze ��������������������������������������������������  22 2.2.1 Data Warehouse als zentrale Speicherkomponente����������������������������  22 2.2.2 Data-Warehouse-Architekturvarianten ����������������������������������������������  24 2.2.2.1 Hub-and-Spoke-Architektur ������������������������������������������������  24 2.2.2.2 Data-Warehouse-Schichtenarchitektur ��������������������������������  26 2.2.3 Extraktion, Transformation und Laden von Daten ����������������������������  28 2.2.4 Berichtssysteme und -lösungen����������������������������������������������������������  32 2.2.4.1 Ad-hoc- vs. Standard-Reporting������������������������������������������  32 2.2.4.2 Dashboarding������������������������������������������������������������������������  35 2.2.4.3 Self Service BI����������������������������������������������������������������������  38 2.3 Big Data als Enabler für das Risikoreporting ������������������������������������������������  40 2.3.1 Begriffliche Einordnung����������������������������������������������������������������������  41 2.3.2 Big-Data-Architekturvarianten ����������������������������������������������������������  42

VII

VIII

Inhaltsverzeichnis

2.4 Business Analytics������������������������������������������������������������������������������������������  45 2.4.1 Begriffliche Einordnung����������������������������������������������������������������������  45 2.4.2 Cross-Industry Standard Process for Data Mining (CRISP-DM) als ausgewähltes Vorgehensmodell ����������������������������������������������������  50 2.4.2.1 Phase 1 – Untersuchung der Geschäftsziele (Business Unterstanding)������������������������������������������������������  52 2.4.2.2 Phase 2 – Datenuntersuchung (Data Understanding) ����������  53 2.4.2.3 Phase 3 – Datenaufbereitung (Data Preparation)������������������  54 2.4.2.4 Phase 4 – Modellierung (Modeling) ������������������������������������  56 2.4.2.5 Phase 5 – Evaluierung (Evaluation)��������������������������������������  59 2.4.2.6 Phase 6 – Bereitstellung (Deployment)��������������������������������  62 2.4.3 Weitere Vorgehensmodelle������������������������������������������������������������������  63 2.4.3.1 Sample, Explore, Modify, Model, Assess (SEMMA)����������  63 2.4.3.2 Microsoft Team Data Science Process (TDSP)��������������������  63 2.4.4 Ausgewählte Analyseverfahren����������������������������������������������������������  64 2.4.4.1 Clusterverfahren��������������������������������������������������������������������  65 2.4.4.2 Hauptkomponentenanalysen������������������������������������������������  66 2.4.4.3 Lineare Regressionsanalysen������������������������������������������������  67 2.4.4.4 Logistische Regressionsanalysen������������������������������������������  72 2.4.4.5 Entscheidungsbaumverfahren����������������������������������������������  80 2.4.4.6 Künstliche neuronale Netze��������������������������������������������������  82 2.5 Data Governance��������������������������������������������������������������������������������������������  84 2.5.1 Begriffliche Einordnung����������������������������������������������������������������������  84 2.5.2 Data-Governance-Framework������������������������������������������������������������  85 2.5.2.1 Strategie��������������������������������������������������������������������������������  86 2.5.2.2 Aufbauorganisation��������������������������������������������������������������  87 2.5.2.3 Richtlinien, Prozesse und Standards������������������������������������  89 2.5.2.4 Messung und Überwachung�������������������������������������������������  89 2.5.2.5 Technologie��������������������������������������������������������������������������  90 2.5.2.6 Kommunikation��������������������������������������������������������������������  90 Literatur ������������������������������������������������������������������������������������������������������������������  91 3 Prototypische Umsetzung einer BI-basierten Reporting-Anwendung und eines Prüfungsansatzes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  97 3.1 Risikofrüherkennung und automatisierte Risikoklassifizierung ��������������������  97 3.1.1 Ausgangspunkt und fachliche Zielsetzung ����������������������������������������  98 3.1.2 Exemplarische Datenlage bei internen Indikatoren in Finanzinstituten���������������������������������������������������������������������������������� 100 3.1.3 Modellerweiterung um externe (makroökonomische) Indikatoren������������������������������������������������������������������������������������������ 112 3.1.4 Konzeption und Prototyping Gesamtmodell�������������������������������������� 123 3.1.5 Skizze zur Datenablage���������������������������������������������������������������������� 130

Inhaltsverzeichnis

IX

3.1.6 Exemplarische Initialvalidierung des Gesamtmodells������������������������ 133 3.1.7 Desiderata ������������������������������������������������������������������������������������������ 137 3.2 Auditierung und Evaluierung von risikorelevanten Reporting-Anwendungen gemäß BCBS #239/MaRisk AT 4.3.4�������������������� 138 3.2.1 Prüfbereiche���������������������������������������������������������������������������������������� 139 3.2.1.1 Datenaggregation������������������������������������������������������������������ 139 3.2.1.2 Datenqualität������������������������������������������������������������������������ 141 3.2.1.3 Standard-Reporting�������������������������������������������������������������� 145 3.2.1.4 Ad-hoc-Reporting ���������������������������������������������������������������� 146 3.2.1.5 Unabhängige Überprüfbarkeit���������������������������������������������� 146 3.2.2 Prototypische Umsetzung ������������������������������������������������������������������ 147 3.2.2.1 Hauptmaske�������������������������������������������������������������������������� 148 3.2.2.2 Bearbeitung von Prüfgegenständen�������������������������������������� 149 3.2.2.3 Ergebnis der Prüfung������������������������������������������������������������ 150 3.2.3 Zusammenfassung������������������������������������������������������������������������������ 151 Literatur ������������������������������������������������������������������������������������������������������������������ 153 4 Detailliertes Fallbeispiel zur Kreditdatenanalyse auf Basis von RStudio. . . . . 155 4.1 Ausgangspunkt und fachliche Zielsetzung ���������������������������������������������������� 156 4.2 Untersuchung der Geschäftsziele (Business Understanding) ������������������������ 156 4.3 Datenuntersuchung (Data Understanding) und Datenaufbereitung (Data Preparation)������������������������������������������������������������������������������������������ 157 4.3.1 Skalenniveaus ������������������������������������������������������������������������������������ 158 4.3.2 Datenvorbereitung������������������������������������������������������������������������������ 160 4.3.3 Explorative Datenanalyse ������������������������������������������������������������������ 186 4.3.3.1 Kategorial skalierte Daten���������������������������������������������������� 186 4.3.3.2 Metrisch (kardinal) skalierte Daten�������������������������������������� 193 4.3.4 Skalentransformation�������������������������������������������������������������������������� 213 4.3.5 Hypothesentest ���������������������������������������������������������������������������������� 218 4.3.6 Normalisierung ���������������������������������������������������������������������������������� 225 4.3.6.1 Z-Standardisierung �������������������������������������������������������������� 225 4.3.6.2 Min-Max-Normalisierung���������������������������������������������������� 236 4.3.7 Datenpartitionierung (Sampling)�������������������������������������������������������� 238 4.4 Modellierung�������������������������������������������������������������������������������������������������� 241 4.4.1 Clusterverfahren���������������������������������������������������������������������������������� 242 4.4.2 Hauptkomponentenanalysen �������������������������������������������������������������� 249 4.4.3 Lineare Regressionsanalysen�������������������������������������������������������������� 257 4.4.4 Logistische Regressionsanalysen�������������������������������������������������������� 269 4.4.5 Entscheidungsbaumverfahren ������������������������������������������������������������ 320 4.4.6 Künstliche neuronale Netze���������������������������������������������������������������� 342 4.5 Evaluierung (Evaluation) und Bereitstellung (Deployment)�������������������������� 371 4.5.1 Clusterverfahren �������������������������������������������������������������������������������� 371

X

Inhaltsverzeichnis

4.5.2 Hauptkomponentenanalysen �������������������������������������������������������������� 372 4.5.3 Lineare Regressionsanalysen�������������������������������������������������������������� 372 4.5.4 Logistische Regressionsanalysen�������������������������������������������������������� 373 4.5.5 Entscheidungsbaumverfahren ������������������������������������������������������������ 374 4.5.6 Künstliche neuronale Netze���������������������������������������������������������������� 375 Literatur ������������������������������������������������������������������������������������������������������������������ 378 5 Zusammenfassung und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385 6 Anhang. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387 6.1 Kurzeinführung in RStudio���������������������������������������������������������������������������� 387 6.2 Programmversionen���������������������������������������������������������������������������������������� 397 6.3 Programmpakete �������������������������������������������������������������������������������������������� 397 Literatur ������������������������������������������������������������������������������������������������������������������ 401

Über die Autoren

Uwe Rudolf Fingerlos  Forschung und Entwicklung für die Risikomodellierung, Banco de Sabadell, S.A., Provinz Barcelona, Spanien, [email protected] Guido  Golla  Risk Advisory, Deloitte GmbH Wirtschaftsprüfungsgesellschaft, Köln, Deutschland, [email protected] Alexander  Pastwa  Risk Advisory, Deloitte GmbH Wirtschaftsprüfungsgesellschaft, Düsseldorf, Deutschland, [email protected] Peter  Gluchowski  Lehrstuhl für Wirtschaftsinformatik, Technische Universität Chemnitz, Deutschland, [email protected] Roland Gabriel  Institut für Unternehmensführung, Ruhr-Universität Bochum, Bochum, Deutschland, [email protected]

XI

Abkürzungen

AIC AT AUC, AUROC BaFin BCBS BI BPM BTO

Akaike Information Criterion Allgemeiner Teil in den MaRisk Area Under Receiver Operating Characteristic Curve (→ROC) Bundesanstalt für Finanzdienstleistungsaufsicht Basel Committee on Banking Supervision Business Intelligence Business Performance Management Besonderer Teil Organisation in den Mindestanforderungen an das Risikomanagement (MaRisk) CART Classification and Regression Trees CHAID Chi-Squared Automatic Interaction Detection CoRep Common Solvency Ratio Reporting CPM Corporate Performance Management CRAN Comprehensive R Archive Network CRISP-DM Cross-Industry Standard Process for Data Mining d Determinationskoeffizient DG Data Governance DGO Data Governance Office DM Deutsche Mark; Data Mining DQ Datenqualität DR Default Rate DS Data Science DSS Decision Support Systems DWH Data Warehouse EIS Executive Information System ETL Extrahieren, Transformieren, Laden EUR Euro EUS Entscheidungsunterstützungssysteme EWT Early-Warning-Tool

XIII

XIV

FinRep FSI FWE

Abkürzungen

Financial Reporting Financial Services Industry Frühwarneigenschaft eines Risikofaktors oder eines risikorelevanten Indikators GE Geldeinheiten GLM Generalisierte Lineare Modelle (Generalized Linear Models) GRP Gewichtete Risikopunkte HK Hauptkomponente IoT Internet of Things (Internet der Dinge) IQR Interquartile Range (Interquartilsabstand) IRB Internal Ratings-Based Approach IT Informationstechnologie(n) KDD Knowledge Discovery in Databases KNN Künstliche neuronale Netze KonTraG Gesetz zur Kontrolle und Transparenz im Unternehmensbereich KQ Kleinstquadratemethode (→OLS) KWG Kreditwesengesetz LM Lineares Modell (Linear Model) LR Likelihood Ratio MaRisk Mindestanforderungen an das Risikomanagement MEM Marginal Effects at Means (Marginale Effekte am Mittelwert evaluiert) MIS Managementinformationssysteme MLP Multi-Layer-Perceptron (→SLP) MSE Mean Squared Error (Mittlere quadratische Abweichung) n/a Nicht anwendbar (not applicable) OG Obergrenze eines Konfidenzintervalls (→UG) OLAP On-Line Analytical Processing OLS Ordinary Least Squares (Kleinstquadratemethode, →KQ) PD Probability of Default (Einjahresausfallwahrscheinlichkeit) RDA Risk Data Aggregation (Risikodatenaggregation) RFID Radio-frequency Identification RMD Residual Mean Deviance (Residuale Mittlere Devianz) ROC Receiver Operating Characteristic (→AUC) RP Risikopunkte (ungewichtet) 0 bis 100 RSS Residual Sum of Squares SEMMA Sample, Explore, Modify, Model, Assess SLP Single Layer Perceptron (→MLP) SPOT Single Point of Truth or Trust SolvV Solvabilitätsverordnung SQL Structured Query Language

Abkürzungen

TDSP Team Data Science-Prozess TSS Total Sum of Squares Tz. Textziffer UG Untergrenze eines Konfidenzintervalls (→OG) URL Uniform Resource Locator VIF Variance Inflation Factor WSS Within Sum of Squares XLS Excel Spreadsheet

XV

1

Einführung in das Reporting von Risikodaten

Die Bedeutung von Daten als wichtige unternehmerische Ressource bekommt mit Schlagworten wie „Big Data“, „Industrie 4.0“ oder „Digitale Transformation“ neuen Auftrieb. Insbesondere durch die Digitalisierung der Industrie steigt die Menge an jährlich erzeugten Daten in Unternehmen ständig weiter an (vgl. Voigt und Seidel 2016). Vor allem in Finanzinstituten (im Folgenden auch als Institute bezeichnet) mit einer über Jahrzehnten gewachsenen und komplexen Systemlandschaft ist es oft nicht ersichtlich, wo und wie Daten gespeichert worden sind und wie im Anschluss mit den Daten umgegangen wird. Hinzu kommt, dass nicht nur die Datenmenge steigt, sondern auch die Anzahl der Datenquellen zunimmt. Als problematisch erweist sich in diesem Kontext, dass diese Daten unterschiedliche Strukturierungsgrade haben und die Datenquellen somit polystrukturiert vorliegen. Semistrukturierte oder unstrukturierte Datenbestände sind beispielsweise Social-Media- oder Geo-Daten, die stetig an Bedeutung gewinnen (vgl. Kaiser und Tetzner 2017). Gleichzeitig stehen Institute (nicht zuletzt mit Blick auf die Zunahme aufsichtsrechtlicher Anforderungen) vor der Herausforderung, Risiken, denen sie ausgesetzt sind, durch den Aufbau und die Weiterentwicklung der erforderlichen ablauf- und aufbauorganisatoischen Strukturen sowie den Einsatz von Informationstechnologien (IT) zu reduzieren. Risiken treten in vielfältiger Form auf und können zu großen Gefahren und negativen Auswirkungen führen, die ein Institut gegebenenfalls sehr belasten, z. B. durch hohe finanzielle Verluste oder sogar durch Insolvenzen. Ein bekanntes Beispiel ist die globale Finanzkrise, die seit 2007 nationale und internationale Finanzinstitute mit schwerwiegenden Folgen getroffen hat. Diese Krise führte allerdings auch zu neuen Erkenntnissen über die Auswirkungen von und den Umgang mit Risiken. Als eine Ursache der Krise wurde der nicht ausreichende und teilweise inkompetente Einsatz der vorhandenen IT ausgemacht, vor allem im Rahmen der Nutzung der entwickelten Berichtssysteme sowie der gespeicherten

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 U. R. Fingerlos et al., Risikoreporting in Finanzinstituten, https://doi.org/10.1007/978-3-658-28440-4_1

1

2

1  Einführung in das Reporting von Risikodaten

Daten. Als großes Problemfeld erwiesen sich weiterhin die nur unzureichend vorhandenen Möglichkeiten zur zeitnahen Auswertung und Analyse von risikorelevanten Daten. Die vielfältigen negativen Auswirkungen führten zu Diskussionen unter Fachleuten und schließlich zur Etablierung neuer regulatorischer Anforderungen an Finanzinstitute. So forderte der Basler Ausschuss für Bankenaufsicht eine effektive Aggregation von Risikodaten und eine aussagekräftige Risikoberichterstattung und stellte im Jahr 2013 Grundsätze und Richtlinien auf, um Risiken zu erkennen und zu steuern. Weiterhin forderte der Ausschuss ein solides Risikomanagementsystem mit einer transparenten Berichterstattung als eine notwendige Voraussetzung für eine erfolgreiche Risikominderung (vgl. Basler Ausschuss für Bankenaufsicht 2013). Im Mittelpunkt eines erfolgreichen Risikomanagements stehen ein Risikoreporting und eine Aggregation der Risikodaten mit der Feststellung des Gesamtrisikos, das aus einer Analyse der Einzelrisiken abgeleitet wird. Dabei sind auch die Abhängigkeiten der Einzelrisiken und mögliche Kombinationseffekte zu beachten und zu bewerten (vgl. Gabler Wirtschaftslexikon 2019). Das Ziel des vorliegenden Buches ist es, das Risikoreporting in Finanzinstituten mit seinen Anforderungen, Konzepten, Technologien und Potenzialen auf der Grundlage von Best Practices vorzustellen. Der in diesem Buch verwendete Reporting-Begriff folgt einem weiten Verständnis. Unter Reporting wird jegliche Form der Datennutzung verstanden, die z. B. durch den Einsatz von Berichtssystemen, Dashboards sowie Data-Mining-Werkzeugen unterstützt werden kann. Reporting umfasst zum einen die systemgestützte Bereitstellung von Informationen und Informationsobjekten in Form eines Standard- und Ad-hoc-Reporting, zum andern die fortgeschrittene Analyse von Datenbeständen zur Erkennung von Datenmustern unter Verwendung geeigneter Verfahren und Algorithmen (vgl. hierzu auch Abschn. 2.4). Nach der Einführung in das Themenfeld Risikoreporting behandelt Kap. 2 etablierte sowie aktuelle Konzepte und Technologien zum Reporting von Risikodaten in Finanzin­ stituten. Kap. 3 präsentiert einen ausgewählten Anwendungsfall des Business-Intelligence (BI)-basierten Reportings in Finanzinstituten zur Risikofrüherkennung und automatischen Risikoklassifizierung. Mit Blick auf aktuelle aufsichtsrechtliche Anforderungen widmet sich dieses Kapitel darüber hinaus der Prüfung von Risikoreporting-Anwendungen. Als weiterer Anwendungsfall wird die prototyische Umsetzung einer Anwendung zur Feststellung der Compliance gemäß BCBS #239 und MaRisk AT 4.3.4 vorgestellt. Die Abkürzung AT steht für den allgemeinen Teil in den MaRisk, der grundsätzliche Prinzipien für die Ausgestaltung des Risikomanagements (z. B. Anwendungsbereich, Geschäftsleitung, Organisation, Dokumentation) umfasst. Gegenstand von Kap.  4 ist ein detailliertes Fallbeispiel zur Kreditdatenanalyse einschließlich einer exemplarischen Implementierung in RStudio. Nach der Darstellung allgemeiner ökonomischer und gesellschaftlicher Entwicklungen in Abschn. 1.1 werden in Abschn. 1.2 aktuelle aufsichtsrechtliche Vorgaben erörtert, die in besonderer Weise den Umgang mit Risikodaten in den Vordergrund stellen. Abschn.  1.3 greift das Themenfeld Risikomanagement auf, das eine breite Perspektive auf den ­Umgang mit Risikodaten einnimmt. Kap 5. schließt mit einer Zusammenfassung und einem Ausblick.

1.1  Allgemeine ökonomische und gesellschaftliche Entwicklungen

1.1

3

 llgemeine ökonomische und gesellschaftliche A Entwicklungen

Das heutige ökonomische und gesellschaftliche Leben ist einem stetigen Wandel unterworfen. Die damit einhergehenden Veränderungen weisen unmittelbare Einflüsse auf die Rahmenbedingungen auf, mit denen sich Institute konfrontiert sehen und finden nicht nur auf einer ökonomischen Ebene statt, sondern auch im persönlichen Umfeld der Mitarbeiter sowie bei den regulatorischen Vorgaben und den nutzbaren und genutzten Technologien. Spätestens seit dem viel beachteten Werk „Megatrends“ von John Naisbitt (vgl. Naisbitt 1982) wird das Thema auch im deutschsprachigen Raum intensiv verfolgt. Zahlreiche, teils selbsternannte Trendforscher versuchen, die relevanten Strömungen zu identifizieren und zu strukturieren (abrufbar z. B. unter www.zukunftsinstitut.de, www.z-punkt.de und www.ami.com). Abb. 1.1 strukturiert aktuelle ökonomische und gesellschaftliche Mega­ trends, mit denen sich Unternehmen im Allgemeinen, aber auch Finanzinstitute im Besonderen, heute konfrontiert sehen.

Geschäftlich

Technisch

• Wettbewerb

• Soziale Netze

• Kostendruck • Komplexität

• Sensorik • Ubiquität

• Dynamik

• Miniaturisierung

Unternehmensrelevante Umfeldfaktoren Persönlich • Mobilität

• Zeitdruck • Mündigkeit

Regulatorisch • Aufsicht • Governance • Auditing

• Anspruch

Abb. 1.1  Megatrends als unternehmensrelevante Umfeldfaktoren (Quelle: eigene Darstellung)

4

1  Einführung in das Reporting von Risikodaten

Geschäftliche Umfeldfaktoren Unter geschäftliche Einflussfaktoren fallen äußere Einflüsse wie Wettbewerb, Kostendruck, Komplexität und Dynamik. Wettbewerb findet zunehmend auf globalen Märkten statt, zumal der Prozentsatz der ökonomisch Handelnden, die von Im- und Exporten sowohl von Produkten als auch Dienstleistungen abhängen, stetig ansteigt. Globale Kommunikations- und Informationssysteme erschließen dabei neue Potenziale, verschärfen aber auch durch die Schaffung von Markttransparenz für alle Akteure den Konkurrenzkampf. Weltweit verfügbare Informationen zu Preis und Qualität von Produkten in Verbindung mit Gewinnerwartungen der Anteilseigner führen zudem zu einem erhöhten Kostendruck. Unternehmen versuchen dem beispielsweise zu begegnen, indem sie kostengünstigere Lösungen für Geschäftsfunktionen einzelner Bereiche im Ausland suchen. Nicht zuletzt die zu beobachtenden ausgeprägten Verflechtungen zwischen Marktteilnehmern (z. B. in großen Supply Chains) münden in Verbindung mit den fast unüberschaubaren Strukturen großer Konzerne in einer immer höheren Komplexität, d. h. die Anzahl und die Zusammenhänge geschäftsrelevanter Einheiten weisen eine zunehmend stärkere Verzahnung in Breite und Tiefe auf. Die hohe Dynamik auf Märkten im Sinne der Veränderungsfrequenz bedingt daneben eine geringe Reaktionszeit, die Unternehmen zur Anpassung an geänderte Rahmenbedingungen zur Verfügung steht, was vor allem im Controlling eine zunehmend kürzere Taktung von Datenerhebung, Analyse und Entscheidungsfindung zur Folge hat. Persönliche Umfeldfaktoren Unter die persönlichen Umfeldfaktoren fallen Mobilität, Zeitdruck, (IT-)Mündigkeit und Anspruch. Zunächst induzieren neue Technologien eine bislang unbekannte Dimension von Mobilität im privaten, aber auch geschäftlichen Bereich. Insbesondere eröffnen aktuelle IT-Infrastrukturen jederzeitige Zugriffe auf beliebige Informationen an fast jedem Ort der Welt und in Verbindung damit auch die flächendeckende Option zur Kommunikation. Wie in kaum einer Generation zuvor leidet der moderne Mensch heute unter einem enormen Zeitdruck, nicht nur im geschäftlichen, sondern auch im privaten Bereich, auch weil insbesondere junge Menschen sich heute genötigt fühlen, schnell alle offenen Kommunikationskanäle zu bedienen. Auf Unternehmensebene lässt sich der Zeitdruck aus der gestiegenen Dynamik und auch dem fortwährenden Kostendruck in Verbindung mit Einsparungen ableiten. Die vor einigen Jahren geforderte Entwicklung hin zu einem mündigen Bürger ist heute in weiten Teilen der Gesellschaft Realität geworden, indem mehr Entscheidungen im privaten Bereich eigenverantwortlich getroffen werden. Dies resultiert nicht zuletzt aus einer erheblich verbesserten Informationsversorgung durch das Internet, das für fast jeden thematischen Bereich ein breites Angebot zur Verfügung stellt. In den Unternehmen zeigt sich die Mündigkeit insbesondere durch das Auftreten der Mitarbeiter in den Fachabteilungen gegenüber der IT, die sich mit zunehmend dezentraler Kompetenz in technologischen Fragestellungen konfrontiert sieht. Als letzter Punkt auf der persönlichen Ebene sei der zunehmende Anspruch an die Leistungsfähigkeit von Produkten und die Qualität von Dienstleistungen, aber auch an das eigene Handeln aufgeführt, der sich im unternehmerischen Kontext durch verstärkten Hang zur Perfektion zeigt, beispielsweise bei angefertigten Präsentationen, Schriftstücken und Projektergebnissen.

1.2  Aufsichtsrechtliche Vorgaben mit Fokus auf Risikodaten

5

Technische Trends Zu den wesentlichen technischen Trends gehören soziale Netzwerke, Sensorik, Ubiquität und Miniaturisierung. Der Siegeszug sozialer Netzwerke und die damit verbundene Veränderung im Austausch von Informationen zwischen Menschen erfolgten in den letzten Jahren mit atemberaubender Geschwindigkeit. Für den unternehmerischen Kontext relevant sind insbesondere die Potenziale, die sich aus den Meinungsbildungsprozessen im Netz ergeben sowie aus der frühzeitigen Erkennbarkeit von Entwicklungen. Als weiterer, von der breiten Öffentlichkeit fast unbemerkter Trend gilt die zunehmende Sensorik, die dazu führt, dass beliebige Alltagsgegenstände, aber auch Produktionsmittel in Unternehmen zunehmend mit Chips ausgestattet sind, die vielfältige Informationen über den zugehörigen Gegenstand sammeln und weitergeben können. Schließlich führt dies zu einer Allgegenwärtigkeit (Ubiquität) der Technik in allen Lebensbereichen und zwar nicht nur im geschäftlichen, sondern auch im privaten Bereich. Ermöglicht wird dies auch durch eine immer weitere Miniaturisierung von technischen Komponenten, die teilweise nur noch unter einem Mikroskop betrachtet werden können und sich daher fast überall verbauen lassen. Regulatorische Einflussfaktoren Als regulatorische Umfeldfaktoren lassen sich Aufsicht, Auditing, Governance und Gesetzesvorschriften sowohl im Inland als auch im Ausland anführen, die deutsche Firmen und/ oder deren Tochtergesellschaften tangieren, wie beispielsweise die Grundsätze für die effektive Aggregation von Risikodaten und die Risikoberichterstattung (BCBS #239), die Mindestanforderungen an das Risikomanagement (MaRisk) oder das Basler Rahmenwerk. Diese Faktoren werden in Abschn. 1.2 vertieft aufgegriffen und diskutiert.

1.2

Aufsichtsrechtliche Vorgaben mit Fokus auf Risikodaten

Als Teil der in Abschn. 1.1 thematisierten allgemeinen Entwicklungen spielen zunehmend regulatorische Umfeldfaktoren eine gewichtige Rolle. Dabei erlangt die Qualität von Risikodaten (als zentrales Asset der Institute) im Kontext der Risikodatenaggregation eine wesentliche Bedeutung für den effektiven Steuerungsprozess. Im Hinblick auf die Kontrollfunktion von Aufsichtsgremien haben die Erfahrungen in der Vergangenheit gezeigt, dass Handlungsbedarf durch den Gesetzgeber besteht. Das am 27. April 1998 erlassene Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG) erweitert die Aufsicht vor allem durch die Haftung von Vorständen, Aufsichtsräten sowie Wirtschaftsprüfern und schreibt verbindlich die Einführung eines Früh­ erkennungssystems für Risiken in Unternehmen vor. Überdies wurden (gültig ab 2007) neue Eigenkapitalvorschriften für Kredit- und Finanzdienstleistungsinstitute (BASEL II, ab 2014 Basel III) erlassen. Im Jahr 2009 erfolgte zudem mit der Verabschiedung der Richtlinie 2009/138/EG (Solvabilität-II-Richtlinie) eine grundlegende Reform des europäischen Versicherungsaufsichtsrechts, die zum 1. Januar 2016 vollständig in Kraft getreten ist. Solvabilität II (auch Solvency II genannt) zielt mit Hilfe eines Dreisäulenansatzes auf die Schaffung einer risikobasierten Eigenmittelausstattung von Versicherungsunter-

6

1  Einführung in das Reporting von Risikodaten

nehmen. Die erste Säule regelt die zu erfüllenden Eigenmittelanforderungen, die Berechnung von Rückstellungen sowie die Kontrolle der entsprechenden Berechnungsansätze. Die zweite Säule widmet sich dem aufsichtsrechtlichen Überprüfungsverfahren (Supervisory Review) und der Geschäftsorganisation (Governance). In der dritten Säule thematisiert die Solvabilität-II-Richtlinie Marktdisziplin, Transparenz sowie Veröffentlichungsund Meldepflichten. Insgesamt zielen die Regelungen nicht nur auf eine Reduktion des Insolvenzrisikos der Versicherer aufgrund einer verbesserten Eigenmittelausstattung ab, sondern wollen auch auf eine Harmonisierung des Aufsichtsrechtes auf europäischer Ebene erreichen. Erste Auswertungen zeigen, dass sich im Durchschnitt die Eigenmittel­ ausstattung der Versicherer tatsächlich positiv zu verändern scheint (vgl. Bundesanstalt für Finanzdienstleistungsaufsicht 2016, Loskamp und Uzelac 2019, S. 18 ff.). Der Sarbanes-­Oxley-­Act (SOX) von 2002 (für ausländische Gesellschaften gültig mit Jahresabschlüssen ab Ende 2006) betrifft Unternehmen mit US-Tochtergesellschaften, deren Wertpapiere dort börslich, außerbörslich (bei Wertpapieren mit Eigenkapitalcharakter) oder öffentlich gehandelt werden. Die Richtlinien zielen auf eine verbesserte Verlässlichkeit von öffentlichen Unternehmensdaten ab. Rechtskonflikte bestehen insofern, als dass die US-­Vorschriften mit deutschem Recht nicht immer vereinbar sind. Unter Governance lässt sich die Gesamtheit der Richtlinien und Grundsätze fassen, die einer Organisationseinheit durch eine übergeordnete Instanz vorgegeben sind. Auf Unternehmensebene erfolgen die Vorgaben durch den Gesetzgeber und Eigentümer (Corporate Governance), für einzelne Unternehmensbereiche dagegen durch die Unternehmens- oder Bereichsleitung (z. B. IT-Governance), wodurch der Handlungsspielraum für die jeweilige Organisationseinheit bestimmt wird. Unter Audit wird allgemein die interne Überprüfung von Unternehmensprozessen im Hinblick auf vorgegebene Richtlinien verstanden, die beispielsweise aus Governance-Vorgaben resultieren. Mit MaRisk AT 4.3.4 und BCBS #239 stellt die Bankenaufsicht zur Stärkung des Risikomanagements regulatorische Anforderungen an die Risikodatenaggregation und Risikoberichterstattung von global systemrelevanten Instituten (Global Systemically Impor­ tant Banks, G-SIBs) und national systemrelevanten Instituten (Domestic Systemically Important Banks, D-SIBs). Die Regularien formulieren Maßnahmen zur Erkennung, Beurteilung, Überwachung und Kommunikation von Risiken, ferner Anforderungen an die Aufbau- und Ablauforganisation sowie IT-Unterstützung der Institute. Aus der Vielzahl an regulatorischen Anforderungen, die sich mit dem Reporting von Risikodaten beschäftigen, fokussieren die folgenden Abschnitte (vor dem Hintergrund ihrer Aktualität) auf BCBS #239, MaRisk AT 4.3.4 sowie das Basler Rahmenwerk.

1.2.1 Basler Rahmenwerk Das Basler Rahmenwerk steht für alle gültigen Regelegungen des Basler Ausschusses für Bankenaufsicht zur strengeren Regulierung von Banken. Mit Basel III liegt das jüngste Reformpaket vor. Wie die vorausgehenden Regulierungsrahmen von Basel I und Basel II

1.2  Aufsichtsrechtliche Vorgaben mit Fokus auf Risikodaten

7

zielen die Regelungen von Basel III darauf ab, die Risiken von Bankenkrisen sowie von insolventen Banken zu reduzieren und damit zu einer größeren Stabilität des global vernetzten Bankensystems beizutragen. Auslöser für die Reform der vorausgehenden Basel II-Regelungen waren identifizierten Schwächen der bisherigen Bankenregulierung, die in die Finanzkrise ab 2007 mündeten. Zielsetzung des Basel III-Reformpakets war, „mit strengeren Regeln für Eigenkapital und Liquidität die Resilienz des Bankensektors in Stresssituationen zu erhöhen und so die Gefahr zu verringern, dass sich Probleme im Finanzsektor auf die Realwirtschaft auswirken. Zudem sollen das Risikomanagement sowie die Führung der Banken verbessert und die Transparenz im Bankensektor erhöht werden“ (Deutsche Bundesbank (2019). Nach ihrer erstmaligen Veröffentlichung im Jahr 2010 sind die Basel III-Vorschriften im Jahr 2013 als neue Eigenkapitalrichtlinie in geltendes Recht der EU übergegangen (Richtlinie 2013/36/EU über den Zugang zur Tätigkeit von Kreditinstituten und die Beaufsichtigung von Kreditinstitutenund Wertpapierfirmen). Nach Inkrafttreten der Basel II-Richtlinien in 2007 sowie der gemäß Säule III des Basler Rahmenwerks obligatorischen Offenlegungspflichten (vgl. Basel Committee on Banking Supervision 2006, Tz. 808 ff.) ist dem marktorientierten Risikoreporting und der strukturierten regelmäßigen Offenlegung von Risikoaktiva gegenüber der Bankenaufsicht und den Marktteilnehmern eine zentrale Bedeutung bei der solvabilitätskonformen Ausgestaltung bankinterner Reportingprozesse sowie der zugehörigen technischen Strukturen und organisatorischen Verantwortlichkeiten beizumessen. Zur technischen Umsetzung eines Basel II-konformen Reportingsystems bietet sich der Einsatz von BI-Lösungen (BI) an. In Hinblick auf die aus dem Basler Rahmenwerk ableitbaren Anforderungen an aufsichtlich valide IT-Systeme (vgl. exemplarisch die Ausführungen in Basel Committee on Banking Supervision 2006, Tz. 429, 529 f., 673, 730, 743) ist konzeptionell zu berücksichtigen, dass die folgenden technischen und organisatorischen Funktionsbausteine Grund­ axiome einer standardisierten Reportinglösung darstellen: • Persistente Ablage und Historisierung der Basel II-relevanten Parameter auf Grundlage einer relationalen Datenbanklösung. • Vorkonfigurierte Berichtsobjekte für eine regelmäßige, mindestens jährliche Erstellung von Standardberichten (Vorgaben gemäß Offenlegungsanforderungen aus den §§ 319 ff. der Solvabilitätsverordnung [SolvV]). • Durchführung von Ad-hoc-Abfragen bzw. Risikoanalysen in verschiedenen Dimensionen und Hierarchien (Drill-Down und Drill-Across bis auf Transaktionsebene, soweit aufgrund der vorliegenden Datenqualität darstellbar). • Standardisierte Rollen- und Sicherheitsmechanismen zur Berichtpersonalisierung und organisationsadäquaten Informationsverteilung. • Systemseitige Unterstützung der Offenlegungspflichten durch integrative Web-­ Kompatibilität und Kompatibilität mit banküblichen Betriebssystemen und Standardprodukten (z. B. Microsoft Office).

8

1  Einführung in das Reporting von Risikodaten

Die SolvV ist eine Verordnung über die angemessene Eigenmittelausstattung von Instituten, Institutsgruppen und Finanzholding-Gruppen) vom 14. Dezember 2006, BGBl. I S. 2926. Die letzte Änderung ist am 28. Februar 2019 in Kraft getreten.

1.2.2 BCBS #239 Nach Ansicht des Basler Ausschusses für Bankenaufsicht besteht eine der wichtigsten Lehren der Finanzkrise (2007) in der Erkenntnis, dass die Reporting-Architekturen der meisten Institute für eine umfassende und krisenkonforme Steuerung finanzieller Risiken nicht geeignet gewesen seien. Zahlreiche Institute seien mangels geeigneter Berichtskapazitäten und Ad-hoc-Analysemöglichkeiten nicht in der Lage gewesen, Risikopositionen zeitnah zu aggregieren und Konzentrationen auf Konzernebene sowie über Geschäftsfelder und Konzerngesellschaften hinweg präzise zu identifizieren. „Aufgrund unzureichender Risikodaten-Aggregationskapazitäten und Verfahren zur Risikoberichterstattung konnten manche Banken ihre Risiken nicht ordnungsgemäß steuern – mit schwerwiegenden Folgen für die Banken selbst und für die Stabilität des gesamten Finanzsystems“, heißt es unter Punkt 1 des vom Basler Ausschuss im Januar 2013 veröffentlichten Dokuments BCBS #239 mit dem Titel „Grundsätze für die effektive Aggregation von Risikodaten und die Risikoberichterstattung“ (Basler Ausschuss für Bankenaufsicht 2013, S. 1). In BCBS #239 hat der Basler Ausschuss 14 Grundsätze bzw. Prinzipien formuliert, die das Fundament für die automatisierte Erstellung von Berichten zur Risiko- und Ertragslage von Instituten bilden sollen. Die Grundsätze geben vor, wie die Systemarchitektur, die Datenaggregation, das Reporting sowie aufsichtliche Maßnahmen ausgestaltet sein sollen. Dabei gilt unter anderem, dass die Institute alle Grundsätze der Aggregation von Risikodaten und der Risikoberichterstattung gleichzeitig erfüllen müssen; Kompromisse zwischen den Grundsätzen sind grundsätzlich nicht erlaubt. Die in BCBS #239 genannten Prinzipien lassen sich vier Gruppen zuordnen. Zur ersten Kategorie „Unternehmensführung  – Infrastruktur“ gehören die Prinzipien „Governance“ sowie „Datenarchitektur und Infrastruktur“. In die zweite Kategorie „Risikodaten-­ ­ Aggregationskapazitäten“ lassen sich die Grundsätze „Genauigkeit und Integrität“, „Vollständigkeit“, „Aktualität“ und „Anpassungsfähigkeit“ der Risikodaten einordnen. Die dritte Kategorie „Fähigkeit zur Risikoberichterstattung“ umfasst die Grundsätze „Genauigkeit der Reports“, „Abbildung aller wesentlichen Risikobereiche“, „Klarheit und Nutzen der Berichte“, „Häufigkeit der Berichterstellung“ und „Verbreitung der Reports“. Die vierte Kategorie „Aufsichtliche Maßnahmen“ bezieht sich auf Instrumente, welche den Aufsichtsin­ stanzen zur Verfügung stehen müssen. Diese Kategorie beinhaltet die Prinzipien „Überprüfung der Einhaltung der Grundsätze“, „Einsatz von Instrumenten und Ressourcen zur effektiven und zeitnahen Korrektur von Mängeln einer Bank“ sowie „grenzüberschreitende Zusammenarbeit der Aufsichtsinstanzen mit den Behörden anderer Länder“. Berichtseitig darf nur in begründeten Ausnahmefällen auf Informationen verzichtet werden, und zwar nur dann, wenn die Entscheidungsprozesse einer Bank dadurch nicht negativ beeinflusst werden. Auf

1.2  Aufsichtsrechtliche Vorgaben mit Fokus auf Risikodaten

9

dieser Basis soll ein zeitnahes, flexibles und qualitätsgesichertes Standard- und Ad-hoc-Berichtswesen der Institute im Sinne einer klassischen Business Intelligence-Lösung (BI-Lösung) ermöglicht werden. Die Prinzipien zielen damit weniger auf die fachlichen oder risikomodelltheoretischen Inhalte der von den Instituten bereitzustellenden Berichtkapazitäten ab, als vielmehr auf die technische Dimension bei der Berichterstellung. Institute aller Größenordnungen (global und national systemrelevante Institute im Besonderen) sollen über die Einhaltung der Prinzipien in die Lage versetzt werden, sich und der Aufsicht kurzfristig auf „Knopfdruck“ einen umfassenden und vollständigen Überblick ihrer Risikosituation zu verschaffen. Nach dem Proportionalitätsprinzip sind ebenfalls kleinere Institute von den Vorgaben betroffen. Die aufsichtlichen Prinzipien sollen dazu beitragen, die Reporting-Infrastruktur im Unternehmen zu novellieren und eine ebenso performante wie ressourcenschonende Informationsbereitstellung und Entscheidungsfindung zu gewährleisten. Der Einsatz einer alle Grundsätze erfüllenden Reportinglösung soll dazu dienen, das Risiko von Fehlentscheidungen und damit Verlustrisiken zu minimieren. Eine rechtliche Scharfstellung der Prinzipien ist zum 1. Januar 2014 erfolgt. Einen wichtigen Indikator zur Umsetzungsreife von Risk Data Aggregation (RDA) lieferte das Ende 2013 publizierte und mittlerweile mehrfach aktualisierte Dokument BCBS #268 („Progress in adopting the principles for effective risk data aggregation and risk reporting“) (vgl. Basel Committee on Banking Supervision 2013; die letzte Aktualisierung [Stand: September 2019] erfolgte im Juni 2018, vgl. Basel Committee on Banking Supervision 2018). Hierbei handelt es sich um eine Zusammenfassung der Selbsteinschätzung zum Thema Risikodatenaggregation, der sich 30 global systemrelevante Institute im Jahr 2013 unterziehen mussten. Als Ergebnis ist festzuhalten, dass die dauerhafte Sicherung der Datenqualität sowie die Effizienz und Effektivität bei der Risikodatenaggregation die größten Herausforderungen darstellen, denen sich die Institute im Zuge der Umsetzung von RDA zu stellen haben. Als Schwächen wurden z. B. die Anpassbarkeit der (risikorelevanten) Daten, deren Aktualität sowie die vollständige Erfassung der Risiken identifiziert. Defizite wurden ebenso bei der Umsetzung von Ad-hoc-Datenanforderungen sowie bei der Dokumentation des Risikodatenaggregationsprozesses festgestellt. Die Bereitstellung integrierter Prozesse zur Identifizierung und Berichterstattung von Dateninkonsistenzen erwies sich bei vielen der befragten Institute als weiterer Schwachpunkt. Die daraufhin initiierten Aktivitäten haben nach Auffassung des Basler Ausschusses noch nicht zu den gewünschten Verbesserungen geführt. Zu konstatieren ist, dass die Institute bestenfalls marginale Verbesserungen vorweisen können, was die Erfüllung der BCBS #239-­Anforderungen anbetrifft (vgl. Basel Committee on Banking Supervision 2018, S. 6). Insbesondere die unzureichende Erfüllung des ersten und zweiten Prinzips („Governance“ sowie „Datenarchitektur und Infrastruktur“) stellt nach Ansicht des Basler Ausschusses den Grund dafür dar, dass alle weiteren BCBS #239-Prinzipien bis 2017 nicht erfüllt werden konnten (vgl. Basel Committee on Banking Supervision 2018, S. 6). Die RDA-Prinzipien und die damit verbundenen aufsichtlichen Anforderungen beziehen sich auf alle Daten einer Bank, die zur Steuerung ihrer Risiken notwendig sind. Diese

10

1  Einführung in das Reporting von Risikodaten

risikorelevanten Daten und die daraus resultierenden Risikoberichte sollen es der Geschäftsleitung ermöglichen, Risiken zu überwachen und zu verfolgen sowie damit zusammenhängende Prozessentscheidungen zu treffen.

1.2.3 MaRisk AT 4.3.4 Bei den Mindestanforderungen an das Risikomanagement (MaRisk) handelt es sich um Verwaltungsanweisungen zur Konkretisierung von § 25a Kreditwesengesetz (KWG). Die Veröffentlichung der MaRisk erfolgt mit einem Rundschreiben der Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) für die Ausgestaltung des Risikomanagements in deutschen Kreditinstituten; die erstmalige Veröffentlichung datiert auf den 20.12.2005. Letztmalig wurden die MaRisk am 27.10.2017 novelliert. Mit den MaRisk wurden qualitative Anforderungen von Basel II bzw. III an das Risikocontrolling von Finanzinstituten in nationales Recht umgesetzt. Der Fokus richtete sich auf das  Risikomanagement  von Finanzinstituten bzw. der entsprechenden Überprüfungsprozesse durch die Aufsicht (zum Risikomanagement vgl. Abschn. 1.3). Die Kontrolle der Erfüllung der MaRisk erfolgt im Rahmen der Jahresabschlussprüfung sowie im Rahmen von Sonderprüfungen nach § 44 Abs. 1 KWG, für die die Prüfer der Bundesbank zuständig sind. Die novellierten MaRisk umfassen einen neuen Abschnitt „AT (Allgemeiner Teil) 4.3.4 Datenmanagement, Datenqualität und Aggregation von Risikodaten“, dessen konsequente Umsetzung entsprechende Vereinfachungen bei der Auslagerung von bankfachlichen Prozessen verspricht und der für systemrelevante Institute („große und komplexe Institute“) gelten soll (vgl. Bundesanstalt für Finanzdienstleistungsaufsicht 2017, S. 19 f.; Basler Ausschuss für Bankenaufsicht 2013, S. 1 ff.; Hofer 2016, S. 16 ff.; Fingerlos et al. 2016, S. 10 ff.). Der Anforderungskatalog der MaRisk zu „Datenmanagement, Datenqualität und Ag­ gregation von Risikodaten“ (AT 4.3.4) ist in sieben Anforderungskomplexe gegliedert, die eine End-to-End-Betrachtung von der Definition von Regeln und Zuständigkeiten bis hin zu einer unabhängigen Überprüfung reichen (vgl. Bundesanstalt für Finanzdienstleistungsaufsicht 2017; Fingerlos et al. 2016, S. 10 ff.). Die folgenden Ausführungen systematisieren diese Anforderungen. Anforderung I – Aggregation von Risikodaten  Institut- und gruppenweit geltende Regeln für das Datenmanagement, die Datenqualität und die Aggregation von Risikodaten sind zu definieren. Diese Regeln sind sowohl auf Gruppenebene als auch auf Ebene der Einzelinstitute gültig und von der Geschäftsleitung zu genehmigen und in Kraft zu setzen. Die Aggregation von Risikodaten beinhaltet die gesamte Prozesskette von der Erfassung über die Verarbeitung bis zur Auswertung von Risikodaten und die damit verbundene Berichterstellung. Anforderung II – Datenstruktur und Datenhierarchie  Eine zweifelsfreie Identifizierbarkeit, Zusammenführbarkeit und Auswertbarkeit von Risikodaten muss gewährleistet

1.2  Aufsichtsrechtliche Vorgaben mit Fokus auf Risikodaten

11

sein. Dies verlangt die Festlegung von einheitlichen Namenskonventionen und Kennzeichnungen von Daten, die auch entsprechend zu kommunizieren sind. Bei unterschiedlichen Konventionen und Kennzeichnungen müssen die Daten automatisiert ineinander überleitbar sein. Anforderung III – Auswertbarkeit nach verschiedenen Kategorien  Die Genauigkeit und Vollständigkeit von Risikodaten und deren Auswertbarkeit nach verschiedenen Risikokategorien und Kriterien wie Geschäftsfeld, Konzerngesellschaft, Art des Vermögenswertes, Branche, Region usw. müssen gegeben sein. Dabei steht eine möglichst automatisierte Aggregation im Vordergrund, während manuelle Prozesse auf ein notwendiges Maß zu beschränken sind. Darüber hinaus sind die Datenqualität und Datenvollständigkeit anhand geeigneter Kriterien laufend zu überwachen, die von den Instituten in internen Anforderungen zu formulieren sind. Anforderung IV  – Andere im Institut vorhandene Informationen  Abgleichs- und Plausibilisierungsmöglichkeiten von Risikodaten mit anderen Informationen müssen vorhanden sein. Dies zielt auf Verfahren und Prozesse zum Abgleich der Risikodaten und der Daten in den Risikoberichten ab, die es erlauben, Datenfehler und Schwachstellen in der Datenqualität zu identifizieren. Hier ist insbesondere auf andere in den Instituten vorhandene Informationen wie Daten aus dem Rechnungs- und Meldewesen zurückzugreifen. Anforderung V – Risikodaten in Stressphasen  Die zeitnahe Verfügbarkeit von Risikodaten sowohl unter normalen Umständen als auch in Krisenzeiten muss sichergestellt sein. Dabei obliegt es den Instituten, unter Berücksichtigung der Häufigkeit von Risikoberichten den Zeitrahmen zu definieren, innerhalb dessen die aggregierten Risikodaten vorliegen müssen. In Stressphasen müssen insbesondere die folgenden Daten zeitnah zur Verfügung stehen: (1) Adressenausfallrisiko auf Gesamtbank- und Gruppenebene; (2) Aggregiertes Exposure gegenüber großen Unternehmensschuldnern; (3) Kontrahentenrisiko (auch aus Derivaten) – zusammengefasst und aufgeteilt auf einzelne Adressen; (4) Marktpreisrisiken, Handelspositionen und -limite inklusive möglicher Konzentrationen; (5) Indikatoren für mögliche Liquiditätsrisiken und -engpässe; (6) Indikatoren für operationelle Risiken. Anforderung VI  – Ad-hoc-Informationen nach verschiedenen Kategorien  Flexible und leistungsfähige Datenaggregationskapazitäten müssen vorhanden sein, die eine Auswertung und Analyse von Ad-hoc-Informationen auf unterschiedlichen Ebenen erlauben. Diese Anforderung bezieht sich auf die Datenaggregationskapazitäten, die hinreichend flexibel und leistungsfähig sein müssen, um Ad-hoc-Informationen nach verschiedenen Kategorien und Risikopositionen auf mehreren Aggregationsebenen (Länder, Branchen, Geschäftsfelder, Portfolios und gegebenenfalls Einzelgeschäfte) ausweisen und analysieren zu können.

12

1  Einführung in das Reporting von Risikodaten

Anforderung VII – Überprüfung durch eine unabhängige Stelle  Die Festlegung von Verantwortlichkeiten, Kontrollen und Überprüfungsfunktionen für sämtliche Prozessschritte muss geklärt sein. Für die in Anforderung VII geforderten Verantwortlichkeiten sind prozessunabhängige Kontrollen einzurichten. Darüber hinaus muss regelmäßig von einer von den operativen Geschäftseinheiten unabhängigen Stelle überprüft werden, ob die institutsinternen Regelungen, Verfahren, Methoden und Prozesse von den Mitarbeitern eingehalten werden. Die Überprüfungsinstanz sollte dabei über hinreichende Kenntnisse der IT-Systeme und des Berichtswesens verfügen.

1.3

Risikomanagement

Eine zentrale Voraussetzung für ein erfolgreiches Handeln in Unternehmen, Organisationen und Finanzinstituten zur Nutzung von Chancen und zur Vermeidung von Risiken ist ein funktions- und leistungsfähiges Risikomanagement. Abschn. 1.3.1 beschreibt ein derartiges Risikomanagement zunächst allgemein und erklärt die Notwendigkeit seiner Anwendung. Danach erfolgt in Abschn. 1.3.2 die Darstellung des Aufbaus bzw. des Einsatzes eines erfolgreichen Risikomanagements. Abschließend widmet sich Abschn. 1.3.3 den Ausprägungen des Reportings von Risikodaten.

1.3.1 Beschreibung und Notwendigkeit eines Risikomanagements Das Risikomanagement ist generell eine Führungsaufgabe in Unternehmen, die nicht nur die bereits aufgetretenen Risiken mit ihren negativen Auswirkungen erkennt und dann erst handelt, um weitere Nachteile zu verhindern, sondern das bereits vorab mögliche Risiken und Gefahren wahrnimmt und diese im Vorfeld abwehrt bzw. ihre Auswirkungen reduziert und minimiert (vgl. Ebersoll und Stork 2016; Gleißner 2017; Hull 2014). Das betriebliche Management hat auf den verschiedenen Ebenen eines Instituts die Aufgabe, zu planen, zu entscheiden, zu organisieren, zu steuern und zu kontrollieren, und zwar sowohl für strategische als auch für taktische und operative Aufgaben. Hierbei trägt das Informationsmanagement für die gesamten IT-Systeme mit ihrer Hard- und Software, mit ihren Daten, Funktionen und Prozessen Verantwortung (vgl. Gabriel und Beier 2003; Krcmar 2015), mit zahlreichen Schnittstellen zum betrieblichen Risikomanagement. Das Risikomanagement setzt sich mit dem Risiko auseinander, das in vielfältigen Ausprägungen und in unterschiedlichen Anwendungsbereichen auftreten kann. Allgemein erweist sich Risiko als ein Wagnis im Zusammenhang mit Ereignissen, die mit möglichen negativen Auswirkungen verknüpft sind, z. B. mit Gefahren für Menschen bei Unfällen oder mit betriebswirtschaftlichen Verlusten bei Fehlinvestitionen. Bei Entscheidungen, die in der Regel ungewisse Folgen aufweisen, lassen sich Risiken oder Wagnisse eingehen, die möglicherweise zu einer Gefahr führen.

1.3 Risikomanagement

13

Risiken können durch unterschiedliche Einflussfaktoren entstehen, die intern oder extern gegeben sind, die durch menschliches Handeln geplant und gezielt eingesetzt werden, aber die auch durch Fehler und unbewusstes Handeln entstehen. Risiken können rein zufällig auftreten, oder es lassen sich Wahrscheinlichkeiten für ihr Auftreten festlegen, mit der sich die Risikotheorie wissenschaftlich auseinandersetzt (vgl. z. B. Romeike und Hager 2013; Wolke 2016; Albrecht und Maurer 2016). Die Entscheidungstheorie differenziert zwischen Verhalten des Entscheiders bei Risikoaversion (risikoscheues Verhalten), bei Risikoneutralität (risikoindifferentes Verhalten) und bei Risikoaffinität (risikofreundliches Verhalten) (vgl. hierzu z. B. Zimmermann 2005; Werners 2013). Finanzinstitute sind mit einer Reihe von Risiken konfrontiert, die frühzeitig erkannt, überwacht und gesteuert werden müssen, damit sie ihre Existenz nachhaltig sichern und wirtschaftlich erfolgreich sein können. Das betriebswirtschaftliche Gesamtrisiko, dem ein Finanzinstitut unterliegt, lässt sich beispielsweise unterteilen in ein operationelles Risiko (z.  B. durch Ausfälle der IT), ein Kreditrisiko (z.  B. durch den Ausfall von Kreditnehmern), ein Liquiditätsrisiko und ein Marktrisiko (z. B. Wechselkursrisiko, Zinsänderungsrisiko). Bei nationalen und internationalen Finanzsystemen können Risiken zu großen Schäden und Verwerfungen der Wirtschaftssysteme führen. Für den erfolgreichen Umgang mit Risiken und zu ihrer Bewältigung muss eine Risikokultur im Unternehmen entstehen. Weiterhin sind Ziele aufzustellen und entsprechende Strategien und Konzepte zu entwickeln, die sich auf sinnvolle Vorgehensmodelle stützen (vgl. hierzu auch Bundesanstalt für Finanzdienstleistungsaufsicht 2017, AT4.2). Als Einzelaufgaben lassen sich Risikoerkennung, -analyse und -bewertung identifizieren. Die institutsinternen Abläufe und Prozesse müssen ständig überwacht und kontrolliert werden. Dem schrittweisen Vorgehen zum Aufbau und Einsatz eines Risikomanagements widmet sich Absch. 1.3.2.

1.3.2 V  orgehensweise zum Aufbau und Einsatz eines Risikomanagements Folgende Schritte lassen sich zum Aufbau eines leistungsfähigen Risikomanagements anwenden: Schritt 1: Formulierung der Ziele und Strategien Ausgehend von den strategischen Unternehmenszielen werden konkrete Ziele für ein Risikomanagement abgeleitet, so z. B. die Erstellung eines Reportings von Risikodaten. Zunächst müssen dazu neben der Etablierung einer Risikokultur Fragen auf strategischer Ebene des Unternehmens beantwortet werden, wie z. B.: • Welche Risiken können auftreten und welche Auswirkungen haben diese Risiken? • Welche Bedeutung haben die Risiken für das Unternehmen? • Welche Bedeutung hat ein Risikomanagement für den Erfolg des Unternehmens?

14

1  Einführung in das Reporting von Risikodaten

Weiterhin werden zunächst allgemeine Strategien zum Umgang mit Risiken erstellt, so z. B. zur • Risikovermeidung, z. B. durch Nicht-Handeln bzw. Rückzug und Verzicht • Risikominderung bzw. -reduzierung, z. B. durch Analysen der Risiken • Risikodiversifikation durch Streuung von Risiken und damit verbundene Vermeidung von Klumpenrisiken • Risikotransfer, z. B. Übertragung der Risiken auf eine Versicherung • Risikovorsorge, d. h. Planung für den Schadensfall • Risikoberatung durch Beratungsunternehmen • Risikodokumentation und Risikoreporting Nach der Feststellung der Notwendigkeit eines Risikomanagements werden konkrete Ziele für den Aufbau und den Einsatz formuliert, die später stets anzupassen und zu erweitern sind. Darauf aufbauend lassen sich ein Plan für die weitere Vorgehensweise aufstellen, ein Planungsteam ernennen, ein Budget festlegen sowie die Beschlüsse dokumentieren. Schritt 2: Erstellung eines Konzepts Das zu erstellende Konzept, das sich an den Zielen und Strategien des ersten Schrittes orientiert, bildet die Basis des Risikomanagements, d. h. die notwendigen Informationen zur Implementierung eines Risikomanagements im anschließenden Schritt 3. Hierzu gehören folgende Tätigkeiten: • Analyse der institutsinternen und -externen Prozesse mit ihren Funktionen, Daten und Schnittstellen und Ableiten der möglichen Risiken • Analyse der Risiken und ihrer Auswirkungen mit Klassifikation, Bewertung und Gruppierung • Analyse der Zusammenhänge von Risiken (Risikoaggregation) • Identifikation von Aktivitäten zur Vermeidung, Erkennung, Reduzierung und Beherrschung von Risiken.

Schritt 3: Implementierung eines Risikomanagements Die Implementierung besteht aus unterschiedlichen Phasen, die den zeitlichen Ablauf bestimmen, d. h. die Vorlage für den konkreten Risikomanagementprozessorientiert sich an den Zielen und Strategien (Schritt 1) und nutzt die in Schritt 2 erarbeiteten Informationen. Der zu durchlaufende Prozess lässt sich in folgende Phasen bzw. Arbeitsbereiche einteilen (vgl. Gabriel und Röhrs 2017, S. 86 f.): • Identifikation der Risiken: Alle möglichen Risiken werden identifiziert und nach Art, Bedeutung, Ursachen und möglichen Auswirkungen (z. B. Schadensausmaß) festgelegt (vgl. Schritt 2).

1.3 Risikomanagement

15

• Analyse der identifizierten Risiken: Es erfolgt die Bestimmung von Eintrittswahrscheinlichkeiten und die Bestimmung möglicher Ausweitungen der Risiken, z. B. unter Zuhilfenahme einer Risikomatrix. • Bewertung der Risiken: Die Risiken werden bezüglich wichtiger Kriterien bewertet, so z. B. bezüglich der Verletzung der Unternehmensziele und der Strategien, bezüglich der Umsatzverluste und der Gewinneinbußen, bezüglich rechtlicher Klagen und ­Imageschäden. Zur Verdeutlichung des Risikopotenzials lassen sich die Risiken in ein Bewertungsschema einordnen. • Aggregation der Risiken: Da in der Regel mehrere Risiken gegeben sind, ist es wichtig, ihre Zusammenhänge bzw. Abhängigkeiten zu analysieren. So können sich beispielsweise Risiken im Verbund verstärken und zu sehr negativen Ergebnissen führen. • Steuerung der Risiken: Bei der Steuerung des Prozesses stellt sich die Frage nach dem weiteren Umgang mit den identifizierten Risiken. Als mögliche Vorgehensweisen bieten sich die reine Akzeptanz des potenziellen Schadens oder die Reduktion mit akzeptablem Aufwand. • Bewältigung und Beherrschung der Risiken: Festlegung der Maßnahmen, welche die Eintrittswahrscheinlichkeiten der Risiken möglichst stark reduzieren und mögliche negative Folgen und Auswirkungen begrenzen. Der Aufwand für die Maßnahmen wird stark auch von der Bewertung des jeweiligen Risikos bestimmt. • Überwachung und Kontrolle der Risiken: Es erfolgt die Festlegung von Kriterien bzw. Faktoren für alle relevanten Risiken, die ständig kontrolliert und abgeglichen werden. Dazu gehören auch Zulassungsbereiche bzw. Intervalle, die nicht über- bzw. unterschritten werden dürfen. Bei der Überwachung sollen auch noch nicht bekannte und neue Risiken erfasst, analysiert und bewertet werden. Die Überwachung und Kontrolle stellt einen Lernprozess mit stetiger Wiederholung dar. • Dokumentation des Prozesses und der Risiken: Der gesamte Risikomanagementprozess soll mit all seinen Aktivitäten in den einzelnen Phasen beschrieben und dokumentiert werden. Als Teil eines Informations- bzw. Wissenssystems sind alle Risiken mit ihren Ursachen, Ausprägungen, Verhalten und Auswirkungen zu beschreiben. Die Dokumentation umfasst auch die Ergebnisse der Analyse und der Bewertungen der Risiken, ebenso die Maßnahmen zur Bewältigung und Beherrschung der Risiken. Wichtig ist zudem, die Erfahrungen festzuhalten und dadurch den Lernprozess aktiv zu unterstützen. Der durchzuführende Risikomanagementprozess versteht sich als ein permanenter Durchlauf, z. B. als Zyklus, der an der laufenden Überwachung und Kontrolle der Risiken ansetzt und wie ein Frühwarnsystem reagiert. Risiko-Monitoring und -Controlling erweisen sich dabei als wichtige Instrumente eines erfolgreichen Risikomanagements. Das Reporting von Informationen über Risiken (risikorelevante Daten bzw. Risikodaten), die schnell verfügbar sind und eine gute Qualität aufweisen, stellt eine wichtige Grundlage für erfolgreiche Entscheidungen dar. Diesem Aspekt widmet sich Abschn. 1.3.3.

16

1  Einführung in das Reporting von Risikodaten

1.3.3 Ausprägungen des Reportings von Risikodaten Ein Reporting von Risikodaten (Risikoreporting) ist eine notwendige Aktivität und strukturierte Basis des Risikomanagements. Eine Unterteilung erfolgt in internes und ein externes Risikoreporting (Risikoberichterstattung). Interne Risikoberichte werden in vorgegebenen zeitlichen Abständen oder auf Anfrage für die Unternehmensführung erstellt. Die aufgeführten Risikodaten sollen aktuell und für unternehmerische Entscheidungen relevant sein. Dabei lassen sich die Risiken bewerten und besonders kennzeichnen bzw. erläutern, so z. B. als Teil eines Management Information Systems (MIS) bzw. eines Executive Information Systems (EIS) (vgl. Abschn. 3.1). Ein externes Risikoreporting ist u. a. durch das KonTraG vorgeschrieben. Hier werden verschiedene Empfehlungen und Standards entwickelt, beispielsweise auch durch den Vorschlag verschiedener Risikokategorien, wie etwa Umfeldrisiken, Branchenrisiken, unternehmensstrategische Risiken, leistungswirtschaftliche Risiken, Personalrisiken, informationstechnische Risiken, finanzwirtschaftliche Risiken und sonstige Risiken. Wichtig ist es, einzelne Risiken zusammenzufassen (Risikodatenaggregation), um ein Gesamtrisiko abzuleiten. Weitere Erklärungen zum Risikoreporting folgen in den weiteren Kapiteln.

Literatur Albrecht, P.; Maurer, R. (2016): Investment- und Risikomanagement, 4. Aufl., Schäffer-Poeschel, Stuttgart. Basel Committee on Banking Supervision (2006): International Convergence of Capital Measurement and Capital Standards. A Revised Framework. Comprehensive Version, June 2006, zuletzt abgerufen am: 14.09.2019, https://www.bis.org/publ/bcbs128.pdf. Basel Committee on Banking Supervision (2013): Progress in adopting the principles for effective risk data aggregation and risk reporting, Bank for International Settlements, December 2013, zuletzt abgerufen am: 14.09.2019, https://www.bis.org/publ/bcbs268.pdf. Basel Committee on Banking Supervision (2018): Progress in adopting the Principles for effective risk data aggregation and risk reporting, Bank for International Settlements, June 2018, zuletzt abgerufen am: 14.09.2019, https://www.bis.org/bcbs/publ/d443.pdf. Basler Ausschuss für Bankenaufsicht (2013): Grundsätze für die effektive Aggregation von Risikodaten und die Risikoberichterstattung, Bank für Internationalen Zahlungsausgleich, Januar 2013, zuletzt abgerufen am: 14.09.2019, https://www.bis.org/publ/bcbs239_de.pdf. Bundesanstalt für Finanzdienstleistungsaufsicht (2017): Erläuterungen zu den MaRisk in der Fassung vom 27.10.2017, zuletzt abgerufen am: 14.09.2019, https://www.bafin.de/SharedDocs/ Downloads/DE/Rundschreiben/dl_rs0917_marisk_Endfassung_2017_pdf_ba.pdf?__blob=publicationFile&v=5. Bundesanstalt für Finanzdienstleistungsaufsicht (2016): Solvency II, zuletzt abgerufen am: 15.02.2019, https://www.bafin.de/DE/Aufsicht/VersichererPensionsfonds/Aufsichtsregime/SolvencyII/solvency_II_node.html. Deutsche Bundesbank (2019): Baseler Rahmenwerk, zuletzt abgerufen am: 14.09.2019, https:// www.bundesbank.de/de/aufgaben/bankenaufsicht/rechtsgrundlagen/baseler-rahmenwerk/baseler-rahmenwerk-598536.

Literatur

17

Ebersoll, M.; Stork, F. (2016): Smart Risk Assessment, Schmidt, Berlin. Fingerlos, U.; Golla, G.; Pastwa, A. (2016): Datenqualität im Risikomanagement – Konkretisierung der Anforderungen aus AT 4.3.4 MaRisk, in: Risiko Manager 10/2016, S. 10–14. Gabler Wirtschaftslexikon (2019): Risikomanagement, Online Lexikon, Springer Gabler, Berlin, zuletzt abgerufen am: 14.09.2019, https://wirtschaftslexikon.gabler.de/definition/risikomanagement-42454. Gabriel, R., Röhrs, H.-P. (2017): Social Media, Potenziale, Trends, Chancen und Risiken, Springer Gabler, Berlin. Gabriel, R.; Beier, D. (2003): Informationsmanagement in Organisationen, Kohlhammer, Stuttgart. Gleißner, W. (2017): Grundlagen des Risikomanagements, 3. Aufl., Vahlen, München. Hofer, M. (2016): Risikomanagement: BaFin konsultiert überarbeitete MaRisk für Banken, in: BaFin Journal 04/2016, S. 16–19. Hull, J. C. (2014): Risikomanagement - Banken, Versicherungen und andere Finanzinstitutionen, 3. Aufl., Pearson, Hallbergmoos. Kaiser, A.; Tetzner, A. (2017): Business Analytics mit SAP HANA Möglichkeiten und Grenzen, in: ERP Management 13 (1), S. 52–54. Krcmar, H. (2015): Informationsmanagement, 6. Aufl., Gabler, Berlin. Loskamp, M.; Uzelac, P. (2019): Berichterstattung zur Veränderungsanalyse, in: BaFin Journal 01/2019, S. 18–21. Naisbitt, J. (1982): Megatrends. Ten New Directions Transforming Our Lives, Warner Books, New York. Romeike, F.; Hager, P. (2013): Erfolgsfaktor Risikomanagement 3.0, 3. Aufl., Springer, Wiesbaden. Voigt, S.; Seidel, H. (2016): Einleitung, in: Kohl, H.; Mertins, K.; Seidel H. (Hrsg.): Wissensmanagement im Mittelstand: Grundlagen – Lösungen – Praxisbeispiele, 2. Aufl., Springer Gabler, Berlin, S. 1–8. Werners, B. (2013): Grundlagen des Operations Research, 3. Aufl., Gabler, Berlin. Wolke, T. (2016): Risikomanagement, 3. Aufl., de Gruyter, Berlin. Zimmermann, H. J. (2005): Operations Rersearch, Methoden und Modelle, Vieweg, Wiesbaden.

2

Technologische und konzeptionelle Ansätze zur Analyse und zum Reporting von Risikodaten in Kreditinstituten

Die Basis für ein tragfähiges Konzept zur Analyse und zum Reporting von Risikodaten in Kreditinstituten bilden die eingesetzten IT-Systeme und deren Zusammenspiel. Dabei erweisen sich heutige IT-Landschaften oftmals als unüberschaubares Geflecht von miteinander verwobenen Einzelkomponenten einschließlich der zugehörigen Schnittstellen. Auch eine Einengung der Betrachtung auf die Bausteine zur Analyse und für das Reporting vermindert die Komplexität nur marginal. Beginnend mit einer Rückschau auf die historischen Ursprünge und die Entwicklung von Ansätzen zur betrieblichen Entscheidungsunterstützung in Abschn. 2.1 widmet sich Abschn. 2.2 zunächst den klassischen Reportingansätzen, die insbesondere auf dem Data-­ Warehouse-­Konzept beruhen. Unter dem Begriff Big Data wird in Abschn. 2.3 ein Ansatz vorgestellt, der seit einiger Zeit von vielen Instituten als Enabler für die Verarbeitung und Bereitstellung von risikorelevanten Daten wahrgenommen wird. Abschn. 2.4 widmet sich den unterschiedlichen Ausprägungen und Verfahren zur Analyse von Datenmaterial. Das vorliegende Kapitel schließt mit der in Abschn.  2.5 vorgestellten Data Governance als Ansatz zur Organisation, Steuerung und Kontrolle der wachsenden Menge und Vielfalt an Daten.

2.1

Historische Herleitung

Erste Ansätze zur Unterstützung betrieblicher Entscheidungsträger bei der Bewältigung anfallender Aufgaben lassen sich bis in die 1960er- und 1970er-Jahre zurückverfolgen, als bereits erste Managementinformationssysteme (MIS) entstanden, die (aufsetzend auf den operativen Anwendungssystemen) detaillierte und verdichtete Informationen aus der operativen Datenbasis extrahierten und zumeist in Form umfangreicher Listen

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 U. R. Fingerlos et al., Risikoreporting in Finanzinstituten, https://doi.org/10.1007/978-3-658-28440-4_2

19

20

2  Technologische und konzeptionelle Ansätze zur Analyse und zum Reporting von …

zur Ausgabe brachten. Dem Management sollten Monitorfunktionen als wirksame ExPost-­Überwachungsinstrumente für vergangenheitsbezogene Geschäftsaktivitäten zur Verfügung gestellt werden. Dabei verzichteten die Systeme weitgehend auf eine (aufwendige) Modellbildung sowie die Anwendung anspruchsvoller Methoden und konzentrierten sich fast ausschließlich auf die Datenbereitstellung. Auch heute sind in fast jedem Institut entsprechende Lösungen vorzufinden und decken das Standard-Berichtswesen ab. Basierend auf den operativen Basissystemen greifen sie verdichtend auf deren Daten zu und richten vorformulierte parametrisierbare Datenbankabfragen periodisch an die vorhandenen operativen Datenbanken mit anschließender Formatierung der Abfrageergebnisse in Berichtform. Als Kritikpunkt lässt sich die eher starre Form des Standard-Berichtswesens anführen, die eine flexible Anpassung an die situativen Bedürfnisse kaum in angemessener Zeit zulässt. An dieser Stelle setzte die nächste Evolutionsstufe der managementunterstützenden Systeme an, die unter der Bezeichnung Entscheidungsunterstützungssysteme (EUS bzw. Decision Support Systems, DSS) versucht, das Verhalten von Fach- und Führungskräften bei der Lösung von Fachproblemen abzubilden. Bei dieser Systemkategorie steht die interaktive Nutzung von bereitgestellten Modellen, Methoden und problembezogenen Daten im Vordergrund. Implizit unterstellen diese DSS bei der Abbildung des menschlichen Lösungsansatzes zumeist ein formallogisches Vorgehen, wobei das Ausgangsproblem zunächst in ein explizites Modell überführt, dieses dann mit Hilfe einer geeigneten Methode gelöst und anschließend die Modellaussage in die Realität zurück transformiert wird. Bei der Gestaltung problembezogener Decision Support Systems werden zumeist DSS-Generatoren eingesetzt, die es als problemspezifische Werkzeugkästen dem Benutzer auf einfache Art und Weise gestatten, entscheidungsunterstützende Software zu erzeugen. Als dominierende Werkzeugklasse zur Erstellung anwendungsfallbezogener Decision Support Systems werden heute in diversen Abteilungen und Bereichen (z. B. Risikomanagement, Controlling) eines Instituts fast ausschließlich Tabellenkalkulationssysteme (Spreadsheets) genutzt, die durch ihre anwendungsnahe Konzeption des Arbeitens in und mit Tabellen bestechen. Der zentrale Kritikpunkt an den aufgebauten Lösungen liegt in der verdeckten Programmierung im Hintergrund, die schnell zu sehr komplexen und undurchschaubaren Arbeitsblättern mit vielfältigen Verweisen und Querverbindungen führt. Dadurch bleibt dem Top-Management eine Nutzung häufig verwehrt. Vor allem die oberste Führungsriege adressiert dagegen die darauf folgende Kategorie managementunterstützender Lösungen unter der Bezeichnung Executive Information System (EIS), die als dialog- und datenorientierte Informationssysteme mit ausgeprägten Kommunikationselementen Fach- und Führungskräften aktuelle entscheidungsrelevante interne und externe Informationen anbieten wollen. Als konstituierendes Merkmal gelten hier intuitiv benutzbare und individuell anpassbare Benutzungsoberflächen mit ansprechendem Design. EIS lassen sich durchaus als wegweisend und strukturbildend verstehen, zumal einige der damals erstmalig genutzten Gestaltungselemente bis heute Bestand haben. So basierten

2.1  Historische Herleitung

21

die Systeme oftmals bereits auf multidimensionalen Datenstrukturen, wie sie heute im Kontext von OLAP-Systemen weiterhin genutzt werden. Auch Navigationsfunktionalitäten wie Drill-Down und Roll-Up kamen erstmalig zur Anwendung. Zudem erfolgte bereits der Einsatz von Colour Coding für die besondere Markierung besonders guter oder schlechter Wertkonstellationen. Als zentrale Schwachstelle erwies sich allerdings häufig rasch die fehlende dauerhafte Datenanbindung bzw. -aktualisierung, zumal die Systeme als Projekt konzipiert und implementiert wurden und der Datenbestand bei Projektende dauerhaft genutzt werden sollte, aber natürlich schnell veraltete. Nicht zuletzt vor diesem Hintergrund lassen sich die in der ersten Hälfte der 1990er-­ Jahre einsetzenden Bemühungen um den Aufbau einer unternehmensweiten Datenbasis zur Entscheidungsunterstützung verstehen. Als Single Point of Truth or Trust (SPOT) sollte das Data Warehouse (DWH) als umfassende Datenplattform harmonisierte und qualitätsgesicherte Inhalte für die unterschiedlichen dispositiven Front-End-Anwendungen bereithalten. Die klare und konsequente hard- und softwareseitige Trennung von den operativen Systemen ermöglichte den Aufbau auswertungsorientierter Architekturen ohne Beeinträchtigung der operativen Systeme. Fast zeitgleich entwickelte sich das Begriffsgebilde On-Line Analytical Processing (OLAP) als Synonym für die multidimensionale und damit nutzergerechte Aufbereitung von betriebswirtschaftlichem Datenmaterial. Heutige Architekturen verwenden das OLAP-Speicherparadigma allerdings seltener im zentralen DWH, sondern eher in den daraus abgeleiteten Data Marts als anwendungsorientierte Teildatenbestände. Mit dem neuen Jahrtausend treten auch neue Begrifflichkeiten in den Vordergrund. Lange Jahre dominierte BI die Diskussion um die Ausgestaltung entscheidungsunterstützender Systeme und deckte dabei nicht nur technologische, sondern auch fachliche und organisatorische Facetten des Themengebiets ab. Noch stärker fachlich ist dagegen die Begrifflichkeit Corporate bzw. Business Performance Management (CPM bzw. BPM) ausgerichtet und konzentriert sich auf Themenfelder wie Planung und Budgetierung, Risikomanagement und Balanced Scorecard mitsamt den zugehörigen Systemen. Im letzten Jahrzehnt hat die Diskussion um die Ausgestaltung entscheidungsunterstützender Systeme neuen Schub erhalten. Nicht zuletzt aufgrund der zunehmenden Digitalisierung weiter Teile von Gesellschaft und Wirtschaft rücken unter dem Oberbegriff Big-Data-Konzepte zur zeitnahen Verarbeitung großer, polystrukturierter Datenmengen in das Bewusstsein der Finanzbranche (vgl. Abb. 2.1). Zudem führt die Erkenntnis, dass nur zielgerichtete und zum Teil aufwändige Analysen der verfügbaren Datenbestände deren volles Potenzial nutzbar werden lässt, zu einer zunehmenden Beschäftigung mit dem Themenfeld Datenanalyse (Business Analytics bzw. Risk Analytics). Die obigen Ausführungen belegen, dass im Laufe der Zeit unterschiedliche Systemkategorien zur Entscheidungsunterstützung im Fokus standen und mit der jeweiligen spezifischen Ausrichtung verschiedene Aufgabenbereiche, aber auch Anwendergruppen bedient wurden. Die folgenden Abschnitte greifen bedeutsame und heute immer noch wichtige Komponenten der klassischen, aber auch der moderneren Lösungen heraus und beleuchten diese näher.

22

2  Technologische und konzeptionelle Ansätze zur Analyse und zum Reporting von …

Entwicklung analytischer Informationssysteme

Unterstützungsgrad bei Managementaufgaben

Big Data / Analytics

BI, CPM / BPM Data Warehouse, OLAP Executive Information Systems

Decision Support Systems

Management Information Systems 1970

1980

1990

2000

2010

Zeit

Abb. 2.1  Historische Entwicklung entscheidungsorientierter Systemkategorien. (Quelle: eigene Darstellung)

2.2

Data-Warehouse-basierte Reportingansätze

Abschn. 2.2.1 widmet sich zunächst dem DWH als zentrale Komponente der Reportinglandschaften vieler Institute. Welche Architekturvarianten zum Aufbau einer DWH-­ basierten Reportinganwendungen zum Einsatz kommen können, wird in Abschn.  2.2.2 thematisiert. Abschn. 2.2.3 setzt sich mit der Datenbewirtschaftung von DWH-­Anwendun­ gen auseinander, worauf Abschn. 2.2.4 mit der Vorstellung klassischer und neuer Reportingansätze zur Auswertungen der bewirtschafteten Datenhaushalte schließt.

2.2.1 Data Warehouse als zentrale Speicherkomponente Unter einem DWH lässt sich eine umfangreiche Datenbasis mit entscheidungsrelevanten Inhalten zur Unterstützung dispositiver Aufgaben verstehen, die im Idealfall unternehmungsweit ausgerichtet ist und das Informationsbedürfnis verschiedenster Anwendergruppen abdeckt (vgl. Mucksch 2006, S. 130 f.). Aus technischen Gründen erweist es sich als sinnvoll, ein derartiges zentrales DWH von den datenliefernden Vorsystemen zu entkoppeln und auf einer separaten Plattform zu betreiben. Die gesammelten Problemdaten müssen dabei aus den unterschiedlichen vorgelagerten operativen Datenbasen extrahiert

2.2  Data-Warehouse-basierte Reportingansätze

23

und in einer eigenständigen Datenbasis derart strukturiert abgelegt werden, dass sich da­ raus der Informationsbedarf der Anwender decken lässt. Die wörtliche Übersetzung des Begriffs DWH, also „Datenlagerhaus“, noch treffender vielleicht die recht freie Übersetzung „Datenwarenhaus“, bietet Ansatzpunkte für die umfassende Erläuterung der weiteren Ideen, die mit dem DWH verbunden sind. Es finden sich tatsächlich viele Merkmale, die mit denen eines Warenhauses übereinstimmen. Das DWH versteht sich als Zentrale zur Bereitstellung aller notwendigen (nachgefragten) Informationen, auf die hauptsächlich ein lesender Zugriff möglich ist. Wie in einem „Warenhaus“ holt sich der „Kunde“ nach seinem „Bedarf“ und in „Selbstbedienung“ die „Ware Information“ aus den „Regalen“ in seinen „Warenkorb“. Die „Regale“ sind nach Themengebieten geordnet, das „Warenangebot“ ist kundenorientiert. Die erstmalige Verwendung des Begriffes kann bis in die späten 1980er-Jahre zurückverfolgt werden, als Devlin und Murphy das DWH als zentrale Datensammelstelle skizzieren, die den Nutzer von technischen Details der Datenintegration entlastet, damit er sich auf die Verwendung der aufbereiteten Inhalte konzentrieren kann (vgl. Devlin und Murphy 1988, S. 61). Sehr zur Popularität des DWH-Konzeptes hat William Inmon beigetragen, der die vier idealtypischen Merkmale Themenorientierung, Vereinheitlichung, Zeitorientierung und Beständigkeit formuliert hat, die bis heute weitgehend Gültigkeit aufweisen (vgl. Inmon 2002): Themenorientierung Die Informationseinheiten in einem DWH konzentrieren sich auf die im Rahmen der Entscheidungsfindung relevanten Inhalte und sind auf betriebswirtschaftliche Themenfelder mit den zugehörigen quantitativen Kenngrößen ausgerichtet. Damit unterscheiden sie sich klar von den eher transaktionsorientierten Datenstrukturen operativer Anwendungssysteme mit ausgeprägter Prozessorientierung. Vereinheitlichung Bevor die Daten in das DWH Eingang finden, sind diese zu vereinheitlichen, um auch Inhalte aus unterschiedlichen Datenquellen miteinander vergleichen zu können. Diese Homogenisierung bezieht sich häufig auf Namensgebungen, Bemaßungen und Kodierungen und hat das Ziel, einen konsistenten Datenbestand zu schaffen, auch wenn die datenliefernden Quellsysteme große Heterogenität aufweisen. Zeitorientierung Die Zeitorientierung weist unmittelbaren Einfluss auf die Art der Strukturierung abgelegter Inhalte auf. Jede quantitative Kenngröße im DWH weist einen Zeitbezug auf. Im Falle von Bestandsgrößen können dies Datumsangaben, im Falle von Bewegungsgrößen Angaben zum entsprechenden Zeitraum sein (z.  B.  Monat Mai 2018, S.  45. Kalenderwoche

24

2  Technologische und konzeptionelle Ansätze zur Analyse und zum Reporting von …

2018, Jahr 2018). Stammdaten werden hingegen häufig mit Gültigkeitsstempeln versehen, auch um Änderungen im Zeitablauf (beispielsweise im Hinblick auf eine strukturelle Zuordnung) nachvollziehen zu können. Beständigkeit Die dauerhafte Speicherung der Daten in einem DWH unterscheidet sich ebenfalls von der eher flüchtigen Speicherung in operativen Systemen, in denen eine Veränderung oder gar Löschung von Daten erforderlich sein kann. Als wesentliche Grundoperationen im DWH erweisen sich dagegen lediglich das Datenladen (Import) und die Datenabfrage. Aktualisierungen können notwendig sein, allerdings nur nach nachvollziehbarer Protokollierung von Änderungen.

2.2.2 Data-Warehouse-Architekturvarianten Mit der Hub-and-Spoke-Architektur und der DWH-Schichtenarchitektur werden in Abschn. 2.2.2.1 und Abschn. 2.2.2.2 die gängigsten Architekturvarianten im DWH-Umfeld vorgestellt, die im Umfeld der Financial Services Industry (FSI) zum Einsatz kommen.

2.2.2.1 Hub-and-Spoke-Architektur Wie in Abb.  2.2 visualisiert, führt bei einer Hub-and-Spoke-Architektur der Datenfluss ausgehend von den operativen und externen Informationssystemen, die als Lieferanten für das Rohdatenmaterial dienen, über die eingesetzten Komponenten für die Extraktion, Transformation und das Laden von Daten (ETL) zunächst bis zum Enterprise DWH. Teilweise wird der dispositive Datenbestand weiter in das Enterprise DWH mit dann eher verdichteten Daten und den Operational Data Store (ODS) mit sehr detaillierten Daten bis auf Belegebene (jedoch ohne allzu lange Historie) untergliedert (vgl. Gluchowski et al. 2008, S. 131). Von dort aus werden die Daten in Abhängigkeit vom jeweiligen Anwendungsbereich extrahiert, ggf. weiter verdichtet und dann in den Data Marts nochmals abgespeichert. Im vorliegenden Beispiel wird ein eigens für DQ-Zwecke vorgehaltener Data Mart sowie ein Risiko Data Mart zur Abbildung der Risikosituation mit bereinigten Daten aus dem Enterprise DWH genutzt. Der Risko Data Mart ermöglicht über den Einsatz eines OLAP-­ Servers multidimensionale Auswertungen. Endbenutzerwerkzeuge greifen bei dieser Architekturvariante direkt auf die Data Marts zu. In Abhängigkeit von der jeweiligen Nutzungs- bzw. Zugriffsphilosophie lässt sich auch der Datenbestand im DWH unmittelbar verwenden. Neben den Speicherkomponenten für die Problemdaten weist eine DWH-Architektur auch ein Archivierungssystem auf, das sowohl der Datenarchivierung als auch der Datensicherung dient. Die Datensicherung wird zur Wiederherstellung der Inhalte eines DWH im Falle von Programm- oder Systemfehlern benötigt. Im Einzelfall und im Hinblick auf

25

Datenquellen

Dashboards

Data Mining

Metadatenbanksystem

Berichtssysteme

DQ Data Mart

OLAP-Frontend

Risiko Data Mart OLAP Server

Enterprise Data Warehouse

Archivierungssystem

Datenbereitstellung

Datennutzung

2.2  Data-Warehouse-basierte Reportingansätze

ETL-System

Risikomanagement Meldewesen

SAP BP Kundendaten

Risikovorsorge

Offenlegung §§ 319ff. SolvV Operative Vorsysteme

Abb. 2.2  Hub-and-Spoke-Architektur. (Quelle: eigene Darstellung)

eine möglichst rasche Wiederherstellbarkeit des Datenbestandes im Schadensfall ist dabei zu entscheiden, ob lediglich atomare Detaildaten oder auch die bereits berechneten, verdichteten Daten gesichert werden. Die zu speichernden Datenvolumina in einem DWH können im Laufe der Nutzungszeit einen erheblichen Umfang erreichen. Um das Volumen in erträglichen Grenzen zu halten, werden Archivierungssysteme eingesetzt, die atomare wie verdichtete Daten aus der DWH-Datenbank entfernen, ohne dass diese für spätere Analysen verloren gehen. Technologisch erfolgt dabei eine Auslagerung eines Teils der Daten aus der DWH-Datenbank in externe Offline-Datenträger, aus denen sich der ursprüngliche Datenbestand jederzeit regenerieren lässt. Neben den entscheidungsorientierten Daten enthält ein DWH auch Metadaten, die in einem Metadatenbanksystem verwaltet werden. Im Idealfall handelt sich dabei nicht nur um rein technische Angaben, die neben ihrer Informationsfunktion auch zur Steuerung des DWH-Betriebs dienen. Vielmehr werden im Metadatenbanksystem auch betriebswirtschaftliche Angaben abgelegt, die dem Endbenutzer dabei helfen, Analyseanwendungen

26

2  Technologische und konzeptionelle Ansätze zur Analyse und zum Reporting von …

effektiver einzusetzen und deren Ergebnisse zu interpretieren oder die für ihn relevanten Daten zu finden. In diese Kategorie der semantischen Metadaten fallen beispielsweise Dokumentationen zu vordefinierten Anfragen und Berichten, zu Datenmodellen und Datenlieferstrecken sowie die Erläuterung von Fachbegriffen und Terminologien, die in ­einem sogenannten Business Glossar als Komponente eines Metadatenbanksystems vorgehalten werden können.

2.2.2.2 Data-Warehouse-Schichtenarchitektur Neben der klassischen Hub-and-Spoke-Architektur sieht ein weiterer Ansatz vor, den DWH-Datenbestand in logische Ebenen bzw. Schichten (Layer) aufzuteilen, so dass diese Variante als DWH-Schichtenarchitektur bezeichnet wird. Auch wenn die einzelnen Ebenen teilweise unterschiedlich benannt sind und auch die Anzahl der Schichten variieren kann, erfolgt hier die Vorstellung einer idealtypischen Architektur mit insgesamt vier Datenschichten (vgl. Abb. 2.3). Acquisition Layer (Staging Area) Der Acquisition Layer dient der Aufnahme untransformierter Rohdaten aus internen und externen Datenquellen. Bereits im Kontext der Hub-and-Spoke-Architektur war ein derartiger Datenbereich unter der Bezeichnung Staging Area gebräuchlich. Vor allem dann, wenn die angelieferten Rohdaten als Textdateien formatiert sind, wird hier auch von einer Landing Zone gesprochen. Im Falle einer dauerhaften Ablage der Rohdaten zur möglichen späteren Verwendung der Extraktionshistorie erfolgt die Bezeichnung Staging Memory.

Analyse

Reporting Layer (Data Marts)

Propagation Layer (inkl. Aggregationen, Anreicherungen) Integration Layer: Core Data Warehouse Corporate Memory oder Enterprise Data Warehouse Acquisition Layer (Staging Area)

Staging Memory

Datenquellen Abb. 2.3  DWH-Schichtenarchitektur. (Quelle: eigene Darstellung)

2.2  Data-Warehouse-basierte Reportingansätze

27

Auf diese Datenschicht haben Endbenutzer in der Regel keinen direkten Zugriff, sondern sie versteht sich als Plattform für weiterführende Datentransformationen. Durch das vergleichsweise schnelle Kopieren der Rohdaten aus den Quellsystemen erfolgt hier eine nur minimale Belastung. Da sich die Daten hier bereits innerhalb der DWH-Datenbank befinden, lassen sich alle weiteren Aufbereitungsschritte des Datenmaterials mit Da­ tenbank-­Bordmitteln (z. B. mit Datenbank-Prozeduren bzw. -Skripten) durchführen. Als weiterer Vorteil dieser Vorgehensweise gilt, dass bei auftretenden Fehlern während der Befüllung des Enterprise DWH keine weiteren Zugriffe auf die Quellsysteme erforderlich sind, weil die Rohdaten für einen neuen Durchlauf bereits im Acquisition Layer vorliegen. Integration Layer Der Integration Layer entspricht dem Enterprise oder Core DWH klassischer Prägung und bildet mit aufbereiteten Daten das Ziel der Transformations- und Harmonisierungsprozesse in ihrer vollständigen Historie. Im Gegensatz zu früheren Lösungen finden sich die Daten hier heutzutage oftmals in der größtmöglichen Detailierung, d. h. bis auf die Beleg­ ebene der datenliefernden Vorsysteme. Das gesamte gespeicherte Datenvolumen kann in dieser Komponente bis in den dreistelligen Terabyte-Bereich und darüber hinaus anwachsen, zumal die Daten über einen mehrjährigen Zeitraum vorgehalten werden. Im Idealfall existiert unternehmens- oder gar konzernweit lediglich ein einzelnes Enterprise DWH, das dann mit abgestimmten und qualitätsgesicherten Daten den Single Point of Truth oder Trust (SPOT) bildet. Der Integration Layer vereinigt durch die Bereitstellung der gesamten relevanten Unternehmensdaten in detaillierter und integrierter Form damit sowohl eine Sammel- und Integrationsfunktion als auch als Hub für nachgelagerte Schichten eine Distributionsfunktion in sich. Propagation Layer Der Propagation Layer implementiert einheitliche Business-Logiken bzw. Business Rules, indem eine zentrale Ermittlung abgeleiteter Merkmale und Kennzahlen an einer Stelle erfolgt. Durch die zentralisierte Ableitung wird vermieden, dass unterschiedliche Berechnungsvorschriften auf dem Weg zu den nachgelagerten Data Marts zur Anwendung gelangen. Je nach Anwendungsfall kann auf diese Schicht auch verzichtet werden. Reporting Layer Der Reporting Layer stellt Daten für den Fachbereich aufbereitet entsprechend der betriebswirtschaftlichen Aufgabenstellungen zur Verfügung. Im Allgemeinen erfolgt die Speicherung dieser Daten in unterschiedlichen, aufgabenbezogenen Data Marts und dort mit multidimensionalen Datenstrukturen, wobei in immer stärkerem Maße auch die Belange von Self Service BI Beachtung finden. Aufgrund der ausgeprägten Volatilität der Anforderungen aus den Fachbereichen (Business Requirements) muss eine gute Anpassbarkeit durch hohe Agilität gewährleistet sein. Im Bereich der Finanzdienstleistungsunternehmen finden sich häufig DWH-­ Archi­ tekturen, die vor mehr als zehn Jahren aufgebaut und seitdem weiterentwickelt wurden

28

2  Technologische und konzeptionelle Ansätze zur Analyse und zum Reporting von …

(vgl. Diekmann und Bresbak 2016, S. 30). Dies führt häufig zu sehr komplexen Systemen, die nur mit erheblichem Aufwand zu betreiben und zu warten sind. Weiterhin sind im Laufe der Zeit oftmals unterschiedliche Entwicklungsvorgaben zum Tragen ­gekommen, so dass ein klares und durchgängiges Architekturkonzept nicht immer auszumachen ist.

2.2.3 Extraktion, Transformation und Laden von Daten Das Extrahieren, Transformieren und Laden von Daten erweist sich oftmals als sehr zeit­ intensives und aufwändiges Unterfangen, zumal die einzelnen Verarbeitungsketten leicht eine erhebliche Komplexität aufweisen und Abhängigkeiten zwischen einzelnen Jobs zu beachten sind. Prinzipiell ist zunächst zwischen dem erstmaligen, initialen Befüllen eines DWH und der nachgelagerten periodischen Aktualisierung zu unterscheiden. Bei der erstmaligen Beladung eines DWH sind in der Regel umfangreiche und vielfältige Datenmengen zu bewegen, was einen ausgeklügelten und abgestimmten Beladungsplan erfordert. Da bei der Nutzung der DWH-Datenbasis von Beginn an auf längere Zeitreihen zurückgegriffen werden soll, stammen die Daten oft aus unterschiedlichen Speicherumgebungen – teils sogar aus Archivbeständen. Nicht selten brauchen die zugehörigen ETL-Prozesse dann mehrere Tage oder gar Wochen, bis der erforderliche Datenbestand im DWH verfügbar ist. Als größere Herausforderung erweisen sich allerdings regelmäßig die periodischen Aktualisierungsläufe, da hierfür häufig nur begrenzte Zeitscheiben zur Verfügung stehen. Aus diesem Grund gelingt es kaum, bei einem Aktualisierungslauf den kompletten Datenbestand im DWH neu aufzubauen (Full Load), vielmehr findet vielfach ein inkrementelles Laden (Incremental oder Delta Load) Verwendung. Dabei werden nur die Daten, die sich seit dem letzten Update geändert haben, in das DWH übertragen. Vor allem in IT-Systemlandschaften, in denen, wie in vielen Finanzinstituten üblich, zahlreiche Altsysteme als Datenlieferanten angeschlossen werden müssen, erweist sich die Identifikation der Dateninkremente (neue oder geänderte Inhalte seit dem letzten Update) als nicht zu unterschätzende Herausforderung. In diesem Kontext hat sich die Begrifflichkeit Change Data Capture (CDC) als Sammelbegriff für die Datenintegration durch Identifikation, Erfassung und Weiterleitung von Änderungen an den Unternehmensdatenquellen etablieren können. Hierunter fallen verschiedene Einzeltechniken: Einsatz von Zeitstempelung, Versionsnummerierung und Statusindikatoren (meist boolesches Feld) zur Erkennung von Änderungen, aber auch die Nutzung von Datenbank-Triggern sowie die Analyse von Datenbank-Log-Dateien. Falls Änderungen an den Quellsystemen vollständig ausscheiden, lässt sich häufig lediglich auf das sogenannte Schnappschuss-­ Vergleichsverfahren zurückgreifen (vgl. Abb. 2.4). Hierbei erfolgt ein satzweiser Abgleich eines aktuellen, domänenbezogenen Datenbestandes (z. B. Kundendaten) mit den Inhalten des letzten, diesbezüglichen Updates, um die relevanten Unterschiede zu lokalisieren. Weitere Kategorisierungsmöglichkeiten für Extraktionsprozesse bieten die verwendeten Lieferverfahren und Austauscharten. Die Lieferverfahren gliedern sich grob in

2.2  Data-Warehouse-basierte Reportingansätze

Quellsystem

29

Staging Area Kundentabelle alt

Kundentabelle aktuell

Kundentabelle Inkrement

Abb. 2.4  Schnappschuss-Vergleichsverfahren. (Quelle: eigene Darstellung)

Push-Verfahren (operative Vorsysteme liefern die Extrakte aktiv an) und Pull-Verfahren (aus der dispositiven Systemumgebung wird z. B. per ETL-Tool aktiv auf die Vorsysteme zugegriffen). Bei den Austauscharten lassen sich entkoppelte (Austausch z. B. per XML- oder CSV-Format) von direkten (über Datenbankkonnektoren) Zugriffen ab­ grenzen. Eine wichtige Rolle spielt in diesem Kontext die Aktualisierungshäufigkeit. In den meisten Fällen erfolgt derzeit eine DWH-Aktualisierung in belastungsarmen Zeiten – dies bedeutet im Nachtbetrieb oder auch an Wochenenden. Die Aktualität im DWH spiegelt dann den Stand der operativen Daten vom Vortag wider. Je nach Anwendungsfall ist zu prüfen, ob eine untertägige oder gar eine Right-/Real-Time-Aktualisierung erforderlich ist. Es liegt auf der Hand, dass hierbei besondere Herausforderungen erwachsen, die sich mit den konventionellen ETL-Werkzeugen kaum bewältigen lassen. Vielmehr kommen spezielle Tools zum Einsatz (wie z. B. Messaging Server), die allerdings einer angepassten und komplexen Architektur bedürfen. Der Transformationsschritt im Rahmen des ETL-Prozesses gliedert sich in vier aufei­ nander folgende Sub-Prozesse (vgl. Kemper und Finger 2016, S.  132), die in Abb.  2.5 veranschaulicht sind: • • • •

Validieren, Filtern und Bereinigen Harmonisieren Aggregieren Anreichern

Durch die Validierung wird überprüft, ob sich die vorhandenen Daten für den vorgesehenen Zweck verwenden lassen (vgl. Apel und Behme 2010, S. 117). Das Ziel ist, die Benutzer vor schlechten Daten zu schützen. Hierbei kann unterschieden werden zwischen

30

2  Technologische und konzeptionelle Ansätze zur Analyse und zum Reporting von …

Transformieren

Quelldaten

DWH / ODS Anreichern

Aggregieren

Extrahieren

Harmonisieren

Laden

Validieren, Filtern und Bereinigen

Abb. 2.5  Sub-Prozesse bei der Transformation von Daten im Rahmen des ETL-Prozesses. (Quelle: eigene Darstellung)

• Validierung mit formalen Datenregeln: Prüfung auf Übereinstimmung mit erwarteten Strukturen (z. B. hinsichtlich Datentypen, Referenzieller Integrität, Null Values) • Validierung mit fachlichen Geschäftsregeln: Überprüfung auf Gültigkeit bei diskreten, abzählbaren Domänen, wie z. B. den Filialen, den Geschäftskunden Während die Filterung den Datenbestand auf die tatsächlich relevanten Inhalte reduziert, korrigiert die Bereinigung semantische und/oder syntaktische Fehler, die in der Regel auf unzureichende Integritätsprüfungen in den Vorsystemen zurückzuführen sind. Zu beobachten sind die folgenden Integritätsdefizite: • Falsche Datentypen (z. B. Buchstaben in numerischen Feldern) • Wertebereichsverletzungen (z. B. der Ausweis von Nominalbeträgen in einem Feld, das die Ausfallwahrscheinlichkeit vorhält) • Inhaltliche Fehler bei korrekter Syntax (treten auf, wenn das Vorsystem Einträge in Mussfelder erfordert, ohne dass die korrekte Ausprägung bekannt ist, oder bei Einträgen in Feldern, die eigentlich für andere Inhalte vorgesehen sind), • Fehlende Werte (Null Values, wobei die Ausprägung nicht existent oder nicht bekannt sein kann) • Fehlende institutsweit gültige Identifier (z.  B. bei der Einspielung und Verarbeitung externer Ratinginformationen) Als weitere und sehr wesentliche Aufgabe im Rahmen der Bereinigung erweist sich die Erkennung von Dubletten, die sich in Form unterschiedlicher Datensätze für gleiche reale

2.2  Data-Warehouse-basierte Reportingansätze

31

Objekte manifestieren (z. B. zwei identische Datensätze für denselben Kunden). Die Identifikation und Eliminierung derartiger Dubletten erweist sich als durchaus anspruchsvoll und kann in den meisten Fällen nur durch manuelle Prüfung vorgenommen werden. Als weiterer Schritt im Rahmen der Transformation gilt die Harmonisierung, die sich das Ziel setzt, Daten aus verschiedenen Vorsystemen abzustimmen, zu verknüpfen und anzugleichen. Zunächst geht es hierbei um eine syntaktische Vereinheitlichung, die deshalb erforderlich ist, weil mit unterschiedlichen Währungen oder auch Datentypen und Kodierungen gearbeitet wurde. Als besondere Herausforderung erweisen sich die verschiedenen Schlüsselungsverfahren in den Vorsystemen, insbesondere im Hinblick auf die Stammdaten. Hier finden sich dann diverse Unterschiede bezüglich Aufbau und Ausgestaltung von beispielsweise Produkt- oder Kundenummern. Als Lösung bietet sich die Erstellung einer Lookup-Tabelle an, die in den Zeilen die jeweiligen Objekte (wie die Produkte oder Kunden eines Instituts), in den Spalten die einzelnen Vorsysteme sowie an den Kreuzungspunkten die zugehörigen Wertausprägungen abbildet und dann im Rahmen des ETL-Prozesses zum Einsatz gelangt. Als besonders schwierig lässt sich die semantische Vereinheitlichung der Daten verstehen, bei der differierende Begriffsverständnisse für Geschäftsobjekte und Berechnungsmethoden für Kennzahlen zu harmonisieren sind. Hierbei ist viel Überzeugungsarbeit nötig, um die Anwender der jeweiligen Vorsysteme von einer Abkehr von althergebrachten Sichtweisen zu überzeugen. Nach der Harmonisierung erfolgt der nächste, optionale Prozessschritt: die Aggregation. In Rahmen der Aggregation werden auf der Basis vorgegebener Hierarchien Verdichtungen des Detaildatenmaterials berechnet, die dann aus Gründen der Performanceoptimierung vorberechnet im DWH gehalten werden können (z. B. quantitative Monats-, Quartals- oder Jahresgrößen aus vorgegebenen Tageszahlen). Im letzten Schritt der Transformation erfolgt im Rahmen der Anreicherung die Kalkulation neuer Größen aus den zuvor gefilterten, harmonisierten und teilweise aggregierten Daten, die sich dann auch später physisch im DWH finden und nutzen lassen (z. B. durch Berechnung eines Saldos aus Einzelbuchungen). Den finalen Teilprozess im Rahmen des ETL-Durchlaufs bildet das Laden der Daten in die Zielumgebung, die in Anlehnung an Abb. 2.2 dem Data Mart zur Darstellung der Risikosituation eines Instituts entspricht (vgl. Abb. 2.6). Im vorliegenden Beispiel werden die Zielfelder der Entitäten zur Abbildung der Risikoarten aus dem jeweiligen Vorsystem nach Durchlauf der Extraktions- und Transformationsschritte befüllt. Beim Laden der Daten kann es sich als erforderlich erweisen, eine nochmalige Überprüfung der referenziellen Integrität durchzuführen, um sicherzustellen, dass keine Bewegungsdaten ohne zugehörige Stammdaten gespeichert werden. Zudem erfolgt hier häufig die Historisierung der Daten (Zeitstempelung, um Gültigkeitszeiträume nachvollziehen zu können). Bei Finanzdienstleistern findet sich oftmals (als Variante zum klassischen ETL-­ Vorgehen) ein ELT, um die relevanten Daten aus den Vorsystemen zu extrahieren und in das Core DWH zu laden. Hierbei werden die Daten aus den Vorsystemen zunächst 1:1 in

32

2  Technologische und konzeptionelle Ansätze zur Analyse und zum Reporting von …

Datenbereitstellung

Risikovorsorge _Risikovorsorge_ID _Kategorie EWB/PWB _Land _Branche _[…]

Kreditrisiko _Risikoklasse _Kreditart _Kreditvolumen _PD/Rating _RWA _[…]

Marktpreisrisiko _Assetklasse _Handelsbereich _Bewertungsverfahren _Geschäftsvolumen _Value-at-Risk (VaR) _[…]

Kundenstammdaten _Kundennummer _Kundenname _Sitzland _[ [ ] […] _[…]

Sicherheitendaten _Sicherheiten_ID _Sicherheitenklasse _Produktgruppe _[…]

Zinsrisiko _Zinsrisiko_ID _Stichtag _Konzern _Währung _[…]

Operationelles Risiko _Schadensfall _Schadensart _Schadenshöhe _[…]

Risiko Data Mart

Datenquellen Risikomanagement

Meldewesen

Risikovorsorge

SAP BP Kundendaten

Offenlegung §§ 319ff. SolvV

DWH

Abb. 2.6  Beispiel zur Befüllung eines Risiko Data Marts. (Quelle: eigene Darstellung)

einen Staging-Bereich transferiert, der sich bereits als abgetrennter Teil der gesamten Datenbankumgebung und damit als Teil des DWH verstehen lässt. Die anschließende Transformation der Daten erfolgt dann mit datenbankeigenen Funktionen, wie Views und Datenbankskripten. Der Vorteil dieser Vorgehensweise liegt in der Ausnutzung der hohen Verarbeitungsleistung des Datenbankservers.

2.2.4 Berichtssysteme und -lösungen Die folgenden Abschnitte thematisieren verschiedene Ausprägungen von Berichtssystemen und -lösungen, die in Finanzinstituten zum Einsatz kommen. Dabei unterscheiden sich klassische Berichtsansätze, zu denen das Standard- und Ad-hoc-Reporting gehören (vgl. Abschn. 2.2.4.1), vom Ansatz des Dashboarding, das auf eine stärkere Interaktion mit dem Berichtsanwender abzielt (vgl. Abschn.  2.2.4.2). Mit dem Self Service BI wird in Abschn. 2.2.4.3 ein Konzept vorgestellt, das das Ziel verfolgt, den individuellen Informationsbedarf von Fachanwendern zu unterstützen.

2.2.4.1 Ad-hoc- vs. Standard-Reporting Finanzinstitute weisen heute ein mehr oder minder ausgeprägtes Berichtswesen auf, das zum einen die Aufgabe hat, die Mitarbeiter ereignis- oder zeitgesteuert mit relevanten Informationen zu versorgen. Zum anderen dient ein wesentlicher Teil des Berichtswesens ausschließlich regulatorischen Zwecken, z. B. zur Erstellung von bankaufsichtlichen Meldungen gemäß Common Solvency Ratio Reporting (CoRep) und Financial Reporting (FinRep). Einem weiten Begriffsverständnis folgend umfasst das Berichtswesen generell

2.2  Data-Warehouse-basierte Reportingansätze

33

alle Personen, Organisationseinheiten, Vorschriften, Daten und Prozesse, die bei der Erzeugung und Weiterleitung von Berichten beteiligt sind (vgl. Küpper 2005, S. 170). Als Berichte lassen sich Dokumente verstehen, die unterschiedliche Informationen für einen bestimmten Untersuchungszweck miteinander kombinieren und in aufbereiteter Form vorhalten (vgl. Kemper et al. 2004, S. 110). Falls die Berichte in elektronischer Form erzeugt und/oder präsentiert werden, lässt sich die zugehörige technische Gesamtlösung als Berichtssystem bezeichnen. Kennzeichnend insbesondere für das IT-gestützte Standardberichtswesen ist, dass die erforderlichen Berichte weitgehend automatisch erzeugt werden und dem Berichtsempfänger damit eine eher passive Rolle zukommt. Auf der Basis vorgedachter Strukturen verknüpfen sie die zugehörigen Informationspartikel und bereiten diese empfängergerecht auf. Dabei reicht das vornehmlich in den größeren Instituten implementierte interne Berichtswesen zumeist deutlich über die vom Gesetzgeber und der Aufsicht vorgeschriebenen regulatorischen Anforderungen und Rechnungslegungsvorschriften hinaus. Bisweilen wird das Berichtswesen auch ausschließlich auf die (unternehmens-) interne Informationsübermittlung reduziert (vgl. Horvath 2006, S. 584). Schließlich ist es für die Fach- und Führungskräfte wesentlich, in periodischen Abständen oder im Bedarfsfall bestimmte Fakten geliefert zu bekommen, die helfen, Trends zu identifizieren, Planungen durchzuführen oder Kontrollaufgaben wahrzunehmen. Auf unterschiedlichen Wegen wandern diese Informationen durch den betrieblichen Instanzenweg und werden dabei verdichtet, bereinigt, ergänzt, modifiziert oder manipuliert. Die Probleme, die bei der Implementierung eines adäquaten Berichtswesens auftreten können, sind nicht zu unterschätzen, zumal Tages-, Wochen-, Monats-, Quartals- und Jahresberichte, aber auch Projektberichte oder Mitarbeiterbeurteilungen zu erstellen sind. Als potenzielle Empfänger bzw. Nutzer der für den unternehmensinternen Gebrauch bestimmten Reports kommen prinzipiell die Fach- und Führungskräfte aller Hierarchieebenen und Abteilungen sowie externe Empfänger in Betracht. Damit reicht das Adressatenspektrum vom Top-Management bis auf die Sachbearbeiterebene. Diese Nutzergruppen erheben sehr unterschiedliche Anforderungen an die formale und inhaltliche Gestaltung einer angemessenen Informationsversorgung. Als Zusammenstellungen relevanter Informationen präsentieren Berichte bzw. Reports dem Benutzer ihre Inhalte entweder direkt am Bildschirm oder als Papierdokument in möglichst anschaulicher und angemessener Form. Zumeist erfolgt bei den traditionellen Reporting-Ansätzen ein direkter Zugriff auf die Speicherkomponenten der operativen Anwendungssysteme in Verbindung mit einer seitenorientierten Aufbereitung des Datenmaterials für eine spätere Druckausgabe. Häufig wird dabei eine sehr detaillierte Sichtweise auf Einzelbelegdaten mit vordefinierten Zwischen- und Endsummen angeboten. Wie in Abb. 2.7 verdeutlicht ist, bieten bestehende Reporting-Lösungen die Möglichkeit, Berichte, z. B. zur Steuerung von verschiedenen Risikoarten, in einer Ordnerstruktur abzulegen und ausgewählten Benutzern bzw. Benutzergruppen zur Verfügung zu stellen. Dabei lässt sich für jeden Bericht der Zugriff auf berechtigte Inhalte anwenderindividuell konfigurieren.

34

2  Technologische und konzeptionelle Ansätze zur Analyse und zum Reporting von …

Abb. 2.7  Beispiel für intranetbasierte Bereitstellung von Berichten. (Quelle: eigene Darstellung)

Als anhaltender Trend kann beobachtet werden, dass die Reportingfunktionalität verstärkt von den operativen Anwendungssystemen gelöst und im Umfeld einer vorhandenen analyseorientierten Datenhaltung (in Form eines DWH) angesiedelt wird. Dies gilt umso mehr, wenn einzelnen Mitarbeitern auch ein direkter Durchgriff auf die Datenbestände eröffnet wird. Entsprechende Abfrage- oder Auskunftssysteme ermöglichen dem Anwender, im Bedarfsfall selbstständig Daten aus einem vorhandenen Datenbestand zu extrahieren (Ad-hoc-Berichtswesen). Zumeist basieren diese Systeme auf einer Datenbank oder einem Dateisystem. Falls die Abfragen bereits vorformuliert sind, muss der Anwender diese lediglich anstoßen. Die freie Abfrage stellt höhere Ansprüche an die Fähigkeiten des Bedieners, da es hier tieferer Einblicke in die Funktionalität des Abfragesystems bedarf. Ist das System etwa auf der Basis eines Datenbanksystems realisiert, muss der Benutzer zumindest mit den zugrunde liegenden Datenstrukturen vertraut sein. Allerdings bieten die freien Abfragesysteme große Flexibilität beim Aufsuchen und Zusammenstellen relevanter Daten. Bei allen Arten von Berichtssystemen lässt sich die Designer- bzw. Entwicklersichtweise von der Sichtweise der Endbenutzer abgrenzen. Prinzipiell beinhaltet jeder Bericht und jede Abfrage zwei unterschiedliche Ebenen oder Modi: einerseits die abstrakte Schablone mit unterschiedlichen Formatierungs- und Gestaltungselementen, die sich im Design- oder Entwurfsmodus manipulieren lassen, und anderseits das konkrete Berichtsergebnis, das sich erst durch die Anwendung auf bestimmte Problemdaten ergibt.

2.2  Data-Warehouse-basierte Reportingansätze

35

2.2.4.2 Dashboarding Im Gegensatz zu Reporting-Lösungen bieten Performance Dashboards und BI-Portale die Informationen nicht in druckoptimierter Form an, sondern sind eher auf die Nutzung am Bildschirm ausgerichtet. Den Ansatz des klassischen Berichtswesens weiterführend inte­ grieren diese Lösungen unterschiedliche Informationszusammenstellungen, wie beispielsweise einzelne Berichte, am Bildschirm und reichern diese mit zusätzlichen Inhalten an. Während jedoch beim Portal-Ansatz stets die Integration unterschiedlicher Inhalte unter einer gemeinsamen Oberfläche erfolgt, steht beim Dashboard-Konzept die Komprimierung zentraler und relevanter Fakten auf zumeist einer Bildschirmseite im Vordergrund, wie die folgenden Ausführungen zeigen. Performance Dashboards versuchen, sich an der visuellen Wahrnehmung des Menschen bei der Aufnahme von Informationen zu orientieren und verwenden dazu intuitiv verständliche und anschauliche Gestaltungsarten. Die Bezeichnung der als spezielle Ausprägung zu interpretierenden, teilweise aber auch synonym verstandenen (Management-) Cockpits lässt bereits erahnen, um welche Visualisierungsformen es sich dabei handelt: Neben den verbreiteten tabellarischen und geschäftsgrafischen Aufbereitungen von Datenmaterial werden hier insbesondere alle Arten von Tachometeranzeigen (in Analogie zum Automobil oder Flugzeug) bzw. künstlichen analogen Anzeigeinstrumenten sowie Landkartendarstellungen verwendet, die sich in Tabellenkalkulationsoberflächen integrieren lassen. Explizites Ziel der Ansätze ist es, wesentliche Informationen, z. B. zur Darstellung der Risikosituation eines Instituts, verdichtet und auf einen Blick wahrnehmbar zu präsentieren. Ein Bespiel für ein Dashboard zur Analyse von Liquiditätsrisiken liefert Abb. 2.8.

Abb. 2.8  Exemplarisches Dashboard zur Analyse von Liquiditätsrisiken. (Quelle: eigene Darstellung)

36

2  Technologische und konzeptionelle Ansätze zur Analyse und zum Reporting von …

Im Zuge der Verbreitung von mobilen Endgeräten wird zunehmend die Nutzung von Dashboards auf Smartphones oder Tablets unterstützt. Auch wenn die unterschiedlichen Spielarten von Performance Dashboards stark variieren, sind einige typische Eigenschaften auszumachen, über die sie sich charakterisieren lassen (vgl. Few 2006, S. 35): Komprimierte Darstellung Performance Dashboards präsentieren die zur Erfüllung der nutzerbezogenen Aufgaben benötigten Informationen in komprimierter Form, häufig auf einer Bildschirmseite, damit der Anwender die relevanten Inhalte „auf einen Blick“ erfassen kann. Dabei bedienen sie sich geeigneter Visualisierungstechniken, um auch komplexe Strukturen und Zusammenhänge unmittelbar erfassbar darzustellen. Konzentration auf wesentliche Informationen Dashboards bieten relevante Inhalte auf aufgabenadäquaten Aggregationsstufen an und verzichten auf eine Überfrachtung mit Detailinformationen. Sie unterstützen den Anwender dabei, wesentliche Fakten rasch zu erfassen, beispielsweise durch geeignete farbliche Markierungen (Ampelfarben) oder durch gesonderte textuelle Hinweise. Spezifische Lösung Dashboards sind stets auf die Belange eines Arbeitsplatzes, einer Person oder einer Personengruppe zugeschnitten. Eine Abgrenzung von Performance Dashboards und BI-­Portalen lässt sich nicht immer trennscharf vornehmen. Generell kann festgehalten werden, dass Portale einen zentralen Zugang zu ausgewählten Themenbereichen sowie den zugehörigen Informationen und Diensten bieten. Als konstituierendes Merkmal ist eine Zusammenführung von Inhalten und Funktionalitäten aus unterschiedlichen Vorsystemen zur Laufzeit zu verstehen. Aus diesem Grund lässt sich als spezielle Portal-Funktionalität das Single Sign-­on anführen, das eine mehrfache Anmeldung eines Anwenders an unterschiedlichen, eingebundenen Systemen verhindern soll. Vielmehr kann nach einmaliger Authentifizierung des Anwenders gegenüber dem BI-System (z. B. durch Benutzerkennung und Passworteingabe) ein Zugriff auf alle eingebundenen Systeme im Rahmen der zugehörigen Berechtigungen erfolgen. Auch aus dem Blickwinkel der Systemsicherheit erweist sich das Single Sign-on als wünschenswert, da sich die Anwender lediglich ein Passwort merken müssen und eine mehrfache Übertragung von Passwörtern über die Netzwerke durch einen Nutzer vermieden werden kann. Selbstverständlich bedeutet dies auch, dass einem Angreifer nach dem erfolgreichen Ausspähen von Benutzername und Passwort alle angeschlossenen Systeme offenstehen. In aller Regel bieten Portale im Vergleich mit Performance Dashboards weiterführende Navigationsmöglichkeiten, um unterschiedliche Facetten oder Detaillierungsstufen eines Themas beleuchten zu können. Moderne Portal-Lösungen nutzen dabei alle Darstellungsformen, die auch bei den Dashboards eingesetzt werden, und erweisen sich ebenso stets als arbeitsplatz- und/oder personengruppenbezogen mit ausgeprägten Personalisierungsmöglichkeiten. Abb. 2.9 vermittelt einen Eindruck über das mögliche Erscheinungsbild eines BI-Portals.

2.2  Data-Warehouse-basierte Reportingansätze

37

Abb. 2.9  Exemplarisches BI-Portal. (Quelle: eigene Darstellung)

Das Beispiel zeigt, wie unterschiedliche Informationssichten bzw. -blöcke simultan und möglichst synchronisiert am Bildschirm dargestellt werden. Navigationshilfen erlauben abweichende Zusammenstellungen zur Laufzeit. Häufig werden auch grundlegende Büro-Funktionalitäten integriert, wie beispielsweise E-Mail- und Newsgroup-­ Komponenten sowie Adressverzeichnisse und Terminplanungs-Bausteine, aber auch Suchmaschinen und To-do-Listen. Zudem lässt sich eine Anreicherung durch den Einbezug unstrukturierter Dokumente vornehmen, indem z. B. Präsentationen oder Analystenberichte bis hin zu Videos durch Verlinkung unmittelbar aufrufbar sind. Oftmals ist ein Bildschirmbereich für die Anzeige interessanter Nachrichten reserviert, die sich allerdings auch in Form eines Laufbandes am Bildschirmrand visualisieren lassen. Da die Anfragen häufig Inhalte aus unterschiedlichen Anwendungen betreffen und diese gleichzeitig am Bildschirm darzustellen sind, wird häufig (wie bei Portalen allgemein üblich) mit Portlets gearbeitet. Jedes Portlet bildet dabei als Container für eine spezielle Applikationssicht innerhalb einer Browserseite ein eigenständiges Fenster mit den gebräuchlichen Schaltflächen zum Schließen, Minimieren, Maximieren und für die Hilfe. Innerhalb vorgegebener Grenzen kann der Anwender die für ihn relevanten Portlets am Bildschirm arrangieren und auch ausblenden. Durch die Strukturierung, Filterung und Aufbereitung des verfügbaren Informationsangebots versuchen BI-Portale einer Informationsüberfrachtung entgegen zu wirken und

38

2  Technologische und konzeptionelle Ansätze zur Analyse und zum Reporting von …

vermindern die Suchkosten für die Anwender. Die Erstellung von Portalen erfolgt heute generell auf der Basis von Web-Technologien (Web-Portale). Die bevorzugte Anzeige von Inhalten bei Dashboard- und BI-Portal-Lösungen im Web-Browser erfordert als zusätzliche Architekturkomponente zwingend einen Web-Server, dem die Aufgabe zukommt, Nutzeranfragen (Requests) so zu beantworten, dass eine Darstellung der gewünschten Informationen auf der Oberfläche erfolgen kann.

2.2.4.3 Self Service BI Ein häufig zu beobachtendes Phänomen in den Fachabteilungen von Unternehmen ist, dass trotz sehr leistungsfähiger und individuell zugeschnittener BI-Applikationen die Mitarbeiter eine Nutzung von Tabellenkalkulationsprogrammen weiter vorziehen. Die Gründe hierfür sind sicherlich vielfältig. Eine Ursache könnte darin liegen, dass sich die BI-­Lösungen oftmals immer noch als zu starr und zu wenig flexibel zeigen, wenn es darum geht, neue Anforderungen in einer komplexen BI-Landschaft rasch umzusetzen oder innovative Analysen testweise im eigenen Hause auszuprobieren, um deren Wertbeitrag zu überprüfen. Hier setzt das Konzept der Self Service BI an, das über die Bereitstellung verschiedener Funktionalitäten für die Navigation und Investigation von Daten den Fachanwender in die Lage versetzt, nicht nur eigenständig und flexibel den Datenbestand nach neuen Verknüpfungen zu untersuchen, sondern auch unabhängig von der Unternehmens-IT seine Systeme betreiben und intuitiv bedienen zu können (vgl. Imhoff und White 2011, S. 5). Ein Beispiel für den Self-Service-BI-Ansatz im Themenbereich Kreditrisiko-Rating liefert Abb. 2.10. Durch die integrierten Filter ergeben sich für den Benutzer vielfältige Analyseund Navigationsmöglichkeiten.

Abb. 2.10  Anwendung für Self-Service-BI. (Quelle: eigene Darstellung)

2.2  Data-Warehouse-basierte Reportingansätze

39

Häufig sind dazu über die herkömmlichen Funktionalitäten für die Navigation und Investigation von Daten hinaus auch weiterführende Analysefunktionen aus der Statistik und aus dem Forschungsbereich Human Computer Interaction, wie z. B. der Einsatz von Tree Maps, zur Visualisierung und Untersuchung hochdimensionierter Datenstrukturen implementiert (vgl. Abb. 2.11). Als sehr eingängig erweisen sich zudem Kartendarstellungen (vgl. Abb. 2.12), die es z. B. erlauben, die Auftragseingänge in einer bestimmten Branche als Inputfaktor zur Risikofrüherkennung und automatisierte Risikoklassifizierung in einer geografischen Darstellung zu visualisieren (siehe hierzu auch den in Abschn. 3.1 dargestellten Anwendungsfall). Um hierzu auch dringende Informationsbedarfe befriedigen zu können, wird oftmals auf das Konzept des Sandboxing zurückgegriffen, bei dem den Fachanwendern Datenmaterial in einem abgegrenzten Datenbankbereich zur freien Verfügung gestellt wird. Erst wenn sich dieses Datenmaterial nach einer eingehenden Erprobung durch den Fachanwender und nach der testweisen Erstellung spezifischer Analysen und Berichte als werthaltig für das Institut erweist, werden die Daten und zugehörigen Auswertungen in den Regelbetrieb übernommen und auch anderen BI-Usern zur Verfügung gestellt. Self Service BI in Verbindung mit Sandboxing adressiert unmittelbar die zunehmende Mündigkeit der Fachanwender im Hinblick auf Systeme und Anwendungen, die durch die

Abb. 2.11  Visual BI in Form einer Tree Map. (Quelle: eigene Darstellung)

40

2  Technologische und konzeptionelle Ansätze zur Analyse und zum Reporting von …

Abb. 2.12  BI-Anwendungen mit geografischen Informationen. (Quelle: eigene Darstellung)

Option zur eigenständigen Durchführung neuer Auswertungen und Analysen dem steigenden Zeitdruck und der wachsenden Dynamik wirksam begegnen können. Durch potenzielle Einsparungen im IT-Sektor kann möglicherweise sogar dem Kostendruck Rechnung getragen werden. Hauptargument aus fachlicher Sicht ist der Zeitgewinn bzw. die gewonnene Flexibilität im Umgang mit zusätzlichen Berichtsanforderungen. Über den Einsatz von Self Service BI lässt sich eine zeitraubende formalisierte Adressierung der Berichtsanforderungen an die IT umgehen. Durch die fortschriftlichen Darstellungsformen der Visual BI gelingt es zudem, auch hochkomplexe Sachverhalte zu strukturieren und auszuwerten (vgl. Eckerson und Hammond 2011, S. 7). Je nach Anspruchshaltung der Anwender bieten die Werkzeuge einen leichten Einstieg für gelegentliche Nutzer, aber auch fortgeschrittene Funktionalitäten mit methodischer Tiefe.

2.3

Big Data als Enabler für das Risikoreporting

Kaum ein technologisches Thema sorgt derzeit für größere Aufmerksamkeit in der breiten Öffentlichkeit als das Begriffsgebilde Big Data. Die Erklärung dafür ist leicht ausgemacht: Noch nie wurden derart gewaltige Datenmengen produziert wie in jüngster Zeit. Sei es im Internet, wo Abermillionen schreibfreudige User sich derzeit als Content Provider betätigen, oder durch die Radio-frequency Identification (RFID)-Technologie, die dazu führt, dass das Zeitalter der miteinander kommunizierenden Dinge (Internet of Things, IoT) längst angebrochen ist.

2.3  Big Data als Enabler für das Risikoreporting

41

Es liegt auf der Hand, dass sich auch in den Peta- und Exabyte an Daten der Finanzinstitute interessante Informationen finden lassen, wenn es nur gelingt, dieses gewaltige Datenvolumen zielgerichtet auszuwerten. Verstärkt setzen sich auch wissenschaftliche Veröffentlichungen mit dem Phänomen auseinander und versuchen, tragfähige Konzepte zur zeitnahen Verarbeitung polystrukturierter Datenmengen zu entwickeln (vgl. Klein et al. 2013, S. 319). Ausgehend von einer Definition zu Big Data, der sich Abschn. 2.3.1 widmet, werden in Abschn. 2.3.2 verschiedene Big-Data-Architekturvarianten vorgestellt.

2.3.1 Begriffliche Einordnung Allerdings ist eine exakte Definition für das Phänomen Big Data nicht leicht zu finden. Einige Veröffentlichungen zu dem Thema greifen auf eine Negativabgrenzung zurück und stellen heraus, dass Big Data dann gegeben ist, wenn die Kapazitäten und Funktionalitäten der klassischen Datenhaltung, -aufbereitung und -auswertung sich als nicht ausreichend erweisen (vgl. Dittmar et al. 2016, S. 3). Zumeist wird Big Data heute durch die charakteristischen Eigenschaften beschrieben. Dann zeichnet sich Big Data nicht allein durch das immense Datenvolumen (Volume) aus, sondern ebenso durch die erhebliche Vielfalt an Datenformaten (Variety) sowie durch die Geschwindigkeit (Velocity), mit der neue Daten entstehen sowie verfügbar und damit analysierbar sind (vgl. Eaton et al. 2012, S. 5). Im unternehmerischen Bereich stellt sich die Frage, wie sich das verfügbare Datenangebot im Hinblick auf die eigenen Ziele nutzbringend auswerten lässt. Einzelne Anwendungsbereiche liegen sicherlich unmittelbar auf der Hand, wie beispielsweise die Analyse von Daten aus sozialen Netzwerken (Social Media Analysis), um etwa die Meinungen und Stimmungen zu eigenen Leistungen oder Angeboten des Wettbewerbs auszuwerten (Sentiment Analysis). Die Diskussion um das Thema Big Data erreicht derzeit in der öffentlichen Wahrnehmung einen großen Stellenwert. Allerdings liegt die Vermutung nahe, dass es sich hier lediglich um ein neues Schlagwort handelt, hinter dem sich ein doch begrenzter Innovationsgehalt verbirgt. So beinhalten die aufgezeigten betriebswirtschaftlichen Einsatzbereiche für Big Data zahlreiche Anwendungsszenarien, die wohlbekannt erscheinen und für die bereits seit einiger Zeit tragfähige Lösungen aus der BI existieren. Natürlich ist Big Data hier willkommen, wenn es darüber gelingt, Analytics verstärkt in die Fachbereiche der Finanzinstitute zu tragen. Dennoch sind die massiv anwachsenden und analysierbaren Datenvolumina in Verbindung mit zunehmend polystrukturierten Daten ein reales Phänomen, dem es zu begegnen gilt und für das auch neue Technologien und Verfahren heranwachsen. Allerdings kann in Frage gestellt werden, ob eine global verfügbare „Killerapplikation“ dem Thema Big Data zum Durchbruch in den Finanzinstituten verhilft. Vielmehr scheinen es derzeit eher die jeweils spezifischen, an einzelnen Bereichen oder Abteilungen orientierten Fragestellungen zu sein, die es zu bearbeiten und beantworten gilt. Für Finanzin­

42

2  Technologische und konzeptionelle Ansätze zur Analyse und zum Reporting von …

stitute ergeben sich dennoch vielfältige interessante Einsatzgebiete für Big Data Analytics, vor allem wenn es dadurch gelingt, ein umfassenderes und besseres Verständnis des Kunden mit seinen Wünschen und Bedürfnissen zu erlangen, um ihm noch passendere Angebote als bisher unterbreiten zu können. Als große Herausforderung für Big Data erweisen sich der Datenschutz und die Datensicherheit. Insbesondere bei der Analyse von Kunden- oder Mitarbeiterdaten sind die Vorgaben der Datenschutzgesetzgebung genau zu beachten, was einige der möglichen Auswertungen bereits ausschließt. Daneben ist das Vorhalten von Daten auf unternehmensexternen Speicherlösungen, wie z.  B. in einer Cloud, mit zusätzlichen Risiken im Hinblick auf unberechtigte Zugriffe verbunden. Bei Gesprächen mit Vertretern der Finanzindustrie sowie anderer Branchen wird deutlich, dass die Unsicherheiten in Bezug auf das Thema Big Data noch sehr groß sind. Bei allen mehr oder minder offensichtlichen Potenzialen befinden sich die Nutzer noch in einem Orientierungs- oder Experimentierstadium, in dem versucht wird, punktuell und mit eher kleinen Budgets überschaubare Anwendungsfälle mit neuen Technologien zu bearbeiten und dabei Erfahrungen zu sammeln. Aufgrund der großen Beachtung, die Big Data auch im oberen Management derzeit genießt, dürfte eine größere Verbreitung allerdings nicht lange auf sich warten lassen.

2.3.2 Big-Data-Architekturvarianten Speicherarchitekturen für Big-Data-Anwendungen müssen in der Lage sein, große und polystrukturierte Datenbestände zeitnah verarbeiten zu können. Dafür hat sich in den letzten Jahren eine Komponente etabliert, die unter dem Oberbegriff Data Lake diskutiert wird. Ein Data Lake nimmt Daten in ihrer unbearbeiteten, originalen Form direkt von den Datenquellen mit keiner oder wenig Bereinigung, Standardisierung, Ummodellierung oder Veränderung auf. Die Transformation der Inhalte des Data Lakes erfolgt On the Fly im Rahmen der Auswertung (wie z. B. im Rahmen von Ad-hoc Analytics) oder als Zwischenschritt zur Vorbereitung für wiederkehrende Aufgaben (wie z. B. das Berichtswesen) (vgl. Russom 2017). Die Abgrenzung zum klassischen DWH kann anhand unterschiedlicher Kriterien erfolgen, wie Tab. 2.1 verdeutlicht (vgl. Schäfer und Goetze 2016). Allerdings erweist sich ein Data Lake durchaus nicht zwingend als homogenes Gebilde, sondern ist durch unterschiedliche Sektoren und Bereiche geprägt. Neben einem Bereich für die Rohdaten (Raw Data) findet sich häufig auch ein Sektor mit qualitätsgesicherten Daten (Refined Data), die durchaus auch als Quelle für die weitere Verarbeitung in einem DWH dienen können. Hierzu gehört dann eine Refinery Area, in der die Datenvorverarbeitung erfolgt (vgl. Abb. 2.13). Die Einsatzbereiche eines Data Lakes sind vielfältig. Empirische Untersuchungen zeigen, dass die Daten des Data Lakes überwiegend für Aufgaben in den Feldern Advanced

2.3  Big Data als Enabler für das Risikoreporting

43

Tab. 2.1  Data Lake vs. DWH Kriterium Data Lake Datenvolumen Gute Skalierbarkeit auch bei sehr großen Datenmengen Datentypen Polystrukturiert Datenwert Potenziell wertvoll Aufbereitung Daten überwiegend detailliert und original Flexibilität Speicherung im Originalformat erlaubt -Transformation nach Datenablage (Schema-on-Read) Datenquellen Batch, Realtime, Stream

DWH Skalierbarkeit aufwändig und kostenintensiv Strukturiert Anerkannt wertvoll Daten überwiegend veredelt und teils vorkalkuliert Limitierung der Analysemöglichkeit durch vorgegebenes DWH-Schema (Schema-on-Write) Batch

Frontend

Data Lake

Data Governance Refined Data - Qualitätsgesicherte Daten - Typischerweise Daten, die ins klassische DWH übergehen können Data Refiniery - Preprocessing Area

Interne Systeme

Raw Data - Sensordaten - Streaming - Social Media - Dokumente - Bilder

Datenquellen

Externe Systeme

Abb. 2.13  Komponenten eines Data Lakes. (Quelle: eigene Darstellung)

Analytics, Data Discovery und Big Data Analytics genutzt werden, aber auch als Erweiterung des DWHs sowie als Data-Landing- und -Staging-Zone Verwendung finden (vgl. TDWI 2017). Fachliche Anwendungsfelder für die abgelegten Inhalte finden sich beispielsweise im Bereich Betrugserkennung oder auch beim Kampagnenmanagement. Insbesondere die Verarbeitung von Datenströmen stellt oftmals eine große Herausforderung für herkömmliche Speichertechnologien dar. Ein tragfähiger Lösungsansatz für den Umgang mit Streaming Data ist die sogenannte Lambda-Architektur, bei der ein Data Lake ebenfalls in unterschiedliche Bereiche aufgeteilt wird (vgl. Marz und Warren 2015). Dieses Architekturkonzept besteht, wie in Abb.  2.14 dargestellt, aus verschiedenen Komponenten bzw. Schichten, die sich ergänzen und aufeinander aufbauen (vgl. Marz und Warren 2015; Mock et al. 2014; Kröhnert 2016). Als zentrale Eingangsschnittstelle in die Architektur dient der Distribution oder Ingestion Layer, der die Aufgabe hat, die ­ankommenden Daten temporär zu puffern und an die nachfolgenden Batch und Speed Layer weiterzuleiten. Im Batch Layer werden alle eintreffenden Daten physisch gespeichert

44

2  Technologische und konzeptionelle Ansätze zur Analyse und zum Reporting von …

Analytics

Data Service (Merged View)Service Layer Real Time View

Real Time View

Batch View

Incremented Information

Precomputed Views (Map Reduce)

Speed Layer

Batch Layer

Real Time Data Stream

Distribution Layer

…

Batch View

Data Storage (All Data)

Message Service

mobile

IoT

… social

Sensor Layer

Abb. 2.14  Architektur bei Streaming Data. (Quelle: eigene Darstellung)

und in festen Zyklen durch eine gegebenenfalls sehr komplexe und damit zeitintensive Verarbeitungslogik (wie beispielsweise das Trainieren statistischer Modelle im Kontext von Machine Learning) aufbereitet (vgl. Abschn. 4.4). Nach Abschluss der Verarbeitung erfolgt die Übertragung der Ergebnisse (Batch Views) in den Service Layer. Der Speed Layer dagegen hat die Aufgabe, die zwischen den Verarbeitungsläufen des Batch Layers aufgelaufenen Daten entgegenzunehmen und für Auswertungen zur Verfügung zu stellen. Dies geschieht durch eine stetige und inkrementelle Aktualisierung der hier erzeugten Sichten (Real Time Views) bei neu hinzukommenden Daten. Sobald der Batch Layer einen Verarbeitungslauf beendet hat und neue Batch Views zur Verfügung stehen, lassen sich die korrespondierenden Daten aus dem Speed Layer löschen. Dadurch gelingt es, das Datenvolumen hier eher überschaubar zu halten. Zu den Aufgaben des Service Layers gehört es dann, die unterschiedlichen Sichten miteinander zu verknüpfen, damit ein einheitliches Bild über alle Daten hinweg entsteht.

2.4  Business Analytics

45

Zudem sind die Daten so aufzubereiten, dass sie für die zugreifenden Analyse- und Visualisierungswerkzeuge nutzbar sind (vgl. Abb. 2.14). Naturgemäß repräsentiert ein Data Lake nur eine von zahlreichen Komponenten einer komplexen IT-Landschaft. Insbesondere für das Zusammenspiel und die Abgrenzung zwischen Data Lake und klassischem DWH existieren unterschiedliche Gestaltungsansätze (vgl. Hardt und Lenzhölzer 2017). Dennoch stellt ein Data Lake heute eine wichtige Komponente einer modernen, hybriden Datenarchitektur dar. Insgesamt lässt sich festhalten, die sich zeitgemäße analytische Öko-Systeme dadurch auszeichnen, dass in den unterschiedlichen Datenhaltungsbereichen oder -schichten verschiedene Speichertechnologien zum Einsatz gelangen und dadurch die jeweiligen individuellen Stärken einbringen können (vgl. Kromer 2015).

2.4

Business Analytics

Nachdem sich im Kontext entscheidungsunterstützender Systemlösungen der Fokus über lange Jahre verstärkt auf den Aufbau tragfähiger technologischer und organisatorischer Konzepte zum Datenmanagement gerichtet hat, treten in letzter Zeit zunehmend die Methoden und Einsatzbereiche einer fortgeschrittenen Datenanalyse in den Vordergrund. Unter der Begrifflichkeit Business Analytics oder schlicht Analytics werden sowohl in der Wissenschaft als auch zunehmend in der Praxis Verfahren und Technologien diskutiert, die interessante Muster in umfangreichen Datenbeständen aufdecken und Prognosen über zukünftige Ereignisse und Gegebenheiten anstellen können. Ein aktuell wichtiges Einsatzgebiet im Bankenumfeld ist die Erkennung verdächtiger Geldwäsche-Aktivitäten oder anderer „pro­ blematischer“ Transaktionen z.  B. beim Online Banking. Dabei schränkte Business Analytics den Betrachtungsschwerpunkt auf Datenanalysen im unternehmerischen Kontext ein, was sich jedoch durchaus nicht als gänzlich neuartige Anwendungsdomäne erweist. Ausgehend von einer begrifflichen Einordnung, die in Abschn. 2.4.1 erfolgt, werden in Abschn.  2.4.2 relevante Vorgehensmodelle vorgestellt. Abschn.  2.4.4 widmet sich den Analyseverfahren, die im Themenfeld Business Analytics zum Einsatz kommen können.

2.4.1 Begriffliche Einordnung Ein Blick in die Vergangenheit zeigt, dass die methodische Aufbereitung von Daten zu Zwecken der Entscheidungsunterstützung eine lange Vorgeschichte aufweist und bereits in den 1970er- und 1980er-Jahren Decision Support Systems bzw. Entscheidungsunterstützungssysteme als interaktive IT-gestützte Systeme diskutiert wurden, die Entscheidungsträger mit Modellen, Methoden und problembezogenen Daten in ihren Entscheidungsprozessen unterstützen (vgl. Gluchowski et  al. 2008, S.  63). Die ausgeprägte Modell- und Methodenorientierung der eingesetzten Systemlösungen manifestierte sich in

46

2  Technologische und konzeptionelle Ansätze zur Analyse und zum Reporting von …

der Verwendung von statistischen Verfahren zur Berechnung von Wahrscheinlichkeiten und Verteilungen sowie insbesondere in der Anwendung mathematischer Simulationsund Optimierungsverfahren, wie sie in der Disziplin des Operations Research entwickelt wurden. Neue Impulse erlangte die Erforschung von Strukturzusammenhängen (Datenmustern) in Datenbanken durch die künstliche Intelligenz, deren Verfahren des Machine Learning und der Pattern Recognition in den 1990er-Jahren maßgebliche Beiträge zum Aufbau von aktiven Informationssystemen (vgl. Bissantz und Hagedorn 1993) leisten konnten. In diesem Zusammenhang hat sich der Begriff Data Mining etabliert, der das Fördern von wertvollen Informationen aus großen Datenbeständen umschreibt. Der Kontext ist sicherlich weiter zu fassen, als das verkürzte Bild des Schürfens nach wertvollen Informationen nahelegt. Daher erweist sich die Begrifflichkeit Knowledge Discovery in Databases (KDD), die den gesamten Prozess der Wissensentdeckung umfasst, zumindest aus wissenschaftlicher Perspektive als zutreffender. KDD stellt sich der Aufgabe, implizit vorhandenes Wissen in umfangreichen Datenbeständen zu identifizieren und explizit zu machen. Die aufzudeckenden Zusammenhänge, die in Form von Beziehungsmustern aufgespürt werden, sollten bisher unbekannt, potenziell nützlich und leicht verständlich sein (vgl. Fayyad et al. 1996). Als zentrale Prozessphase bei einem KDD-Durchlauf ist die Analyse zu verstehen, bei der die potenziell interessanten Beziehungsmuster (Regelmäßigkeiten, Auffälligkeiten) aus dem Datenbestand destilliert und durch logische bzw. funktionale Abhängigkeiten beschrieben werden. Diese Phase wird auch mit Data Mining gleichgesetzt und lässt sich sehr frei als Datenmustererkennung übersetzen (vgl. Bissantz und Hagedorn 1993, S. 481). Als Aufgabe des Data Minings erweist es sich dann, aus einem bereinigten und vorverarbeiteten Datenbestand durch Einsatz geeigneter Algorithmen Datenmuster zu extrahieren. Die weitgehenden Überschneidungen zur heute gebräuchlichen Begrifflichkeit Business Analytics liegen auf der Hand. Im neuen Jahrtausend konnte sich das Begriffsgebilde Business Intelligence (BI) zunächst in der Praxis und später auch in der wissenschaftlichen Diskussion als Synonym für innovative IT-Lösungen zur Entscheidungsunterstützung fest etablieren (vgl. Gluchowski und Kemper 2006). BI gehört zu der wachsenden Anzahl englischsprachlicher IT-­ Schlagworte, bei denen eine Übersetzung bislang keinen Eingang in den deutschen Sprachgebrauch gefunden hat. Eine Übersetzung mit „Geschäftsintelligenz“ liegt zwar nahe, würde die inhaltliche Bedeutung aber nur unzureichend widerspiegeln. Vielmehr soll „Intelligence“ hier im Sinne von Einsicht oder Verständnis interpretiert werden, wodurch das Ziel des Einsatzes von BI klarer zum Ausdruck gelangt. Nach dem heute vorherrschenden, weiten Begriffsverständnis zählen zu BI alle Systemkomponenten, die dabei helfen, das entscheidungsrelevante Datenmaterial zu sammeln und aufzubereiten, dauerhaft und nutzungsorientiert zu speichern, aufgabenadäquat zu analysieren und in geeigneter Form anzuzeigen (vgl. Gluchowski und Kemper 2006, S. 14). Unter technologischen Gesichtspunkten lassen sich dann zu BI alle Werkzeuge und Anwendungen mit entscheidungsunterstützendem Charakter zählen, die zur besseren Einsicht in das eigene Geschäft und damit zum

2.4  Business Analytics

47

besseren Verständnis der Mechanismen relevanter Wirkungsketten führen (vgl. Gluchowski 2001, S. 6). Durch diese Abgrenzungen wird deutlich, dass sich BI nicht nur auf das reine Informationsangebot an der Endbenutzeroberfläche, z. B. durch Reports oder Dashboards, beschränkt, sondern darüber hinaus auch die weiterführenden Werkzeuge für eine anspruchsvolle Analyse des Datenbestandes umfasst. Dennoch findet sich heute in zahlreichen Zeitschriften und auf Konferenzen die explizite Betonung der Analyse, beispielsweise durch die Wortkonstruktion „Business Intelligence & Analytics“. In letzter Zeit etablieren sich verstärkt Varianten und Erweiterungen des Analytics-­ Begriffs. Als Beispiel hierfür ist Advanced Analytics anzuführen, das sich als Sammlung unterschiedlicher Techniken und Tools verstehen lässt, die Predictive Analytics, Data Mining, statistische Analysen und komplexes SQL (Structured Query Language) sowie Datenvisualisierung und Verarbeitung natürlicher Sprache umfasst (vgl. Russom 2013, S. 5) und damit konventionelle und innovative Analyseverfahren unter einen Oberbegriff zu bringen sucht. Dabei erweist sich Predictive Analytics als Unterbereich von Advanced Analytics, der proaktive Analysetechniken nutzt, um Vorhersagen über zukünftige Ereignisse und Entwicklungen anzustellen (vgl. Halper 2014, S. 18). Noch einen Schritt weiter geht Prescriptive Analytics, da hier über die reine Vorhersage hinaus Handlungsvorschläge unterbreitet und die zugehörigen Konsequenzen aufgezeigt werden. Möglich wird dies, indem weitere, ggf. unternehmensexterne Daten in die Analyse einbezogen und mit zu optimierenden Zielgrößen in Verbindung gesetzt werden (vgl. Evans und Lindner 2012). Die herkömmlichen, rein beschreibenden Verfahren, wie sie in der klassischen BI mit Dashboards und Reports sowie mit On-Line Analytical Processing (OLAP) gegeben sind, werden in diesem Kontext dann auch als Descriptive Analytics bezeichnet. In diesen Bereich fallen in der Regel auch die Lösungen, die sich der Analyse von Web-Daten (Web Analytics) zuwenden und vor allem das Zugriffsverhalten auf sowie die Inhalte von Web-Sites untersuchen. Als frappierend erweist sich die Überschneidung mit der seit langer Zeit gebräuchlichen Kategorisierung von Modelltypen in der Betriebswirtschaftslehre, die zwischen Beschreibungs-, Erklärungs- und Entscheidungsmodellen unterscheidet (vgl. die in Anlehnung an Hahn und Laßmann 1986, S. 63 entwickelte Abb. 2.15). Längst stehen heute nicht mehr nur unternehmensinterne und strukturierte Daten im Fokus analytischer Untersuchungen, sondern verstärkt auch unternehmensexterne Daten, beispielsweise aus sozialen Netzwerken und Foren, sowie unstrukturierte und semi-­ strukturierte Daten, wie sie im Produktionsbereich und in Text-, Video- oder Audio-­ Dateien Gestalt annehmen. Als aktuelle Begrifflichkeiten, welche die beschriebenen Phänomene adressieren, werden heute häufig Big Data oder Big Data Analytics verwendet (vgl. Abschn. 2.3). Die anzutreffenden Big-Data-Analysen beschränken sich nicht nur auf den unternehmerischen Bereich, wie im Kontext Business Analytics, sondern erstrecken sich z.  B. auch auf Non-Profit-Organisationen, den Katastrophenschutz, ­Verkehrsprognosen und den Medizinbereich. Insgesamt lässt sich damit eine Einordnung unterschiedlicher Analytics-Ausprägungen vornehmen, wie in Abb.  2.16 dargestellt.

48

2  Technologische und konzeptionelle Ansätze zur Analyse und zum Reporting von …

Prescriptive Analytics

Zielsystem

Entscheidungsmodell

Predictive Analytics

Ursache-Wirkungsbeziehung zwischen Modellvariablen

Erklärungsmodell

Descriptive Analytics

Abbildung relevanter Merkmale realer Erscheinungen

Beschreibungsmodell

Abb. 2.15  Analysearten und Modelltypen der Betriebswirtschaftslehre. (Quelle: eigene Darstellung in Anlehnung an Hahn und Laßmann 1986, S. 63) Abb. 2.16 Einordnung unterschiedlicher Analytics-­ Ausprägungen. (Quelle: eigene Darstellung)

Analytics

Business Analytics

Descriptive Analytics

Advanced Analytics

Predictive Prescriptive Analytics Analytics

Big Data Analytics

Um den Begriff des Data Mining im Kontext der zuvor erwähnten Analytics-­ Ausprägungen greifbar machen zu können, bietet es sich an, die eingangs genannte Knowledge Discovery in Databases (KDD), die den gesamten Prozess der Wissensentdeckung aus wertvollen Informationen umfasst, als Ausgangspunkt der Diskussion zu wählen (vgl. die aus Fayyad et al. 1996, S. 41 entnommene Abb. 2.17). Data Mining im engeren Sinne ist ein Teilschritt in diesem KDD-Prozess, der von der Datenauswahl über die Vorverarbeitung und Transformation bis zur Interpretation und Evaluierung der Ergebnisse und schließlich zum Wissensgewinn reicht. Die Aufgabe von Data Mining

2.4  Business Analytics

49 Datenmustererkennung

Data Mining

Muster

Transformation Vorverarbeitung Auswahl

Datenbank

Ziel Daten

Vorverarbeitete Daten

Interpretation Transformierte Daten

„Wissen“

Abb. 2.17  KDD-Prozesse. (Quelle: Fayyad et al. 1996, S. 41)

ist es laut Fayyad et al., interessante Muster in den untersuchten Daten zu finden. Hier findet die eigentliche Wissensgenerierung statt, die sich wiederum in eine entdeckende und eine überprüfende Komponente aufspaltet. Im ersten Fall steht die Überprüfung der vom Anwender vorformulierten Hypothesen im Vordergrund, während im zweiten Fall mehr oder minder autonom neue Muster im vorliegenden Datenbestand gesucht werden. Ob die zur Beschreibung der beobachteten Daten erstellten Modelle und die mit ihrer Hilfe extrahierten Informationen nützliches Wissen darstellen, kann jedenfalls nur im Gesamtzusammenhang des KDD-Prozesses beurteilt werden und hängt nicht zuletzt von der Einschätzung des Anwenders ab (vgl. Fayyad et al. 1996, S. 43). Generell hat sich in der Praxis ein Verständnis von Data Mining durchgesetzt, das auch die restlichen Schritte des KDD-Prozesses mit einbezieht. Dieses sogenannte Data Mining im weiteren Sinne fokussiert nicht nur auf die Gewinnung von Wissen aus bereits vorhandenen Daten, sondern umfasst auch die für den erhofften Erkenntnisgewinn unabdingbare Formulierung von Untersuchungsfragestellungen sowie die gesamte vorgelagerte Kette von Arbeiten zur Bereitstellung, Aufbereitung und Transformation der Daten und ferner eine entsprechende Präsentation der Erkenntnisse. In der Bankenpraxis erfolgt etwa die in Kap. 4 des vorliegenden Buches anhand stilisierter Beispiele skizzierte Kreditdatenanalyse in weiten Teilen diesem Verständnis. Abschließend sei darauf hingewiesen, dass noch einige weitere (oft ebenfalls englischsprachige) Begriffe für Data Mining existieren, die zum Teil in verschiedenen Wissenschaftsdisziplinen geprägt wurden. Statistisches Lernen (Statistical Learning), maschinelles Lernen (Machine Learning) oder Datenwissenschaft (Data Science) bedienen sich großteils derselben Vorgehensmodelle und Analyseverfahren, sind von den im Folgenden vorgestellten Data-Mining-Konzepten nur bedingt unterscheidbar und werden deshalb häufig synonym mit diesen gebraucht (vgl. hierzu beispielsweise EMC 2015; James et al. 2013; Hastie et al. 2009; Müller und Guido 2017; Witten et al. 2011; Fingerlos et al. 2016).

50

2  Technologische und konzeptionelle Ansätze zur Analyse und zum Reporting von …

Eine vereinfachte Gegenüberstellung von Data Science (DS) und Business Intelligence [BI, vgl. Abschn. 2.1] im Hinblick auf 1) angewandte Analysetechnik, 2) Datenbeschaffenheit, 3) den analytischen Zugang, 4) den typischen Zeithorizont bei der Analyse sowie 5) behandelte Untersuchungsfragestellungen findet sich in Fingerlos et al. 2016, die sich wie folgt zusammenfassen lässt: Business Intelligence: 1) Standard- und Ad-hoc-Reports, Dashboards, Distribution Services, Abfragen, Detailanalysen im Bedarfsfall; 2) Strukturierte Daten, wenige Datenquellen, handhabbare Datensatzlänge; 3) Beschreibend (deskriptiv); 4) Vergangenheitsorientiert (ex post); 5) Was geschah in der Vergangenheit?, Wie hoch war das Risiko?, Wo liegt das Problem?; In welchen Situationen tritt das Pro­ blem auf?; Data Science: 1) Prognosemodelle, Data-driven Decision Making, Statistical Learning, Detailanalysen als Standard; 2) Unstrukturierte Daten, zahlreiche Datenquellen, komplexe Datensätze; 3) Erkundend (explorativ); 4) Zukunftsorientiert (ex ante); 5) Was wird in der Zukunft geschehen?, Wie hoch wird das Risiko sein?, Was wäre wenn?, Wie lautet das Optimalszenario?, Was geschieht bei fortgesetztem Trend?, Warum tritt ein bestimmtes Szenario ein? Insgesamt ist ohnehin weniger die (mitunter auch modischen Schwankungen in der wissenschaftlichen Community unterliegende) Bezeichnung der verwendeten Analysemethode für die Mittelauswahl ausschlaggebend, sondern der mit der Datenanalyse verfolgte Zweck. Insofern wird an dieser Stelle auf eine weitere Systematisierung der verwendeten Begriffe verzichtet.

2.4.2 C  ross-Industry Standard Process for Data Mining (CRISP-DM) als ausgewähltes Vorgehensmodell Unter einem Vorgehensmodell lässt sich die strukturierte Beschreibung des Ablaufes von Data Mining verstehen, um dieses möglichst gut an das vorliegende Geschäftsumfeld bzw. Erkenntnisinteresse anzupassen. Alle gängigen Vorgehensmodelle sind prozessual und in der Regel nichtlinear aufgebaut. Dies bedeutet, dass grundsätzlich aufeinander folgende Arbeitsschritte ablaufen, die bei Bedarf mithilfe diverser Feedback-Schleifen auch rekursiv durchschritten werden können. Somit kehrt der Prozessablauf gegebenenfalls immer wieder zu vorgelagerten Schritten zurück, um im Bedarfsfall Anpassungen vorzunehmen. In diesem Fall findet sich auch die Bezeichnung Phasenmodelle, in denen die einzelnen Phasen über verschiedene Rückkoppelungsschleifen solange miteinander interagieren, bis die Ausgangsfragestellung bzw. das zu untersuchende Problem hinreichend gelöst ist. Das bekannteste und am weitesten verbreitete Vorgehensmodell ist der sogenannte Cross-Industry Standard Process for Data Mining (CRISP-DM), der laut einer in den Jahren 2007 bzw. 2014 durchgeführten, nicht repräsentativen Online-Umfrage von 42 % bzw. 43 % der Befragten als bevorzugte Data-Mining-Methode angegeben wurde (vgl. P ­ iatetsky 2014) und dem sich der vorliegende Abschnitt widmet. Neben CRISP-DM existieren mit dem Sample, Explore, Modify, Model, Assess (SEMMA)-Ansatz des Softwareanbieters SAS und dem Microsoft Team Data Science-Prozess (TDSP) noch weitere Vorgehensmo-

2.4  Business Analytics

51

delle, die nicht zuletzt aufgrund ihrer Implementierung in Anwendersoftware eine gewisse Marktdurchdringung erreicht haben und die im Anschluss an CRISP-DM in Abschn. 2.4.3 kurz angeschnitten werden. Da es sich bei SEMMA und TDSP ebenfalls um Phasenmodelle handelt, die in weiten Teilen konzeptuelle Überschneidungen bzw. Ähnlichkeiten mit CRISP-DM aufweisen, kann an dieser Stelle auf eine detailliertere Darstellung verzichtet und auf die in den betreffenden Abschnitten zitierten Quellen verwiesen werden. Das im Folgenden näher ausgeführte Phasenkonzept des CRISP-DM-Modells wird auch im Hinblick auf den Ablauf des in Kap. 4 des vorliegenden Buches gezeigten Fallbeispiels zur Kreditdatenanalyse eine zentrale Rolle spielen. Unter Federführung der Daimler AG (damals Daimler-Benz), Integrated Solutions Limited (später von SPSS gekauft und heute Teil von IBM), NCR (National Cash Register, zwischenzeitlich bekannt durch Teradata, das später wieder abgespalten wurde) und OHRA (eine niederländische Versicherungsgesellschaft) wurde Mitte der 1990er-Jahre (zum Teil kofinanziert durch die Europäische Kommission) ein industrieübergreifendes Konsortium führender Data-Mining-Anbieter und -Anwender in dem damals noch relativ jungen Data-Mining-Markt gebildet. Das Ziel bestand darin, die bis dahin zumeist unabhängig voneinander entwickelten Data-Mining-Ansätze in ein auf breiter Front akzeptiertes und anwendbares Vorgehensmodell zu überführen, das von zukünftigen bzw. für zukünftige Kunden in deren Geschäftsprozesse übernommen und dort verwendet werden konnte. So sollte eine Blaupause entstehen, die jedem neuen und alt eingesessenen Data-­ Mining-­Anwender ein Werkzeug in die Hand gab, um Data-Mining-Projekte auch ohne das bis dahin übliche, auf Trial and Error basierende Vorgehen strukturiert durchführen zu können. Es zeigte sich, dass die Entwicklung eines für die Mitglieder des Konsortiums und die Data Mining Community frei zugänglichen, industrie-, werkzeug- und anwendungsneutralen Referenz- bzw. Standardmodells sinnvoll und hilfreich sein konnte. Im Jahr 2000 wurde das Ergebnis der Anstrengungen des Konsortiums, der Cross-Industry Standard Process for Data Mining (CRISP-DM), präsentiert. CRISP-DM stellt ein Data-­Mining-­ Lebenszyklusmodell dar, das als praxisorientierter Referenzrahmen zur erfolgreichen Durchführung von Data-Mining-Projekten dient und nicht eigentumsrechtlich geschützt ist (vgl. Chapman et al. 2000, S. 1 f.; Shearer 2000, S. 14; IBM 2017, S. 1; Piatetsky 2014). Es wird zwar nicht mehr von seinen Mitbegründern laufend weiterentwickelt, zumindest jedoch von IBM und anderen Autoren in Teilbereichen adaptiert, wie ein Vergleich von Shearer 2000; Azevedo und Santos 2008; Rollins 2015; IBM 2015, 2017; Larose und Larose 2015; EMC 2015 und Niakšu 2015 zeigt. Diesen Werken sind die folgenden Ausführungen entnommen, die an den durch entsprechende Zitate gekennzeichneten Stellen um Details zur Datenaufbereitung, Modellierung und Evaluierung erweitert wurden. Aus methodologischer Sicht beschreibt CRISP-DM die sechs verschiedenen Phasen im Ablauf eines Data-Mining-Projektes und gibt einen Überblick über die in jeder Phase durchzuführenden Aufgaben. Zugleich bildet es die Abfolge und Interdependenzen zwischen den einzelnen Phasen ab und beschreibt somit den Lebenszyklus eines Data-­Mining-­ Projektes. IBM fasst die einzelnen Phasen, die in den nachstehenden Abschnitten erläutert werden, wie in Abb. 2.18 gezeigt zusammen (vgl. IBM 2015, S. 1).

52

2  Technologische und konzeptionelle Ansätze zur Analyse und zum Reporting von …

Business understanding

Data understanding

Data preparation Deployment

Data Modeling

Evaluation

Abb. 2.18  Data-Mining. (Quelle: eigene Darstellung)

2.4.2.1 Phase 1 – Untersuchung der Geschäftsziele (Business Unterstanding) In Phase 1 geht es in erster Linie darum, ein Verständnis für die Ziele eines Forschungsprojektes aus Sicht eines Unternehmens zu entwickeln, eine Analyse der Ist-Situation durchzuführen und daraus eine entsprechende Problemdefinition bzw. die Beschreibung eines wünschenswerten Soll-Zustandes zu entwickeln, der mithilfe des Data-Mining-­ Projektes erreicht werden soll. Das Sammeln von Hintergrundinformationen über die Geschäftssituation und das Dokumentieren von mit der Unternehmensleitung abgestimmten Geschäftszielen helfen dabei, sich schon zu Beginn ein möglichst klares Bild der Gegebenheiten zu verschaffen. Sollte es nicht möglich sein, das vorliegende Geschäftsproblem in ein eindeutiges Data-Mining-Problem zu überführen, mit dem das Problem gelöst werden kann, dann ist der Sinn des Gesamtprojektes zu hinterfragen. Klar definierte Data-Mining-Ziele, die mit ausformulierten Forschungsfragen und daraus abgeleiteten Untersuchungshypothesen einhergehen, helfen dabei, diesen Übersetzungsprozess zu strukturieren und später den Erfolg des Projektes zu überprüfen. Die Formulierung von Forschungsfragen und die Überprüfung der daraus abgeleiteten Untersuchungshypothesen setzt ein von der wissenschaftlichen Methode geleitetes Vorgehen voraus (vgl. Seiler und Alvarez 1994; Gower 1997). Insofern sollte ein Projektplan eine umfangreiche Definition von Projektzielen, messbaren Erfolgskriterien und der dazugehörigen Meilensteine beinhalten, die mit den eingangs definierten Unternehmenszielen in Verbindung stehen müssen. So ist gewährleistet, dass einerseits bei Hinweisen auf einen mangelhaften Zielerreichungsgrad im Projektab-

2.4  Business Analytics

53

lauf sofort steuernd eingegriffen und andererseits das am Ende erzielte Ergebnis mit den Erwartungen an das Projekt abgeglichen werden kann. Unterstützend sind hierfür Kosten-­ Nutzen-­Analysen sowie eine Risikoabschätzung heranzuziehen. Ebenso helfen eine detaillierte Ressourcenplanung (finanziell, personell, materiell), die durch die verfügbaren Ressourcen bedingte zeitliche Ablaufplanung sowie eine erste Methodenauswahl dabei, die Rahmenbedingungen des Projektes möglichst präzise auszuformulieren und zu kon­ trollieren. Je besser dies gelingt, desto weniger Schwierigkeiten sind in den folgenden Projektphasen zu erwarten. Im Falle eines Kreditinstituts wäre hier etwa an die Aufgabe zu denken, ein internes Modell (IRB-Modell) zur Prognose von Kreditausfallwahrscheinlichkeiten (Probability of Default, PD) entwickeln zu müssen. In diesem Fall sind das Geschäftsproblem, die Data-Mining-Ziele sowie die zugehörigen Forschungsfragen und Untersuchungshypothesen (auch aufgrund der bei der Erstellung von internen PD-Modellen zur Anwendung kommenden aufsichtsrechtlichen Vorgaben im Umfeld des Basel-Regelwerkes) klar abgesteckt: Konkret sollte ein funktionierendes PD-Modell nämlich nicht nur dazu in der Lage sein, erwartete Ausfälle von Nichtausfällen zu unterscheiden (also eine hohe Trennschärfe bzw. Discriminatory Power aufweisen), sondern auch über eine hinreichend gute Genauigkeit bzw. Kalibrierung (Calibration) verfügen (also die beobachteten Ausfallquoten nicht unterschätzen). Auf die Erreichung dieser Vorgaben zielen die in den folgenden Phasen anfallenden Arbeitsschritte ab.

2.4.2.2 Phase 2 – Datenuntersuchung (Data Understanding) Phase 2 beginnt damit, die benötigten Rohdaten zu sammeln. An dieser Stelle steht also die Frage im Zentrum, ob alle im weiteren Projektablauf benötigten Daten auch tatsächlich vorhanden bzw. beschaffbar sind. Dabei sollte großer Wert auf eine umfangreiche Dokumentation gelegt werden. Dies fördert die Wiederholbarkeit, wenn Daten aus vielen unterschiedlichen Quellen stammen, deren Nutzung mit unterschiedlich komplexen Vorbereitungsarbeiten und Vorlaufzeiten verbunden ist. Überdies kann die Aufzeichnung von Schwierigkeiten im Datenbeschaffungsprozess dabei helfen, den Projektablauf und dessen Planung in zukünftigen Projektdurchläufen zu verbessern und so Verzögerungen zu vermeiden. Sind die erforderlichen Daten gesammelt, erfolgt eine erste Analyse des vorliegenden Datenbestandes (teils als Data Profiling bezeichnet), um ein Gefühl für die vorliegenden Informationen zu bekommen. Diese Analyse beinhaltet eine Beschreibung von Struktur, Format und Umfang der Datenbestände, wobei insbesondere die folgenden Fragen im Zentrum stehen: • „Welche Attribute der Daten (Felder, Variablen) sind für den Fortgang der Untersuchung relevant und welche können weggelassen werden?“ • „Sind ausreichend Daten vorhanden, um die Forschungsfragestellung zu beantworten?“

54

2  Technologische und konzeptionelle Ansätze zur Analyse und zum Reporting von …

Mit der Untersuchung (Exploration) des Datenbestandes lässt sich ein erster Abgleich im Hinblick auf die in Phase 1 formulierten Forschungsfragen bzw. Zielsetzungen des Data-Mining-Projektes vornehmen. Es treten beschreibende Analysen bzw. im Falle von numerischen Daten erste deskriptiv statistische Auswertungen und Grafiken in den Vordergrund, die in entsprechenden Berichten zusammengefasst aufbereitet werden. Hier sind Fragen essenziell wie: • „Welche Hypothesen haben sich aus der Analyse der Daten gebildet und wie wurden dadurch die ursprünglichen Hypothesen geändert?“ • „Hat die Datenexploration die Data-Mining-Ziele beeinflusst?“ Überdies ist es die Aufgabe von Phase 2, den Datenbestand auf erfüllte Mindestanforderungen hinsichtlich Vollständigkeit und Qualität zu überprüfen und dies ebenfalls zu dokumentieren. Hier geht es darum, eine Vorstellung von der Plausibilität (Richtigkeit) der Werte zu bekommen, zu verstehen, wie sich fehlende Werte auf die Untersuchung auswirken können, wie Attribute von Variablen zu interpretieren sind usw. Der Untersuchungs­ bericht sollte zudem Aussagen zu fehlenden Daten (leere Datenfelder), Datenfehlern (Tippfehler bei der Dateneingabe, falsch berechnete Werte) und Inkonsistenzen (nicht einheitliche Kodierung desselben Tatbestandes über verschiedene Beobachtungen hinweg, z. B. „0“ und „1“ vs. „nein“ und „ja“) sowie eine Beurteilung von Metadatenfehlern (der Inhalt einer Datenspalte weicht von der ihr zugewiesenen Bedeutung ab) enthalten. Da im Risikoreporting beispielsweise die Entwicklung von Modellen zur Prognose von Ausfallwahrscheinlichkeiten bzw. deren periodische Adaptierung zumeist unter Zeitdruck erfolgt, die Modellentwicklung an besonders strenge regulatorische Anforderungen im Hinblick auf die Reproduzierbarkeit der einzelnen Schritte geknüpft ist und überdies eine Nacherhebung fehlender oder falscher Daten mit großem Zeitaufwand verbunden ist, kommt einer umfangreichen Qualitätsprüfung und nachvollziehbaren Dokumentierung eine große Bedeutung zu. Im Anschluss an das in Phase 1 gewonnene Geschäfts- und das in Phase 2 gewonnene Datenverständnis lassen sich in Phase 3 die Daten für das eigentliche Data Mining vorbereiten.

2.4.2.3 Phase 3 – Datenaufbereitung (Data Preparation) Die Datenaufbereitungsphase umfasst alle Verarbeitungs- und Transformationsprozesse, die notwendig sind, um von den Rohdaten aus Phase 2 zu einem fertigen Analysedatenbestand für das eigentliche Data Mining zu gelangen. Hier ist zunächst eine Auswahl von geeigneten und für den Untersuchungsgegenstand relevanten Daten zu treffen und zu beschreiben, warum bzw. welche Daten als relevant erachtet oder aber ausgeschlossen werden. Diese Datenauswahl erstreckt sich beispielsweise bei strukturierten Daten in Form einer Datentabelle sowohl auf die Spalten (Variablen, Attribute, Merkmale) als auch auf die Beobachtungsanzahl (Zeilen, Elemente).

2.4  Business Analytics

55

Im Anschluss werden die ausgewählten Daten bereinigt, also von Qualitätsmängeln so weit wie möglich befreit. Dies kann vom Weglassen über das Umformen bis hin zum Ersetzen von ungültigen Werten (die zuvor erwähnten fehlenden Daten, Datenfehler, Inkonsistenzen, Metadatenfehler) reichen. Ebenso Gegenstand der Datenaufbereitung ist es, bestehende Variablen zu transformieren oder neue Variablen zu generieren, falls es die Untersuchungsfragestellung bzw. die anzuwendende Untersuchungsmethode erfordert (z. B. Normalisierung von Werten, Definition von Indikatorvariablen). Bei Bedarf können auch zusätzliche Daten integriert werden. Darunter fällt sowohl das horizontale Kombinieren (Join) mehrerer Datentabellen mit gleichen Zeilenwerten (Beobachtungen) aber sich unterscheidenden Spaltenwerten (Attributen, Variablen) als auch das vertikale Kombinieren mehrerer Datentabellen mit gleichen Spaltenwerten und unterschiedlichen Zeilenwerten (Append). Des Weiteren erweisen sich die Berechnung neuer Variablenwerte aus verschiedenen Zeilen- oder Spaltenwerten sowie die Kalkulation von Zeilen- oder Spaltensummen usw. in diesem Kontext als relevant. Je nach Aufgabenstellung sind die Datenbestände vor ihrem Einsatz in der Modellierungsphase noch entsprechend zu formatieren. Hier werden überflüssige oder ungültige Zeichen entfernt, die Genauigkeit überprüft, mit der Werte gespeichert werden, Ausgabeformate eingefügt oder verändert sowie mitunter auch die Datenstruktur angepasst (z. B. durch Transponieren von Tabellen oder Entfernung redundanter Daten). Abschließend wird die fertig aufbereitete Datenbasis in der Regel in voneinander getrennte Trainings- und Testdatenbestände zerlegt (Partitionieren bzw. Sampling); insbesondere, wenn in der anschließenden Modellierungsphase (vgl. Abschn.  2.4.2.4) überwachte Analyseverfahren zur Anwendung kommen sollen: Während die Trainingsda­ tenbestände für die Modellbildung Verwendung finden, gelangen die Testdatenbestände bei der anschließenden Modellevaluierung zum Einsatz (vgl. Abschn. 2.4.2.5). Das Größenverhältnis zwischen derartigen Trainings- und Testdatenbeständen bewegt sich in der Regel in einem Bereich zwischen 70 % zu 30 % und 80 % zu 20 % (vgl. Hastie et al. 2009, S. 222). Auf die Erklärung der bei ausreichendem Datenbestand bislang angewandte weitere Unterteilung der Datenbasis in Trainings-, Validierungs- und Testdatenbestand wird hier verzichtet (vgl. Hastie et al. 2009, S. 222). Abgesehen von solchen mittels Zufallsauswahl generierten Out of Sample-­ Test­ datenbeständen ist je nach Aufgabenstellung und Verfügbarkeit auch die Verwendung von Testdaten denkbar, die eine andere Zeitdimension als der Trainingsdatenbestand aufweisen (sogenannte Out of Time-Testdaten) (vgl. Varian 2014, S.  6  f.; Larose und Larose 2015, S. 162; Baesens et al. 2016, S. 391 ff.). An dieser Stelle tritt mit der Zukunftsorientierung eine zentrale Eigenschaft aller Predictive Analytics-Ansätze in den Vordergrund: Die bei der Modellierung (beim Training der Modelle) bereits bekannten Daten lassen sich nicht als Grundlage zur Beurteilung (Evaluierung bzw. Validierung) der Modelle heranziehen. Richtiger und wichtiger ist viel-

56

2  Technologische und konzeptionelle Ansätze zur Analyse und zum Reporting von …

mehr die Genauigkeit der erzielten Prognosen bei Verwendung des Modells auf Basis „neuer“ Daten, die nicht bereits bei der Kalibrierung eingesetzt wurden. Denn letztlich ist es nicht entscheidend, wie gut ein Modell sich an die Datenbasis anpasst, auf deren Grundlage es kalibriert (geschätzt) wurde, sondern ob es eine zufriedenstellende Prognosegüte bei Verwendung unbekannter Daten erzielt. Häufig liefern Modelle nämlich bei Verwendung des zur Modellkalibrierung verwendeten Datenbestandes (der Trainingsdaten) ausgezeichnete Prognosen (sogenannte In-Sample-Prognosen), während bei Verwendung neuer Daten (die etwa aus einem Testdatenbestand stammen können) schlechtere Prognosen zustande kommen (sogenannte Out-of-Sample-Prognosen). Dies ist auch der Grund, warum sich die Ausprägungen der vorhandenen Variablen im Vergleich zwischen Trainings- und Testdatenbestand nicht statistisch signifikant voneinander unterscheiden sollten. Nur wenn die Verteilung der Variablenausprägungen in den Testdaten (insbesondere im Hinblick auf die erklärte Variable) repräsentativ für die Trainingsdaten ist, lässt sich nämlich im Anschluss an die Modellierungsphase eine korrekte Modellevaluierung gewährleisten. Ob diese Voraussetzung erfüllt ist, kann mithilfe deskriptivstatistischer Analysen und entsprechender statistischer Tests überprüft werden (vgl. Larose und Larose 2015, S. 162). Als zusammenfassendes Beispiel im Kontext des Risikoreportings lässt sich wieder die Prognose von Ausfallwahrscheinlichkeiten heranziehen. Die entsprechenden Prognosemodelle werden auf Grundlage des Zusammenhanges zwischen aufgezeichneten Vergangenheitswerten von Ausfallquoten und eines Satzes erklärender Variablen (Ratings oder Scorings, soziodemografische Daten, Finanzdaten usw.) kalibriert. Die Beurteilung, wie gut ein derart konfiguriertes Modell funktioniert, kann jedoch nur beim Einsatz des Modells zur Prognose von neuen Ausfällen erfolgen. Eine vergangenheitsorientierte Pro­ gnose, basierend auf der ohnehin bereits bekannten und zur Kalibrierung des Modells verwendeten Datenbasis, würde zwar in der Regel gute, aber wenig aufschlussreiche Ergebnisse liefern. Insofern kann nur auf Grundlage neuer Datenpunkte bzw. im Rahmen von Stresstests, die nicht aus dem zur Modellierung verwendeten Datenbestand kommen, eine Aussage darüber gemacht werden, ob die Prognosequalität zufriedenstellend ist (vgl. James et al. 2013, S. 30). Nach abgeschlossener Datenaufbereitung folgt die im nächsten Abschnitt gezeigte ­Modellierungsphase.

2.4.2.4 Phase 4 – Modellierung (Modeling) In dieser Phase werden zunächst potenziell zur Modellierung des in der Fragestellung unterstellten empirischen Sachverhaltes geeignete Analyseverfahren beurteilt und ausgewählt. Ob eine bestimmte Modellierungsmethode praktikabel ist, hängt von der zu untersuchenden Problemstellung, den zugehörigen Forschungshypothesen und den vorhandenen Daten ab. Mitunter muss an dieser Stelle die Anpassung der Datenstruktur an die zu verwendende Methode erfolgen. Die dem Forschungsprojekt zugrunde liegenden Hypothesen sollten jedoch aus Gründen der wissenschaftlichen Korrektheit unverändert bleiben.

2.4  Business Analytics

57

In technischer Hinsicht lässt sich die Modellierungsphase anhand der Eigenschaften der verwendeten Daten (Variablen) und der durch sie bedingten Menge an potenziell anwendbaren Analyseverfahren charakterisieren. Verfolgt die Modellierung nämlich das Ziel, den Einfluss der Ausprägungen einer oder mehrerer erklärender Variablen (unabhängiger Variablen, Inputvariablen) auf die Ausprägungen einer bzw. in selteneren Fällen auch mehrerer erklärter Variablen (abhängige Variablen, Outputvariablen) abzuschätzen, dann wird dies als überwachtes statistisches Lernen („supervised statistical learning“) bezeichnet. Im Gegensatz zu überwachtem Lernen beschäftigt sich unüberwachtes statistisches Lernen (Unsupervised Statistical Learning) ausschließlich mit der Suche nach Mustern in den Ausprägungen einer oder mehrerer (unabhängiger) Variablen, ohne jedoch über erklärte Variablen zu verfügen oder solche zu verwenden. In diesem Fall erfolgt die Analyse also in „unbeaufsichtigter“ Weise, weil keine Prognosen für die erklärte(n) Varia­ ble(n) erstellt werden und somit naturgemäß eine auf dem Vergleich zwischen Prognosewerten und beobachteten Ausprägungen basierende Abschätzung der Prognosegüte entfällt (vgl. James et  al. 2013, S.  16  ff., S.  373  ff.; Agresti 2013, S.  577; Hastie et  al. 2009, S. 28 ff.; EMC 2015, S. 118; Larose und Larose 2015, S. 160). Im deutschen Sprachraum sind auch die Begriffe „überwachte Verfahren“ und „unüberwachte Verfahren“ gebräuchlich. Wie Larose und Larose hinweisen, sollte der Gebrauch des Wortes „unüberwacht“ nicht darüber hinwegtäuschen, dass die Anwendung unüberwachter Verfahren ebenso wie die Anwendung überwachter Verfahren mit einem erheblichen manuellen Aufwand verbunden ist (vgl. Larose und Larose 2015, S. 161). Im Normalfall mit nur einer erklärten Variablen, Y, und p erklärenden Variablen, X = X1, X2, …, Xp, versucht überwachtes Lernen den Zusammenhang zwischen den Datenpaaren (Y, X) mithilfe eines statistischen Modells der Form

Y = f (X)+ε

zu beschreiben – also zu modellieren. Weil der wahre Zusammenhang zwischen Y und X zumeist nicht exakt bestimmt werden kann, wird dem statistischen Modell in der Regel ein Störterm bzw. Zufallsfehler ε mit einem Erwartungswert von E(ε) = 0 und unterstellter Unabhängigkeit von X hinzugefügt, der diese stochastische Komponente repräsentiert (vgl. James et al. 2013, S. 16 ff.; Hastie et al. 2009, S. 28 ff.; Hill et al. 2018, S. 4 f.). Ziel des überwachten statistischen Lernens ist es zunächst, den Zusammenhang f(X) zwischen X und Y anhand der beobachteten Daten zu schätzen und so eine Vorstellung von der funktionalen Form des Modells, fˆ ( X ) , zu erhalten. Der Prozess zur Ermittlung (des Lernens) von Modellparametern zur Beschreibung des funktionalen Zusammenhanges zwischen erklärter Variablen und erklärenden Variablen wird auch als Kalibrierung bezeichnet. Kenntnisse über diesen funktionalen Zusammenhang erweisen sich deshalb als bedeutsam, weil sie sich dazu eignen, Prognosen für die Werte von Y in einem vergleichbaren Datenbestand anzustellen, wenn dort lediglich die Werte von X bekannt sind. Da für den Störterm die Annahme ε = 0 gilt, lässt sich die Prognose als Yˆ = fˆ ( X ) schreiben. Hier ist Yˆ der prognostizierte Wert von Y und fˆ ( X ) der geschätzte Zusammenhang mit X (Schätzer).

58

2  Technologische und konzeptionelle Ansätze zur Analyse und zum Reporting von …

Der Erwartungswert der quadrierten Abweichung zwischen dem wahren Wert Y = f(X) + ε

(

und dem prognostizierten Wert Yˆ = fˆ ( X ) der abhängigen Variablen als E Y − Yˆ

(

)

)

2

ergibt

2

2

= E  f ( X ) + ε − fˆ ( X )  . Das Auflösen der Erwartungswerte 2 2 auf der rechten Seite der Gleichung führt zu E Y − Yˆ =  f ( X ) − fˆ ( X )  + Var ( ε ) , wobei Var(ε) die Varianz des Störterms ε bzw. den nicht reduzierbaren Fehler der Schätzung bezeichnet. Die Varianz ist ein Streuungsmaß, das die Verteilung von Werten um den arithmetischen Mittelwert angibt. Die Varianz ist das Quadrat der Standardabweichung. Die Berechnung der Varianz erfolgt, indem die Summe der quadrierten Abweichungen aller Messwerte vom arithmetischen Mittelwert durch die Anzahl der Messwerte dividiert wird. 2 Hingegen stellt der Klammerausdruck  f ( X ) − fˆ ( X )  den reduzierbaren Fehler der Schätzung dar. Das Ziel bei der Auswahl eines geeigneten Analyseverfahrens im Rahmen des Supervised Learning ist es immer, den reduzierbaren Fehler möglichst gering zu halten und derart die Prognosegenauigkeit zu maximieren. Neben der möglichst präzisen Vorhersage von Yˆ existiert noch ein weiteres Erkennt­ nisinteresse des Supervised Learning: die Inferenz. Hier wird versucht, den Einfluss von Änderungen von X auf die Werte von Y zu ergründen (vgl. James et al. 2013, S. 16 ff.; Hastie et al. 2009, S. 28 ff.; Hill et al. 2018, S. 46 ff.). Dabei treten die folgenden Fragen in den Vordergrund (vgl. James et al. 2013, S. 16 ff.): nach Einsetzen E Y − Yˆ

(

)

• „Welche unabhängigen Variablen beeinflussen die abhängige Variable?“ • „Besteht ein positiver oder ein negativer Zusammenhang zwischen erklärter Variable und den erklärenden Variablen?“ • „Ist eine lineare Gleichung zur Erklärung dieses Zusammenhanges ausreichend oder sind kompliziertere funktionale Formen erforderlich?“ Alle weiteren Arbeitsschritte hängen von den Skalenniveaus ab, mit denen die involvierten Variablen gemessen werden. Denn liegen die Variablen im falschen Skalenniveau vor, dann ändern sich die Anwendungsvoraussetzungen des statistischen Modells und damit auch die Interpretierbarkeit der erzielten Ergebnisse. Insofern gilt es zu ­berücksichtigen, dass die Methodenauswahl die Mindestanforderungen an das Skalenniveau der zu messenden Daten vorgibt bzw. das maximal messbare Skalenniveau der für eine Messung zugänglichen Daten das Spektrum der verwendbaren Analyseverfahren einschränkt. Insbesondere sind Transformationen von in höheren Skalenniveaus gemessenen Daten in tiefer liegende Skalenniveaus stets mit einem Informationsverlust verbunden, während umgekehrte Transformationen ausgeschlossen sind. Gegebenenfalls sind an dieser Stelle also Rückkoppelungen zu den vorangegangenen Phasen notwendig, wenn das Skalenniveau geändert oder Daten nacherhoben werden müssen. Das in Kap. 4 gezeigte Fallbeispiel zur Kreditdatenanalyse wird diesen Umstand näher beleuchten.

2.4  Business Analytics

59

Nach der hypothesenbasierten Formulierung eines statistischen Modells erfolgt in einem nächsten Schritt die Erstellung eines Testdesigns, das Gütekriterien für die zu entwickelnden Modelle und die zur Modellierung verwendeten Daten festschreibt. Dabei kann es sich sowohl um objektive Gütekriterien im Sinne einer im anschließenden Abschn. 2.4.2.5 noch zu definierenden Fehlerkennzahl als auch um subjektive Gütekriterien wie die Handhabbarkeit und Interpretierbarkeit von Modellen handeln. Hierbei erweist es sich als sinnvoll, die maximale Anzahl der Änderung von Modellspezifikationen sowie bei unzureichender Modellgüte den Zeitpunkt für den Wechsel des Modelltypus insgesamt festzulegen. In der Regel ist auch die Entwicklung mehrerer konkurrierender Modelle bzw. Modellvarianten mithilfe derselben Data-Mining-Technik angezeigt, deren Performance-­Eigenschaften dann miteinander verglichen werden können. Oftmals bilden aber auch gänzlich unterschiedliche Data-Mining-Techniken ein Analysebündel von dann nicht konkurrierenden, sondern einander ergänzenden Modellen. In Jedem Fall sollte eine ausreichende Dokumentation der erzielten Resultate insbesondere Antworten auf die folgenden Fragen beinhalten (IBM 2017, S. 28 f.): • „Erlauben die Modelle sinnvolle Schlussfolgerungen?“ • „Deckt das Modell neue Muster auf?“ • „Welche Probleme sind beim Ausführen der Modelle aufgetreten?“ Welches Modellierungsverfahren für die gegebene Untersuchungsfragestellung letzten Endes am besten geeignet ist, wird also insgesamt durch die eingangs formulierten Data-­ Mining-­Ziele, die daraus abgeleiteten Untersuchungshypothesen und nicht zuletzt auch die verfügbare Datenstruktur und Datenqualität und die vorhandenen Skalenniveaus der Variablen bedingt. Ist unter diesen Rahmenbedingungen ein geeignetes Modell bzw. sind gegebenenfalls sogar mehrere konkurrierende Modelle gefunden, kalibriert und dokumentiert worden, dann kann in der nächsten Data-Mining-Phase die Evaluierung (Validierung) dieser Modelle bzw. der mit ihnen erzielten Ergebnisse erfolgen.

2.4.2.5 Phase 5 – Evaluierung (Evaluation) Nach erfolgreicher Modellierung widmet sich die Evaluierungsphase der Beurteilung, ob die vorab festgelegten Modellgütekriterien erreicht wurden und die erzielten Prognosen zufriedenstellend ausfallen. Anhand dieser Beurteilung ist eine abschließende Auswahl des in Bezug auf die Erklärung der Wirklichkeit besten Modells möglich. In der Regel werden zur Evaluierung (Validierung) von Prognosemodellen (also von Modellen aus der Methodenfamilie des überwachten statistischen Lernens) abseits des Trainingsdatenbestandes generierte Testdatenbestände verwendet, um eine maximale Generalisierbarkeit der erstellten Modelle und ihrer Parameter in Bezug auf die zuvor unbe-

60

2  Technologische und konzeptionelle Ansätze zur Analyse und zum Reporting von …

obachteten Testdaten sicherzustellen. PD-Modelle werden in der Regel anhand vorab vonseiten der Aufsichtsbehörden bzw. interner Kontrollinstanzen (interne Validierungsabteilung, Auditabteilung) festgelegter statistischer Tests und Metriken evaluiert, die im Rahmen des Basel-Regelwerkes die Mindestanforderungen an die Modellgüte von internen Modellen (IRB) abstecken (vgl. beispielsweise Basel Committee on Banking Supervision 2005). Insofern beschäftigt sich die Evaluierungsphase in erster Linie mit Techniken, die eine Beurteilung dahingehend erlauben, ob die zuvor in der Modellierungsphase erzielten Ergebnisse lediglich in dem zur Modellbildung (Modellkalibrierung) verwendeten Trainingsbestand gut funktionieren, oder die Modelle auch auf bislang unbekannte Datenbestände (am Beispiel des Testdatenbestandes) übertragbar sind. Nur im zweiten Falle liegt eine hinreichende Generalisierbarkeit der Modelle vor. Zudem erfolgt die Betrachtung des Zusammenhanges zwischen der Komplexität der Modelle einerseits und dem Grad der Generalisierbarkeit der Modelle andererseits. Denn je komplexer ein Modell ist, desto eher passt es sich nicht nur an die tatsächlichen Zusammenhänge zwischen erklärenden Variablen und erklärter Variable an, sondern bildet zunehmend auch Zufallsgrößen mit ab. Dieses Phänomen wird im englischen Sprachgebrauch als Overfitting bezeichnet (vgl. James et al. 2013, S. 22 ff., S. 29 ff.; Varian 2014, S. 6; Larose und Larose 2015, S. 163 f.). Eine Evaluierung der Güte von Prognosemodellen auf Basis eines statistischen Modells der Form Y = f(X) + ε erfolgt durch einen Vergleich der mithilfe des Modells erzielten Prognosewerte der erklärten Variable, Yˆ , mit den beobachteten Datenpunkten der erklärten Variable, Y. Hier bietet es sich an, als Maß für die Genauigkeit der Anpassung des Modells an die Wirklichkeit den sogenannten Mean Squared Error (MSE) als Fehlerkennzahl zu verwenden. Ein weiteres Maß der Anpassungsgüte ist das Informationskriterium von Akaike (AIC), das in Abschn. 2.4.4.4 zur logistischen Regressionsanalyse besprochen wird. Der MSE besteht aus der durch die Beobachtungsanzahl n dividierten Summe der quadrierten Abweichungen der i = 1, …, n Prognosewerte der erklärten Variable, Yˆ , von den beobachteten Werten der erklärten Variable, Y. Bei der Berechnung dieser durchschnittlichen Abweichungsquadratsumme beinhaltet der Vektor Y = (y1, y2, …, yn) die n beobachteten Werte und der Vektor Yˆ = ( yˆ1 , yˆ 2 ,…, yˆ n ) die n Prognosewerte der abhängi-

(

gen Variable, wobei die Prognosewerte auch als Yˆ = fˆ ( X ) = fˆ ( x1 ) , fˆ ( x2 ) ,…, fˆ ( xn )

)

geschrieben werden können (vgl. James et al. 2013, S. 29 ff.; Hastie et al. 2009, S. 219 ff.): MSE =

(

)

2 1 n 1 n 2 ˆ y − y = yi − fˆ ( xi ) ( ) ∑ ∑ i i n i =1 n i =1

Den obigen Ausführungen entsprechend, sollte im Falle mehrerer konkurrierender Pro­ gnosemodelle jenes Prognosemodell ausgewählt werden, dessen MSE im Testdatenbestand (und nicht im Trainingsdatenbestand) am geringsten ausfällt. Während nämlich der MSE im Trainingsdatenbestand immer weiter abnimmt, je komplizierter bzw. flexibler das zugrunde liegende Modell ist, erweist sich der MSE der Modelle im Testdatenbestand als ausschlaggebend für die Auswahl des besten Modells. Denn es lässt sich zeigen, dass er im Gegensatz zum MSE im Trainingsdatenbestand keine mit zunehmender Komplexität

2.4  Business Analytics

61

der Modelle monoton fallende Funktion ist, sondern zumeist einen U-förmigen Verlauf hat. An der Stelle, wo der MSE im Testdatenbestand sein Minimum erreicht, befindet sich dann der optimale Komplexitätsgrad des Modells, der durch eine geringe Verzerrung (Bias) bei zugleich geringer Varianz der geschätzten Parameter gekennzeichnet ist. Links von diesem Punkt mit minimalem MSE im Testdatenbestand sind die Modelle nicht flexibel genug, um die vorliegenden Zusammenhänge zwischen der erklärten Variablen und den erklärenden Variablen abzubilden. Diese Konstellation mit stark ausgeprägtem Bias bei zugleich geringer Varianz wird als Underfitting bezeichnet. Die Verzerrung kommt dadurch zustande, dass ein wenig flexibles Modell die Wirklichkeit nur ungenügend abbildet. Zugleich würde ein Hinzufügen zusätzlicher Datenpunkte zum Testdatenbestand nur zu geringfügigen Änderungen der Parameter solcher wenig flexiblen Modelle führen (geringe Varianz). Umgekehrt bilden die rechts vom Punkt mit minimalem MSE im Testdatenbestand liegenden Modelle die vorliegenden Zusammenhänge sehr genau ab (geringer Bias), was jedoch um den Preis einer hohen Varianz der Modellparameter erkauft wird. Schon bei kleinen Änderungen in der Datenstruktur des Testdatenbestandes würden sich die Parameter solcher flexiblen Modelle stark ändern, weil sie sich an alle diese Änderungen beliebig genau anpassen würden (Overfitting). Insgesamt spiegelt sich dieser Zwiespalt (Trade-off) zwischen Verzerrung und Varianz direkt in einer besonderen Eigenschaft des MSE wider. Er lässt sich nämlich bei Vernachlässigung der Varianz des Störterms im statistischen Modell Y = f(X) + ε in genau diese beiden Komponenten aufspalten: MSE = Varianz + Bias2. Dies ist der Grund dafür, warum sich bei der Modellauswahl der MSE bzw. von der Idee des MSE inspirierte Fehlermaße als besonders geeignet erweisen. Schließlich wird jenes Modell ausgewählt, das den Bias-Varianz-Trade-off am besten ausbalanciert, somit das geringste Fehlermaß im Testdatenbestand und folglich auch einen optimalen Flexibilitätsgrad aufweist (vgl. Hastie et al. 2009, S. 219 ff.; Larose und Larose 2015, S. 161 ff.; James et al. 2013, S. 33 ff.). Eine weitere populäre Evaluierungs- bzw. Validierungsmethode ist neben der Verwendung von Testdatenbeständen die sogenannte Kreuzvalidierung (Cross Validation). Die Idee ist hier erneut, einen Teil der verfügbaren Daten zur Bestimmung der Modellparameter und einen anderen Teil zur Validierung zu verwenden. Allerdings wird nun der Komplexitätsgrad der Modelle ebenfalls als zu optimierender Parameter aufgefasst und dann ein mehrstufiger Algorithmus auf den mittels Zufallsauswahl in k annähernd gleich große Teile partitionierten Trainingsdatenbestand angewandt (k-fache Kreuzvalidierung) (vgl. Varian 2014, S. 7; Efron und Hastie 2016, S. 208 ff.; Hastie et al. 2009, S. 241 ff.; James et al. 2013, S. 176 ff.). Darüber hinaus existieren noch andere Validierungsverfahren wie das Regularisieren der Modelle oder Bootstrapping, die beispielsweise in den weiterführenden Arbeiten von Efron und Hastie 2016; James et  al. 2013 und Hastie et  al. 2009 ausführlich beschrieben werden. Insgesamt besteht das Ziel von Phase 5 also darin, die Qualität und Effektivität der entwickelten Modelle so zu beurteilen und zu reihen, dass das Gewinnermodell die „beste“ Beschreibung der Wirklichkeit in Bezug auf die eingangs formulierten Ziele und Erfolgskriterien liefert. Zur Evaluierung gehört demnach eine eingehende Überprüfung aller bis-

62

2  Technologische und konzeptionelle Ansätze zur Analyse und zum Reporting von …

lang durchlaufenen Schritte des Data-Mining-Prozesses. Dabei wird beurteilt, ob alle relevanten Einflussfaktoren bzw. Aspekte der Forschungsfragestellung beachtet wurden, ob die bislang entwickelten Modelle korrekt und hinreichend präzise formuliert sind und ferner, ob die Forschungsziele erreicht wurden. Ist dies der Fall, erfolgt der Übergang zu Phase 6, andernfalls muss ein Rücksprung zu den Phasen 1 bis 4 oder sogar ein Neudesign des Forschungssetups erfolgen.

2.4.2.6 Phase 6 – Bereitstellung (Deployment) In der Bereitstellungsphase (Implementierungsphase) treten die zuvor entwickelten Modelle in den Anwendungsmodus über: Sie werden als Entscheidungsgrundlagen verwendet, um reale Probleme in Betrieben beurteilen und Prognosen erstellen zu können. Für ein gutes Funktionieren der Modelle in der Anwendungsphase sind laufende Überprüfungen der Performance sowie entsprechende Wartungs- und Änderungsarbeiten unabdingbar. Dies schließt einen ausführlichen Projektabschlussbericht mit ein, der den Auftrags- und Lieferumfang des Data-Mining-Projektes sowie die verwendeten Methoden und alle erzielten Ergebnisse (Modelle und Schlussfolgerungen) strukturiert und entsprechend kommentiert. Ein guter Abschlussbericht beinhaltet auch einen Überblick über Erfolge und Misserfolge, liefert Hinweise auf Stolpersteine und Sackgassen, stellt alle Abweichungen vom eingangs aufgestellten Projektplan dar und gibt Verbesserungsvorschläge für zukünftige Projekte. Häufig erfolgt der Projektabschluss im Rahmen einer mündlichen Präsentation, bei der die Ergebnisse an den Auftraggeber überreicht werden. Insgesamt werden im CRISP-DM-Vorgehensmodell die Phasen 1 und 2 solange wiederholt, bis ein ausreichend verdichtetes Wissen über das dem Data-Mining-Projekt zugrunde liegende Geschäfts- und Datenumfeld vorliegt. Auch die Datenaufbereitungs- und Modellierungsphase (Phasen 3 und 4) hängen voneinander ab. Nur bei richtiger Güte und Struktur der vorliegenden Daten mit allen notwendigen Attributen lassen sich sinnvolle Modelle entwickeln. Ist dies nicht der Fall, muss sogar mit einer Nacherhebung (Phase 2) und neuerlichen Aufbereitung (Phase 3) gerechnet werden. Ebenso sind die Phasen 4 (Modellierung) und 5 (Evaluierung) naturgemäß stark zyklisch miteinander verschränkt und werden häufig (auch bedingt durch die verwendete statistische Software) sogar im gleichen Programmierschritt oder unmittelbar aufeinander folgend durchlaufen. Letztlich führt nur eine zufriedenstellende Evaluierung dazu, dass die in einem Data-Mining-­Projekt erzielten Ergebnisse in die Bereitstellungsphase (Phase 6) übergehen. In der Praxis sind alle bei der Erstellung interner PD-Modelle durchlaufenen Phasen vom Basel-Regelwerk und den darin enthaltenen Mindeststandards geprägt. Konkret bedeutet dies, dass nicht nur eine interne Evaluierung (Validierung) der Modelle bereits im Zuge der Modellierungsarbeiten zu erfolgen hat, sondern dass der gesamte, die Phasen 1 bis 6 durchlaufende Data-Mining-Prozess auch durch die interne Validierungs- bzw. Auditabteilung und den Regulator positiv beurteilt werden muss, bevor ein internes PD-­ Modell zur Prognose von Ausfallwahrscheinlichkeiten herangezogen werden darf. Periodische Neuevaluierungen (sogenannte Backtests) geben Auskunft darüber, ob das verwendete Modell angesichts der sich in der Regel im Zeitablauf ändernden Populations-

2.4  Business Analytics

63

und Makrocharakteristika noch hinreichend genaue PD-Prognosen zulässt oder eine Neukalibrierung des Modells erforderlich wird.

2.4.3 Weitere Vorgehensmodelle 2.4.3.1 Sample, Explore, Modify, Model, Assess (SEMMA) Das durch den Softwareanbieter SAS seit Mitte der 1990er-Jahre parallel zu CRISP-DM entwickelte SEMMA-Vorgehensmodell repräsentiert als Akronym die fünf zentralen Phasen des Data-Mining-Prozesses Sample, Explore, Modify, Model, Assess (vgl. SAS Institute 1998). Als Baustein einer zyklisch angelegten, übergeordneten BI-Prozesskette setzt der Data-Mining-Prozess nach der Formulierung einer Geschäftsfragestellung und der Bereitstellung von Daten in einem DWH mit dem Ziel auf, Daten in nützliche Informationen zu verwandeln, diese für die Folgeschritte (Enterprise Information Systems, Berichtswesen) im BI-Prozess bereitzustellen und so den Kreis hin zur anfänglichen Forschungsfragestellung zu schließen. Im Gegensatz zu CRISP-DM lässt sich SEMMA als anbieterspezifisches Vorgehensmodell verstehen, dem etwa der Aufbau der Anwendersoftware SAS Enterprise Miner folgt. Da SEMMA durch eine große Ähnlichkeit zu den Phasen 2 bis 5 von CRISP-DM-Modells gekennzeichnet ist, ergibt sich durch Hinzunahme des erwähnten BI-Prozessablaufes zum eigentlichen Data Mining und dessen SEMMA-­Struktur eine ähnlich umfangreiche Handlungsanleitung, wie sie auch CRISP-DM bietet (vgl. SAS Institute 1998, S. 2 ff., 2013). 2.4.3.2 Microsoft Team Data Science Process (TDSP) Microsoft bezeichnet den Team Data Science-Prozess (TDSP) als eine flexible, iterative Data Science-Methodik zur effizienten Bereitstellung von Predictive Analytics-Lösungen und intelligenten Anwendungen, die auf eine verbesserte Zusammenarbeit und das Lernen im Team abzielt und eine erfolgreiche Implementierung von Data Science-Initiativen erleichtert. Besonderer Wert wird auf die Definition von Rollen von Mitarbeitern (Gruppenleiter, Teamleiter, Projektleiter, Projektmitwirkende) und deren Aufgaben im Rahmen des gesamten Analyseablaufes sowie auf eine agile Projektentwicklung gelegt (vgl. Microsoft 2017). Der TDSP strebt zudem an, Unternehmen bei der Nutzung ihrer Analyseprogramme zu unterstützen, und erweist sich als Lebenszyklusmethode, die zyklisch fünf Phasen durchläuft. Sogenannte Prüfpunktentscheidungen am Ende von Teilschritten liefern die Grundlage dafür, dass in die nächste Phase übergegangen werden kann oder nicht (vgl. Microsoft 2017). Insgesamt ist der TDSP das jüngste Vorgehensmodell zum Data Mining. Sein Phasenaufbau lässt sich ebenfalls mit dem zuvor dargestellten Konzept des CRISP-DM vergleichen, weist aber bisweilen einen höheren Detaillierungsgrad auf. So bietet Microsoft auf seinen Webseiten zahlreiche (verschachtelte) Hilfsmaterialien an, die unter anderem von einer Beispielsammlung zur Data Science über einschlägige Trainings, Handlungsanwei-

64

2  Technologische und konzeptionelle Ansätze zur Analyse und zum Reporting von …

sungen zum Einrichten von Data Science-Umgebungen, Anleitungen zum Verstehen von Daten bis hin zur Hilfestellung bei der Auswahl von Algorithmen reichen. Sie sind über den folgenden Link erreichbar [zuletzt abgerufen am: 22.06.2019]: https://docs.microsoft. com/de-de/azure/machine-learning/team-data-science-process/overview. Der folgende Abschnitt gibt einen Überblick über ausgewählte Analyseverfahren, die integrale Bausteine jedes auf Data Mining beruhenden Risikoreportings sind.

2.4.4 Ausgewählte Analyseverfahren Ein auf Business Analytics basierendes Risikomanagement von Finanzinstituten bietet breite Entwicklungsmöglichkeiten für Data-Mining-Projekte in Bereichen wie der Modellierung von Kredit-, Markt- und operationellen Risiken und der Betrugsbekämpfung (Fraud Detection). In solchen (im Sinne der zuvor beschriebenen Vorgehensmodelle in der Regel prozessual ablaufenden) Data-Mining-Projekten kommen insbesondere in der Datenauswertungs- und Modellierungsphase diverse Analyseverfahren zur Anwendung, mit deren Hilfe die gesuchten Informationen aus den vorliegenden Datenmustern extrahiert werden können. Angesichts der in Abschn. 2.4.2.4 beschriebenen Abgrenzung zwischen überwachten und unüberwachten Analyseverfahren ist es naheliegend, dass sich ein Risikoreporting auf Basis der in Abschn. 2.4.1 besprochenen Descriptive Analytics verstärkt der Methoden aus dem Bereich der unüberwachten Methoden bedient, während ein Risikomanagement im Sinne von Predictive Analytics und den darauf aufbauenden Prescriptive Analytics eher auf die im Bereich der überwachten Analyseverfahren beheimateten Methoden zurückgreift. Im Hinblick auf die zuvor in Abschn. 2.4.2 skizzierten Vorgehensmodelle wird somit deutlich, dass unüberwachte Analyseverfahren eher in den deskriptiv-statistisch orientierten Phasen 2 (Datenuntersuchung) und 3 (Datenaufbereitung) des CRISP-DM-Vorgehensmodells anzutreffen sind, während sich der Anwendungsschwerpunkt von überwachten Analyseverfahren auf die Phasen 4 (Modellierung) und 5 (Evaluierung) des CRISP-DM-Vorgehensmodells konzen­ triert (vgl. Fingerlos et al. 2016). Zu den in derartigen Risikoreportings anzutreffenden Methoden aus dem Bereich der unüberwachten Analyseverfahren zählen Clusterverfahren und Haupkomponentenanalysen, deren Zweck in erster Linie in der Datengruppierung und Informationsreduktion liegt. Mit ihrer Hilfe lassen sich etwa Kreditnehmer oder Kreditprodukte anhand ihrer Charakteristika in homogene Gruppen aufteilen (Clusteranalyse) oder Variablen, die das ökonomische Umfeld im Rahmen von Kreditvergaben aus verschiedenen Gesichtspunkten reflektieren, zu einem einzelnen Indikator der ökonomischen Entwicklung verdichten (Hauptkomponentenanalyse). Die Ergebnisse könnten dann in die Modellierung von Kreditausfallwahrscheinlichkeiten einfließen, die mithilfe überwachter Analyseverfahren wie linearen und logistischen Regressionsanalysen, Entscheidungsbaumverfahren und künstlichen neuronalen Netzen erfolgt (vgl. James et  al. 2013, S.  373  ff.; Larose und Larose 2015, S. 160 ff.).

2.4  Business Analytics

65

Die folgenden Ausführungen stellen die genannten Analyseverfahren kurz vor. Ihre praktischen Anwendungsmöglichkeiten werden in Abschn. 4.4 gezeigt.

2.4.4.1 Clusterverfahren Der Einsatzbereich von Clusterverfahren zielt auf die Zuordnung der einzelnen Objekte eines Datenbestandes zu disjunkten Segmenten bzw. Clustern. Dabei sollen die Objekte eines Segmentes in Bezug auf die jeweiligen Merkmalsausprägungen möglichst ähnlich, die Objekte unterschiedlicher Segmente dagegen unähnlich sein (vgl. Küsters 2001). Da hier eine Überprüfung der Ergebnisse kein originärer Analysebestandteil ist, handelt es sich um ein unüberwachtes Verfahren. Zur Messung der Ähnlichkeit bzw. Unähnlichkeit von Datenbeständen erfolgt zumeist der Einsatz von Distanzmaßen. Die Art des eingesetzten Distanzmaßes hängt wesentlich von den Skalenniveaus der verwendeten Attribute ab. Bei metrisch skalierten Attributen wird zur Bemessung der Distanz häufig auf die Euklidische Distanz zurückgegriffen, die für korrespondierende Attribute zweier Datenpunkte die Quadrate der Wertdifferenzen berechnet, daraus die Summe bildet und aus der Summe die Wurzel zieht. Bei nominal skalierten Attributen dagegen findet die Anzahl der unterschiedlichen Wertausprägungen zweier Datenpunkte als Distanzmaß Verwendung. Der Gower-Koeffizient nutzt eine Kombination beider Verfahren (allerdings wird hier statt auf die euklidische Distanz bei metrischen Attributen auf die Manhatten-Distanz als Absolutwert der einfachen Differenzen zurückgegriffen und diese anhand der Spannweite bei diesem Attribut normiert), um auch gemischt skalierte Attribute von Datensätzen zu einer Maßzahl zusammenzuführen (vgl. Chamoni et al. 2010). Neben der Auswahl des Distanzmaßes erweist sich vor allem das verwendete Verfahren zur Clusterbestimmung als zentral. Insbesondere werden heute partitionierende oder hie­ rarchische Clusterverfahren gewählt, um einen Ausgangsdatenbestand in möglichst homogene Segmente aufzuteilen. Dabei ist den partitionierenden Verfahren gemein, dass zunächst die Anzahl der zu erzeugenden Cluster festgelegt werden muss. Anschließend erfolgt (automatisch oder durch einen Anwender vorgegeben) die Bestimmung der zugehörigen Clusterzentren, denen ­danach die übrigen Datenobjekte durch Verwendung eines Distanzmaßes zugeordnet werden. Durch Neujustierungen der Clusterzentren und Neuzuordnung von Datenobjekten zu Clustern wird die Einteilung solange kalibriert, bis sich die Clusterzentren nicht mehr verändern. Als sehr verbreitete partitionierende Methodik erweist sich das K-Means-­Ver­ fahren. Als Alternative zu den partitionierenden sind hierarchische Verfahren verwendbar, bei denen keine Clusterzentren und damit Cluster als Ausgangsaufteilung vorgegeben werden. Zu unterscheiden ist hier zwischen agglomerativen und divisiven Verfahren. Die agglomerativ-hierarchischen Verfahren verstehen zunächst jedes Datenobjekt als separates Cluster und ziehen diese sukzessiv zu neuen, größeren Gruppen zusammen. Dazu sind im ersten Schritt die Distanzen zwischen allen Datensätzen und nachfolgend zu den bereits gebildeten Clustern zu berechnen. Die Distanzen zwischen Clustern lassen

66

2  Technologische und konzeptionelle Ansätze zur Analyse und zum Reporting von …

sich auf unterschiedliche Arten ermitteln. Eine Verwendung der Datensätze aus zwei Clustern mit dem größten Abstand wird als Complete-Linkage-Verfahren, mit dem geringsten Abstand als Single Linkage-Verfahren bezeichnet. Alternativ dazu lassen sich die Mittelwerte aller Attribute der Datensätze eines Clusters zur Distanzbestimmung verwenden (Average-Linkage-Verfahren). Im Gegensatz zu den agglomerativen starten die divisiven Verfahren mit einem einzigen Cluster, in dem sich alle Datensätze befinden. Schrittweise erfolgt anschließend die Aufspaltung der Datenobjekte in homogenere Teilgruppen. Im Vergleich beider Ausprägungen einer hierarchischen Clusteranalyse erweisen sich agglomerative Verfahren als schneller und werden daher in der praktischen Anwendung den divisiven Methoden vorgezogen (vgl. Küsters 2001). Im anwendungsorientierten Teil des Buches (Kap. 4) wird das Clustering mithilfe des K-Means-Verfahrens an einem Beispiel mit zwei numerisch skalierten Variablen näher besprochen. Der Fall mit zwei Variablen hat den Vorteil, dass die Formeln noch relativ einfach verständlich sind und sich zudem die Ergebnisse leicht grafisch analysieren und interpretieren lassen (vgl. EMC 2015, S. 120 ff.).

2.4.4.2 Hauptkomponentenanalysen Ebenso wie die Clusterverfahren gehören Hauptkomponentenanalysen zu den unüberwachten Methoden. Als Datenreduktionsverfahren nutzen sie Korrelationen bzw. Kovarianzen zwischen einer ursprünglichen Anzahl von k Variablen X1, X2, …, Xk und destillieren die ihnen zu Grunde liegenden gemeinsamen Informationen in eine Menge von m neuen Variablen, die über eine Anzahl von m Linearkombinationen der ursprünglichen Variablen gebildet werden. Obwohl die Anzahl der Linearkombinationen (meist, aber nicht notwendigerweise) kleiner als die Anzahl der ursprünglichen Variablen ist (m ≤ k), beinhalten sie fast dieselbe Information wie die ursprünglichen Variablen, sind jedoch nicht miteinander korreliert. Wenn die ursprünglichen Variablen beispielsweise als erklärende Variablen in einer Regressionsanalyse genutzt werden sollen, lässt sich mithilfe der Hauptkomponentenanalyse die Variablenanzahl reduzieren (bei m  1 prognostiziert werden, wäre es zielführend, entweder die zulässigen Werte der erklärenden Variablen auf der rechten Seite der Gleichung einzuschränken oder aber eine Transformation auf die Wahrscheinlichkeit auf der linken Seite der Gleichung anzuwenden, welche die Intervallgrenzen von 0 und 1 aufhebt (vgl. Allison 2012, S. 12 ff.; Verbeek 2012, S. 207 ff.; Kennedy 2008, S. 254 ff.; Kutner et al. 2005, S. 591 f.; Wooldridge 2016, S. 224 ff., S. 265 ff.; Backhaus et al. 2015, S. 292 ff.).

2.4  Business Analytics

75

Bei dieser Transformation wird die Wahrscheinlichkeit p in einem ersten Schritt durch einen Ausdruck ersetzt, der als Odds (Chancen bzw. Gewinnchancen) bezeichnet wird und p Odds bzw. p = mit der Wahrscheinlichkeit p in Verbin1− p 1 + Odds dung steht. Zur Erläuterung dieser sogenannten Odds-Transformation erfolgt ein Rückgriff auf das anfängliche Beispiel, in dem p die Wahrscheinlichkeit des Eintritts eines Zahlungsausfalls eines Bankkunden bezeichnet. Die Wahrscheinlichkeit des Nichteintritts des Zahlungsausfalls bei demselben Kunden beträgt dann 1 − p. Die Odds setzen beides zueinander ins Verhältnis und besitzen somit denselben Informationsgehalt wie die Wahrscheinlichkeit p. Dies bedeutet, dass sich bei einer Ausfallwahrscheinlichkeit von p = 0,1 1 Odds von = 0,1 ergeben und daraus folgt, dass die Wahrscheinlichkeit eines Nichtaus9 falls neunmal größer ist als die Wahrscheinlichkeit eines Ausfalls – was natürlich demselben Informationsgehalt wie p = 0,1 bzw. einer Ausfallwahrscheinlichkeit von 10 Prozent entspricht. Odds = 1 bedeuten, dass die Ausfallwahrscheinlichkeit bei p = 0,5 liegt bzw. dass Ausfallwahrscheinlichkeit und Nichtausfallwahrscheinlichkeit gleich groß sind (nämlich jeweils 50 Prozent). Ein Wahrscheinlichkeitswert von p = 0,9 bzw. 90 Prozent 9 wiederum ergibt Odds von = 9 , was bedeutet, dass die Ausfallwahrscheinlichkeit neun1 mal größer ist als die Nichtausfallwahrscheinlichkeit. An diesen Zahlenspielen lässt sich eine praktische Eigenschaft der Odds verdeutlichen. Solange Werte im definierten Bereich der Wahrscheinlichkeit von 0 ≤ p  0 EUR mit einer Gesundung des Kreditnehmers gerechnet werden kann.

(1) Dem Indikator kommt aufgrund der im Eventualfall bereits eingetretenen finanziellen Schieflage des Kreditnehmers und der bereits eingetretenen Zahlungsrückstände eine stark eingeschränkte Frühwarnfunktion zu. (2) Zur Interpretation des Indikators ist aufgrund des fehlenden Geschäftspartnerbezugs die Hinzuziehung der Merkmale [066] und [068] notwendig. (3) Die Information ist für die Frühwarnung teilweise redundant, siehe Merkmal [068].

073 Tage im Verzug (für Die Anzahl der die letzten 12 Monate) aufeinanderfolgenden Kalendertage im Verzug bis zum Erreichen der aufsichtsrechtlich vorgegebenen 90-Tage-Frist lässt Rückschlüsse auf einen absehbaren Ausfall des Kreditnehmers zu. Erläuterung: Nach der hier verwendeten Ausfalldefinition gemäß SolvV liegt ein Ausfall für einen Schuldner vor, wenn es (1) aufgrund konkreter Anhaltspunkte unwahrscheinlich ist, dass der Schuldner ohne Rückgriff des Instituts auf Maßnahmen wie die Verwertung von Sicherheiten seinen Zahlungsverpflichtungen aus Kreditgewährung gegenüber dem Institut oder einem gruppenangehörigen Unternehmen der Institutsgruppe, Finanzholding-Gruppe oder gemischten FinanzholdingGruppe, der das Institut angehört, vollständig nachkommt. (2) Ein Ausfall liegt auch vor, wenn der Schuldner mit einem wesentlichen Teil seiner extern zugesagten Gesamtverpflichtung an mehr als 90 aufeinanderfolgenden

(1) Dem Indikator kommt aufgrund der im Eventualfall bereits eingetretenen finanziellen Schieflage des Kreditnehmers, der sich bereits im Zahlungsverzug befindet, und der rückwärtsgerichteten Betrachtung keine Frühwarnfunktion zu. (2) Die Informationen stehen im Beispielinstitut für Mietinvestoren und den Eigenheimbereich nur teilweise zur Verfügung. (3) Zur Relativierung der Kriterienaussage sind zusätzliche Informationen über die Verzugshöhe bzw. die Höhe des Verzugsschadens heranzuziehen (siehe Merkmal [071] in Tab. 3.1). Da die Verzugszähler bei einem Schuldnerwechsel im vorliegenden Fall nicht zurückgesetzt werden, ist zur Verknüpfung mit dem aktuellen Schuldner zusätzlich das Merkmal [066] "Schuldnerwechsel stattgefunden (ja/nein)" notwendig.

3.1  Risikofrüherkennung und automatisierte Risikoklassifizierung

109

Tab. 3.2 (Fortsetzung) Tagen überfällig ist. Hierbei gilt der Schuldner gegenüber dem Institut oder gegenüber einem gruppenangehörigen Unternehmen als überfällig, wenn für diesen Schuldner die aktuell bestehende Gesamtschuld den gegenwärtig mitgeteilten Gesamtrahmen um mehr als 2,50 %, mindestens jedoch um 100 EUR übersteigt (vgl. § 125 Abs. 1 Nr. 1 und 2 SolvV). Zu den Ereignissen, die als Hinweise auf die Unwahrscheinlichkeit der Erfüllung von Zahlungsverpflichtungen durch den Kreditnehmer anzusehen sind, vgl. § 125 Absatz 2 SolvV. Zu den Ereignissen zählen u.a. die Vornahme einer Wertberichtigung durch das Institut, der Verkauf von Verpflichtungen aus der Kreditgewährung mit einem erheblichen wirtschaftlichen Verlust oder die Einwilligung des Instituts in eine Sanierungsumschuldung der Verpflichtung aus Kreditgewährung. – Ist ein Ausfall gemäß der vorbezeichneten Ausfalldefinitionen gegeben, wird dem betreffenden Kreditnehmer ein entsprechendes Ausfallrating D1, D2, D3 zugeordnet und in den ratingführenden Systemen bzw. in der Ausfalldatenbank des Beispielinstituts hinterlegt.

074 Tage im Verzug (in Gesamtlaufzeit)

Aus der Anzahl der Tage im Verzug und dessen Entwicklung im Zeitablauf können Rückschlüsse auf einen drohenden Ausfall des Kreditnehmers gezogen werden.

(1) Dem Indikator kommt aufgrund der im Eventualfall durch den Zahlungsverzug bereits eingetretenen finanziellen Schieflage des Kreditnehmers sowie der ggf. im Gang befindlichen Intensivbearbeitung keine signifikante Frühwarnfunktion zu.

(Fortsetzung)

110

3  Prototypische Umsetzung einer BI-basierten Reporting-Anwendung und eines …

Tab. 3.2 (Fortsetzung) (2) Die Informationen stehen für Mietinvestoren und den Eigenheimbereich nur teilweise zur Verfügung. (3) Zur Relativierung der Kriterienaussage sind zusätzliche Informationen über die Verzugshöhe heranzuziehen. Zur maßgeblichen Verzugshöhe siehe die Erläuterung zu Merkmal [073].

075 Stundungsanträge

Mithilfe des Indikators sowie dessen kreditnehmerspezifische Entwicklung im Zeitablauf können mögliche Liquiditätsprobleme antizipiert werden. Eine Gegensteuerung ist möglich.

(1) Die Frühwarneigenschaften des Indikators werden infolge des Time-Lags bis zur Einreichung von Stundungsanträgen durch den Kreditnehmer ggf. beeinträchtigt.

Aus der Zeitspanne zwischen Sollstellungsdatum (Einbuchungsdatum) und Leistungsdatum (Datum des Zahlungseingangs) können Rückschlüsse auf evtl. Liquiditätsengpässe des Darlehensnehmers gezogen werden.

(1) Die Kontoumsätze werden auf Tagesbasis aktualisiert.

(2) Historische Daten stehen Stundungsanträge werden pro im Beispielinstitut seit [Geschäftspartner] auf der mindestens 5 Jahren zur Hierarchieebene Verfügung. [Antragsnummer] hinterlegt. Mit der Einreichung eines Stundungsantrages durch den Kreditnehmer ist gemäß der im vorliegenden Fall verwendeten Ausfalldefinition (siehe die Erläuterung zu Merkmal [073]) noch keine persistente Ablage in der Ausfalldatenbank des Beispielinstituts verbunden. 100 Kontoumsätze

(2) Mit dem Auftreten von Zahlungsstörungen kann im Regelfall nur zu den vertraglich festgelegten Leistungsterminen 30.06. und 31.12. gerechnet werden. Eine höhere, mindestens monatliche Überwachungsfrequenz kann zum Untersuchungszeitpunkt nicht sichergestellt werden.

Anzahl an Indikatoren als vernachlässigbar anzusehen, soweit die Indikatoren in ihrer Gesamtheit eine Frühwarnung auslösen, die den Ausgangspunkt für eine nähere Betrachtung des Risikoträgers und eine mögliche anschließende Anpassung des Bonitätsratings bildet. Somit stehen nach den bisherigen Ausführungen für ein Konzept zur Risikofrüherkennung die in Abb. 3.1 prototypisch zusammengefassten sieben internen Indikatoren zur Ver-

3.1  Risikofrüherkennung und automatisierte Risikoklassifizierung

111

Abb. 3.1  Exemplarisches Scoringmodell nach fachlicher Ersteinschätzung der internen Indikatoren. (Quelle: eigene Darstellung)

fügung, wobei die Detailbereiche [Familienstand], [Beschäftigung und Einkommen] sowie [Objektfinanzierung und Schuldendienst] angesprochen werden. Pro Detailbereich werden die Indikatoren hier und nachfolgend gemäß den Gewichtungen absteigend sortiert. Für die Gewichtungen der Risikofaktoren und Detailbereiche, hier: [Familienstand], [Beschäftigung und Einkommen] sowie [Objektfinanzierung und Schuldendienst], stellen die in Tab. 3.2 abgelegten Skalierungen der Frühwarneigenschaften einen ersten Anhaltspunkt dar. Die sogenannten „KO-Kriterien“, die in Abb. 3.1 an den rot markierten Gewichtungsbalken erkennbar sind, gehen bei Überschreitung der pro KO-Kriterium definierten individuellen Warnmarke definitionsgemäß mit einer Punktzahl in das Gesamtscoring ein, die das Ergebnis des Scoringbogens auf den maximalen Scoringwert verschlechtert. Hierbei entspricht die für das erste KO-Kriterium vergebene Punktzahl der Differenz zwischen der auf dem Scoringbogen in Summe maximal möglichen gewichteten Risikopunktzahl und der auf dem Scoringbogen bei den übrigen Kriterien bis dahin bereits vergebenen gewichteten Risikopunkte. Die Berücksichtigung mindestens eines KO-Kriteriums führt demnach stets zu einer Verschlechterung des Gesamtergebnisses auf die pro Scoringbogen maximal mögliche gewichtete Risikopunktzahl und löst somit in jedem Fall eine Frühwarnung für den betreffenden Risikoträger aus.

112

3  Prototypische Umsetzung einer BI-basierten Reporting-Anwendung und eines …

Zur Berechnung der pro KO-Kriterium relevanten Risikopunktzahl ist im ersten Schritt die auf dem Scoringbogen ohne KO-Kriterien maximal erreichbare gewichtete Gesamtpunktzahl GRPMAX zu bestimmen. Es gilt: GRPMAX = ∑ Gewichti ⋅ RPi mit i= Anzahl der Indikatoren. Von GRPMAX wird im zweiten Schritt die Summe der gewichteten Risikopunkte subtrahiert, die im Rahmen der Bewertung der regulären Indikatoren auf dem Scoringbogen erreicht worden ist (GRPREG). Von GRPMAX zu subtrahieren sind bereits vergebenen Risikopunkte aus KO-Kriterien GRPKO. Die verbleibende Differenz (DKO) bildet die Risikopunktzahl ab, die für das erste KO-Kriterium systemseitig so angesetzt wird, dass das Gesamtscoring stets der maximal erreichbaren gewichteten Risikopunktzahl GRPMAX entspricht. Für alle weiteren KO-Kriterien nimmt DKO den Wert 0 an, da die höchste gewichtete Risikopunktzahl bereits erreicht wird, sobald ein KO-Kriterium den vorgegebenen Schwellenwert übersteigt. Es gilt: DKO = max (0, GRPMAX − ∑ GRPREG − ∑ GRPKO) mit DKO ∈ {0,GRPMAX}.

3.1.3 M  odellerweiterung um externe (makroökonomische) Indikatoren Zur Verbesserung und inhaltlichen Ergänzung der Prognosegüte werden marktbasierte externe Risikofaktoren in die weiteren Überlegungen einbezogen. Grundsätzlich kommen in Abhängigkeit von den zugrunde liegenden Portfolien z. B. externe Ratinginformationen, Lebenshaltungskosten, Mietpreisindizes, Zinsentwicklungen, Kursindizes, Entwicklungen der Löhne und Gehälter in Betracht (vgl. zur Kriterienauswahl Huergo und Schmalzried 2016, S. 16). Um die laufenden bzw. Lizenzkosten der regelmäßigen Einspielung von externen Informationen gering zu halten, soll in einem ersten Schritt auf volkswirtschaftliche Daten zurückgegriffen werden, die (a) im Internet frei zugänglich sind und die (b) über automatisierbare Zugriffe und eine Ablage im Datenhaushalt des Instituts regelmäßig (täglich, wöchentlich, monatlich) importiert und verarbeitet werden können. Sämtliche der hier und nachfolgend aufgeführten externen Indikatoren können auf automatisierter Basis über das Statistische Bundesamt oder die Statistischen Landesämter bezogen werden. Zudem ist davon auszugehen, dass bei den meisten Indikatoren, z. B. Angaben zum Verbraucherpreis­ index, zu den Wohnungsmieten (einschließlich Nebenkosten) sowie zu den Auftragseingängen im Bauhauptgewerbe (vorbereitende Baustellenarbeiten, Hoch- und Tiefbau), auf bereits bestehende, institutsinterne Zulieferwege zurückgegriffen werden kann (z. B. Volkswirtschaftliche Abteilung oder Wohnungsmarktbeobachtung des Instituts). Für retailnahe Portfolien wie die private Immobilienfinanzierung oder die Wohnraumförderungen, die unserem Beispiel zugrunde liegen, sind nach einer expertenbasierten Einschätzung die folgenden makroökonomischen Kenngrößen geeignet (vgl. Tab. 3.3). Im nächsten Schritt werden die externen Risikofaktoren hinsichtlich ihrer Frühwarneigenschaften für das Portfolio der privaten Immobilienfinanzierung bzw. Wohnraumförderung näher untersucht. Die Faktoren werden nach den Ergebnissen einer statistischen Zeitreihenanalyse mit der weiter oben beschriebenen Bewertung A bis E versehen. Die

3.1  Risikofrüherkennung und automatisierte Risikoklassifizierung

113

Tab. 3.3  Externe risikorelevante Faktoren zur Erweiterung des Scoringmodells Lebenshaltung e01 Verbraucherpreisindex für Wohnung, Wasser, Strom und Brennstoffe e02 Index der Nettokaltmieten [Bundesland] e03 Mietspiegel [Musterstadt] (40–80 m2) in EUR pro m2 Beschäftigung und Einkommen e04 Anzahl der (gemeldeten) offenen Stellen [ggf. regional] e05 Auftragseingang im Bauhauptgewerbe: Wohnungsbau in Tsd. EUR e06 Anzahl der Kurzarbeiter [ggf. regional] Marktnahe Indikatoren e07 Hypothekenzins mit 5 Jahren Sollzinsbindung (Topzins) in % e08 Dispositionszins in % e09 Anzahl Privatinsolvenzen (Insolvenzverfahren eröffnet) e10 DAX Kursindex (Basis = 1988)

Bewertungen basieren auf Detailuntersuchungen der in Tab. 3.4 aufgeführten Risikofaktoren, wobei pro Faktor mithilfe eines (einfachen) linearen Regressionsansatzes nach der Methode der kleinsten Quadrate eine mögliche Korrelation mit den Kreditausfällen im Vorfeld der Ausfallzeitpunkte untersucht wird. Es kommt ein statistisches Modell der Form Yi = a + bXi + εi zur Anwendung. Als abhängige Variable Yi fließt der jeweils untersuchte externe Risikofaktor zum ­Beobachtungszeitpunkt i in das Modell ein, εi stellt den Störterm sowie a und b die zu schätzenden Koeffizienten dar. Die erklärende Variable Xi ist als lineare Trendvariable modelliert, welche die Anzahl der seit einem (datenbankintern festgelegten) Stichtag (Nullpunkt) bis zum jeweiligen Beobachtungszeitpunkt verstrichenen Tage beinhaltet. In dem im Folgenden verwendeten Datenbestand lässt sich beispielsweise der Beobachtungszeitpunkt 26.02.2010 in Xi = 40235 seit dem Stichtag verstrichene Tage umrechnen.

Anschließend erfolgt eine fachliche Einschätzung der Ergebnisse. Diese fachliche Einschätzung unterstellt, dass 1.) die Anwendungsvoraussetzungen der linearen Regressionsanalyse erfüllt sind (vgl. Abschn. 2.4.4.3, Annahmen A1 bis A5), dass 2.) die geschätzten Koeffizienten b statistisch signifikant sind sowie dass 3.) die Zeitreihen der externen Risikofaktoren nicht mit Saisonalität behaftet sind bzw. saisonale Effekte explizit nicht modelliert werden sollen (vgl. Wooldridge 2016, S. 336 ff.). Im Hinblick auf die bankenpraktischen Anwendungsmöglichkeiten der hier gezeigten prototypischen Einbindung von Risikoindikatoren ist festzuhalten (Desideratum), dass die Einhaltung der zuvor skizzierten Annahmen zu belegen bzw. ihre Nichteinhaltung zu begründen ist, wenn statistisch bzw. regulatorisch belastbare Prognosen erstellt werden sollen.

Exemplarisch für die den Einschätzungen A bis E zugrunde liegenden statistischen Analysen wird in Abb. 3.2 die Regressionsanalyse des externen Risikofaktors (e01) „Verbraucherpreisindex für Wohnung, Wasser, Strom und Brennstoffe“ dargestellt. Bei der Regressionsanalyse ist hier und nachfolgend auf Grundlage der zur Verfügung gestellten Institutsdaten auf zwei markante Ausfallzeitpunkte referenziert worden: Auf den 31.03.2011 sowie zur Verifizierung der Regressionsparameter und Auslöser für eine

114

3  Prototypische Umsetzung einer BI-basierten Reporting-Anwendung und eines …

Tab. 3.4  Frühwarneigenschaften ausgewählter externen Risikofaktoren Nr.

Merkmal

e01 Verbraucherpreisindex für Wohnung, Wasser, Strom und Brennstoffe

Frühwarnansatz

Regressionsanalyse

FWE

Lebenshaltungskosten als genereller Gradmesser der finanziellen Leistungsfähigkeit des Kreditnehmers bzw. des Begünstigten (z. B. private Immobilienkredite, soziale Mietwohnraumförderung)

Anhand der bereitgestellten Zeitreihen ist für die letzten (7) Stützpunkte bis zum Referenz-Ausfalldatum ein signifikanter Anstieg der Lebenshaltungskosten zu erkennen. Mithilfe eines linearen Regressionsansatzes nach der Methode der kleinsten Quadrate lässt sich eine Regressionsgerade mit einem Determinationskoeffizienten , bestimmen, von entsprechend einer sehr hohen Prognosegüte. Der Determinationskoeffizient ( ) gibt hierbei den Anteil der durch die Regressionsgerade erklärten Varianz an der Gesamtvarianz an. Es gilt 0 ≤ ≤ 1. Je größer ist, desto besser ist die Abbildung der Zeitreihe durch die im Rahmen der Analyse ermittelte Regressionsgerade. Als Auslöser (Trigger) für die Frühwarnung kommen in Betracht: A. Die Überschreitung eines kritischen Schwellenwertes mit der Warnmarke (Trigger) hier und nachfolgend definiert als [Arithmetischer Mittelwert] ± [Standardabweichung1]. B. Eine signifikante Veränderung des Steigungsmaßes der Regressionsgeraden gegenüber der EinjahresTrendentwicklung mit der Warnmarke (Trigger) hier und nachfolgend definiert als [Steigungsmaß kurzfristige Regressionsgerade] > oder < 1,10 [Steigungsmaß EinjahresRegressionsgerade].

(Fortsetzung)

3.1  Risikofrüherkennung und automatisierte Risikoklassifizierung

115

Tab. 3.4 (Fortsetzung) e02 Index der Nettokaltmieten [Bundesland]

A. Der maßgebliche (regionale) Mietspiegel sinkt unter das zur Refinanzierung der Kreditaufnahme erforderliche Mindestniveau (relevant für Mietinvestoren). B. Allgemeines Mietniveau als wesentlicher Bestandteil der Lebenshaltungskosten (relevant für begünstigte Haushalte in der privaten Immobilien-, Mietwohnraumoder Eigenheimförderung). Ein Anstieg des Mietpreisniveaus kann sich tendenziell nachteilig auf die im Rahmen der Wohnraumförderung begünstigen Haushalte auswirken. Daraus resultierende Fluktuationen führen tendenziell zu höheren Wohnungsleerständen und möglichen weiteren finanziellen Nachteilen für die Mietinvestoren (z. B. in Form von Zinsaufschlägen).

e03 Mietspiegel [Musterstadt] (4080 m2) in EUR pro m2

Ansatz wie e02

A. Im Betrachtungszeitraum lässt sich ein konstanter Anstieg des Mietpreisniveaus feststellen. Aussagekräftige Warnmarken (Trigger) können infolge der inversen Entwicklung der Nettokaltmieten derzeit nicht definiert werden. B. Die Analyse ergibt einen leicht überdurchschnittlichen Anstieg des Mietpreisniveaus mit einem Vorlauf von etwa 3 Monaten vor den ReferenzAusfallzeitpunkten. Mithilfe eines linearen Regressionsansatzes lässt sich eine Regressionsgerade mit einem Determinationskoeffizienten von = , bestimmen, entsprechend einer sehr hohen Prognosegüte. Als Auslöser (Trigger) für die Frühwarnung kommen sowohl die Überschreitung eines kritischen Mietniveaus als auch eine Veränderung des Steigungsmaßes der Regressionsgeraden gegenüber der EinjahresTrendentwicklung (14 Stützpunkte) in Betracht. Das Niveau des (regionalen) Mietspiegels bleibt im Betrachtungszeitraum unverändert.

/

Aussagekräftige Warnmarken (Trigger) können aufgrund der fehlenden Varianz des Mietspiegels (Steigungsmaß der Regressionsgeraden = 0) nicht definiert werden. Demnach wird e03 als Risikofaktor ausgeschlossen.

(Fortsetzung)

116

3  Prototypische Umsetzung einer BI-basierten Reporting-Anwendung und eines …

Tab. 3.4 (Fortsetzung) e04 Anzahl der (gemeldeten) offenen Stellen [ggf. regional]

Lässt ggf. Rückschlüsse auf die Konjunkturentwicklung und damit mittelfristig auf die Möglichkeiten der (regionalen) Einkommenserzielung bzw. auf die Entwicklung der Kaufkraft zu.

Im Betrachtungszeitraum lässt sich ein tendenzieller Anstieg der gemeldeten offenen Stellen beobachten. Die graphische Analyse lässt – abgesehen von saisonalen Schwankungen – keine Sensitivität in Bezug auf die Referenz-Ausfallzeitpunkte erkennen. Aussagekräftige Warnmarken (Trigger) können infolge der inversen Entwicklung der gemeldeten offenen Stellen nicht definiert werden. Als Frühwarnindikator kommt e04 demnach nicht in Betracht.

(Fortsetzung)

3.1  Risikofrüherkennung und automatisierte Risikoklassifizierung

117

Tab. 3.4 (Fortsetzung) e05 Auftragseingang im Bauhauptgewerbe: Wohnungsbau in Tsd. EUR

Auftragseingänge als klassischer Frühwarnindikator für die (sektorale) Konjunkturentwicklung

Die graphische Analyse lässt mit einem Vorlauf von 3 bis 4 Monaten vor den ReferenzAusfallzeitpunkten eine absolute Verringerung der Auftragseingänge im Bauhauptgewerbe erkennen. Mithilfe eines linearen Regressionsansatzes lässt sich eine Regressionsgerade mit einem Determinationskoeffizienten bestimmen, von = , entsprechend einer eher geringen Prognosegüte. Aufgrund der in [e05] enthaltenen saisonalen Komponente kann angenommen werden, dass mithilfe einer exponentiellen Trendfunktion eine höhere Prognosegüte erzielt werden kann. Durch eine Reduzierung der Stützpunkte, z. B. von derzeit 7 auf 5, kann ebenfalls eine für das Triggern der Frühwarnung relevante Änderung des Steigungsmaßes der kurzfristigen Trendgeraden bzw. eine Drehung erzielt werden (wodurch sich infolge der Verkürzung des Referenzzeitraums in Richtung eines „gleitenden Durchschnitts“ auch saisonale Zeitreihen nachbilden lassen). Als nachteilig wirkt sich in diesem Fall die tendenziell häufigere Erreichung der über den Einjahres-Trend definierten Warnmarken aus; insbesondere die häufigere, gegenüber der EinjahresTrendentwicklung überdurchschnittliche Änderung des Steigungsmaßes der kurzfristigen Trendgeraden, was zu einer entsprechend häufigeren Warnmarkenüberschreitung und Frühwarnung führt (zur Definition des Determinationskoeffizienten siehe die Ausführungen zu [e01]).

(Fortsetzung)

118

3  Prototypische Umsetzung einer BI-basierten Reporting-Anwendung und eines …

Tab. 3.4 (Fortsetzung) Als Auslöser (Trigger) für die Frühwarnung kommt ansatzweise eine Veränderung des Steigungsmaßes der Regressionsgeraden gegenüber der EinjahresTrendentwicklung (14 Stützpunkte) in Betracht.

e06 Anzahl der Kurzarbeiter [ggf. regional]

e07 Hypothekenzins mit 5 Jahren Sollzinsbindung (Topzins) in %

Lässt ggf. Rückschlüsse auf die Konjunkturentwicklung und die (regionalen) Möglichkeiten der Einkommenserzielung zu; und damit auf kurzfristige Beeinträchtigungen der Kaufkraft. Aus makroökonomischer Sicht stellt die Zahl der Kurzarbeiter eine konjunkturreagiblere Größe dar als z. B. die Zahl der Arbeitslosen oder die Zahl der gemeldeten offenen Stellen.

Die Zahl der Kurzarbeiter nimmt im Betrachtungszeitraum signifikant ab.

Aus der (mittelfristigen) Zinsentwicklung kann auf künftige Veränderungen des Kreditzinses und damit auf absehbare finanzielle Minderoder Mehrbelastungen für den Kreditnehmer geschlossen werden.

Anhand der bereitgestellten Zeitreihen ist für die letzten (7) Stützpunkte vor dem Referenz-Ausfalldatum ein Anstieg des Zinsniveaus erkennbar.

Aussagekräftige Warnmarken (Trigger) lassen sich infolge der inversen Entwicklung im vorliegenden Fall nicht definieren.

Mithilfe eines linearen Regressionsansatzes lässt sich eine Regressionsgerade mit einem Determinationskoeffizienten berechnen, von = , entsprechend einer mittelmäßigen Prognosegüte. Als Auslöser (Trigger) für die Frühwarnung kommen sowohl die Überschreitung eines kritischen Zinsniveaus als auch die Veränderung des Steigungsmaßes der Regressionsgeraden gegenüber der EinjahresTrendentwicklung (14 Stützpunkte) in Betracht.

(Fortsetzung)

3.1  Risikofrüherkennung und automatisierte Risikoklassifizierung

119

Tab. 3.4 (Fortsetzung) e08 Dispositionszins in %

Lässt Rückschlüsse auf Überziehungskosten und die (kurzfristigen) Möglichkeiten der Refinanzierung der Kreditnehmer zu.

Die graphische Analyse lässt mit einem Vorlauf von 1 bis 2 Monaten vor den ReferenzAusfallzeitpunkten einen leichten Anstieg des Dispositionszinssatzes erkennen. Mithilfe eines linearen Regressionsansatzes lässt sich eine Regressionsgerade mit einem Determinationskoeffizienten bestimmen, von = , entsprechend einer sehr geringen Prognosegüte. Als Auslöser (Trigger) für die Frühwarnung kommt ansatzweise eine Veränderung des Steigungsmaßes der Regressionsgeraden gegenüber der EinjahresTrendentwicklung (14 Stützpunkte) in Betracht.

e09 Anzahl Privatinsolvenzen (Insolvenzverfahren eröffnet)

Allgemeiner Indikator für die Konjunkturentwicklung (relevant für den Eigenheimbereich und private Mietinvestoren)

Die Zahl der Privatinsolvenzen nimmt im Betrachtungszeitraum tendenziell ab. Die graphische Analyse lässt zusätzlich zu starken zyklischen Schwankungen keine Sensitivität in Bezug auf die beiden ReferenzAusfallzeitpunkte erkennen. (Darüber hinaus sind die zyklischen absoluten Zunahmen eher marginal). Aussagekräftige Warnmarken (Trigger) können infolge der inversen Entwicklung der Anzahl eröffneter Insolvenzverfahren für den Betrachtungszeitraum nicht definiert werden.

(Fortsetzung)

120

3  Prototypische Umsetzung einer BI-basierten Reporting-Anwendung und eines …

Tab. 3.4 (Fortsetzung) e10 DAX Kursindex (Basis 1988)

Allgemeiner Indikator für die Konjunkturentwicklung

Die graphische Analyse lässt keine eindeutigen Rückschlüsse auf die Sensitivität bezüglich der Referenz-Ausfallzeitpunkte zu (die Änderungen der Steigungsmaße sind vor beiden Referenzzeitpunkten nicht signifikant). Mithilfe eines linearen Regressionsansatzes lässt sich eine Regressionsgerade mit einem Determinationskoeffizienten bestimmen, von entsprechend einer befriedigenden bis ausreichenden Prognosegüte. Als Auslöser (Trigger) für die Frühwarnung kommt die Unterschreitung eines kritischen DAXKursindexwertes in Betracht.

Die Standardabweichung ist ein Maß dafür, wie weit der Wert eines Merkmals um das arithmetische Mittel streut. Die Standardabweichung ist verwandt mit der Varianz. Im Gegensatz zu dieser besitzt die Standardabweichung dieselbe Dimension und dieselbe Einheit wie das Merkmal selbst 1

Frühwarnung (Alerting) auf den 30.09.2011. Die im Rahmen der Validierung zugrunde gelegten Regressionsanalysen beziehen sich pro Indikator auf den zur Überprüfung der Frühwarneigenschaften jeweils geeigneteren der beiden Ausfallzeitpunkte. Die Regressionsgüte des externen Risikofaktors (e01) kann abschließend als vergleichsweise hoch bezeichnet werden. Als Gegenbeispiel findet sich in Abb. 3.3 die Detailanalyse des externen Risikofaktors (e03) „Mietspiegel [Musterstadt] (40–80  m2) in EUR pro m2“. Aufgrund der fehlenden Varianz erweist sich die Regressionsanalyse als überflüssig und die Kenngröße kommt als Frühwarnindikator nicht in Frage. Aus der statistischen Analyse ergibt sich mit Blick auf die Eignung der in die weitere Analyse ausgewählten externen (makroökonomischen) Faktoren für die risikobasierte Frühwarnung das in Tab. 3.4 zusammengefasste Gesamtbild. Zur Ergänzung der internen Risikofaktoren können nunmehr die in Tab. 3.4 mit einer Einschätzung A bis E versehenen externen Indikatoren herangezogen werden. Die auf die Ergebnisse referenzierende Abb. 3.4 fasst die in Frage kommenden sechs externen bzw. portfoliospezifischen Indikatoren in einem Oberflächenprototypen zusammen. Für die Gewichtung der externen Risikofaktoren und der drei Detailbereiche [Lebenshaltung], [Beschäftigung und Einkommen] sowie [Marktnahe Indikatoren] sind die in

3.1 Risikofrüherkennung und automatisierte Risikoklassifizierung

121

Abb. 3.2  Exemplarische Regressionsanalyse externer Risikofaktor (e01). (Quelle: eigene Darstellung)

122

3  Prototypische Umsetzung einer BI-basierten Reporting-Anwendung und eines …

Abb. 3.3  Exemplarische Regressionsanalyse externer Risikofaktor (e03). (Quelle: eigene Darstellung)

Tab.  3.4 hinterlegten Skalierungen der Frühwarneigenschaften maßgebend. Wie in Abb. 3.4 zu erkennen, sind bei den externen Indikatoren (anders als bei den kundenbezogenen internen Risikofaktoren; vgl. Abb.  3.1) keine sogenannten „KO-Kriterien“ ­vorgesehen. Dies ist dem portfoliospezifischen Charakter der externen Indikatoren geschuldet, die dem Grunde nach keine Rückschlüsse auf einzelne Kreditengagements zu-

3.1  Risikofrüherkennung und automatisierte Risikoklassifizierung

123

Abb. 3.4  Scoringmodell nach einer Analyse ausgewählter externer Faktoren. (Quelle: eigene Darstellung)

lassen, sondern stattdessen auf die allgemeine makroökonomische (regionale) Entwicklung und daraus ableitbare Risiken für das Gesamtportfolio abstellen. Je nach Beschaffenheit des zugrunde liegenden Portfolios sind durchaus Szenarien denkbar, in denen die makroökonomischen Kriterien einen Downgrade anzeigen, die kundenbezogenen (internen) Indikatoren aber keine entsprechenden Rückschlüsse zulassen.

3.1.4 Konzeption und Prototyping Gesamtmodell Bei Zusammenfassung zu einem Gesamtmodell der bis hierher entwickelten internen und externen Indikatoren, die aufgrund ihrer fachlichen Inhalte sowie der aktuellen und geplanten Aktualisierungsfrequenzen für eine Risikofrüherkennung geeignet sind, lassen sich die in Tab. 3.5 genannten Detailbereiche und Risikofaktoren unterscheiden. Die Nummerierung der Indikatoren in der Spalte [Nr.] orientiert sich an den in Tab. 3.2 und Tab. 3.4 vorgegebenen Ordnungszahlen (externe Indikatoren sind mit dem Präfix „e“ gekennzeichnet). Die Reihenfolge der Indikatoren pro Detailbereich entspricht (bei absteigender Priorisierung) der Gewichtung bzw. der Relevanz des Kriteriums für das Gesamtergebnis auf dem Scoringbogen. Der interne Indikator 068 ist der Vollständigkeit halber mit aufgeführt,

124

3  Prototypische Umsetzung einer BI-basierten Reporting-Anwendung und eines …

Tab. 3.5  Detailbereiche sowie kombinierte interne und externe Risikofaktoren Nr.

Detailbereich | Risikofaktor | Frühwarneigenschaft (FWE)

Familienstand 023

Beziehung zwischen 1. und weiterem Antragsteller |

→ KO-Kriterium

Lebenshaltung e01

Verbraucherpreisindex für Wohnung, Wasser, Strom und Brennstoffe |

e02

Index der Nettokaltmieten [Bundesland] |

Beschäftigung und Einkommen 024

Einkommenskategorie und Merkmale aus Zinsanhebungen (nur Eigenheimbereich) |

e05

Auftragseingang im Bauhauptgewerbe: Wohnungsbau in Tsd. EUR |

Objektfinanzierung und Schuldendienst 065

Rücklastschriften (bezogen auf eigene Darlehensraten) |

075

Stundungsanträge |

028

Zins fix / variabel |

100

Kontoumsätze |

068

Aktueller Gesamtrückstand in Euro |

→ KO-Kriterium

Marktnahe Indikatoren e07

Hypothekenzins mit 5 Jahren Sollzinsbindung (Topzins) in % |

e10

DAX Kursindex (Basis

e08

Dispositionszins in % |

1988) |

wird aber aufgrund der mit „E“ bewerteten, mithin gering ausgeprägten Frühwarneigenschaft und als schwächster der internen Indikatoren von der weiteren Betrachtung ­ausgeschlossen. Im Rahmen der systembasierten Umsetzung der Frühwarnung sind neben den Skalierungen A bis E, die in Gewichtungen transformierten werden, sowie den Besonderheiten der KO-Kriterien die pro Indikator definierten fachlichen Auslöser (Trigger) zu berücksichtigen (vgl. Tab. 3.6). Bei denjenigen Risikofaktoren, bei denen stetige Merkmalsausprägungen möglich sind (also nicht nur die Zustände WAHR oder FALSCH), erfolgt die Auslösung der Frühwarnung in zwei Fällen: (a) ein vorab definierter absoluter Schwellenwert wird erreicht oder überschritten bzw. unterschritten und/oder (b) das Steigungsmaß der Regressionsgeraden erreicht oder übersteigt bzw. unterschreitet einen vorab definierten kritischen Wert. Mit Erreichung bzw. Über- oder Unterschreitung der Warnmarken führen die Trigger pro Indikator zur Vergabe von Risikopunkten in Höhe der in Tab.  3.6, Spalte [Resultat (gewichtete Risikopunkte)] beschriebenen Metrik. Ferner wird eine rote Ampelmarkierung ( ) in der betreffenden Indikatorzeile auf dem Scoringbogen angezeigt.

3.1  Risikofrüherkennung und automatisierte Risikoklassifizierung

125

Tab. 3.6  Indikatorspezifische Auslöser (Trigger) für die Frühwarnung

Nr.

Risikofaktor

Auslöser (Trigger) auf Indikatorebene

023

Beziehung zwischen 1. und weiterem Antragsteller

Änderung des Familienstands von 1 [verheiratet] in die Zustände:

Resultat (gewichtete Risikopunkte)  =

2 [geschieden] | 4 [verwitwet] | 5 [getrennt lebend] ODER Änderung des Familienstands von 6 [eheähnliche Gemeinschaft] in die Zustände: 4 [verwitwet] | 5 [getrennt lebend] Ausprägung = WAHR | FALSCH e01

Verbraucherpreisindex für Wohnung, Wasser, Strom und Brennstoffe

a) Linearer Prognosewert für ( 14+1 ) auf Basis der letzten 7 Stützpunkte > -Faktor( , ) ∙ [Arithmetischer Mittelwert + Standardabweichung auf Basis der letzten 14 Stützpunkte] mit -Faktor( , ) = 1,04 ODER

 = 0,8 ∙

b) Steigungsmaß der Regressionsgeraden auf Basis der letzten 7 Stützpunkte ≥ -Faktor( , ) ∙ [Steigungsmaß der Regressionsgeraden auf Basis der letzten 14 Stützpunkte] mit Faktor( , ) = 1,10 Ergänzende Hinweise: Je nach Datenaktualisierungsfrequenz wird hier und nachfolgend auf die letzten monatlichen oder die letzten wöchentlichen historisierten Indikatorwerte (= Stützpunkte) vor dem Analysedatum zurückgegriffen Sollte keine lückenlose Datenhistorie vorhanden sein, so muss bis zum Aufbau einer entsprechenden Datenhistorie übergangsweise auf eine geringere Anzahl an Stützpunkten für die kurzfristige Trendentwicklung sowie den mittelfristigen Trend referenziert werden, z. B. (2 | 4), (3 | 6), (4 | 8). Zur Feinjustierung der Warnmarkenberechnung werden bei den externen Indikatoren sogenannte Korrekturfaktoren ( -Faktoren) verwendet. Mit wird der -te dem -Faktor( , ) oder Korrekturfaktor für die -te Berechnungsmethodik bzw. den -ten Indikator bezeichnet, wobei -Faktor( , ) = 1 ± . Die in den vorliegenden Berechnungen verwendeten -Faktoren basieren auf vorsichtigen ersten Expertenschätzungen und sollen gemäß den künftigen Validierungsergebnissen angepasst werden. ≤ 0,10 bzw. 0,90 ≤ Aktuell gilt: 0,00 ≤ Faktor( , ) ≤ 1,10.

(Fortsetzung)

126

3  Prototypische Umsetzung einer BI-basierten Reporting-Anwendung und eines …

Tab. 3.6 (Fortsetzung) e02

Index der Nettokaltmieten Bundesland

a) Linearer Prognosewert für ( 14+1 ) auf Basis der letzten 7 Stützpunkte > -Faktor( , ) ∙ [Arithmetischer Mittelwert + Standardabweichung auf Basis der letzten 14 Stützpunkte] mit -Faktor( , ) = 1,04 ODER

 = 0,6 ∙

b) Steigungsmaß der Regressionsgeraden auf Basis der letzten 7 Stützpunkte ≥ -Faktor( , ) ∙ [Steigungsmaß der Regressionsgeraden auf Basis der letzten 14 Stützpunkte] mit kFaktor( , ) = 1,10 024

Einkommenskategorie und Merkmale aus Zinsanhebungen (nur Eigenheimbereich)

Kreditnehmer stellt innerhalb der letzten 14 Stützpunkte einen Antrag auf Zinssenkung bei (geplanter) Zinsanhebung UND unterschreitet die Einkommensgrenze um ≥ 5,0 %

 = 0,6 ∙

Ausprägung = WAHR | FALSCH e05

Auftragseingang im Bauhauptgewerbe: Wohnungsbau in Tsd. EUR

Steigungsmaß der Regressionsgeraden auf Basis der letzten 7 Stützpunkte ≤ -Faktor( , ) ∙ [Steigungsmaß der Regressionsgeraden auf Basis der letzten 14 Stützpunkte] mit Faktor( , ) = 1,10

065

Rücklastschriften (bezogen auf eigene Darlehensraten)

Innerhalb der letzten 14 Stützpunkte geht eine Rücklastschrift ein

 = 0,2 ∙

 =

Ausprägung = WAHR | FALSCH 075

Stundungsanträge

Kreditnehmer stellt innerhalb der letzten 14 Stützpunkte einen Stundungsantrag

 = 1,0 ∙

Ausprägung = WAHR | FALSCH 028

Zins fix / variabel

Zinssenkung innerhalb der letzten 7 Stützpunkte

 = 0,6 ∙

Ausprägung = WAHR | FALSCH 100

Kontoumsätze

Zahlungsverzug innerhalb der letzten 14 Stützpunkte mit: [Leistungsdatum] − [Sollstellungsdatum] > 0

 = 0,6 ∙

Ausprägung = WAHR / FALSCH e07

Hypothekenzins mit 5 Jahren Sollzinsbindung (Topzins) in %

a) Linearer Prognosewert für ( 14+1 ) auf Basis der letzten 7 Stützpunkte > -Faktor( , ) ∙ [Arithmetischer Mittelwert + Standardabweichung auf Basis der letzten 14 Stützpunkte] mit -Faktor( , ) = 1,04 ODER

 = 0,6 ∙

b) Steigungsmaß der Regressionsgeraden auf Basis der letzten 7 Stützpunkte ≥ -Faktor( , ) ∙ [Steigungsmaß der Regressionsgeraden auf Basis der letzten 14 Stützpunkte] mit Faktor( , ) = 1,10 e10

DAX Kursindex (Basis = 1988)

Linearer Prognosewert für (t14+1 ) auf Basis der letzten 7 Stützpunkte < -Faktor( ) ∙ [Arithmetischer Mittelwert − Standardabweichung auf Basis der letzten 14 Stützpunkte] mit -Faktor( )

 = 0,4 ∙

(Fortsetzung)

3.1  Risikofrüherkennung und automatisierte Risikoklassifizierung

127

Tab. 3.6 (Fortsetzung) e08

Dispositionszins in %

Steigungsmaß der Regressionsgeraden auf Basis der letzten 7 Stützpunkte ≥ -Faktor( , ) ∙ [Steigungsmaß der Regressionsgeraden auf Basis der letzten 14 Stützpunkte] mit Faktor(

 = 0,2 ∙

In den Erläuterungen zu den MaRisk wird in Bezug auf die Verfahren zur Früherkennung von Risiken unterstrichen, dass das kreditierende Institut selbst im Fall der i­ ndirekten Kreditvergabe (über eine Hausbank) sicherzustellen hat, „[…] dass es über wesentliche Vorkommnisse bei dem Kreditnehmer informiert wird“ (Bundesanstalt für Finanzdienstleistungsaufsicht 2017, BTO 1.3). Die in den Erläuterungen exemplarisch genannten Indikatoren Kontoumsätze und Scheckrückgaben stellen ebenfalls die kundenspezifische Sicht der Frühwarnung in den Vordergrund. Um die in den MaRisk formulierte kundenspezifische Zuordnung der Frühwarnung zu zu erfüllen, wird mit Blick auf den vorwiegend portfoliospezifischen Charakter der externen Indikatoren der Schwellenwert für das Gesamtscoring (= Summe der gewichteten Risikopunkte) bzw. der Auslöser für die Frühwarnung in unserem Modell so angelegt, dass neben einem oder mehreren externen Indikatoren mindestens ein interner Risikofaktor einen kritischen Wert annehmen muss. Damit soll ein Anreiz geschaffen werden, die Qualität der intern verfügbaren portfoliospezifischen Daten im Zeitablauf weiter zu verbessern, was mitunter die (interne) Akzeptanz des Modells erhöht. Im Einzelfall und je nach zugrunde liegendem Portfolio kann eine abweichende Regelbindung sinnvoll sein. Die Überschreitung der kritischen Marke von 0,5 ⋅ GRPMAX wird im Beispielfall durch einen roten Ampelstatus in der Kopfzeile des Scoringbogens angezeigt. Welche Risikofaktoren die indikatorspezifischen Warnmarken überschritten haben und in die Gesamtbewertung einfließen, ist für den Kreditanalysten an den zeilenweisen roten Ampelmarkierungen in der Spalte [Forecast] erkennbar (vgl. Abb. 3.5). Im vorliegenden Fall wird die notwendige Bedingung mit Überschreitung eines Limits von 50 % der auf dem Bogen maximal möglichen gewichteten Scoringsumme erfüllt. Die Warnmarke für das Gesamtscoring entspricht (bei maximal 56,00 gewichteten Risikopunkten auf dem Scoringbogen) einem Wert von 28,00 Risikopunkten. In Abb. 3.5 setzt sich die gewichtete Scoringsumme von 34,00 Risikopunkten aus allen sechs externen Indikatoren e01, e02, e05, e07, e08, e10 (= 28,00 Risikopunkte) sowie dem internen Indikator 028 (= 6,00 Risikopunkte) zusammen. Ebenso kann eine Frühwarnung in Gestalt der KO-Kriterien ausschließlich durch interne Indikatoren ausgelöst werden, wobei definitionsgemäß das Anschlagen eines bzw. des ersten KO-Kriteriums einen roten Ampelstatus zur Folge hat (vgl. Abb. 3.6). In diesem Fall wird durch den internen Indikator 023, der laut Tab. 3.5 aufgrund seiner Relevanz für das Gesamtergebnis der Bonitätseinschätzung als „KO-Kriterium“ definiert worden ist, ein Aufschlag von 56,0 gewichteten Risikopunkten ausgelöst, was einer Frühwarnung mit der maximal möglichen Risikopunktzahl entspricht.

128

3  Prototypische Umsetzung einer BI-basierten Reporting-Anwendung und eines …

Abb. 3.5  Gesamtscoring Frühwarnung (Bsp. KO-Kriterien = 0 Risikopunkte). (Quelle: eigene Darstellung)

Die Frühwarneigenschaften des Scoringmodells können von technischer Seite durch eine marktgängige BI-Lösung unterstützt werden. Übergangsweise und/oder bei vergleichsweise kleinen Datenbeständen kann das Dashboarding auch mittels eines Microsoft Excel-basierten Frontends erfolgen. Der Abb. 3.6 zugrunde liegende Excel-Prototyp konnte nach geringen Anpassungen und Anbindung an eine relationale Datenbank als temporäre Early Warning Tool (EWT)-Lösung verwendet werden. Mittels entsprechender Alerting-Funktionalitäten, beispielsweise eines automatisierten und personalisierten Emailversands, wird der Analyst von der Überschreitung der Warnmarke bzw. der Anzeige eines roten Ampelstatus für den betreffenden Geschäftspartner proaktiv in Kenntnis gesetzt. Der Analyst entscheidet nach einer Einzelfallbetrachtung, ob und inwieweit die Frühwarnung bzw. die Über- oder Unterschreitung der fachlich vorgegebenen Schwellenwerte und Steigungsmaße einen belastbaren Ansatzpunkt für eine Anpassung der den oder die Kreditnehmer bzw. Risikogemeinschaft betreffenden Risikoklassifizierung darstellt.

3.1  Risikofrüherkennung und automatisierte Risikoklassifizierung

129

Abb. 3.6  Gesamtscoring Frühwarnung (Bsp. KO-Kriterien > 0 Risikopunkte). (Quelle: eigene Darstellung)

Bei Überschreitung einer Grenze von 25 % der (gewichteten) Gesamtpunktzahl wird in der Kopfzeile des Scoringbogens unter [Forecast] eine gelbe Ampelmarkierung angezeigt (vgl. Abb. 3.7). Der gelbe Ampelstatus hat lediglich informellen Charakter und ist (anders als die rote Ampelmarkierung) nicht mit einer systemseitigen Aktion bzw. der automatischen Benachrichtigung des für den Darlehensnehmer zuständigen Analysten verbunden. Als weitere Möglichkeit bietet sich bei der Umsetzung neben der Anzeige eines roten Ampelstatus ( ) oder gelben Ampelstatus ( ) unter [Forecast] die Anzeige einer neutralen Ampel ( ) an, falls die risikogewichtete Punktzahl einen Wert > 2 annimmt, d. h. sofern bei mehr als ­einem Indikator mit einem Risikogewicht von 0,20 eine Warnung angezeigt wird. Eine dahingehende Feinjustierung der Statusanzeige setzt allerdings eine entsprechend hohe Datenaktualisierungsfrequenz sowie eine ausreichende Datenqualität voraus. – Auf Ebene der einzelnen Indikatoren 023 bis e08 (vgl. Abb. 3.7) ist ausschließlich die Überschreitung der in Tab. 3.6 in der Spalte [Gewichtete RP] definierten kritischen Warnmarken relevant, so dass nur hier nur genau ein Ampelzustand ( ) existiert.

130

3  Prototypische Umsetzung einer BI-basierten Reporting-Anwendung und eines …

Abb. 3.7  Gesamtscoring Vorwarnung (gelber Ampelstatus). (Quelle: eigene Darstellung)

3.1.5 Skizze zur Datenablage Die dem Scoringmodell zugrunde liegenden internen und externen kunden-und portfolio­ spezifischen Informationen werden mittels automatisierter Batchläufe pro Kombination aus Geschäftspartner/Vertragsnummer in einem monatlichen oder – soweit technisch möglich und sinnvoll – in kürzeren Zyklen aktualisiert und in einer Datenbank persistent abgelegt. Wünschenswert ist, dass die nachfolgend skizzierten Datenanforderungen zur Frühwarnung in ein Gesamtmodell zur Risikodatenaggregation gemäß BCBS #239 integriert werden. Hierbei gelingt es idealerweise, die Frühwarnung als festen Bestandteil des Risikoreportings auf Instituts- oder Konzernebene zu etablieren und in die DG- und Datenqualitätsanforderungen einzubinden. Für einen exemplarischen institutsweiten Berichtcluster zum Risikoreporting unter Einbeziehung einer Frühwarnkomponente vgl. Golla et al. 2014b, S. 36 ff. Ein Gesamtüberblick über die Frühwarnung als Teil der BCBS #239-Bericherstattung findet sich bei Golla et al. 2015.

3.1  Risikofrüherkennung und automatisierte Risikoklassifizierung

131

Abb. 3.8  EWT-Zieltabellenstruktur (Skizze). (Quelle: eigene Darstellung)

Einen Überblick über die zur Verarbeitung der Scoringinformationen notwendigen Tabellenstrukturen und Datenflüsse enthält das in Abb. 3.8 skizzierte einfache Klassenmodell. Zur Ermittlung der Scoringwerte gemäß Tab. 3.6 ist die Ablage einer ausreichenden Anzahl an Stützpunkten pro Indikator erforderlich. Die Historisierung der Indikatorwerte erfolgt in [EWT_BASIS] mit Hilfe des Feldes [Aktualisierungsdatum]. In dieses Feld wird das Importdatum des Datensatzes abgelegt, wobei sich ein historisierter Datensatz definitionsgemäß aus den Stammdaten pro Scoringbogen sowie den internen und externen Indikatorwerten zusammensetzt. Da die Scoringinformationen pro Aktualisierungsdatum anhand der in Tabelle [EWT_BASIS] abgelegten Historie reproduzierbar sind, ist eine gesonderte Ablage der Scoringergebnisse nicht erforderlich, solange keine Änderung der Berechnungsmethodik und/oder der Gewichtungen vorgenommen wird. Falls doch eine regelmäßige Anpassung der Struktur des Scoringbogens erfolgen soll, ist zur Nachvollziehbarkeit der Berechnungsmethodik zusätzlich die jeweils gültige Versionierung des Scoringbogens abzulegen. In Bezug auf die Indikatorwerte wird davon ausgegangen, dass es sich jeweils um die zuletzt gültigen aktuellen Werte handelt (andernfalls müsste pro Indikator zusätzlich ein Aktualisierungsdatum abgelegt werden, was bereits mit Blick auf die Anzahl der zusätzlich benötigten Datenfelder als nicht praktikabel angesehen wird). Zum Aufbau einer ausreichenden Datenhistorie, die u. a. die Grundlage für die regelmäßige Validierung der Scoringmodells darstellt, soll in der Tabelle [EWT_ BASIS] bei monatlicher Aktualisierung ein Datenbestand über einen Zeitraum von zwei bis drei Jahren bzw. bei wöchentlicher Aktualisierung über einen Zeitraum von einem Jahr angelegt werden. Nach Abb.  3.8 sind zur Einspielung und Verarbeitung von internen und externen Frühwarndaten, zur Berechnung eines Scoringergebnisses pro Geschäftspartner und zur Speicherung in den Tabellen [EWT_BASIS], [EWT_TEMP_01] und [EWT_TEMP_02] pro Aktualisierungslauf mehrere Konsolidierungsschritte notwendig:

132

3  Prototypische Umsetzung einer BI-basierten Reporting-Anwendung und eines …

• Schritt 1: Datenaggregation auf Ebene des zusammengesetzten Schlüssels [Geschäftspartner]/[Vertragsnummer] in der Tabelle [EWT_Basis], die laufend (mindestens einmal monatlich) aktualisiert wird und in der alle für die Frühwarnung relevanten ­internen und externen Risikofaktorwerte historisiert werden. Unter Zugrundelegung von 75.000 aktiven Geschäftspartnern (private Eigenheimer und private Mietinvestoren) und 2 Vertragsnummern pro Geschäftspartner kann je nach Aktualisierungshäufigkeit von einem jährlichen Bestand zwischen 1,80 Mio. Datensätzen (monatlicher Aktualisierung) und 8,40 Mio. Datensätzen (wöchentliche Aktualisierung) ausgegangen werden. • Schritt  2:  Aus der EWT-Basistabelle wird auf der Ebene Geschäftspartner/Vertrags­ nummer pro Risikofaktor mithilfe des jedem Indikator zugrunde liegenden statistischen Schätzverfahrens (z. B. lineare Regression, Trend-Saison-Modell, Holt-Winters-­Verfahren) die künftige Entwicklung prognostiziert. Pro Indikator wird auf Grundlage von 7 historisierten Stützpunkten (aktueller Wert + 6 vorausgehende Werte) ein Prognosewert errechnet und mit einem Scoring unterlegt. Die Prognosezeiträume orientieren sich hierbei an der Häufigkeit und Güte der zur Verfügung stehenden internen und externen Daten. Aus Konservativitätsgründen sollte gerade in Fall geringer Aktualisierungsfrequenzen (weniger als 1 Aktualisierung pro Monat) bzw. bei nur in unregelmäßigen Abständen aktualisierten Daten auf die Definition längerer Gültigkeitszeiträume verzichtet werden. Dementsprechend kürzere Vorlaufzeiten sind einzuplanen. – Die Gesamtprognose für eine Geschäftspartner/Vertragsnummer-Kombination ergibt sich aus der Zusammenfassung der gewichteten Scoringergebnisse pro Indikator. Die Resultate werden zur weiteren Verarbeitung in eine temporäre Tabelle [EWT_TEMP_01] geschrieben. Unter der Annahme eines aktiven Datenbestandes von 75.000 Geschäftspartnern und durchschnittlich 2 Vertragsnummern pro Geschäftspartner kann bei 12 internen und externen Indikatoren sowie 7 Vergangenheitswerten (Stützpunkten) pro Indikator von insgesamt 12,6 Mio. zu verarbeitenden Indikatorwerten und 1,8 Mio. mit Prognoserechnungen zu versehenden Datensätzen ausgegangen werden. Sofern das Portfolio – wie im vorliegenden Fall – auf ein Set an externen Frühwarnindikatoren geclustert wird, d. h. auf ein und denselben Bestand an makroökonomischen Daten zurückgreift, ist die Verarbeitungszeit für die pro Aktualisierungslauf nur einmal durchzuführende Prognose der (6) externen Frühwarnindikatoren vernachlässigbar. Somit reduziert sich das Volumen der mit individuellen Prognoserechnungen zu unterlegenden Datensätze auf 0,9  Mio. Bei Unterstellung einer Verarbeitungszeit von 0,020 Sekunden pro Datensatz für die Prognoserechnung und 0,010 Sekunden pro Datensatz für das UPDATE der temporären Tabelle [EWT_TEMP_01] ergibt sich eine Verarbeitungszeit von 5 Stunden für die Prognoserechnung (0,9 Mio. Datensätze) und insgesamt 5 Stunden für das Update der temporären Tabelle (1,8 Mio. Datensätze inklusive der Prognosewerte für die externen Indikatoren), also eine voraussichtliche Verarbeitungsdauer auf den maximalen Gesamtbestand von 10 Stunden. Dabei hängen die Updatezeiten wie auch die Selektierungs- und Berechnungszeiten von der Kapazität und der Auslastung des verwendeten Servers bzw. Hauptrechners ab.

3.1  Risikofrüherkennung und automatisierte Risikoklassifizierung

133

• Schritt 3: Zur Bestimmung des maßgeblichen Scorings pro Geschäftspartner wird auf den in der Tabelle [EWT_TEMP_01] hinterlegten Prognosebestand von 1,8 Mio. Datensätzen ein SELECT DISTINCT auf den höchsten bzw. schlechtesten Scoringwert pro Partnernummer ausgeführt. Das Ergebnis wird in [EWT_TEMP_02] abgelegt. ­Unter Berücksichtigung einer Verarbeitungszeit von 0,010 Sekunden pro Datensatz ist für diesen Prozessschritt eine Dauer von ca. 5 Stunden anzusetzen. Insgesamt lässt sich aus den Schritten 1 bis 3 eine Verarbeitungszeit von bis zu 15 Stunden (Übernachtlauf) berechnen. Die internen und externen Scoringinformationen werden in zwei temporäre Tabellen [EWT_TEMP_01] und [EWT_TEMP_02] abgelegt, die zur Minimierung des Speicherplatzbedarfs bei der nächsten wöchentlichen oder monatlichen Aktualisierung bedarfsweise überschrieben werden können.

3.1.6 Exemplarische Initialvalidierung des Gesamtmodells Zur Initialvalidierung des vorab entwickelten Scoringmodells ist in unserem Beispiel auf den Ausfallzeitpunkt 30.09.2011 referenziert worden (zur Ausfalldefinition siehe die Erläuterung zu Merkmal [073] in Tab. 3.2). Hierbei ist für annahmegemäß 366 ausgefallene Darlehensnehmer unter Zugrundelegung der in Tab. 3.6 definierten Auslöser (Trigger) und der vorab definierten Berechnungslogik die Möglichkeit einer rechtzeitigen Vorhersage des Default-Ereignisses überprüft worden. Zur initialen Validierung und stichprobenartigen Plausibilisierung der Ergebnisse ist zusätzlich ein MS Excel-basierter Scoringbogen eingesetzt worden, mit dessen Hilfe einzelne Merkmalsträger selektiert werden können und mit dem sich die gewichteten Risikopunkte pro Stichtagsdatum, pro Ampelstatus und für unterschiedliche Niveaus der Korrekturfaktoren verifizieren lassen (vgl. Abb. 3.9). Zur Einschätzung der Prognosegüte des Scoringmodells bzw. der Vorlaufzeit bis zum Eintreffen eines tatsächlichen Default-Ereignisses sind auf Grundlage der in Tab. 3.6 vorgegebenen indikatorspezifischen Auslöser für den Zeitraum [t0–6; t0] monatliche Scoringwerte und Ampelzustände berechnet worden. Es lässt sich annehmen, dass eine über sechs Monate hinausgehende Betrachtung und Extrapolation aufgrund der geringen Volatilität des zugrunde liegenden Portfolios, der im Regelfall halbjährlichen Leistungstermine sowie der höchstens monatlichen Datenbereitstellungsfrequenz mit zu großen Unsicherheiten behaftet ist und daher für eine verlässliche Frühwarnung nur geringe Aussagekraft besitzt. Ausgehend vom 30.09.2011 reicht die der Untersuchung zugrunde liegende Datenreihe entsprechend der pro Indikator individuell verfügbaren Anzahl der Stützpunkte bis Ende Februar 2010 zurück. Für die externen Frühwarnindikatoren stehen im Betrachtungszeitraum monatliche Daten zur Verfügung. Bei den internen (= kundenbezogenen) Indikato-

134

3  Prototypische Umsetzung einer BI-basierten Reporting-Anwendung und eines …

Abb. 3.9  Berechnungsbeispiel Initialvalidierung. (Quelle: eigene Darstellung)

ren sind die im Beispielinstitut vorhandenen Datenlücken, die aus der zum Implementierungszeitpunkt noch niedrigen Aktualisierungsfrequenz resultieren, durch eine logische Fortschreibung von Daten simuliert worden, was sich gerade in der Einführungsphase des Frühwarnsystems und bis zum Aufbau einer ausreichenden Datenhistorie nachteilig auf die Prognosegüte auswirkt. Zur Erhöhung der auswertbaren Datenmenge werden bei allen internen Indikatoren Änderungen der Merkmalsausprägungen in den Zustand WAHR, die vor Beginn der untersuchungsrelevanten Datenreihe eingetreten sind, dem 26.02.2010 zugeordnet. Die nachstehende Tab. 3.7 gibt nach einer Analyse von 366 Merkmalsträgern mit jeweils 20 Stützpunkten (= 7320 Datensätze) Auskunft darüber, wieviel Prozent der Merkmalsträger sich im Untersuchungszeitraum auf die Warnmarken und Ampelzustände verteilen. Im vorliegenden Beispiel finden sich bei 6 der zum 30.09.2011 ausgefallenen 366 Kreditnehmer zu den internen Kriterien 023, 024, 065, 075, 028 und 100 über alle ­Stützpunkte hinweg keine Tabelleneinträge. Im Rahmen der Analyse sind die internen Kriterienausprägungen für die betreffenden Geschäftspartner an jedem der 20 Stützpunkte auf FALSCH gesetzt worden. Die Migration der Ausprägungen pro Ampelstatus kann im Zeitablauf t0 − 6 bis t0 und in Abhängigkeit von der Höhe der Korrekturfaktoren nachvollzogen werden. Durch eine Änderung der sogenannten „k-Faktoren“ (Korrekturfaktoren) bzw. der Summanden pij kann eine Verschiebung in Richtung einer mehr (vgl. Tab. 3.8) oder weniger häufigen Anzeige des roten Ampelstatus (vgl. Tab. 3.9) und damit der systemseitig ausgelösten Frühwarnung

3.1  Risikofrüherkennung und automatisierte Risikoklassifizierung

135

Tab. 3.7  Migrationsmatrix Initialvalidierung (t0 = 30.09.2011 ∣ p1 j = 0,04 ∣ p2 j = 0,10) Zeitpunkt

Status NULL

Status Schwarz 

Status Gelb 

Status Rot 

Check

0−6

0,0 %

0,0 %

28,8 %

71,2 %

100,0 %

0−5

0,0 %

0,0 %

49,2 %

50,8 %

100,0 %

0−4

0,0 %

0,0 %

49,5 %

50,5 %

100,0 %

0−3

0,0 %

0,0 %

47,5 %

52,5 %

100,0 %

0−2

0,0 %

32,8 %

19,7 %

47,5 %

100,0 %

0−1

0,0 %

27,8 %

23,4 %

48,8 %

100,0 %

0,0 %

2,0 %

27,4 %

70,6 %

100,0 %

Tab. 3.8  Migrationsmatrix Initialvalidierung (t0 = 30.09.2011 ∣ p1j = 0,00 ∣ p2j = 0,05) Zeitpunkt

Status NULL

Status Schwarz 

Status Gelb 

Status Rot 

Check

0−6

0,0 %

0,0 %

28,8 %

71,2 %

100,0 %

0−5

0,0 %

0,0 %

49,2 %

50,8 %

100,0 %

0−4

0,0 %

0,0 %

49,5 %

50,5 %

100,0 %

0−3

0,0 %

0,0 %

47,5 %

52,5 %

100,0 %

0−2

0,0 %

0,0 %

32,8 %

67,2 %

100,0 %

0−1

0,0 %

0,0 %

27,8 %

72,2 %

100,0 %

0,0 %

0,0 %

2,0 %

98,0 %

100,0 %

Tab. 3.9  Migrationsmatrix Initialvalidierung (t0 = 30.09.2011 ∣ p1j = 0,10 ∣ p2j = 0,10) Zeitpunkt

Status NULL

Status Schwarz 

Status Gelb 

Status Rot 

Check

0−6

0,0 %

0,0 %

28,8 %

71,2 %

100,0 %

0−5

0,0 %

0,0 %

49,2 %

50,8 %

100,0 %

0−4

0,0 %

0,0 %

49,5 %

50,5 %

100,0 %

0−3

0,0 %

0,0 %

47,5 %

52,5 %

100,0 %

0−2

0,0 %

32,8 %

19,7 %

47,5 %

100,0 %

0−1

2,3 %

28,4 %

24,4 %

44,8 %

100,0 %

0,0 %

26,8 %

29,1 %

44,1 %

100,0 %

136

3  Prototypische Umsetzung einer BI-basierten Reporting-Anwendung und eines …

erreicht werden. Im vorliegenden Fall ist die geringe unterjährige Aktualisierungsfrequenz der internen (kundenbezogenen) Risikofaktoren zu berücksichtigen, weshalb insbesondere eine Reduzierung der Korrekturfaktoren bzw. Reduzierung der Warnmarken (vgl. Tab. 3.8) nur eine vorübergehende Lösung bis zur Erzielung einer ausreichenden internen Aktualisierungshäufigkeit darstellt. Die Ursache für die in Tab. 3.7, Tab. 3.8 und Tab. 3.9 erkennbare signifikante Warnmarkenüberschreitung im Zeitpunkt t0 − 6 (71,2 % mit Status Rot; 28,8 % mit Status Gelb) ist darin zu sehen, dass die Auslöser auf risikorelevante Ereignisse zurückgehen, die bereits vor dem Untersuchungszeitraum eingetreten sind. Diese Ereignisse sind in der Datenanalyse aus Vereinfachungsgründen dem ersten für die Untersuchung relevanten Stichtag (t0 − 6) mit (Trigger = WAHR) zugeordnet worden. Nach der Definition der indikatorspezifischen Auslöser gemäß Tab. 3.6 wird dieser anfängliche Zustand im Rahmen der statistischen Analyse in den nachfolgenden (je nach Kriterium) 6 bis 13 Stützpunkten fortgeschrieben, d. h. in t0 − 6= 31.03.2011 übernommen, solange für die betreffenden Stützpunkte im Datenbestand keine zwischenzeitliche Zustandsänderung enthalten ist. Da im Beispielinstitut für den Untersuchungszeitraum aufgrund der vergleichsweise niedrigen Datenaktualisierungsfrequenz in nur 5,4 % der Fälle eine weitere (zweite) Aktualisierung der internen Indikatoren erfolgt ist, wirken sich die dem ersten Stützpunkt zugeordneten Zustände (Trigger = WAHR) im Rahmen der Analyse bis zum Zeitpunkt t0  −  6 aus, bevor aufgrund einer Überschreitung der im Rahmen der ­Scoringermittlung maximal in die Analyse einzubeziehenden Stützpunkte (7 | 14) ab t0 − 5 eine Zurücksetzung auf Trigger = FALSCH erfolgt.

Fazit Mit Hilfe des in diesem Kapitel vorgestellten Scoringmodells hätten für (p1j = 0,04 ∣ p2j = 0, 10) insgesamt mehr als 56  % der ausgefallenen Darlehensnehmer anhand einer Überschreitung der roten Warnmarke mit einer Vorlaufzeit von bis zu 6 Monaten identifiziert werden können. Lediglich in 9 % der Kreditausfälle lässt sich über den Betrachtungszeitraum [t0 − 6; t0] hinweg eine nur geringfügige Warnmarkenüberschreitung (Status = Schwarz ) feststellen, die dementsprechend im Produktivbetrieb keine Frühwarnung ausgelöst hätte. Für (p1j = 0,04 ∣ p2j = 0,10) ergibt sich im Betrachtungszeitraum [t0 − 6; t0] für das Beispielinstitut folgende Verteilung der Ampelzustände: NULL = 0,0 % | Schwarz ( ) = 8,9 % | Gelb ( ) = 35,1 % | Rot ( ) = 56,0 %. Auch unter Anwendung eines höheren Korrekturfaktors wäre für 51,6 % der tatsächlich ausgefallenen Darlehensnehmer im Zeitraum [t0 − 6; t0] eine Frühwarnung (Status = Rot ) ausgelöst worden, d. h. hätte die überwiegende Mehrzahl der ausfallgefährdeten Kreditnehmer frühzeitig identifiziert werden können. Für (p1j = 0,10 ∣ p2j = 0,10) ergibt sich im Betrachtungszeitraum [t0 − 6; t0] für das Beispielinstitut folgende Verteilung der Ampelzustände: NULL = 0,3 % | Schwarz ( ) = 12,6 % | Gelb ( ) = 35,5 % | Rot ( ) = 51,6 %. Die höchste Trefferquote (hier als Summe aus gelben und roten Ampelzuständen) lässt sich unter Berücksichtigung der durch Datenlücken bedingten Einschräsx in einem

3.1  Risikofrüherkennung und automatisierte Risikoklassifizierung

137

Zeitraum von [t0 − 5; t0 − 3] erzielen, und zwar ungeachtet des Niveaus der k-Faktoren. Hierbei ist davon auszugehen, dass durch eine häufigere als halbjährliche Datenaktualisierung der internen Risikofaktoren die Prognosegüte des Scoringmodells deutlich verbessert werden kann (zur Stützung der vorliegenden Validierungsergebnisse ist als Benchmark eine Stichprobe der zum 30.09.2011 nicht ausgefallenen Kreditnehmer herangezogen worden). Auch unter Berücksichtigung der Verarbeitungszeiten scheint daher eine mindestens monatliche Datenaktualisierung zumutbar.

3.1.7 Desiderata Die folgende Aufstellung fasst exemplarische Maßnahmen und Empfehlungen zusammen, die erfahrungsgemäß in vielen Kreditinstituten dazu beitragen können, die interne und externe Datenbeschaffung zu optimieren und die Prognosegüte von Frühwarnsystemen zu verbessern. Die Zusammenstellung erhebt keinen Anspruch auf Vollständigkeit, sondern skizziert praxisnahe Problembereiche, mit denen Institute bei der Konzipierung und Umsetzung retailnaher Frühwarnsysteme typischerweise konfrontiert werden. • In Instituten aller Größenklassen gibt es in Bezug auf die die Datenerhebungs- und Aktualisierungsfrequenz der für die Frühwarnung relevanten kundenbezogenen (internen) Risikofaktoren erhebliche Steigerungspotenziale. Dies betrifft Indikatoren, die aus fachlicher Sicht gute Frühwarneigenschaften besitzen, die aber aufgrund der gegenwärtigen Datenlage und/oder einer unzureichenden Datenqualität nicht mit einer ihrer Frühwarneigenschaft entsprechenden Gewichtung in das Gesamtscoring eingehen können. Dazu zählen im Bereich der der retailnahen Frühwarnung erfahrungsgemäß Indikatoren wie (024) Anträge auf Zinssenkung, (025) Mieten, (065) Aktuelle Informationen über Rücklastschriften oder (100) Kontoumsätze (siehe oben Tab. 3.2). • Zur Ergänzung der internen Frühwarnindikatoren ist eine regelmäßige, mindestens monatliche Einspielung und Verarbeitung ausgewählter marktnaher (regionaler) Indikatoren sicherzustellen, z.  B. (e01) Verbraucherpreisindex, (e07) Hypothekenzins oder (e10) DAX Kursindex) (vgl. Tab. 3.4). In erster Linie ist hierbei auf Indikatoren zu fokussieren, die täglich, häufig auch Intraday abgerufen werden können und mit deren Hilfe sich Änderungen des wirtschaftlichen Klimas zeitnah antizipieren lassen. • Zur persistenten Ablage der Frühwarnindikatoren und der zugrunde liegenden Berechnungssystematik pro Scoringbogen und Portfolio, ferner zur temporären Ablage der pro monatlicher oder wöchentlicher Aktualisierung ermittelten Ergebnismenge ist die Konzipierung und Umsetzung einer EWT-Datenbanklösung vorzusehen (inklusive der zugehörigen ETL-Prozesse). Die Datenbanklösung stellt die Grundlage dar für (a) die BI-basierte Berechnung der Frühwarnergebnisse, (b) deren proaktive Kommunikation an die fachlichen Entscheidungsträger innerhalb des Instituts (sog. Narrowcasting) sowie (c) die regelmäßige Validierung der bisherigen Scoringergebnisse. Daran anknüpfend sind auf Basis der EWT-Datenbank (d) zukunftsbezogene Berichtkapazitäten zu

138

3  Prototypische Umsetzung einer BI-basierten Reporting-Anwendung und eines …

konzipieren und institutsweit bereitzustellen. Mit Hilfe der Berichte können mögliche Verletzungen bestehender Risikolimits über die Risikotoleranz des Instituts hinaus offengelegt und analysiert werden (siehe BCBS #239, Tz. 24). Die Frühwarnberichte sind in die Risikoberichterstattung des Instituts zu integrieren. Die EWT-Datenbank dient schließlich (e) als Quellsystem für die Überleitung von Frühwarnergebnissen in ­benachbarte Risikomanagement-Systeme, u. a. in die ratingführenden Systeme des Instituts. • Zur Steigerung der Frühwarneigenschaften ist für interne Risikofaktoren, die auf die rechtliche Beziehung zwischen dem (ersten) Antragsteller des Kredits und weiteren Antragstellern referenzieren  – wie z.  B. bei der gleichnamigen internen Kennzahl (023) – die Möglichkeit zur Ablage von Zustandsänderungen vorzusehen. Hierbei sind standardisierte Zustände zu berücksichtigen und zu bewerten: 1 [Verheiratet], 2 [Verwitwet], 3 [Geschieden], 4 [Getrennt lebend], 5 [In Scheidung lebend], 6 [Eheähnliche Gemeinschaft] und 7  [Sonstige Beziehung]. Die Zustandsänderungen sollen gemäß ihren Auswirkungen für die Bonitätseinschätzung des Antragstellers mit einer Änderung der Risikopunktzahl verbunden sein. Hingegen sollte mit einer Änderung des Familienstands in Hinblick auf die Möglichkeiten der Datenhistorisierung keine Änderung der Geschäftspartnernummer einhergehen. Nach einer ausreichenden Vorlaufzeit bzw. nach Aufbau einer mindestens 7 aufeinanderfolgende Stützpunkte umfassenden monatlichen oder wöchentlichen Datenhistorie der internen Indikatoren ist zur Feinjustierung der Gewichtungen und Korrekturfaktoren (vgl. Tab.  3.6) eine regelmäßige Validierung des Scoringbogens durchzuführen. Dazu gehört eine regelmäßige Überprüfung, ob und inwieweit sich durch einen geänderten Zuschnitt des Portfolios eine punktgenauere Frühwarnung erzielen lässt.

3.2

 uditierung und Evaluierung von risikorelevanten A Reporting-Anwendungen gemäß BCBS #239/MaRisk AT 4.3.4

Während Abschn. 3.1 die prototypische Umsetzung einer Reporting-Anwendung aufzeigt, widmet sich der vorliegende Abschnitt der Auditierung und Evaluierung von risikorelevanten Reporting-Systemen. Zur Veranschaulichung wird eine exemplarische Realisierung vorgestellt, die für Prüfungen sowohl einzelner Risikoreporting-Anwendungen (wie in Abschn. 3.1 dargestellt) als auch von Reporting-Architekturen, die sich aus verschiedenen Anwendungen und Systemen zusammensetzen, gemäß BCBS #239/MaRisk AT 4.3.4 zum Einsatz kommen kann. Bevor die Prüfmethodik und die konkrete Handhabung der Auditierungsanwendung in Abschn. 3.2.2 dargestellt werden, widmet sich Abschn. 3.2.1 den zugrunde liegenden Prüfbereichen, ohne dabei den Anspruch zu erheben, ein vollständiges Prüfprogramm vorzustellen, das sich ohne zusätzliche Berücksichtigung der institutsindividuellen Erfordernisse 1:1 übernehmen lässt.

3.2  Auditierung und Evaluierung von risikorelevanten Reporting-Anwendungen …

139

3.2.1 Prüfbereiche Für eine Prüfung gemäß BCBS #239/MaRisk AT 4.3.4 lassen sich fünf Prüfbereiche identifizieren, die in Abb. 3.10 visualisiert sind und in den folgenden Abschnitten diskutiert werden. Bei den Prüfbereichen handelt es sich um die Themenfelder „Datenaggregation“, „Datenqualität“, „Standard-Reporting“, „Ad-hoc-Reporting“ und „Unabhängige Überprüfbarkeit“.

3.2.1.1 Datenaggregation Die Anwendbarkeit von Risikodaten hängt maßgeblich von den Datenaggregationskapazitäten eines Instituts ab. Aus regulatorischer Sicht umfasst die Aggregation von Risikodaten eine den Anforderungen an die Risikoberichterstattung einer Bank entsprechende Definition, Erhebung und Verarbeitung von Risikodaten (das Auswählen, Zusammenführen und Aufschlüsseln von Datensätzen eingeschlossen) unter der Prämisse, einen Abgleich der Performance der Bank gegenüber der von der Bank formulierten Risikotoleranz zu ermöglichen (vgl. Basler Ausschuss für Bankenaufsicht 2013, Tz. 8 sowie S. 18). Grundsätzlich ist aus Prüfungssicht zu fordern, dass ein Institut über eine Definition verfügt, aus der hervorgeht, was unter risikorelevanten Daten zu verstehen ist. Diese Definition muss institutsweit bekannt und in Form eines geeigneten Rahmenwerks oder einer Richtlinie (z. B. DG-Richtlinie) festgehalten sein. Als risikorelevant können z. B. alle Daten verstanden werden, die für das interne Berichtswesen, für Steuerungszwecke, für aufsichtsrechtliche Meldungen oder für die öffentliche Berichterstattung zum Einsatz ­kommen. Abb. 3.10 Prüfbereiche gemäß BCBS#239/MaRisk AT 4.3.4. (Quelle: eigene Darstellung)

140

3  Prototypische Umsetzung einer BI-basierten Reporting-Anwendung und eines …

Ein Prüfobjekt dieses Prüfbereiches bezieht sich auf die angemessene Dokumentation des Prozesses zur Risikodatenaggregation (z. B. in Form eines Datenflussdiagramms oder einer Ablaufbeschreibung). Dieser Prozess muss systematisch und für sachkundige Dritte nachvollziehbar dokumentiert sein. In diesem Zusammenhang ist zu bewerten, ob Risikodaten institutsweit eindeutig definiert und in einem Data Dictionary, das Bestandteil eines Metadaten-Werkzeugs ist, zentral vorgehalten und gepflegt werden. Auch die eindeutige Definition der Quellsysteme, die für die Risikodatenaggregation von Bedeutung sind, ist ein Prüfgegenstand. Weitere Prüfpunkte beziehen sich auf das Vorhandensein und die in­ stitutsweite Etablierung sowohl eines Historisierungs- als auch eines Backup-Konzepts (für die Quellsysteme und das Zielsystem). Eine Anforderung in diesem Zusammenhang ist, dass halbautomatische und manuelle Zulieferprozesse für das Zielsystem gesondert zu dokumentieren sind. Sofern Umgehungslösungen (manuelle Workarounds) zum Einsatz kommen, müssen hierzu aussagekräftige Dokumentationen mit Erläuterungen hinsichtlich ihrer Angemessenheit vorliegen. Zu beschreiben ist in diesem Zusammenhang auch, inwiefern sich derartige Umgehungslösungen auf die Genauigkeit der Datenaggregation auswirken und welche Maßnahmen vorgeschlagen werden, um die Auswirkungen zu minimieren, die sich aus einer geringen Datenqualität ergeben (vgl. Basler Ausschuss für Bankenaufsicht 2013, BCBS #239, Tz. 39). Ferner müssen Verantwortlichkeiten für die manuellen Workarounds in der Dokumentation zugeordnet sein. Zu prüfen ist darüber hinaus, ob der Prozess zur Risikodatenaggregation Bestandteil des Überwachungssystems ist und von der internen Revision hinsichtlich Angemessenheit und Vollständigkeit sowie seitens des IKS-Beauftragten regelmäßig evaluiert wird. Eine weitere Prüffanforderung lautet, dass die an der Risikodatenaggregation und Risikoberichterstattung beteiligten Systeme in einer Gesamtarchitektur visualisiert (statische Sicht) sind. Darüber hinaus müssen Institute sicherstellen, dass das Datenmodell im Zielsystem (Reportingsystem) eindeutig definiert, dokumentiert und gepflegt ist. Die Datenaggregationskapazitäten eines Instituts haben sämtliche wesentlichen Risikopositionen zu berücksichtigen, einschließlich der außerbilanziellen Risiken (vgl. Basler Ausschuss für Bankenaufsicht 2013, BCBS #239, Tz.  41). Dabei müssen verschiedene Aggregationsgrade je nach zugrunde liegender Risikoart darstellbar sein. Pro Risikoart soll nach Möglichkeit eine maßgebliche Quelle bzw. ein maßgebliches Zuliefersystem zum Einsatz kommen (vgl. Basler Ausschuss für Bankenaufsicht 2013, BCBS #239, Tz. 36). Die Risikoarten müssen sich im Zielsystem eindeutig zuordnen lassen (z. B. zu einzelnen Entitäten/Tabellen innerhalb des Datenmodells). Mit Blick auf die Verwendung von Metadaten ist zu prüfen, ob diese eindeutig definiert und dokumentiert sind. Änderungen an den Metadaten müssen revisionssicher aufgezeichnet und historisiert werden. Ebenso müssen Datenmodelländerungen (Zielsystem) im Zeit­ ablauf protokolliert und jederzeit nachvollzogen werden können. Verantwortlichkeiten für Datenmodelländerungen und -anpassungen (Zielsystem) sind dabei eindeutig fest­ zulegen.

3.2  Auditierung und Evaluierung von risikorelevanten Reporting-Anwendungen …

141

Neben dem haben Institute eine am technischen Ressourcenbedarf orientierte Vertreterregelung sicherzustellen, damit personalbedingte Sytemausfallzeiten auch in Krisenzeiten vermieden werden.

3.2.1.2 Datenqualität Im Prüfbereich Datenqualität (DQ) werden alle technischen, organisatorischen und prozessualen Maßnahmen eines Instituts evaluiert, die dazu dienen, den Anforderungen aus BCBS #239 und MaRisk AT 4.3.4 zum Themenfeld DQ zu genügen. Bemerkenswert an Abschnitt AT 4.3.4 der MaRisk ist, dass keine Definition des Begriffes „Datenqualität“ vorgegeben wird, sondern dort lediglich von „Grundsätzen und Kriterien zur Festlegung und Überwachung der Datenqualität“ sowie von der „Identifikation von Schwachstellen in der Datenqualität“ gesprochen wird. Angesichts der darüber hinaus in den MaRisk fehlenden Definition von Datenqualität verbleibt den betroffenen Instituten demnach theoretisch ein großer Spielraum, was die Festlegung einer „ausreichenden“ Qualität der Daten sowie ihre wiederkehrende Überprüfung anbelangt. Damit Institute die gelisteten Anforderungen detailliert auf datenqualitätsrelevante Anknüpfungspunkte untersuchen und so den auf sie zukommenden Implementierungsaufwand und -erfolg hinreichend genau abschätzen können, ist eine Konkretisierung der Begriffe „Datenqualität“ und „Datenqualitätsüberprüfung“ erforderlich. Für die Institute bedeutet das, dass sie ein Verständnis für diese beiden Themenfelder entwickeln müssen, das in eine entsprechende institutsweit gültige Definition mündet. Ungeachtet der fehlenden Definition, was unter DQ und DQ-Überprüfung zu verstehen ist, sind die Institute aus BCBS #239-Sicht mit der Kernanforderung und damit auch dem Prüfbereich konfrontiert, entgegen der vielfach zu beobachtenden Praxis, ein proaktives Datenqualitätsmanagement (DQM) mit standardisierten Abläufen einzurichten. Dies setzt voraus, dass entsprechende Abläufe im Rahmen eines DQM-Prozesses zur Verfügung stehen und institutsweit etabliert sind. Abb. 3.11 stellt exemplarisch dar, aus welchen Teilprozessen sich ein DQM-Prozess zusammensetzt. Im DQ-Anforderungsmanagement, das den Ausgangspunkt darstellt, wird ein DQ-­ Bedarf geäußert und im Hinblick auf die DQ-Relevanz evaluiert. Ein DQ-Bedarf kann einer wirtschaftlichen, regulatorischen und/oder rechtlichen Anforderung entstammen. Nachdem eine DQ-Anforderung erstellt und alle erforderlichen Informationen vorliegen, erfolgt in der Regel unter Einsatz eines entsprechenden DQM-Tools die initiale Anlage einer oder mehrerer DQ-Regeln. Ihre Ausführung führt zu einem ersten Messergebnis, in dem tatsächliche Fehler oder potenzielle Fehlerkandidaten in Form einer Liste ausgewiesen werden. Nachdem die Inhalte des Messergebnisses dem Anforderer vorgestellt wurden, setzt dessen Analyse mit dem Ziel an, potenzielle DQ-Mängel zu identifizieren und die identifizierten Mängel zu bewerten. Hieraus ergeben sich Ansatzpunkte für Gegenmaßnahmen, die zur Beseitigung der DQ-Mängel führen. Im Folgeschritt muss die Umsetzung dieser Maßnahmen beauftragt und der Realisierungsfortschritt überwacht werden. DQ-Maßnahmen können z. B. Einspielungen von Da-

142

3  Prototypische Umsetzung einer BI-basierten Reporting-Anwendung und eines …

Abb. 3.11 DQM-Regelkreis. (Quelle: eigene Darstellung)

DQ-Bedarf ermitteln (Anforderungsmanagement) Kontrolle der Umsetzung

Sicherung sowie stetige Verbesserung der Datenqualität

Definition von DQRegeln

Identifikation und Bewertung von Fehlern

Beseitigung von (Daten-) Mängeln Maßnahmendefinition zur Behebung von Mängeln

tenkorrekturen, manuelle Datenanpassungen, Modifikationen von Schnittstellen, Schulungen oder Veränderungen an der Aufbau- und/oder Ablauforganisation sein. Nach Umsetzung der beauftragten DQ-Maßnahmen sind die DQ-Regeln erneut auszuführen, um zu kontrollieren, ob sich der erwartete Erfolg der DQ-Maßnahmen eingestellt hat. Hieraus folgt im Bedarfsfall Anpassungsbedarf an den bereits erstellten DQ-Regeln oder der Bedarf, neue DQ-Regeln zu implementieren, so dass der Regelkreis erneut mit der Definition von DQ-Regeln beginnt. Voraussetzung für den erfolgreichen „Betrieb“ des in Abb. 3.11 dargestellten DQM-­ Regelkreises ist der Einsatz adressatengerechter DQ-Berichte. DQ-Berichte enthalten alle relevanten Informationen, die die jeweiligen Empfänger dazu befähigen, anhand geeigneter Indikatoren den aktuellen DQ-Status einzusehen, geeignete DQ-Maßnahmen zu identifizieren und ihre Umsetzung mit dem Ziel zu steuern, die Anzahl der identifizierten Fehler im Zeitablauf auf ein vorab definiertes Zielniveau zu reduzieren. Dies setzt voraus, dass DQ-Regeln konzipiert und erstellt worden sind, deren Ausführung zu Messergebnissen führen, die sich in Form von DQ-Berichten analysieren lassen. Wie Abb. 3.12 verdeutlicht, kommen aus DQ-Sicht Messungen z. B. auf Vollständigkeit, Validität, Genauigkeit, Konsistenz, Zuverlässigkeit, Aktualität und Plausibilität in Frage. Mit Blick auf den Aussagegehalt von DQ-Berichten ist aus Prüfungssicht darüber hi­ naus zu fordern, dass Institute den Status der DQ im Zeitablauf abbilden, wodurch Änderungen der DQ anhand der definierten Qualitätskriterien nachvollzogen werden können. Ferner wird geprüft, ob standardisierte Berichte zum Abgleich von Risikodaten mit Daten aus risikorelevanten Zuliefersystemen vorhanden sind und in definierten sowie etablierten Prozessen und Verfahren erstellt und genutzt werden. Institutsseitig sind ebenso automati-

Datennutzung

3.2  Auditierung und Evaluierung von risikorelevanten Reporting-Anwendungen …

Data QualityReporting

StandardReporting

Ad-hocReporting

143

Kriterien zur DQ-Messung

Datenbereitstellung

Vollständigkeit

Validität Banksteuerung

Genauigkeit Konsistenz

DWH

Zuverlässigkeit

Aktualität

ETL

Datenquellen

Plausibilität

SAP FI

Murex

Interne Vorsysteme

Marktdaten Externe Datenquellen

Abb. 3.12  Automatisierung und Standardisierung von Datenqualitätsmaßnahmen. (Quelle: eigene Darstellung)

sierte Abgleiche zwischen relevanten Liefersystemen (z. B. Meldewesen, ­Rechnungswesen, Risikovorsorge, Risikomanagement, Offenlegung SolvV, Kundenstammdaten) zu gewährleisten, sofern diese erforderlich sind. Bei Erkennung von Auswertungsschwachstellen und Fehlern müssen systemseitig Ausnahmeberichte ausgelöst werden können (vgl. Basler Ausschuss für Bankenaufsicht 2013, BCBS #239, Tz. 53c). Mit Blick auf die Nutzbarkeit von risikorelevanten Daten ist aus BCBS #239-/MaRisk AT 4.3.4-Sicht seitens des Instituts sicherzustellen, dass diese sich im Zielsystem möglichst automatisch bzw. ohne manuelle Zusatzaufwände auswerten lassen. Dabei erhalten Institute aus Prüfungssicht „eine gute Note“, wenn externe risikorelevante Informationen (z. B. externe Ratinginformationen) mit systemseitiger Unterstützung zugeordnet werden können. Ein weiteres Prüfobjekt richtet sich auf das Vorhandensein eines standardisierten und institutsweit einheitlich geregelten Prozesses für das Mapping von externen zu institutsinternen Identifiern. Gefordert wird darüber hinaus, dass Mapping- und Überleitungskriterien zwischen Quellsystemen und Zielsystem vorliegen.

144

3  Prototypische Umsetzung einer BI-basierten Reporting-Anwendung und eines …

Was die Aufnahme und Pflege von Daten anbetrifft, ist institutsseitig sicherzustellen, dass sich nutzerspezifische Dateneingaben in das Zielsystem nur im Rahmen des Grundsatzes der Datenintegrität vornehmen lassen. Systemseitig muss gewährleistet sein, dass nutzerspezifische Berichtanpassungen, etwa zur Durchführung von Simulationen, nicht zu einer Änderung des produktiven Datenbestands führen. Gefordert wird darüber hinaus, dass manuelle Aggregationsprozesse und die manuelle Anreicherung von Daten automatisch protokolliert werden. Manuelle Eingriffe sind zur Aufrechterhaltung der Datenintegrität weitgehend auf die Zuliefersysteme zu beschränken. Ausnahmsweise manuelle Anpassungen des aggregierten Datenbestandes müssen jederzeit nachvollziehbar sein. Für manuelle Anpassungen/Änderungen dieserart sind Institute gefordert, einen Freigabeworkflow (Vier-Augen-Prinzip) mit automatischer Aufzeichnung der Freigaben vorzusehen. Darüber hinaus wird im Rahmen einer Auditierung gemäß BCBS #239/MaRisk AT 4.3.4 geprüft, ob und inwieweit integrierte Datentaxonomien einschließlich einer entsprechenden konzernweiten Datenarchitektur genutzt werden. Nach Möglichkeit sind Single Identifier und/oder einheitliche Benennungskonventionen für bestimmte Daten festzulegen (z. B. für Konzerngesellschaften, Kontrahenten, Kunden oder Konten) und zu verwenden. Eine gute Bewertung vergeben die Prüfer, wenn die Kommunikation der Namenskonventionen und Kennzahlen für die Risikoberichterstattung instituts- sowie gruppenweit erfolgt. Mit Blick auf die organisatorische Verankerung des Themenfeldes DQ ist institutsseitig (in Abhängigkeit von der Größe und Komplexität des Instituts) sicherzustellen, dass Aufgaben und personelle Verantwortlichkeiten für die DQ-Sicherung auf Geschäftsebene und in den IT-Funktionen eindeutig festgelegt sind (vgl. Basler Ausschuss für Bankenaufsicht 2013, BCBS #239, Tz.  34). Eine Anleitung hierfür liefert exemplarisch das in Abb.  3.13

GVQM Bereichsl. Koordinator Abteilungsleitung Bereichsleitung IT-Abteilung

Sachbearbeiter

Gesamtverantwortung für das Datenqualitätsmanagement • Steuerung und Überwachung des Gesamtprozesses • Vorgabe für Fachanweisungen im Unternehmen • Implementierung von Kontrollinstanzen Steuerung der Datenqualität • Steuerung und Überwachung der Datenqualität • Erstellung von Arbeitsanweisungen • Definition und Erstellung von Reports Verantwortung für das Datenqualitätsmanagement spezifischer Datenbereiche • Steuerung und Überwachung der Disziplin-spezifischen Prozesse • Vorgabe für Fachanweisungen in der Fachabteilung / im Bereich Erstellung und Wartung der IT-Infrastruktur • Operative Umsetzung von Datenqualitätsmaßnahmen • Historisierung von Umsetzungsvorgaben Verantwortung für Datenqualität im einzelnen Prozess • Sachgemäße Eingabe von Daten • Plausibilisierung der Daten auf Basis von Einzelfällen / Stichproben • Fehlerkorrektur und lfd. Erfassung von Veränderungen

Abb. 3.13  Stufenmodell zur Verortung von DQM-Verantwortlichkeiten. (Quelle: eigene Darstellung)

3.2  Auditierung und Evaluierung von risikorelevanten Reporting-Anwendungen …

145

dargestellte Stufenmodell. Bei der Definition der Verantwortlichkeiten erweist sich eine unabhängige Validierungsfunktion als Kontrollinstanz auf der sogenannten 2nd Line of Defence als zielführend (vgl. Basler Ausschuss für Bankenaufsicht 2013, BCBS #239, Tz. 29a).

3.2.1.3 Standard-Reporting Was den Prüfbereich Standard-Reporting anbetrifft, muss ein Institut nachweisen, dass diverse Berichtsobjekte, zu denen z. B. Filter, Hierarchien, Metriken und Kennzahlen gehören, für die jährliche Risikoberichterstattung definiert und dokumentiert werden. Hierfür sind Erwartungen an die Verlässlichkeit von Näherungswerten in der Risikoberichterstattung seitens der Geschäftsleitung klar zu formulieren (siehe die BCBS #239-Prinzipien „Genauigkeit“ und „Aktualität“). Dazu zählt auch die Benennung der Grundsätze bezüglich der Daten, auf denen diese Näherungswerte basieren (vgl. Basler Ausschuss für Bankenaufsicht 2013, BCBS #239, Tz. 54). Was das Berichtsspektrum anbetrifft, fordern BCBS #239 und MaRisk AT 4.3.4, Tz. 5 die systemseitige Bereitstellung der folgenden Berichte (vgl. Basler Ausschuss für Bankenaufsicht 2013; Bundesanstalt für Finanzdienstleistungsaufsicht 2017): • • • •

Berichte zu Adressenausfallrisiken (Konzern- und Gruppenebene), Berichte zum aggregierten Exposure gegenüber großen Schuldnern (Klumpenrisiken), Berichte zu Kontrahentenrisiken (z. B. aus Derivaten), Berichte zu Handelsrisiken und Handelspositionen, operativen Limits sowie branchenund regionsbezogenen Marktkonzentrationen (vgl. Basler Ausschuss für Bankenaufsicht 2013, BCBS #239, Tz. 46), • Ausgabe von Indikatoren für Liquiditätsrisiken, z.  B.  Zahlungsströme/Abwicklungszahlungen und Refinanzierung, • Berichte zu operationellen Risiken, z. B. Systemverfügbarkeit, unbefugter Zugriff. Berichtbasierte Abfragen auf den Datenbestand sollen sich zeitnah ausführen lassen, und die Performance soll anhand eines geeigneten Kriteriums gemessen werden (z.  B. anhand der risikogewichteten Berichtzeit in Sekunden/Minuten]. Institutsseitig ist sicherzustellen, dass tagesaktuelle Daten (z.  B. externe Ratinginformationen) verarbeitet und ohne großen Verzug in Berichtsform ausgewertet werden können. Als Messkriterium kann z. B. die risikogewichtete Berichtszeit in Stunden verwendet werden. Gefordert wird da­ rüber hinaus, dass sich risikorelevante Berichte über alle relevanten Kredit-, Markt- und Liquiditätspositionen/-engagements zeitnah erstellen lassen (vgl. Basler Ausschuss für Bankenaufsicht 2013, BCBS #239, Tz. 71). Als Kriterium kann hierfür die risikogewichtete Berichtszeit in Stunden zum Einsatz kommen. Wichtig ist in diesem Zusammenhang, dass Gesamtrisikoberichte in einem zeitlichen Rahmen von (t  +  10 Tage) bereitgestellt werden können. Um ein flexibles Risikoreporting betreiben zu können, ist institutsseitig sicherzustellen, dass standardmäßig verschiedene Analysefunktionalitäten vorliegen. Zu diesen gehört z. B. die Möglichkeit eines Drill-Down/Drill-Across auf den aggregierten Datenbestand.

146

3  Prototypische Umsetzung einer BI-basierten Reporting-Anwendung und eines …

Hinsichtlich des Berichtshorizonts ist zu evaluieren, ob das Standard-Reporting um zukunftsbezogene Berichtkapazitäten im Sinne von Frühwarnberichten angereichert werden kann [vgl. hierzu auch Abschn. 3.1]. Im BCBS #239-Papier wird die Abrufbarkeit derartiger Berichte pro Portfolio gefordert (vgl. Basler Ausschuss für Bankenaufsicht 2013, BCBS #239, Tz. 24). Ebenso sollen entscheidungsrelevante Daten in Stressphasen und Krisenzeiten zeitnah zur Verfügung gestellt werden können (t + 10 Tage). Dies setzt voraus, dass Institute über entsprechende Stresstestszenarien verfügen, die weiterentwickelt werden.

3.2.1.4 Ad-hoc-Reporting Neben dem Standard-Reporting stellt das Ad-hoc-Reporting einen integrierten Bestandteil eines institutsweiten Berichtssystems dar (vgl. Abschn. 2.2.4.1); im Idealfall auf Basis eines Self-Service-Ansatzes, wie er in Abschn. 2.2.4.3 thematisiert worden ist. Gemäß BCBS #239 (vgl. Basler Ausschuss für Bankenaufsicht 2013) und MaRisk AT 4.3.4 (vgl. Bundesanstalt für Finanzdienstleistungsaufsicht 2017) wird gefordert, die Datenaggregationskapazitäten flexibel und anpassungsfähig anzulegen, damit Ad-hoc-Abfragen erstellt und sich abzeichnende Risiken bewertet werden können [vgl. BCBS #239, Tz. 48, MaRisk AT 4.3.4, Tz. 6]. Anpassungsfähigkeit beinhaltet in diesem Zusammenhang u. a. die Bereitstellung von Kapazitäten für nutzerspezifische Datenanpassungen (z. B. die Erstellung von Datenübersichten, einer Liste der wichtigsten Aspekte, von Anomalien), für bedarfsgerechte Detailaufbereitungen und die Erstellung von Kurzberichten [vgl. BCBS #239, Tz. 49]. Gemäß MaRisk AT 4.3.4, Tz. 6 besteht die Anforderung, dass der Risikodatenbestand sich im Bedarfsfall nach unterschiedlichen Dimensionen auswerten lässt (z. B. nach Ländern, Branchen, Geschäftsfeldern), wobei Funktionalitäten zur flexiblen Analyse der risikorelevanten Daten systemseitig zur Verfügung stehen, z. B. Slicing, Dicing, Drill-Down, Roll-Up. In diesem Zusammenhang wird gefordert, dass Anwender bei Ad-hoc-Abfragen risikorelevante Daten, soweit möglich und sinnvoll, bis auf Einzelgeschäftsebene analysieren können [vgl. MaRisk AT 4.3.4, Tz. 6]. Auf Basis vordefinierter Szenarien oder externer Ereignisse soll es Berichtsanwendern darüber hinaus möglich sein, Teildatenreihen zu generieren. Hierzu gehört z. B. die Erstellung einer Auswertung zu einem bestimmten Stichtag mit länderspezifischen Risikopositionen auf Basis einer Länderliste oder mit branchenspezifischen Risikopositionen auf Grundlage einer Branchenliste unter Berücksichtigung aller Geschäftsfelder und Regionen [vgl. BCBS #239, Tz. 50]. Ungeachtet der jeweiligen Ad-hoc-Abfrage ist systemseitig und organisatorisch sicherzustellen, dass der Aufruf von Dimensionen und Kennzahlen auf die erlaubten Nutzungsrechte nach dem Need-to-know-Prinzip (Minimalprinzip) beschränkt ist. 3.2.1.5 Unabhängige Überprüfbarkeit Der im vorliegenden Abschnitt thematisierte Prüfbereich hat zum Ziel, die Fähigkeit eines Instituts zu evaluieren, im Bedarfsfall eine unabhängige Überprüfbarkeit der o.  g.

3.2  Auditierung und Evaluierung von risikorelevanten Reporting-Anwendungen …

147

­ rüfbereiche zu ermöglichen. Institute erhalten zum einen eine gute Bewertung, wenn P prozessunabhängige Kontrollinstanzen vorhanden und institutsweit etabliert sind [vgl. MaRisk AT 4.3.4, Tz. 7]. Dies betrifft: • die Quellsysteme und die Datenbereitstellung, • die Datenverarbeitung und Durchführung von ETL-Prozessen (Extraktion, Transformation, Laden), • die Datenhaltung und Historisierung sowie • die Auswertung, die Analyse und das Reporting. Zum anderen wird seitens der Aufsicht gefordert, dass die mit der Validierung der Aggregationskapazitäten betrauten Kontrollinstanzen auf Berichtkapazitäten und Analysefunktionalitäten der Risikoberichterstattung zugreifen können. Voraussetzung hierfür ist, dass entsprechende Benutzerrechte (Leserechte) sich im Bedarfsfall über das zum Einsatz kommende Reporting-Werkzeug einrichten lassen. Darüber hinaus ist zu gewährleisten, dass die mit der (technischen) Validierung der Aggregationskapazitäten betrauten Mitarbeiter über hinreichende Kenntnisse in den folgenden Themenbereichen verfügen. Dies betrifft die Bereiche ETL-Prozesse, BI, DWH, IT-Architektur, IT-Infrastruktur und institutsweites Reporting. Ferner ist regelmäßig, mindestens einmal jährlich, zu prüfen, ob die institutsinternen Vorgaben zur Risikodatenaggregation von den Mitarbeitern eingehalten werden [vgl. MaRisk AT 4.3.4, Tz. 7] – mit der zugehörigen Protokollierung der Prüfergebnisse. Die regelmäßige Kontrolle muss durch eine von den operativen Einheiten unabhängige Stelle (z. B. Compliance, interne Revision oder externe Prüfer im Rahmen von Sonderprüfungen) erfolgen und Bestandteil des internen Kontrollsystems sein. Um die Überprüfung der Risiko- und DQ-Berichte durch Dritte zu unterstützen, richtet sich eine weitere Anforderung auf die Einbettung von Verlinkungen (in den Reports) auf beschreibende Informationen zu den verwendeten Berichtsobjekten.

3.2.2 Prototypische Umsetzung Im vorliegenden Abschnitt wird die prototypische Umsetzung einer Anwendung vorgestellt, die dazu dient, bei der Bearbeitung der in Abschn. 3.2.1 thematisierten Prüfbereiche zu unterstützen. Methodisch basiert diese Anwendung auf einem scoringbasierten Prüfungsansatz. Ihr liegt das in Abb. 3.14 dargestellte Metamodell zugrunde, das alle relevanten Objekte samt ihrer Beziehungen zueinander visualisiert. Sie werden in den nachfolgenden Abschnitten erörtert. Die Audit-Anwendung setzt sich aus 74 Prüfgegenständen zusammen, die aus den in Abschn. 3.2.1 vorgestellten Prüfbereichen abgeleitet wurden. Die Prüfgegenstände ermöglichen eine Einschätzung hinsichtlich des Erfüllungsgrads gemäß MaRisk AT 4.3.4. Jeder Prüfgegenstand ist einer von sieben Prüfkategorien zugeordnet, die sich an den Teilziffern des AT 4.3.4 der MaRisk anlehnen und im Folgenden aufgelistet sind:

148

3  Prototypische Umsetzung einer BI-basierten Reporting-Anwendung und eines … wird als Prüfergebnis zugeordnet

Risikogruppe gehen ein in

bestehen aus

Prüfgegenstände

setzen sich zusammen aus

Prüfschritte Prüfkategorien

Gesamtbericht

gehen ein in

Gesamtübersicht

ermöglicht die Ausgabe von

Abb. 3.14  Objektmodell der Audit-Anwendung. (Quelle: eigene Darstellung)

I. Aggregation von Risikodaten II. Datenstruktur und Datenhierarchie III. Auswertbarkeit nach verschiedenen Kategorien IV. Andere im Institut vorhandene Informationen V. Risikodaten in Stressphasen VI. Ad-hoc-Informationen nach verschiedenen Kategorien VII. Überprüfung durch eine unabhängige Stelle

3.2.2.1 Hauptmaske Als Einstiegspunkt zur Bedienung der Anwendung dient die in Abb.  3.15 dargestellte Startmaske, die zugleich die Gesamtübersicht darstellt, in der die gewonnenen Erkenntnisse aus einer Prüfung in aggregierter Form angezeigt werden. Die sieben Prüfkategorien sind auf der linken Seite der Startseite platziert. Jeder Prüfkategorie ist ein Gesamtergebnis in Form von sogenannten Risikopunkten zugeordnet, das in der zugehörigen Spalte ausgegeben ist. Das Gesamtergebnis einer Prüfkategorie wird ermittelt, indem die Teilergebnisse aus den einzelnen Bewertungen der Prüfgegenstände, die einer Prüfkategorie zugeordnet sind, summiert werden (vgl. Abschn. 3.2.2.2). Bei den Prüfgegenständen sind zur Einstufung eines Prüfungsergebnisses fünf Risikogruppen vorgesehen (Qualifizierungen von „A“ bis „E“). Während die Risikogruppe „A“ die Bestnote darstellt, steht die Risikogruppe „E“ für einen Zustand, in dem der betrachtete Prüfgegenstand gemäß MaRisk AT 4.3.4 nicht erfüllt ist. Die dazwischenliegenden Bewertungsklassen „B“ bis „D“ sind Abstufungen. Tab. 3.10 fasst die Zuordnung der Risikogruppen zu den Risikopunkten zusammen.

3.2  Auditierung und Evaluierung von risikorelevanten Reporting-Anwendungen …

149

Abb.  3.15  Hauptmaske zum Einstieg in die Prüfkategorien/zur Darstellung der Ergebnisse. (Quelle: eigene Darstellung) Tab.  3.10  Zuordnung der Risikogruppen und Risikopunkten

Risikogruppe A B C D E

Risikopunkte Von 0 bis unter 20 Von 20 bis unter 40 Von 40 bis unter 60 Von 60 bis unter 80 Von 80 bis 100

Jeder Prüfkategorie sind Gewichte zugeordnet, die in der vorletzten Spalte der Hauptseite angeordnet sind (vgl. Abb.  3.15). Multipliziert mit den Risikopunkten lassen sich damit für jede Prüfkategorie gewichtete Risikopunkte ermitteln, die in der letzten Spalte der Hauptansicht vorgehalten werden. Die einzelnen gewichteten Risikogruppen ergeben sich zu einem Gesamtscoring, das rechts unten in der letzten Spalte platziert ist. Im Beispiel wird ein Gesamtscoring von 56,5 gewichteten Risikopunkten erzielt, das der Risikogruppe „C“ entspricht.

3.2.2.2 Bearbeitung von Prüfgegenständen Damit die Prüfergebnisse ermittelt und in der Hauptmaske ausgegeben werden können (vgl. Abb. 3.15), müssen zunächst die Prüfgegenstände der in Abschn. 3.2.2.1 genannten Prüfkategorien bearbeitet werden. Nach einem Klick auf eine der sieben Prüfkategorien in der Hauptmaske gelangt der Anwender zu den jeweiligen Prüfgegenständen. Der im Beispiel geöffnete Prüfgegenstand lautet „Prozessbeschreibungen zur Risikodatenaggregation (Datenflussdiagramm) sind systematisch und für sachkundige Dritte nachvollziehbar dokumentiert“ (vgl. Abb. 3.16).

150

3  Prototypische Umsetzung einer BI-basierten Reporting-Anwendung und eines …

Abb. 3.16  Evaluation eines Prüfgegenstandes. (Quelle: eigene Darstellung)

Die Bearbeitung eines Prüfgegenstands erfolgt anhand mehrerer Prüfschritte (Leitfragen), die dazu dienen, den zugrunde liegenden Sachverhalt zu konkretisieren. Zu jedem Prüfschritt lässt sich in einem Textfeld das jeweilige Ergebnis der Prüfung dokumentieren; ergänzt um die Option, Dokumentennachweise (z. B. Fachkonzepte, Datenflussdiagramme, Datenmodelle) anzuhängen und mit dem Prüfbogen abzulegen. Im Feld „Ausprägung“ wird die Gesamteinschätzung zum Prüfgegenstand festgehalten, wobei die in Abschn. 3.2.2.1 vorgestellten Risikogruppen gelten. Im dargestellten Beispiel (vgl. Abb.  3.16) lautet die Gesamteinschätzung „E“. Jeder Risikogruppe sind Risikopunkte zugeordnet. Für die Risikogruppe „E“ fallen 100 Risikopunkte bzw. Maluspunkte an. Multipliziert mit der vorgegebenen Gewichtung werden die Risikopunkte ermittelt, die im zugrunde liegenden Beispiel einen Wert von 100 betragen. Anhand dieses Aufbaus und Vorgehens lassen sich alle 74 Prüfgegenstände bearbeiten. Ein Fortschrittsbalken, der unterhalb der Eingabemöglichkeiten auf zwei Leisten positioniert ist, visualisiert, wie viele Prüfschritte einer Prüfkategorie (hellgrüner Fortschrittsbalken) sowie im Verhältnis zu allen 74 Prüfschritten (dunkelgrüner Fortschrittsbalken) offen geblieben sind. Eine Rotfärbung des Speicherknopfes deutet an, dass sich ein Prüfgegenstand im Bearbeitungsmodus befindet und der jeweilige Arbeitsstand noch gespeichert werden muss.

3.2.2.3 Ergebnis der Prüfung Die Ergebnisse der scoringbasierten Prüfung lassen sich per Knopfdruck zu einem Gesamtbericht (z. B. als Word- oder PDF-Dokument) erstellen und auf einem gewünschten Ablageort im Dateiverzeichnis speichern (vgl. Abb. 3.17).

3.2  Auditierung und Evaluierung von risikorelevanten Reporting-Anwendungen …

151

Abb. 3.17  Ausgabe eines Gesamtberichts. (Quelle: eigene Darstellung)

Im vorliegenden Prototyp stellt sich der Gesamtbericht in Textform mit Erläuterungen dar (siehe hierzu den Auszug, der in Abb. 3.17 visualisiert ist). Die Ausgabe der Prüfergebnisse erfolgt anhand von vorgefertigten, systemseitig hinterlegten Textfragmenten sowie auf Basis einer Erstindikation zum Aufwand, um identifizierte Defizite zu verbessern. Die entsprechende Formulierung zu einem Prüfergebnis wird bei der Erstellung des Gesamtberichts für jeden der 74 Prüfgegenstände „gezogen“ und zu einem zusammenhängenden Text gefügt (vgl. Abb.  3.18). Auf diese Weise wird für den Berichtsempfänger die ­Möglichkeit geschaffen, das Prüfergebnis in komprimierter und verbalisierter Form einzusehen.

3.2.3 Zusammenfassung Die vorgestellte Applikation enthält u. a. eine fachlich valide Zusammenstellung gewichteter Prüfschritte und Prüfungsleitfragen, die eine fundierte Einschätzung und Quantifizierung des Erfüllungsgrades in Bezug auf die am 27.10.2017 veröffentlichte Endfassung der MaRisk gemäß AT 4.3.4 bzw. in Bezug auf die Prinzipien gemäß BCBS #239 ermöglichen. Neben einer Ad-hoc-Bestimmung des aktuellen Umsetzungsstandes lässt sich durch die regelmäßige Anwendung der scoringbasierten Applikation eine wirksame Überwachung und Steuerung der Konformität gemäß BCBS #239 und MaRisk AT 4.3.4 erreichen und revisionssicher dokumentieren. Die Umsetzung des in AT 4.3.4 der MaRisk gelisteten Anforderungskataloges ist gleichbedeutend mit weitreichenden konzeptionellen und operativen Anpassungen der bisher

152

3  Prototypische Umsetzung einer BI-basierten Reporting-Anwendung und eines …

Abb. 3.18  Gesamtbericht in Textform. (Quelle: eigene Darstellung)

gängigen Praxis des Datenmanagements und der Risikodatenaggregation. Eine strukturierte und detaillierte Ausgestaltung eines entsprechenden Prüfgrößenkataloges auf Basis der in Abschn. 3.2.1 vorgestellten Prüfbereiche eröffnet zunächst die Durchführung von Self-Assessments hinsichtlich des Umsetzungsstandes der Anforderungen der MaRisk in Form von Checklisten. Derart werden nicht nur Fehler und Auslassungen bei der Implementierung (und das damit einhergehende regulatorische und finanzielle Risiko) minimiert. Zudem können über die Einführung geeigneter Metriken die Prüfgrößen direkt in Schlüsselkontrollen umgewandelt und kann der aktuelle Stand der Umsetzung der Anforderungen im Zeitablauf verfolgt werden. Damit ist zugleich der Grundstein für eine weitgehend automatisierte und wiederkehrende Datenqualitätsüberprüfung und -optimierung (Datenprofiling, Datenstandardisierung und Bereinigung, Datenüberwachung und Kon­ trolle) gelegt (vgl. BITKOM 2014, S. 98.).

Literatur

153

Literatur Basler Ausschuss für Bankenaufsicht (2013): Grundsätze für die effektive Aggregation von Risikodaten und die Risikoberichterstattung, Bank für Internationalen Zahlungsausgleich, Januar 2013, zuletzt abgerufen am: 14.09.2019, https://www.bis.org/publ/bcbs239_de.pdf. BITKOM (2014): Big-Data-Technologien – Wissen für Entscheider, Leitfaden, Eigenverlag, Wiesbaden, zuletzt abgerufen am: 14.09.2019, https://www.bitkom.org/sites/default/files/file/import/140228-Big-Data-Technologien-Wissen-fuer-Entscheider.pdf. Bundesanstalt für Finanzdienstleistungsaufsicht (2017): Erläuterungen zu den MaRisk in der Fassung vom 27.10.2017, zuletzt abgerufen am: 14.09.2019, https://www.bafin.de/SharedDocs/ Downloads/DE/Rundschreiben/dl_rs0917_marisk_Endfassung_2017_pdf_ba.pdf?__blob=pu­ blicationFile&v=5. Dürselen, K. (2012): MaRisk der Banken und Frühwarnindikatoren, in: Jacobs, J.; Riegler, J.; Schulte-­Mattler, H.; Weinrich, G. (Hrsg.): Frühwarnindikatoren und Krisenfrühaufklärung. Konzepte zum präventiven Risikomanagement, Wiesbaden, S. 198–204. Gabler Wirtschaftslexikon (2019): Frühwarnsysteme, Online Lexikon, Springer Gabler, Berlin, zuletzt abgerufen am: 14.09.2019, https://wirtschaftslexikon.gabler.de/definition/fruehwarnsysteme-33743/version-257263. Golla, G.; Hoppe, T.; Klimetzek, C. et al. (2012): Bonitätsbezogene Frühwarnindikatoren und Integration in das Kreditrisikomanagementreporting, in: Jacobs, J.; Riegler, J.; Schulte-Mattler, H.; Weinrich, G. (Hrsg.): Frühwarnindikatoren und Krisenfrühaufklärung. Konzepte zum präventiven Risikomanagement, Gabler, Wiesbaden, S. 443–464. Golla, G.; Hoppe, T.; Pastwa, A. (2015): BCBS #239 – Frühwarnung und Datenqualitätssicherung, in: Risiko Manager, 06/2015, S. 12–16. Golla, G.; Hoppe, T.; Pastwa, A. (2014a): Umsetzung einer leistungsfähigen Reportingplattform und künftige Aufgaben für das Datenmanagement, in Risiko Manager, 25–26/2014, S. 35–38. Golla, G.; Pastwa, A.; Hoppe, T. (2014b): Risk Data Aggregation (RDA): Umsetzung auf Basis von Business Intelligence (BI), in: Niehoff, W.; Hirschmann (Hrsg.): BCBS 239. Regulatorische Anforderungen und effiziente Umsetzung, Bank-Verlag, Köln, S. 29–41. Huergo, L.; Schmalzried, M. (2016): Entscheidungsbaumbasierte Frühwarnsysteme für Low-­ Default-­Portfolien, in: Risiko Manager, 06/2016, S. 14–19. Wooldridge, J.  M. (2016): Introductory Econometrics  – A Modern Approach. 6.  Aufl., Cengage Learning, Boston.

4

Detailliertes Fallbeispiel zur Kreditdatenanalyse auf Basis von RStudio

Das vorliegende Kapitel beschäftigt sich mit einigen typischen Anwendungsfällen von Data Mining im Bereich des Risikoreportings von Finanzinstituten, die den in Abschn. 2.4.2 vorgestellten Phasen 2 und 3 (Datenuntersuchung und Datenaufbereitung), 4 (Modellierung) und 5 (Evaluierung) des CRISP-DM-Vorgehensmodells angesprochenen Problemfeldern nachempfunden sind. Dabei greift es auf die in Abschn. 2.4.4 vorgestellten Analyseverfahren (Clusterverfahren, Hauptkomponentenanalysen, lineare und logistische Regressionsanalysen, Entscheidungsbaumverfahren, künstliche neuronale Netze) zurück und zeigt in stark vereinfachter Form mithilfe des Programmpaketes RStudio, wie Teilaspekte der Modellierung von Kreditausfallwahrscheinlichkeiten in der Praxis aussehen könnten. Nach einer Darstellung der Ausgangssituation in Abschn. 4.1 widmen sich die folgenden Abschnitte den zuvor skizzierten Analyseverfahren. Die Umsetzung der dort gezeigten Programmierbeispiele erfolgte unter Einsatz der Programmiersprache R sowie der Entwicklungsumgebung RStudio (eine Kurzeinführung in RStudio vermittelt Kap. 6). Die Programmierbeispiele wurden mit Blick auf größtmögliche Nachvollziehbarkeit sowie Verständlichkeit und nicht nach programmierökonomischen Gesichtspunkten ausgewählt. Dass die verwendete Datengrundlage im Hinblick auf Beobachtungs- und Variablenanzahl (und somit Qualität und Umfang der erstellten Modelle insgesamt) einem Vergleich mit der Realität nicht standhält, ist insofern nachrangig, als weder die Vollständigkeit der erzielten Resultate noch deren regulatorische Brauchbarkeit, sondern vielmehr ein kursorischer Überblick über erforderliche Arbeitsabläufe sowie die Anwendungsfelder der gezeigten Analysemethoden im Vordergrund stehen. Diese Einschränkung sollte bei der Beurteilung der folgenden Ausführungen berücksichtigt werden.

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 U. R. Fingerlos et al., Risikoreporting in Finanzinstituten, https://doi.org/10.1007/978-3-658-28440-4_4

155

156

4.1

4  Detailliertes Fallbeispiel zur Kreditdatenanalyse auf Basis von RStudio

Ausgangspunkt und fachliche Zielsetzung

Das Ziel des hier gezeigten Fallbeispiels ist es, die in Abschn. 2.4.4 vorgestellte Auswahl von Analyseverfahren mit einigen stilisiert und stark vereinfacht dargestellten Anwendungsfällen im Bereich des Risikoreportings zu verknüpfen. Vor dem Hintergrund der in Abschn. 2.4.2 besprochenen Vorgehensmodelle erweist es sich als sinnvoll, den Ablauf des Beispielprojekts zumindest in Grundzügen an den dort vorgestellten Phasenmodellen zu orientieren. Weil sich die folgenden Ausführungen hauptsächlich auf Problemstellungen im Bereich der Datenuntersuchung, Datenaufbereitung, Modellierung und Evaluierung konzentrieren sollen, fallen die Ausführungen zum Business Understanding bzw. zur Startphase des Projektes, die im Cross-Industry Standard Process for Data Mining (CRISP-DM) die erste Phase des Vorgehens bilden, knapp aus. Gleiches gilt für die abschließende Phase, die sich mit der Modellbereitstellung (Deployment) beschäftigt. Auch hierzu werden im Rahmen des Beispielprojektes nur relativ wenige Aussagen getroffen.

4.2

Untersuchung der Geschäftsziele (Business Understanding)

Um mit möglichst vielen Analyseverfahren arbeiten zu können, soll als Geschäftsziel aus Sicht einer Bank ein einfaches Modell zur Beurteilung der Ausfallwahrscheinlichkeit von Kreditanträgen entwickelt werden (PD-Modell). Ob dieses PD-Modell dem Basel-­ Regelwerk unterliegt (und deshalb als internes Modell (IRB), das einer Reihe von aufsichtsrechtlichen Mindestanforderungen genügen müsste, zu qualifizieren wäre) soll im Folgenden der Einfachheit halber keine Rolle spielen. Wenn die Bank einen Kreditantrag von einem potenziellen Kreditnehmer erhält, analysiert sie (stark vereinfacht) zunächst das Risikoprofil des Antragstellers, um gute Risiken von schlechten Risiken zu trennen. Insofern will die Bank zunächst ein ausreichendes Verständnis der Charakteristika der Kreditanträge bzw. der Antragsteller erlangen. Auf Basis dieser Analyse kann sie den Kredit entweder gewähren oder den Antrag ablehnen. Wenn der Antragsteller in Wirklichkeit ein gutes Risikoprofil (hohe Kreditwürdigkeit) aufweist, besteht eine hohe Wahrscheinlichkeit, dass er den Kredit auch zurückzahlen kann, was mit entsprechenden Gewinnen für die Bank verbunden ist. Beurteilt die Bank hingegen ein derartig gutes Risikoprofil falsch und lehnt deshalb den Kreditantrag des Kunden in ungerechtfertigter Weise ab, verliert sie diese Einnahmen mit hoher Wahrscheinlichkeit. Besitzt der Antragsteller umgekehrt in Wirklichkeit ein schlechtes Risikoprofil (eine geringe Kreditwürdigkeit), dann besteht die richtige Entscheidung der Bank darin, den Kreditantrag des Kunden abzulehnen. Nimmt sie ihn in fälschlicher Weise an, dann muss sie mit einem Verlust rechnen. Denn in diesem Fall ist die Wahrscheinlichkeit hoch, dass der Kunde den Kredit nicht zurückzahlen kann. Insgesamt besteht die optimale Strategie der Bank also darin, mithilfe der über den Kunden vorliegenden Informationen gute zukünftige Risiken (geringe Kreditausfallwahrscheinlichkeiten) von schlechten ­zukünftigen Risiken (hohe Kreditausfallwahrscheinlichkeiten) zu trennen – und nur bei hinreichend geringen Ausfallwahrscheinlichkeiten Kreditanträge zu gewähren.

4.3  Datenuntersuchung (Data Understanding) und Datenaufbereitung (Dat …

157

Zusammengefasst resultieren hieraus die folgenden Ziele für das vorliegende exemplarische Data-Mining-Projekt zur Erstellung eines PD (Probability of Default)-Modells: 1. Entwicklung eines Verständnisses der Charakteristika der Kreditanträge und Verwendung beschreibender Statistiken sowie Methoden des unüberwachten statistischen Lernens wie Clusterverfahren und Hauptkomponentenanalyse. 2. Entwicklung eines Prognosemodells für die Ausfallwahrscheinlichkeiten und Verwendung von Methoden des überwachten statistischen Lernens wie (lineare und) logistische Regressionsanalysen, Entscheidungsbaumverfahren und künstliche neuronale Netze. Nachdem an dieser Stelle vorausgesetzt werden soll, dass die Ziele des Projektes mit dem Management der Bank als Auftraggeber abgestimmt sind, geht der folgende Abschnitt bereits dazu über, die verwendeten Daten zu verstehen (Data Understanding) und in geeigneter Weise aufzubereiten (Data Preparation). In der Beschreibung des CRISP-DM-Vorgehensmodells hatte sich bereits gezeigt, dass in der Praxis beide Phasen miteinander verwoben sind und mitunter mehrmals hintereinander durchlaufen werden (müssen). Da sich hier das Kreditinstitut annahmegemäß in der glücklichen Lage befindet, bereits über einen verwendbaren Datenbestand zu verfügen, werden diese beiden Phasen zu einem Abschnitt zusammengefasst.

4.3

 atenuntersuchung (Data Understanding) und D Datenaufbereitung (Data Preparation)

Häufig bestehen die mittels Data Mining analysierten Datenbestände aus vielen Tausenden oder Millionen von Datensätzen. Datenbestände im Risikoreporting von Finanzinstitutionen bilden hiervon keine Ausnahme. Um sich einen Überblick über die Datenlage zu verschaffen, ist deshalb zuerst im Sinne der in Abschn. 2.4.2.2 und Abschn. 2.4.2.3 besprochenen Phasen 2 und 3 des CRISP-DM-Vorgehensmodells eine entsprechende Datenvorbereitung sowie explorative Datenanalyse angebracht. Weil es unmöglich ist, jede einzelne Beobachtung getrennt zu beurteilen, erfolgt in der Praxis die Berechnung verschiedener statistischer Kennwerte und zudem eine grafische Aufbereitung der Daten. Durch die damit verbundene Verdichtung der enthaltenen Informationen können Aussagen über die Eigenschaften der Daten sowie erwartete und unerwartete Zusammenhänge im Datenbestand angestellt werden. Aus dieser Analyse gehen zudem Informationen über Extremwerte (Ausreißer) hervor und es lässt sich beurteilen, ob Werte fehlen. In beiden Fällen muss entsprechend reagiert werden, um in der eigentlichen Datenanalyse keine verzerrten oder falschen Schlüsse zu ziehen. Hier gilt die Regel Garbage in, Garbage out: Ein Modell kann immer nur so gut sein, wie es die vorliegenden Daten zulassen. Werden keine qualitativ guten Daten zur Modellierung verwendet, dann können selbst bei größtem Modellierungsaufwand die erzielten Resultate nur ungenügend sein.

158

4  Detailliertes Fallbeispiel zur Kreditdatenanalyse auf Basis von RStudio

Ein wesentlicher Aspekt der Datenuntersuchungs- und -aufbereitungsphase ist ein korrektes Verständnis der Maßeinheiten, in denen die zu bearbeitenden Daten vorliegen. Dies ist deshalb wichtig, weil nicht nur die im Rahmen der in der Datenuntersuchungs- und Datenaufbereitungsphase durchzuführenden statistischen Vorarbeiten, sondern auch die Entscheidung über die letztlich in der Modellierungsphase anwendbaren Analyseverfahren von den verwendeten Maßeinheiten (den sogenannten Skalenniveaus) abhängen. Was unter Skalenniveaus zu verstehen ist, beschreibt der folgende Abschnitt.

4.3.1 Skalenniveaus Vor einer Beschäftigung mit den Skalenniveaus, mit denen die Eigenschaften (Merkmale) von Untersuchungsobjekten erfasst werden können, ist der Begriff des „Messens“ zu definieren. Messen bedeutet allgemein die Zuordnung einer Zahl zur Ausprägung einer Eigenschaft des Untersuchungsgegenstandes mithilfe einer geeigneten Regel. Als allgemein gültige Unterscheidungskriterien der über die Eigenschaften eines Untersuchungsgegenstandes gesammelten Daten machen Skalenniveaus diese Regeln sichtbar. Dementsprechend ist bei der Beschreibung bzw. Charakterisierung der Variablen, die die gesammelten Daten aufnehmen, von NOIR-Attributen (Nominal, Ordinal, Intervall, Ratio) bzw. NOIR-Datentypen die Rede (vgl. Bortz und Schuster 2010, S.  12  ff.; Bleymüller und Weißbach 2015, S. 5 f.; Baesens 2014, S. 64 f.; EMC 2015, S. 71): Kategorial skalierte Daten (qualitative Daten) • Nominalskala: Hier findet ein Kategorisieren bzw. Etikettieren von Objekten statt, wobei die definierten Skalenwerte nicht mit den quantitativen Ausprägungen der Objekteigenschaften verbunden sind. So lässt sich z. B.das Geschlecht von weiblichen Kreditnehmern mit „W“ oder mit „1“ und von männlichen Kreditnehmern mit „M“ oder mit „2“ beschreiben. Jede andere Kategorisierung, die eindeutige Rückschlüsse auf die Gleichheit bzw. Verschiedenheit der Kategorien zulässt (etwa „0“ für weibliche und „1“ für männliche Kreditnehmer), wäre ebenso denkbar. Dies ist zugleich ein Beispiel binärer Daten, die dann vorliegen, wenn die genannten Kategorien nur zwei Werte annehmen können. • Ordinalskala: Die Ordinalskala weist den Objekten Zahlen zu, die mit den quantitativen Ausprägungen der Objekte verbunden sind, allerdings mit willkürlichen Abständen zwischen den einzelnen Skalenabschnitten. Als Beispiel lässt sich etwa die Ordnung (Reihung) der Abschlüsse von Kreditnehmern nach ihrer Wertigkeit im Bildungssystem (Abitur = 1, Diplom/Master = 2, Promotion = 3 oder Abitur = 0, Diplom/Master = 1, Promotion  =  3) heranziehen. Ordinal  skalierte Daten erlauben neben der e­ indeutigen Unterscheidbarkeit der zugeordneten Kategorien („gleich“ oder „ungleich“) auch die Bildung von Rangfolgen bzw. die Beurteilung „größer als“ oder „kleiner als“. Dies eröffnet die Anwendbarkeit von mathematischen Transformationen auf die zugeordneten Werte, solange die Rangfolge erhalten bleibt. Würden beispielsweise die oben angewandten Werte mit der Zahl 2 multipliziert, ergäbe sich 2, 4, 6 bzw. 0, 2, 6, und in beiden Fällen bliebe die Rangfolge Abitur, Diplom/Master, Promotion unverändert.

4.3  Datenuntersuchung (Data Understanding) und Datenaufbereitung (Dat …

159

Metrisch bzw. kardinal skalierte Daten (quantitative bzw. numerische Daten) • Intervallskala: Diese erste metrische Skala geht im Vergleich mit den zuvor beschriebenen kategorialen Skalen noch einen Schritt weiter. Nun werden auch die Abstände zwischen den Skalenwerten interpretierbar, weil sie konstant sind. Häufig werden hier Temperaturskalen in Grad Celsius (C) und Fahrenheit (F) genannt, die über eine lineare Transformation der Form C = a + bF miteinander in Verbindung stehen. Konkret gilt 5 160 5 die Formel C = × ( F − 32 ) , mit a = − und b = . Beide Skalen besitzen ver9 9 9 schiedene Nullpunkte, aber keinen gemeinsamen, absoluten Nullpunkt, da 0 Grad Celsius einem Wert von 32 Grad Fahrenheit entsprechen. Zwar erweisen sich die Abstände (Intervalle) zwischen den Temperaturwerten innerhalb der Celsiusskala und innerhalb der Fahrenheitskala als konstant, aufgrund der linearen Transformation zwischen Celsius- und Fahrenheitskala gilt dies jedoch nicht für das Verhältnis der Abstände von Temperaturwerten im Vergleich zwischen den beiden Skalen. Dass etwa die Aussage „eine Temperatur von 64°F ist doppelt so warm wie 32°F“ nicht zulässig ist, ergibt sich aus der Umrechnung der beiden Werte anhand der obigen Formel in Celsius: 17,8 °C und 0 °C. Der Wahrheitsgehalt der Aussage hängt also von der verwendeten Temperaturskala ab. Die Aussage „die Temperaturdifferenz zwischen 32°F und 34°F beträgt 2 Grad und die Temperaturdifferenz zwischen 64°F und 66°F beträgt ebenfalls 2 Grad“, ist jedoch zulässig. Es sind bei einer Verhältnisskala also nicht nur Vergleichsaussagen wie „größer als“ und „kleiner als“ möglich, sondern auch Aussagen über die Gleichheit von Differenzen zwischen den Skalenwerten. • Verhältnisskala (Ratioskala): Eine Verhältnisskala besitzt im Gegensatz zur Intervallskala einen absoluten Nullpunkt, wodurch nicht nur Aussagen über die Gleichheit von Differenzen, sondern auch Aussagen über Größenverhältnisse zulässig werden. Als Beispiele für verhältnisskalierte Merkmale dienen Länge, Alter, Preis, Einkommen, Kontostand usw. Ein Wert von Null bezeichnet in diesen Skalen die völlige Abwesenheit der beschriebenen Eigenschaft. Beispielsweise entspricht ein Kontostand von 1000 Euro (EUR) exakt 1955, 83 Deutschen Mark (DM), weil der Umrechnungskurs zwischen EUR und DM bei der Einführung des Euro als neue Währung unwiderruflich mit 1 EUR = 1, 96683 DM festgelegt wurde. Die Aussage, wonach 2000 Euro doppelt soviel wert sind wie 1000 Euro, erweist sich aufgrund des absoluten Nullpunktes als zulässig. Bei Umrechnung mithilfe des fixen Umrechnungskurses u  =  1, 95583  in ­Deutsche Mark zeigt sich, dass diese Aussage auch für den Kontostand in DM gilt, denn 3911, 66 DM sind doppelt so viel wie 1955, 83 DM. Insgesamt ist die Verhältnisskala die genaueste Skala, weil sie neben Identitätsvergleichen (Nominalskala), Ordnungen (Ordinalskala), Additionen und Subtraktionen (Intervallskala) auch Multiplikationen bzw. Divisionen erlaubt. Transformationen von einem höheren Skalenniveau zu einem niedrigeren finden im Rahmen der Datenreduktion und Datenanalyse häufig Verwendung. Eine umgekehrte Transformation ist ohne die Beschaffung zusätzlicher Informationen nicht ohne Weiteres machbar.

160

4  Detailliertes Fallbeispiel zur Kreditdatenanalyse auf Basis von RStudio

So kann beispielsweise die im obigen Beispiel verwendete dreiteilige ordinal skalierte Gliederung der Schulabschlüsse in einer Gruppe von Kreditnehmern in Abitur = 1, Diplom/Master = 2, Promotion = 3 einfach in die nominal skalierte (binäre) Gliederung Promotion = 1 und Promotion  =  0 umkodiert werden. In diesem Fall umfasst Promotion  =  0 die Gruppe der Personen, die keinen Doktorgrad erworben haben. Allerdings erlaubt nach erfolgter Umkodierung die Information Promotion = 0 Dritten keinerlei Aussage über den Erwerb eines Diplom-/Masterabschlusses, sofern diesen die zuvor angewandte Kodierregel nicht bekannt ist. Intervall- und Verhältnisskala werden bisweilen unter dem Begriff „Kardinalskala“ zusammengefasst. Diese Aggregation basiert auf der Tatsache, dass eine Unterscheidung zwischen intervall- und verhältnisskalierten Daten für die Anwendbarkeit statistischer Testverfahren nicht relevant ist, zumal sich auf verhältnisskalierten Daten anwendbare statistische Tests auch für intervall skalierte Daten verwenden lassen und umgekehrt (vgl. Bortz et al. 2008, S. 62; Bortz und Lienert 2008, S. 26 ff.). Zur Beschreibung der Eigenschaften von metrisch skalierten Daten werden univariate und multivariate Häufigkeitsverteilungen, Lageparameter (Mittelwert, Median, Modus, Interquartilsbereich), Streuungsmaße (Standardabweichung, Varianz) und Parameter der Gestalt einer Verteilung (Schiefe, Wölbung, auch als Kurtosis bezeichnet) – häufig auch in Kombination mit grafischen Darstellungen (Histogramme, Scatterplots, Boxplots) – verwendet. Zudem kommen verschiedene Korrelationsmaße zur Anwendung, die Abhängigkeiten zwischen Variablen veranschaulichen sollen. Im Falle von kategorial  skalierten Daten ist das Spektrum zur Darstellung der Eigenschaften deutlich reduziert. Hier werden zumeist einfache Häufigkeitsverteilungen, Balken- und Tortendiagramme eingesetzt. Die folgenden Ausführungen erläutern einige dieser Kennzahlen sowie grafischen Methoden anhand des vorliegenden Beispieldatenbestandes. Ausführliche Beschreibungen hierzu finden sich in den Arbeiten von Bleymüller und Weißbach 2015; Bortz und Schuster 2010; Miller 2014; Larose und Larose 2015; EMC 2015; Crawley 2013 und Baesens et al. 2016, die den folgenden Abschnitten zugrunde liegen. Vor dem Hintergrund der Wichtigkeit des Skalenniveaus, mit dem die vorliegenden Daten gemessen werden, widmet sich der nächste Abschnitt der Vorbereitung des in den folgenden Analysen verwendeten Datenbestandes.

4.3.2 Datenvorbereitung Das vorliegende Fallbeispiel basiert auf einem Datenbestand mit deutschen Kreditdaten, der von Prof. Dr. Hans Hofmann in den frühen 1990er-Jahren erstellt wurde und vom „UCI Machine Learning Repository“ (vgl. Dua und Graff 2019) frei heruntergeladen werden kann. Er ist dort unter der folgenden URL verfügbar (Stand: 14.09.2019): https://archive.ics.uci.edu/ml/datasets/statlog+(german+credit+data). Um eine dauerhafte und stabile Zugänglichkeit des Datenmaterials zu gewährleisten, steht dieses überdies auch auf der Homepage des Verlages unter https://www.springer.com/ de/book/9783658284398 (DOI: 10.1007/978-3-658-28440-4) gemeinsam mit den gezeigten Programmierbeispielen (R-Scripts) zum Download bereit.

4.3  Datenuntersuchung (Data Understanding) und Datenaufbereitung (Dat …

161

Der Originaldatenbestand beinhaltet 1000 in der Vergangenheit bearbeitete (angenommene und abgelehnte) Kreditanträge von Kunden einer deutschen Bank. Er besteht aus insgesamt 21 relativ aufwändig kodierten Variablen (Attributen), von denen 7 metrisch sowie 13 kategorial skaliert sind. Hinzu kommt eine nominal skalierte erklärte Variable mit dem Namen kredit, die Informationen darüber beinhaltet, ob ein Kreditantrag angenommen wurde (1 = gutes Risiko) oder abgelehnt wurde (2 = schlechtes Risiko). Eine andere Version des Datenbestandes wird von der Pennsylvania State University (Eberly College of Science) für den Kurs „STAT 508 – Applied Data Mining and Statistical Learning“ verwendet (https://newonlinecourses.science.psu.edu/stat508/). Er kann ebenfalls frei im Internet heruntergeladen werden (abgerufen am: 29.06.2019): https://newonlinecourses.science.psu.edu/stat508/ resource/analysis/gcd. Von diesem Datenbestand werden die deutschen Variablennamen und Teile der Variablenbeschreibungen übernommen, nicht jedoch die restlichen Inhalte.

Dementsprechend lässt sich die Kreditausfallserwartung der Bank als Funktion der Kreditgewährung auffassen. An dieser Stelle ist einschränkend zu erwähnen, dass eine derartige Modellierung der erwarteten Kreditausfallwahrscheinlichkeit in der Regel dazu führt, dass die in der Zukunft realisierte tatsächliche Kreditausfallwahrscheinlichkeit deutlich überschätzt wird, weil die Kreditvergabe eher konservativ erfolgt und deshalb nicht alle der zum Zeitpunkt des Antrages abgelehnten Kreditanträge tatsächlich in der Zukunft zu einem Kreditausfall geführt hätten. Deshalb werden die auf dem vorliegenden Kreditantragsdatenbestand basierenden erwarteten Kreditausfallwahrscheinlichkeiten sehr deutlich über jenen Kreditausfallwahrscheinlichkeiten liegen, die sich in einem „echten“ Kreditausfallsdatenbestand beobachten ließen, der in der Vergangenheit beobachtete (und nicht für die Zukunft erwartete) Kreditausfälle zur Modellbildung heranzieht. Realisierte Kreditausfallwahrscheinlichkeiten liegen im Normalfall im niedrigen einstelligen und nicht im mittleren zweistelligen Prozentbereich. Die Tatsache, dass im Folgenden streng genommen ein Kreditvergabeszenario auf Seiten der Bank und kein Kreditausfallsszenario auf Seiten der Kunden modelliert wird, sollte jedoch die hier im Vordergrund stehende Vorstellung der angewandten Analysemethoden nicht negativ beeinflussen. Dies gilt ebenso für den Umstand, dass der verwendete Datenbestand keine Scorings der Kreditnehmer beinhaltet – und die Ausfallwahrscheinlichkeiten aus diesem Grund direkt auf individueller Ebene ohne Einbeziehung von Scorings prognostiziert werden müssen. Realistischere PD-Modelle würden hingegen die Scorings als erklärende Variablen berücksichtigen. Die Kreditgewährung wird im Beispiel mithilfe der Variable kredit und die Kreditausfallserwartung mit der neu zu erstellenden binären Variable kreditausfall erfasst. Unter der Annahme, dass kredit=1, wenn der Antragsteller als kreditwürdig eingestuft wurde (also der Kredit gewährt wurde), und kredit=2, wenn der Antragsteller nicht als kreditwürdig eingestuft wurde (also der Kredit nicht gewährt wurde), lässt sich der Zusammenhang zwischen Kreditausfallserwartung und Kreditgewährung wie folgt definieren: kreditausfall=0, wenn kredit=1 kreditausfall=1, wenn kredit=2

162

4  Detailliertes Fallbeispiel zur Kreditdatenanalyse auf Basis von RStudio

Es gilt also kreditausfall=0, wenn der Kredit gewährt wurde (der Kunde ist kreditwürdig), und kreditausfall=1, wenn der Kredit nicht gewährt wurde (der Kunde ist nicht kreditwürdig). Der im Folgenden verwendete Datenbestand verfügt tatsächlich über eine Variable kredit, die die Kreditgewährung wie gezeigt beschreibt und mit den Werten „1“ (kreditwürdig) und „2“ (nicht kreditwürdig) kodiert ist. Allerdings erweist es sich als sinnvoller, für die folgenden Analysen die Variable kredit wie gezeigt in die binäre Variable kreditausfall zu transformieren und diese zu verwenden. Sie besitzt zwar denselben Informationsgehalt wie die Variable kredit, Prognosen können aber aufgrund des binären Charakters der Variable mit den Werten „0“ und „1“ direkt als (erwartete) Kreditausfallwahrscheinlichkeiten interpretiert werden: Es kann dann nämlich bei kreditausfall=0 von einer (erwarteten) Kreditausfallwahrscheinlichkeit von 0  % und bei kreditausfall=1 von einer (erwarteten) Kreditausfallwahrscheinlichkeit von 100  % gesprochen werden. Mithilfe von logistischen Regressionen erstellte Prognosen liegen dann nämlich im Intervall [0,1] (vgl. hierzu Abschn. 2.4.4.3 zur Logistischen Regressionsanalyse). In der Praxis erfolgt die Beurteilung eines erwarteten Kreditausfalls (der Kreditausfallwahrscheinlichkeit) auf Basis zahlreicher demografischer und sozioökonomischer Charakteristika des Kunden. Das Ziel des Data-Mining-Projektes ist es nun, aus dem durch das vorliegende Datenmuster beschriebenen Risikoprofil der Kunden mithilfe leistungsfähiger Analyseverfahren geeignete Entscheidungsregeln abzuleiten, die aus Sicht der Bank eine systematische Kreditgewährung bei Neuanträgen erlauben. Mithilfe dieser Entscheidungsregeln kann sie dann für zukünftige Antragsteller auf Basis ihrer Attribute (Charakteristika) prognostizieren, ob es sich um gute oder schlechte Risiken handelt. Erwartet sie einen Kreditausfall, wird sie den Kredit nicht gewähren. Der vorliegende Datenbestand enthält eine Reihe von erklärenden Variablen, deren Wirkungen auf eine (binäre) abhängige bzw. erklärte Variable modelliert werden sollen. Dabei handelt es sich um eine Aufgabenstellung, der sich mit Methoden des überwachten Lernens begegnen lässt. Wenn eine binäre abhängige Variable wie kreditausfall Verwendung findet, dann kommen zumindest die logistische Regressionsanalyse und die Entscheidungsbaumanalyse als ­mögliche Modellierungsmethoden in Frage. Darüber hinaus beschäftigen sich die folgenden Ausführungen noch mit weiteren der in Abschn. 2.4.4 vorgestellten Analyseverfahren. Den Inhalt des Datenbestandes aus (https://archive.ics.uci.edu/ml/machine-learning-databases/statlog/german/german.data) fasst die folgende Tab. 4.2  zusammen. Der Datenbestand selbst beinhaltet nur die Informationen, die in den Spalten „Attribut“ und „Ausprägung“ angeführt sind. Es erweist sich als zielführend, diese Inhalte zuerst in der Originalskalierung einzulesen und dann für weitere Analysen neu zu skalieren. Eine Beschreibung der Attribute im Original befindet sich in der folgenden Datei (abgerufen am: 17.06.2018): https://archive.ics.uci.edu/ml/machine-learning-databases/statlog/german/german.doc.

Da in jedem Data-Mining-Projekt im Allgemeinen möglichst theoriegeleitet vorgegangen werden soll, ist es wichtig, sich bereits im Rahmen des Business Understanding (also vor

4.3  Datenuntersuchung (Data Understanding) und Datenaufbereitung (Dat …

163

der Datenanalyse) Gedanken über den möglichen Einfluss der erklärenden Variablen auf die erklärte Variable zu machen. Deshalb trägt die Spalte „Hypothese“ die vermutete (hypothetische) Wirkungsrichtung des Einflusses jeder potenziellen erklärenden Variablen auf die erklärte Variable ab. Die hier gezeigten Hypothesen basieren lediglich auf einer „Ad-hoc“-Einschätzung der Wirkungsrichtung, ohne diese z. B. auf Basis eines Literaturreviews näher zu begründen. In der Praxis wissen die mit der Datenanalyse betrauten Experten eines Kreditinstituts ohnehin aus Erfahrung, mit welcher Wirkungsrichtung der erklärenden Variablen sie rechnen müssen. Ein (+) in der Spalte „Hypothese“ in Tab. 4.2 bedeutet, dass sich die betreffende erklärende metrische Variable positiv auf die Kreditgewährung (erklärte Variable kredit) auswirken könnte, ein (−) bedeutet einen erwarteten negativen Zusammenhang zwischen der erklärten metrischen Variable und der betreffenden erklärenden Variable. Im Datenbestand befinden sich aber auch metrische erklärende Variablen, für die eine Wirkungsrichtung nicht vorab bestimmt werden kann. So könnte, ceteris paribus (also wenn alle anderen Einflussgrößen konstant gehalten werden), das Alter des Antragstellers in Jahren (alter) bei sehr jungen und sehr alten Antragstellern einen positiven Einfluss auf die Kreditausfallwahrscheinlichkeit haben, bei Antragstellern mittleren Alters einen negativen Einfluss. In diesem Fall wird die erwartete Wirkungsrichtung unbestimmt gelassen und eine Kennzeichnung mit (+/−) verwendet. Bei ordinal skalierten Variablen gilt die beschriebene Wirkungsrichtung für die in der Tabelle gezeigte Abfolge von Kategorien. Wie sich in Kürze zeigt, wird diese Abfolge von Kategorien/Attributen dann mithilfe einer Dummy-Kodierung in eine Reihe von Dummy-Variablen zerteilt. Eine Eigenschaft von nominal skalierten Variablen ist, dass sich keine derartige Wirkungsrichtung/Rangordnung aus den Kategorien ableiten lässt. So ist beispielsweise bei der nominal skalierten Variablen zur Zahlungsmoral (moral) nicht geklärt, ob die Kategorie „A30“ oder „A31“ ceteris paribus (alles andere konstant) mit einer höheren Kreditausfallwahrscheinlichkeit in Verbindung gebracht werden kann. In diesem Fall erweist sich ebenso eine Kennzeichnung mit (+/−) als angebracht. Nun lässt sich ein statistisches Modell formulieren, wie es aus Abschn. 2.4.2.4 bereits bekannt ist. Allgemein nimmt es die Form Y  =  f(X)  +  ε an. Da im konkreten Fall die ­Kreditausfallwahrscheinlichkeit erklärt werden soll, schreibt sich das PD-Modell mit der Kreditausfallwahrscheinlichkeit als erklärte Variable auf Basis einer Funktion f(⋅) der im Datenbestand vorhandenen erklärenden Variablen sowie unter Einbeziehung einer Störgröße ε wie folgt:



kreditausfall = f (laufkont , laufzeit , moral, verw, hoehe, sparkont , beszeit, rate, famges, buerge, wohnzeit , verm, alter , weitkred , wohn, bishkred , beruf , pers, telef , gastarb) + ε

Nach der im Detail auf den folgenden Seiten dargestellten Vorbereitung der erklärten Variable kreditausfall und der erklärenden Variablen kann ein detailliertes ökonome­ trisches Prognosemodell formuliert werden. Bei der Entwicklung dieser Prognosemodelle können auch Kostenmatrizen zum Einsatz kommen, welche die Auswirkungen von richtigen

164

4  Detailliertes Fallbeispiel zur Kreditdatenanalyse auf Basis von RStudio

und falschen Prognosen quantifizieren und so bei der Modellierung eine asymmetrische Berücksichtigung von Prognosefehlern erlauben. Eine mögliche Kostenmatrix für die zu prognostizierende binäre Variable kreditausfall enthält in den Zeilen die tatsächlichen Werte, die die Variable im Datenbestand annehmen kann. Wie in Tab. 4.1 dargestellt, steht 0 für einen nicht ausgefallenen Kredit und 1 für einen ausgefallenen Kredit. Die Spalten enthalten die prognostizierten Werte: 0 für einen als nicht ausgefallen prognostizierten Kredit und 1 für einen als ausgefallen prognostizierten Kredit. Die aus diesen Kombinationen resultierenden vier Felder beinhalten die Kosten, die sich bei Abweichungen zwischen Beobachtungswert und Prognosewert für die Variable kreditausfall ergeben. Wenn Beobachtungswert Y und Prognosewert Yˆ übereinstimmen, wurde richtig prognostiziert und es fallen keine Kosten einer Fehlprognose an. Die beiden Kostenwerte in der Hauptdiagonale der Matrix nehmen deshalb den Wert 0 an. Wird ein Ausfall pro­ gnostiziert, obwohl es sich tatsächlich um einen „guten“ Kredit handelt (Prognosewert Yˆ = 1 , obwohl Beobachtungswert Y = 0), dann fallen Kosten in der Höhe von 1 Geldeinheit an. In diesem Fall verliert die Bank (Zins-) Einnahmen aus einem „guten“ Kredit, der fälschlich nicht vergeben wurde. Schlimmer ist jedoch der Fall, in dem ein Ausfall nicht prognostiziert wird, obwohl es sich um einen „schlechten“ Kredit handelt (Prognosewert Yˆ = 0 , obwohl Beobachtungswert Y = 1). In diesem Fall vergibt die Bank einen Kredit, der ausfallen wird. Sie verliert nicht nur (Zins-) Einnahmen, sondern (zumeist) zumindest auch einen Teil des als Kredit vergebenen Kapitals. Deshalb fallen hier die Kosten mit den angenommenen 5 Geldeinheiten deutlich höher aus. Die durch die asymmetrische Kostenmatrix ausgedrückte Aversion des Kreditinstituts gegen fälschlich vergebene „schlechte“ Kredite kann nun explizit bei der Erstellung von Prognosemodellen als Optimalitätskriterium berücksichtigt werden. Als optimales unter vielen möglichen Prognosemodellen gilt nun nämlich jenes Modell, das die in der Kostenmatrix gezeigten Kosten von Fehlprognosen minimiert. Je größer die gezeigte Asymmetrie der Kosten von Fehlprognosen ist, desto konservativer wird die durch das Prognosemodell beschriebene Kreditvergabepolitik ausfallen. Aus Gründen der Einfachheit verzichten jedoch die folgenden Ausführungen auf die praktische Anwendung einer Kostenmatrix. Mit diesem Wissen kann nun der Datenbestand eingelesen werden und die eigentliche Datenvorbereitung beginnen. Eine zusammenfassende Beschreibung der aufzubereitenden Variablen, deren Ausprägungen, Hypothesen im Hinblick auf die Kreditwürdigkeit sowie eine Zusammenfassung einiger grundlegender Kennzahlen liefert vorab die folgende Tab. 4.2. Auf ihrem Inhalt bauen die folgenden Ausführungen zur Datenvorbereitung schrittweise auf.

Tab. 4.1 Kostenmatrix Prognosewert kreditausfall

Beobachtungswert kreditausfall

=0

̂ =0

̂ =1

0

1

5

0

moral

laufzeit

Variable laufkont

V3

Zahlungsmoral, nominal skaliert

Variablenname (Attribut) beim Einlesen in RStudio Beschreibung Saldo des Girokontos V1 in Geldeinheiten (GE; ursprünglich in Deutsche Mark, DM), nominal skaliert Laufzeit des Kredits V2 in Monaten, verhältnisskaliert

Tab. 4.2  Deutsche Kreditdaten – Variablenbeschreibung

(+/−)

(−)

Hypothese im Hinblick auf die Kredit-würdigkeit (+/−)

49

530

A31

A32

A30

Keine

Keine vorangegangenen Kredite oder alle vorangegangenen Kredite zurückgezahlt Alle Kredite bei der aktuellen Bank bis jetzt pünktlich zurückbezahlt Alle existierenden Kredite bis jetzt pünktlich zurückgezahlt

Zahl

Kategorie Saldo < 0 GE 0 GE ≤ Saldo < 200 GE Saldo ≥ 200 GE Kein Girokonto vorhanden

(Fortsetzung)

x =20,903 s=12,059 min=4 max=72 40

Kennzahlen:   - Häufigkeit   - Mittelwert ( x )   - Standardab-­ weichung (s) Ausprä-­   - Minimum (min) gung   - Maximum (max) A11 274 A12 269 A13 63 A14 394

4.3  Datenuntersuchung (Data Understanding) und Datenaufbereitung (Dat … 165

verw

Variable

V4

Verwendungszweck, nominal skaliert

Variablenname (Attribut) beim Einlesen in RStudio Beschreibung

Tab. 4.2 (Fortsetzung)

(+/−)

Hypothese im Hinblick auf die Kredit-würdigkeit

Kennzahlen:   - Häufigkeit   - Mittelwert ( x )   - Standardab-­ weichung (s) Ausprä-­   - Minimum (min) Kategorie gung   - Maximum (max) Zahlungsschwierigkeiten bei A33 88 der Rückzahlung in der Vergangenheit A34 293 Problematisches laufendes Kreditkonto oder andere laufende Kredite bei anderen Banken Neuwagen A40 234 Gebrauchtwagen A41 103 Möbel, A42 181 Einrichtungsgegenstände Unterhaltungselektronik A43 280 Haushaltsgeräte A44 12 Reparaturen A45 22 Ausbildung A46 50 Urlaub A47 0 Weiterbildung A48 9 Geschäftliches A49 97 Anderes A410 12

166 4  Detailliertes Fallbeispiel zur Kreditdatenanalyse auf Basis von RStudio

V6

V7

sparkont

beszeit

Variable hoehe

Hypothese im Hinblick auf die Kredit-würdigkeit (−)

Beschäftigungszeit beim aktuellen Arbeitgeber in Jahren, ordinal skaliert (+)

Höhe der Ersparnisse (+/−) in Geldeinheiten (GE; ursprünglich in DM), nominal skaliert

Variablenname (Attribut) beim Einlesen in RStudio Beschreibung Kreditvolumen in V5 Geldeinheiten (GE; ursprünglich in DM), verhältnisskaliert

Saldo < 100 GE 100 GE ≤ Saldo < 500 GE 500 GE ≤ Saldo < 1000 GE Saldo ≥ 1000 GE Kein Sparkonto vorhanden Ohne Beschäftigung Beschäftigungsdauer < 1 Jahr 1 ≤ Beschäftigungsdauer < 4 Jahre 4 ≤ Beschäftigungsdauer < 7 Jahre Beschäftigungsdauer ≥ 7 Jahre

Kategorie Keine

603 103 63 48 183 62 172 339 174 253

A61 A62 A63 A64 A65 A71 A72 A73 A74 A75

(Fortsetzung)

Kennzahlen:   - Häufigkeit   - Mittelwert ( x )   - Standardab-­ weichung (s) Ausprä-­   - Minimum (min) gung   - Maximum (max) Zahl x =3271,258 s=2822,737 min=250 max=18424

4.3  Datenuntersuchung (Data Understanding) und Datenaufbereitung (Dat … 167

buerge

famges

Variable rate

V10

Zusätzliche Sicherheiten durch Mitantragsteller oder Bürgen, nominal skaliert

Variablenname (Attribut) beim Einlesen in RStudio Beschreibung Tilgungsrate in V8 Prozent des verfügbaren Einkommens, verhältnisskalierta Familiärer Status V9 nach Geschlecht, nominal skaliert

Tab. 4.2 (Fortsetzung)

(+/−)

(+/−)

Hypothese im Hinblick auf die Kredit-würdigkeit (−)

Männlich: geschieden oder getrennt lebend Weiblich: verheiratet oder geschieden oder getrennt lebend Männlich: alleinstehend Männlich: verheiratet oder verwitwet Weiblich: alleinstehend Keine Mitantragsteller Bürge

Kategorie Keine

50 310

548 92 0 907 41 52

A91 A92

A93 A94 A95 A101 A102 A103

Kennzahlen:   - Häufigkeit   - Mittelwert ( x )   - Standardab-­ weichung (s) Ausprä-­   - Minimum (min) gung   - Maximum (max) Zahl x =2,973 s=1,119 min=1 max=4

168 4  Detailliertes Fallbeispiel zur Kreditdatenanalyse auf Basis von RStudio

V12

V13

verm

alter

Variable wohnzeit

Hypothese im Hinblick auf die Kredit-würdigkeit (+)

Alter des Antragstellers in Jahren, verhältnisskaliert

(+/−)

Höchster verfügbarer (+/−) Vermögenswert, nominal skaliert

Variablenname (Attribut) beim Einlesen in RStudio Beschreibung Anzahl der Jahre V11 wohnhaft im aktuellen Haushalt, verhältnisskaliert Haus- oder Grundbesitz Wenn kein Haus-, Grundbesitz: Bausparvertrag oder Lebensversicherung Wenn kein Haus-, Grundbesitz, kein Bausparvertrag, keine Lebensversicherung: Auto oder Vergleichbares, das nicht bereits in Variable (Attribut) V6 erfasst wurde Nicht verfügbar oder kein Vermögen Keine

Kategorie Keine

154

A124

(Fortsetzung)

x =35,546 s=11,375 min=19 max=75

332

A123

Zahl

232

A122

Kennzahlen:   - Häufigkeit   - Mittelwert ( x )   - Standardab-­ weichung (s) Ausprä-­   - Minimum (min) gung   - Maximum (max) Zahl x =2,845 s=1,104 min=1 max=4 A121 282

4.3  Datenuntersuchung (Data Understanding) und Datenaufbereitung (Dat … 169

V15

V16

wohn

bishkred

Variable weitkred

(+/−)

Hypothese im Hinblick auf die Kredit-würdigkeit (−)

Anzahl der (+/−) bisherigen Kredite bei der aktuellen Bank (inklusive des laufenden Kredites), verhältnisskaliert

Wohnsituation, nominal skaliert

Variablenname (Attribut) beim Einlesen in RStudio Beschreibung Laufende RatenzahV14 lungsvereinbarungen, nominal skaliert

Tab. 4.2 (Fortsetzung)

Miete Eigentum Unbezahltes Wohnen ohne Eigentum Keine

Kategorie Bei anderen Banken Beim Handel Keine weiteren laufenden Ratenzahlungsvereinbarungen

Zahl

A151 A152 A153

x =1,407 s=0,578 min=1 max=4

179 713 108

Kennzahlen:   - Häufigkeit   - Mittelwert ( x )   - Standardab-­ weichung (s) Ausprä-­   - Minimum (min) gung   - Maximum (max) A141 139 A142 47 A143 814

170 4  Detailliertes Fallbeispiel zur Kreditdatenanalyse auf Basis von RStudio

pers

Variable beruf

V18

Anzahl der für das Kreditobjekt verantwortlichen Personen, verhältnisskaliert

Variablenname (Attribut) beim Einlesen in RStudio Beschreibung Berufliche Situation, V17 nominal skaliert

(+/−)

Hypothese im Hinblick auf die Kredit-würdigkeit (+) Kategorie Ungelernte Arbeitskraft ohne ständigen Aufenthaltb Ungelernte Arbeitskraft mit ständigem Aufenthalt Gelernte Arbeitskraft, einfache Beschäftigung im öffentlichen Dienst Hoch qualifizierte Arbeitskraft, leitende Arbeitskraft, höhere Beschäftigung im öffentlichen Dienst, Selbstständig Keine 148

A174

(Fortsetzung)

x =1,155 s=0,362 min=1 max=2

630

A173

Zahl

200

A172

Kennzahlen:   - Häufigkeit   - Mittelwert ( x )   - Standardab-­ weichung (s) Ausprä-­   - Minimum (min) gung   - Maximum (max) A171 22

4.3  Datenuntersuchung (Data Understanding) und Datenaufbereitung (Dat … 171

V20

V21

gastarb

kredit

Variable telef

"Gastarbeiter"c, nominal skaliert Erklärte Variable: Kreditwürdigkeitd

Variablenname (Attribut) beim Einlesen in RStudio Beschreibung V19 Telefon, nominal skaliert

Tab. 4.2 (Fortsetzung)

nicht anwendbar

(+/−)

Hypothese im Hinblick auf die Kredit-würdigkeit (+/−) Kategorie Nein Ja, auf den Antragsteller registriert Nein Ja 1: Kunde ist kreditwürdig, d.h. der Kreditantrag wurde angenommen (kein Kreditausfall erwartet) 2: Kunde ist nicht kreditwürdig, d.h. der Kreditantrag wurde nicht angenommen (Kreditausfall erwartet)

963 37 700

300

A201 A202 1

2

Kennzahlen:   - Häufigkeit   - Mittelwert ( x )   - Standardab-­ weichung (s) Ausprä-­   - Minimum (min) gung   - Maximum (max) A191 596 A192 404

172 4  Detailliertes Fallbeispiel zur Kreditdatenanalyse auf Basis von RStudio

Beschreibung Nach dem Einlesen neu erzeugte erklärte Variable: Kreditausfallwahrscheinlichkeit

Hypothese im Hinblick auf die Kredit-würdigkeit nicht anwendbar Kategorie 0: Kein Kreditausfall erwartet 1: Kreditausfall erwartet 1

300

a

Es handelt sich dabei um die Summe der geleisteten Tilgungen als Prozentsatz des verfügbaren Einkommens, also die Gesamtbelastung des Kreditnehmers mit Tilgungsraten. Um aus Sicht der Bank sicherstellen zu können, dass ein Kreditnehmer seinen Kredit bedient, sollte die derart berechnete Tilgungsrate einen vorab festgelegten Maximalwert nicht überschreiten. Je höher die Gesamtbelastung mit Tilgungsraten aus bereits bestehenden Krediten ist, desto niedriger wird die Kreditwürdigkeit im Hinblick auf einen zusätzlichen Kredit ausfallen und desto höher ist daher die Kreditausfallswahrscheinlichkeit einzuschätzen. b Im Originaldatenbestand wird die Kategorie mit „arbeitslos oder ungelernte Arbeitskraft ohne ständigen Aufenthalt“ beschrieben. Da die Variable beszeit bereits Arbeitslose explizit erfasst, wird dieser Teil der Beschreibung aus der Variable beruf entfernt. Die Interpretation der Eigenschaft „arbeitslos“ erfolgt damit in einem zeitlichen Kontext und nicht im Kontext der Berufsausbildung. Damit wird zugleich unterstellt, dass bei der Erstellung des Datenbestandes die Arbeitslosen tatsächlich nicht fälschlicherweise doppelt in beiden Variablen erfasst wurden (was sich aus heutiger Sicht nicht mehr überprüfen lässt). c Mit der Diskussion, ob Variablen wie der Status einer Person als „Gastarbeiter“ aus rechtlichen Gründen heute (der Datenbestand stammt aus den frühen 1990er-Jahren) überhaupt noch als erklärende Variablen herangezogen werden dürfen bzw. selbst bei rechtlicher Unbedenklichkeit aus ethischen Gründen dennoch verworfen werden sollten, beschäftigt sich das vorliegende Buch nicht weiter. Dass die in der Analyse erzielten Resultate etwa aus politischen Gründen missbraucht werden können, sollte jedoch bewusst sein. d Der Anteil der Anträge, die als nicht kreditwürdig eingestuft wurden (bei denen ein Ausfall erwartet wird), fällt im vorliegenden Datenbestand mit 300/1000 (30 %) auf den ersten Blick hoch aus. Dies ist deshalb der Fall, weil es sich de facto um Kreditvergabedaten (ex ante erwartete Ausfälle) handelt, die lediglich als Ausfallsdaten (ex post beobachtete Ausfälle) interpretiert werden. In der Realität treten bei tatsächlich eingetretenen Ausfällen niedrige einstellige Prozentsätze auf.

Variablenname (Attribut) beim Einlesen in RStudio Variable kreditaus- nicht im fall Datenbestand enthalten

Kennzahlen:   - Häufigkeit   - Mittelwert ( x )   - Standardab-­ weichung (s) Ausprä-­   - Minimum (min) gung   - Maximum (max) 0 700

4.3  Datenuntersuchung (Data Understanding) und Datenaufbereitung (Dat … 173

174

4  Detailliertes Fallbeispiel zur Kreditdatenanalyse auf Basis von RStudio

Vor dem Einlesen der Daten ist zunächst ein neues (leeres) Script in RStudio zu öffnen und in einem beliebigen Pfad zu speichern. Hier wird es Credit_Data.R genannt und im Ordner D:\Credit_Data abgespeichert. Nach dem Setzen des Arbeitsverzeichnisses mit setwd("D:/Credit_Data") lässt sich der Datenbestand bereits in RStudio einlesen. Dies geschieht am einfachsten direkt von der Quelle aus, sofern eine Internetverbindung besteht. Die Funktion read.table() ist dazu in der Lage, die Daten direkt von der angegebenen URL zu laden. Die eingelesenen Daten werden einem Dataframe mit einem beliebigen Namen (hier german0) zugewiesen: german0 t.test(ausfall_0$ln_hoehe,ausfall_1$ln_hoehe,var.equal=FALSE) Welch Two Sample t-test data: ausfall_0$ln_hoehe and ausfall_1$ln_hoehe t = -3.2804, df = 497.47, p-value = 0.001109 alternative hypothesis: true difference in means is not equal to 0 95 percent confidence interval: -0.29670311 -0.07442206 sample estimates: mean of x mean of y 7.733022 7.918585 > wilcox.test(ausfall_0$ln_hoehe,ausfall_1$ln_hoehe, conf.int=TRUE) Wilcoxon rank sum test with continuity correction data: ausfall_0$ln_hoehe and ausfall_1$ln_hoehe W = 93480, p-value = 0.005918 alternative hypothesis: true location shift is not equal to 0 95 percent confidence interval: -0.2783577 -0.0446464 sample estimates: difference in location -0.1605196

Abschließend kann nun das statistische Modell, basierend auf der erklärten Variable kreditausfall und den verhältnisskalierten Variablen laufzeit, rate, wohnzeit, alter, und bishkred sowie den Dummy-Variablen, die die kategorial skalierten erklärenden Variablen repräsentieren, endgültig formuliert werden. Angesichts der zuvor gezeigten Resultate findet zudem das Kreditvolumen wahlweise in nicht logarithmierter Form (hoehe) oder logarithmierter Form (ln_hoehe) Verwendung. Gleiches

224

4  Detailliertes Fallbeispiel zur Kreditdatenanalyse auf Basis von RStudio

gilt für die Kreditlaufzeit, die in der Form laufzeit und ln_laufzeit zum Einsatz gelangt. Um die Übersichtlichkeit zu erhöhen, finden sich in dem unten formulierten ökonomischen Modell die verhältnisskalierten erklärenden Variablen laufzeit, ln_laufzeit, hoehe, ln_hoehe, rate, wohnzeit, alter und bishkred gemeinsam in einer eigenen Zeile wieder. Die in Dummy-Variablen transformierten Ausprägungen der kategorial skalierten erklärenden Variablen sind jeweils gruppiert in einer eigenen Zeile abgebildet. Zur Vermeidung der Dummy-Variable-Trap fließen die Dummy-­Variablen laufkont_A14 („Kein Girokonto vorhanden“), moral_A30 („keine vorangegangenen Kredite oder alle vorangegangenen Kredite zurückgezahlt“), verw_1_A40 („Neuwagen, Gebrauchtwagen“), sparkont_A65 („Kein Sparkonto vorhanden“), beszeit_A71 („arbeitslos“), famges_A91 („männlich: geschieden oder getrennt lebend“), buerge_A101 („keine“), verm_A121 („Haus- oder Grundbesitz“), weitkred_A141 („bei anderen Banken“), wohn_A151 („Miete“), beruf_A171 („arbeitslos oder ungelernte Arbeitskraft ohne ständigen Aufenthalt“), telef_A191 („nein“), gastarb_ A201 („nein“) und pers_1 („nur eine Person ist für das Kreditobjekt verantwortlich“) nicht ins Modell ein, sofern es sich um ein Regressionsmodell mit Interzept handelt. Sie dienen als Referenzkategorien bei der Durchführung von Regressionsanalysen. Insgesamt beschreibt so das vollständige ökonomische Modell die Kreditausfallwahrscheinlichkeit (kreditausfall) als Funktion f(⋅) der erklärenden Variablen und des Störterms ε wie folgt: kreditausfall=f( laufzeit (ln_laufzeit),hoehe (ln_hoehe),rate,wohnzeit,alter,bishkred, laufkont_A11,laufkont_A12,laufkont_A13 moral_A31,moral_A32,moral_A33,moral_A34, verw_1_A41,verw_1_A42,verw_1_A43,verw_1_A44,verw_1_A45,verw_1_A46,verw_1_A48,verw_1_A49, sparkont_A61,sparkont_A62,sparkont_A63,sparkont_A64 beszeit_A72,beszeit_A73,beszeit_A74,beszeit_A75, famges_A92,famges_A93,famges_A94, buerge_A102,buerge_A103, verm_A122,verm_A123,verm_A124, weitkred_A142,weitkred_A143, wohn_A152,wohn_A153, beruf_A172,beruf_A173,beruf_A174, telef_A192, gastarb_A202, pers_2 )+ε

Nach der Formulierung des ökonomischen Modells zur Erklärung der Kreditausfallwahrscheinlichkeit folgen die nächsten Schritte. Zunächst wird die Standardisierung der verhältnisskalierten Variablen laufzeit, ln_laufzeit, hoehe, ln_hoehe, rate,

4.3  Datenuntersuchung (Data Understanding) und Datenaufbereitung (Dat …

225

wohnzeit, alter und bishkred besprochen. Im Anschluss daran erfolgt die Aufteilung des Datenbestandes per Zufallsauswahl in zwei Teildatenbestände; einen Trainingsdatenbestand zur Kalibrierung der Modelle und einen Testdatenbestand, der später zur Modellevaluierung verwendet wird.

4.3.6 Normalisierung In vielen Fällen ist es sinnvoll, verhältnisskalierte Daten zu normalisieren, bevor die eigentliche Datenanalyse beginnt. Trotz ihres (missverständlichen) Namens führt die Normalisierung nicht zu normalverteilten Variablen, sondern zu Variablen, die dasselbe Skalen­ niveau aufweisen und/oder in ein bestimmtes Intervall fallen. Ist die Verteilung der zu normalisierenden Variablen asymmetrisch, erfolgt durch die Normalisierung keine Korrektur dieser Asymmetrie. Der Vorteil der Normalisierung liegt vielmehr darin, dass sich dadurch eine Nivellierung des relativen Einflusses einzelner Variablen in der Modellierung einstellt. Dies wirkt sich nicht nur positiv auf die Anwendbarkeit und Stabilität von Clustering-­Algorithmen und künstlichen neuronalen Netzen aus, sondern kann auch die Interpretierbarkeit der erstellten Modelle erleichtern (vgl. Backhaus et al. 2016, S. 394; Larose und Larose 2015, S. 31 ff., 524 f.; Baesens et al. 2016, S. 39 ff.; James et al. 2013, S. 402; Hastie et al. 2009, S. 398 ff.; Bishop 1995, S. 298 ff.). Hastie et al. zeigen allerdings, dass in gewissen Konstellationen die Normalisierung (genauer die sogleich erläuterte Z-Standardisierung) von Variablen nicht immer zu einer Verbesserung der Ergebnisse von Clusteranalysen führen muss (vgl. Hastie et al. 2009, S. 505 f.). Insofern ist der Vorteil der Normalisierung zum Teil auch von bestimmten Variableneigenschaften abhängig.

Die folgenden Abschnitte stellen mit der Z-Standardisierung und der Min-Max-­ Normalisierung zwei häufig angewandte Datennormalisierungsmethoden vor. Darüber hinaus gibt es noch zahlreiche weitere Normalisierungsverfahren mit unterschiedlichen statistischen Eigenschaften, die jedoch hier aus Platzgründen nicht weiter behandelt werden können (vgl. Jahan und Edwards 2015, S. 335 ff.; Suarez-Alvarez et al. 2012, S. 2630 ff.; Zhang et al. 1998, S. 49 ff.; Jayalakshmi und Santhakumaran 2011, S. 89 ff.) Vgl. im Zusammenhang mit künstlichen neuronalen Netzen auch die von Angelini et al. 2008, S. 749 f. angewandte logarithmische Transformation und die Begründung für die Verwendung der Min-Max-Transformation in Khashman 2010, S. 6235 f.

4.3.6.1 Z-Standardisierung Eine der gängigsten Normalisierungsmethoden ist die sogenannte Z-Standardisierung von Variablen. Erfolgt beispielsweise in einer Datenstichprobe eine Beobachtung xi der Varian ble x, die den Stichprobenmittelwert x = 1 ∑ xiund die Stichprobenstandardabweichung n i =1 1 n 2 s= ∑ ( xi − x ) aufweist, eine Z-Standardisierung, dann wird von jedem der i = 1, n − 1 i =1 …, n Datenpunkte xi der zugehörigen Mittelwert x subtrahiert und das Ergebnis durch die

226

4  Detailliertes Fallbeispiel zur Kreditdatenanalyse auf Basis von RStudio

Stichprobenstandardabweichung s dividiert. Die standardisierten Beobachtungswerte zi lassen sich dann wie folgt schreiben:

zi =

xi − x s

Aus dieser Formel ist ersichtlich, dass die Standardisierung nicht automatisch zu einer Standardnormalverteilung der betreffenden Variablen führt. Durch die Standardisierung wird nämlich eine Variable lediglich derart neu skaliert, dass sie einen Mittelwert z = 0 und eine Standardabweichung sz = 1 erhält. Die Minima und Maxima derart standardisierter Variablen sind zudem nicht auf das Intervall [0; 1] beschränkt (vgl. Hastie et al. 2009, S. 398 ff.; Bishop 1995, S. 298 ff.). Da im Zuge der Standardisierung von Variablen die korrigierte Beobachtungsanzahl n − 1 in der Stichprobe zu ermitteln ist (wobei insbesondere bei großen Stichproben oft auch die einfache Beobachtungszahl n zur Anwendung kommt), erweist sich eine Überprüfung des Datenbestandes auf fehlende Datenwerte (missing values) als unumgänglich. Sie sind in RStudio mit dem Wert "NA" gekennzeichnet. Denn um die Standardisierung korrekt durchführen zu können, sind entweder die fehlenden Werte durch „brauchbare“ Werte zu ersetzen oder aber – wenn es sich um relativ wenige Zeilen mit einem zufälligen Muster von fehlenden Werten handelt und dieses Zufallsmuster keinen statistisch signifikanten Erklärungsbeitrag hinsichtlich der abhängigen Variable leistet (vgl. Baesens 2014, S. 19 f.; Hosmer et al. 2013, S. 395 ff.; Eid et al. 2017, S. 291 f.) – aus den Berechnungen herauszulassen und die Beobachtungsanzahl entsprechend zu reduzieren. Ob ein statistisch signifikanter und ökonomisch relevanter Erklärungsbeitrag der fehlenden Werte im Hinblick auf eine erklärte Variable vorliegt, kann mithilfe entsprechender Methoden, beispielsweise χ2-Tests, überprüft werden. Ist ein solcher Erklärungsbeitrag vorhanden, dann lässt sich die Information über die fehlenden Werte als neue Kategorie in die Analyse mit aufnehmen. Eine weitere Möglichkeit besteht darin, die fehlenden Werte zu ersetzen (zu imputieren). Einige Analysemethoden wie z. B. Entscheidungsbaumverfahren werden durch fehlende Werte ohnehin nicht behindert, weil sie vom Algorithmus automatisch als eigene Kategorie betrachtet werden (vgl. Baesens 2014, S. 19 f.; Eid et al. 2017, S. 291 f.).

Solche „brauchbaren“ Werte könnten je nach Charakteristika der Variablen und Aufgabenstellung der Mittelwert, der Median, der Modus, eine Zufallszahl oder eine andere festgelegte Konstante sein. Auf nähere Ausführungen, wie fehlende Werte durch brauchbare Werte zu ersetzen sind, wird an dieser Stelle aus Platzgründen verzichtet. Sollten in der Folge fehlende Werte auftreten, lassen sich entsprechend der zweiten Vorgehensweise alle Zeilen mit fehlenden Werten aus dem Datenbestand eliminieren (vgl. EMC 2015, S. 85 ff.; Larose und Larose 2015, S. 22 ff.; Siddiqi 2017, S. 174 ff.). Zunächst können die Funktionen dim(), nrow() und ncol() verwendet werden, um die gesamte Zeilen- und Spaltenanzahl des Datenbestandes festzustellen. Dies ergibt für die Zeilenanzahl (Beobachtungsanzahl) den Wert 1000 und für die Spaltenanzahl ­(Variablenanzahl) den Wert 81. Damit ist klar, dass jede der Variablen im Datenbestand insgesamt 1000 nicht fehlende Beobachtungen haben muss:

4.3  Datenuntersuchung (Data Understanding) und Datenaufbereitung (Dat …

227

dim(german) nrow(german) ncol(german)

Ebenso ist es möglich, mit der Funktion length(german$kreditausfall) für einzelne Spalten (Variablen) des Datenbestandes die gesamte Zeilenanzahl (Beobachtungsanzahl) zu ermitteln. Am Beispiel der potenziellen erklärenden Variable kreditausfall liefert dies ebenfalls den Wert 1000: length(german$kreditausfall)

Nun kann mithilfe der kombinierten Funktion colSums(!is.na(german)) für jede Variable im Datenbestand german die Anzahl der Zeilen mit nicht fehlenden Werten summiert werden. So lässt sich für alle Variablen die Anzahl der Zeilen bestimmen, die keine fehlenden Datenwerte aufweisen. Da dies für jede Variable den Wert 1000 ergibt (also die gesamte Beobachtungszahl), können keine fehlenden Werte vorliegen: colSums(!is.na(german))

In diesem Fall führt beispielsweise die Funktion na.exclude() zur Erzeugung eines neuen Datenbestandes german.nomiss, der nur die Zeilen ohne fehlende Werte enthält. Bei Anwendung (zur Veranschaulichung) auf den vorhandenen Daten zeigt der Vergleich der Dimensionen der beiden Datenbestände german und german.nomiss mithilfe von dim(german) und dim(german.nomiss) nun ebenfalls, dass der ursprüngliche Datenbestand german keine fehlenden Werte enthält, da sich in beiden Fällen die volle Beobachtungsanzahl von 1000 Zeilen (sowie 83 Variablen) einstellt. Somit bietet sich eine Löschung des Datenbestandes german.nomiss an: german.nomiss