FinanzrechtlicheAufsichtsregelnfürdieRisikosteuerunginFinanzinstituten

WiekannDataVaultbeiderModernisierungderRisikosteuerunginBankenhelfen?Die Folgen der Finanzmarkt- und Staatsschuldenkrise sind teuer, vor allem für uns Steuerzahler. DieRegulierungsbehörden in Europa und Deutschland versuchen jetzt die Steuerbarkeit der Finanzinstitute zugewährleistenundeineWiederholungderKrisezuverhindern.DieRegulatorenvonBCBS239(einerVorschriftvom„BaselComitteeonBankingSupervision“kurzBCBS)schätzenfürdieUmsetzungdieserMaßnahmeeinenmittleren,zweistelligen Millionenbetrag pro Institut insgesamt und in Einzelfällen einen dreistelligen Millionenbetrag anInvestitionen. Anhand der Handlungsbedarfe, die sich aus BCBS 239 ergeben erläutere ich wie die Data VaultMethodikbeiderRealisierunghelfenkann.

Die Vorgaben der internationalen Aufsichtsbehörden,Finanzgremien und –organisationen verstecken sich hinterBegriffen wie MaRisk, IFRS 9-13, FinRep, CoRep usw.Gemeinsam ist ihnen heutzutage vor allem das Ziel dasRisikomanagement, die Rechnungslegung und dieFinanzmarktprodukte imBankensystemso zu regulierenundwiedersteuerbarzumachen,dasssicheineFinanzmarktkrisenichtmehrwiederholenkann.

Abbildung 1 Regulierungsbehörden International undNationalgemäß(Quelle3)

Über den Sinn oder die Fähigkeit dieserMaßnahmen diesesZiel tatsächlich zu erreichen lässt sich streiten, aber darumsolles indiesemArtikelnichtgehen.Vielmehrsollesdarumgehen, welche konkreten RealisierungsmaßnahmenbeispielhafthinterBCBS239–einerweiterenRegulierung indiesem Zuge – vor den Finanzinstitutionen stehen undinwieferndieDataVaultMethodedabeihelfenkanndiesezuimplementieren.Bei der Aufarbeitung und Analyse der Ursachen für dieFinanzmarktkrise sind wir bestimmt noch nicht und werden

vielleichtauchnieamEndeankommen.Dafüristesaucheinzu komplexes Gebilde mit vielen Einflussfaktoren und vielPolitik. Allgemein anerkannt ist die Erkenntnis dass es auchum ein Regulierungsversagen ging und effizienteFrühwarnsysteme basierend auf einem standardisierten undumfassendenRisikomanagementindenInstituteneinesolcheKrise verhindern könnten, wenn dies die Qualität deranalytischen Datengrundlage in den Finanzinstitutionenhergäbe. Diese Qualität wiederum hängt vonDatenmanagementProzessenundderInfrastrukturinnerhalbdieserInstitutionenab.Risikodatenexistiertenhäufiglediglichin Silos in Geschäften und Funktionen und sind dannwederübergreifend,nochgranularnachvollziehbar.Verkürzt könnte man also sagen, dass Banken es nichtgeschaffthabenvalideRisikodateninangemessenerZeitsozuaggregieren und auszuwerten, dass Risiken wie dieImmobilienblase, undurchsichtige Finanzprodukte und dieallgemeineMarktlagetatsächlichsteuerbargewesenwären–dieRisikenwurdennichtquantifiziertundstandensomitauchweder im Fokus der Entscheider noch in dem derKontrolleure. Institutionen haben zudem nicht mehr dieMöglichkeit ihre Probleme mit dem Datenmanagement inintensiven und langen Projekten zu verifizieren - auch hierwirdderDrucknachschnellerReaktionszeithöher–nichtnurfür die Befriedigung der Regulatoren, sondern auch beimErfüllenvonAnforderungenfürdasManagement.

Abbildung 2 BCBCS 239 Themenbereiche und Prinzipien(Quelle3)

DieBCBS239imDetailUmdasRisikomanagement,Datenmanagementunderstmaligauchganzkonkretumdie ITderBankengehtes inderBCBS

239, einer Vorgabe der Bank of International Settlements(www.bis.org) und seinem „Basel Commitee on BankingSupervision“.Es werden 14 Grundsätze formuliert, die konkreteEinzelforderungen zu vier Themenbereichen beinhalten. DieGrundsätze regeln ProzesseundDaten zurBankensteuerungundRisikotragfähigkeit.AußerdemimFokusstehtdiead-hocFähigkeitinStresssituationenErgebnisseautomatisiertliefernzu können. Es sollen auch Szenarien undSimulationsrechnungenermöglichtwerden.Beispielhaftsinddies:

• GovernanceundInfrastrukturo Vollständige Dokumentation der

DatenaggregationaufgranularemLevelo Einheitliche Taxonomien und zentrales

Metadatenmanagemento Transparenz zu Lebenszyklus von Daten –

konsistenterBusinessundITView• AggregationvonRisikodaten

o Vollständige Dokumentation dertechnischenundorganisatorischenProzesserundumdieErstellungdesRisikoberichtes.

o Technische und organisatorische Prozesserund umdie Erzeugung des Risikoberichtesmüssendokumentiertsein

• Risikoreportingo Glossar mit Risikobegriffen – Verlinkung in

RisikoreportsDieAnforderungen sind imDetail vielschichtigund komplex,weil eine solche Konsolidierung von Risikokennzahlen aufgranularer Ebene bisher noch nicht im Fokus der BankenstandundaufdieserEbenediverseQuellsystemwieKredite,Liquidität, Marktdaten, Immobilien integriert sein müssen,um dann auch die notwendigen Metadaten für dieNachvollziehbarkeitderaggregiertenRisikodatenanbietenzukönnen. Hinzukommt dass die Zeit zur Umsetzungverhältnismäßigknappbemessenwurde.NachdruckwurdedieserRegelungdadurchverliehen,dassdieGeschäftsleitung selbst für die Umsetzungsverantwortungeingeteiltwordenist.HandlungsbedarfeSomit ergeben sich sehr konkrete Handlungsbedarfe für dieOrganisationunddenAblaufderRisikofunktionenunddieIT-Architekturbzw.dasDatenmanagement:

• AutomatisierungderReportauslieferungundAd-hocAuswertungen

• FlexibleAnpassungenregulatorischerÄnderungen• Integrierte Datenhaltung (Insbesondere Risiko- und

Finanzdaten),einheitlichesDatenmodell• SchnellereBereitstellung(Reporterstellunginnerhalb

von10TagennachStichtag–zuvorwarenes56)• Fokus auf Kreditrisiko, Kontrahentenrisiko,

Handelsrisiken, Marktrisiken, Liquiditätsrisiken undOperationelleRisiken

• EineeinheitlichetechnologischePlattformenundIT-Anwendungen

• Deutliche Reduzierung von Medienbrüchen undIntegrationvonInsellösungen

• Einführung vonmodernen und effektiven SystemenundVerfahrenzurDatenverarbeitungund-analyse

• Verankerung der Gesamtlösung in das Governance-Framework

Es wird seitens der Regulierer von Investitionskosten in derGrößenordnungvondreistelligerMillionenhöheausgegangen– zumindest bei den großen, systemrelevanten Banken (G-SIBs).

Abbildung3BiswannmussBCBS239umgesetztwerden? (Quelle3)

DieRegelungwirdbis2016bereitsfürdiesogenanntenG-SIBsverpflichtendundsomitbereitsinderRealisierung,allerdingsgibtesanschließendnochdieweiterenInstitute,dienationalsystemrelevanteingestuft(D-SIB)undnachundnachbenanntwerden.DieseInstitutehabenfürdieUmsetzung3JahreZeitnach ihrer Benennung; alle anderen Institute haben keinezwingendeBindungandieRegelung, allerdings kommtBCBS239 auch zur Aufnahme in den MaRisk Standard. LetztenEndes bedeutet dies also dass BCBS 239 die Institute nocheinigeZeitbeschäftigenwird,soferndasThemanichtbereitsschonangegangenwurde.SindBankengutvorbereitet?Interessantist indiesemZusammenhangaucheineUmfrage,die msgGillardon im IT-Finanzmagazin veröffentlichte (sieheQuelle4).

Abbildung 4 Integrationsgrad von Finanz-, Risiko- und Treasury-DatengemäßQuelle4

Demnach sind viele deutsche Institute gerade was diegeforderten Bereiche von BCBS 239 angeht nicht gutaufgestellt. 29% der Banken seien ohne Daten- undProzessverantwortlichkeiten, 45% der Banken haben keinedurchgängigeMessung der Datenqualität. Unter Sparkassenhaben 61% noch Nachholbedarf und 20% der InstitutekorrigierenihrezuGrundeliegendenDatennichtregelmäßig.Außerdem schneiden die Institute schlecht bei derGovernance ab,wonur 13%der Befragten unterhalb der 2.Hierarchiestufe Wissen zu Datenqualitätsprozessen hatten.Beim Thema Datenintegration gibt die Studie vomFaktenkontor (Abb. 4) Auskunft darüber, dass Risiko- undFinanzdaten nur in 50% der Institute integriert vorliegen.Weiter wird zitiert, dass Metadatenverwaltung in 27% derFälle existiert und bei 56% der Banken nur unvollständigeMetadatenimDatamartaufweisen.TraditionellerDWHAnsatzinFinanzinstitutenHäufig wird bisher versucht in Ladeprogrammen im DataWarehouseeineKombinationvielerAnliegenineinemSchrittzuerledigen.Somüssen imklassischenDataWarehousedas3NF-Modell erzeugt, Daten bereinigt und die technischeHistorisierung und Harmonisierung berücksichtigt werden.Diedaraus resultierendenETL-MappingswerdenzukomplexundsorgenfürInflexibilitätbeiÄnderungen.DasweitereProblembeidiesemAnsatz ist dieVeränderungderQuelldatenvorAufnahmeindasDataWarehouse,sodassunterUmständendieNachvollziehbarkeitderDatenunddieRückverfolgungindasQuellsystemgarnichtmehrmöglichist.Hinzukommt,dassgeradeDWHsinfinanziellenInstitutionenstarken Änderungen und Schwankungen in denGeschäftsregeln unterliegen. Die Komplexität inBerechnungsmethoden und die Anforderungen in denverschiedenen Geschäftsbereichen machen einenmonolithischen,zentralistischenDWH-Ansatzproblematisch:

• Fokus auf Datenakquisition und Bereinigung derQuelldatenaufdemWegindasDWH

o ETLalsmanuellerAufwandstreibero „Enterprise Data Model“, EDM

(unternehmensweites Datenmodell) mit zugroßem Scope und 3NF-Modellierung,Quellsystem sind häufig fragmentiert undüberlappend, was zu Schwierigkeiten beiderIntegrationnachEDMführt

• AnalytischeProzesseaußerhalbdesDWHo DWH Ersteller und Nutzer driften zu weit

auseinandero DatenflüsseumgehendasDWHo Unternehmensübergreifende Sichten über

mehrereRisikogruppenwirdunmöglich• Data Mart Silos mit Logik, die ins Data Warehouse

gehörtDurch solch eine Situation kommt es bei diesen DWH-Ansätzen häufig zu einem Veränderungsstau nach einigenJahren, weil das Umsetzen neuer Anforderungen durch dielaufend gestiegene Komplexität des ETL immer teurerwerden.Konzepte zurDatenqualitätundMetadatenwerdendanngerneauchunterdemDruckderständigeintreffendenFachbereichsanforderungen immer weiter nach hintenverschoben.

DataVaultArchitekturimEinsatzVor diesem Hintergrund kann es Sinn machen dieanstehenden Aufgaben und Herausforderungen durch BCBS239 ernst zu nehmen und die bestehende DataWarehouseLösungdurcheineneue,moderneArchitekturundMethodikzuergänzenoderersetzen.Zusätzlich zur Data Vault Architektur möchte ich noch dasQuadrantenmodell von Ronald Damhoff (Abb. 5) vorstellen,da es sich hervorragend dazu eignet eine Data VaultArchitektur abseits von Technik zu vermitteln. Es verwendeteineAnalogieausderWirtschaft:DatenaufbereitungimDWHwirdmiteinemLieferprozessverglichen.Unterschiedenwird,obdasProdukt(dieDaten)vomKundenspezifiziertsindoderseitens der IT auf Lager produziert wird. Die horizontaleUnterscheidung spielt für unsere Betrachtung nur einesekundäre Rolle. In Q1 wird also zu möglichst niedrigenStückkostenproduziert,umdieLägerzufüllen.Dasbedeutetwir haben einfache Fertigungsprozesse und einen hohenAutomationsgrad.ImQ2allerdingsbestimmtderKunde(denKontext) und damit wie das Produkt aussehen soll. ImErgebnis bedeutet dies also einen manuellen

DMStrategie„DataQuadrantenModell“vonRonaldDamhof

Quadrant1:„SingleVersionofFacts“,automatisierteBereitstellung„Simple/Order“Quadrant2:Kontextinformation,„Complicated/Order“Quadrant4:„Complex/Un-order“Quadrant3:ChaosQuadrant2undQuadrant4:„MultipleVersionsoftheTruth“http://prudenza.typepad.com/dwh/2015/05/data-quadrant-model-decreasing-entropy.html

Abbildung5DataDeploymentQuadrantvonRonaldDamhoffgemäßQuelle2

Fertigungsprozess zu höheren Stückkosten, aber dafür mitindividuellangepasstenProdukten.ImQ1sindunsereStandardproduktedienachübergreifendenBusiness Keys integrierten Quelldaten, die gemäß der DataVault Modellierung und den zugehörigen Lademustern vollautomatisiertundhistorisiertgeladenwerdenkönnen.ImQ2allerdings gibt es unterschiedlicheAbnehmer und Szenarien,die dafür sorgen dass wir Kontext vom Kundenberücksichtigen und Geschäftsregeln implementierenmüssen, um die Daten so anzupassen, wie der Kunde dieseauchverwertenmöchte.

Abbildung 6 Datenmodellierung und Datenfluss im DataVaultDWH

Dies beschreibt dann auch schon sehr gut das Prinzip des„SeparationofConcerns“beiderDatenaufbereitung imDataWarehouse. Die Ladeprozesse im Raw Vault sind so trivial,dasssieanhandderphysischenDatenmodellevonStageundRawDataVault undeinemeinfachen1:1Mapping generiertwerdenkönnen,ohnedasshiermanuelleProgrammierungzutätigen ist – dank der Lademuster zu Hub, Link und Satellit.AußerdemsinddieDatenbereitsnachder technischenSichtdes Data Warehouse historisiert, so dass häufig fürAnforderungen ohne weitere Timelines in späterenLadeprozessennichtsmehrhinzugefügtwerdenmuss.Der zweite, wichtige Aspekt dieser Vorgehensweise im RawVault ist die vollständige Nachvollziehbarkeit der Datenzurück in die Quelle, weil alle Attribute 1:1 abgebildet sindundgranulareDatengeladenwerden.IndiesemerstenSchrittwerdenabernichtnurQuelltabellenkopiert,sondernesfindetaucheineIntegrationnachBusinessKeys statt. Hierüber wird gewährleistet, dass sichwiederholende Entitäten der Quellsysteme im DataWarehouse in identische Strukturen geladen werden(IntegrationüberdieHubs).Somit folgt der Data Vault auch einem logischen oderkonzeptionellen Unternehmensmodell, bleibt dabei aberaufgrund der physischen Trennung von fachspezifischenAttributenundRelationenflexibleralsdie3NF-Modellierung.Diese flexiblere Ausgestaltung der Tabellenstrukturenermöglicht dabei auch die iterative – also dieanforderungsgetriebene Vorgehensweise. Analyseprozesse,die bereits auf bestehende Tabellenstrukturen zugreifenwerden für neue Anforderungen nicht in Mitleidenschaftgezogen, da neue oder geänderte fachliche Relationen undAttributekeineVeränderungenmehr inderTabellenstrukturder Datenbank nach sich ziehen. (Non-Destructive DataModel). Somit sollte auch das Problem von komplexen,

überlappenden Quellsystemen in den Griff zu bekommensein.Zusätzlich soll hier auch noch erwähnt werden, dass einigeDatenmodellierungswerkzeuge das Mapping vonDatenelementenbeherrschen,sodassindenSituationen,woDatenmodelle transformiert werden tatsächlich anhand derMetadaten vom Modellierungswerkzeug Ladeprozessegeneriert werden können, ohne die Notwendigkeit dasModellierungswerkzeugzuverlassen(sieheAbb.5).Im nächsten Schritt werden im Business Vault ebenfallswieder Datenelemente per Mapping umgeschrieben –diesmal von DataVault nach DataVault – aber unterAnwendung von Geschäftsregeln. Hier werden dann dietatsächlichen Berechnungen ausgeführt, die zumRisikomanagement gehören und manuellen Aufwand ineinem ETL-Werkzeug verlangen. Die komplexen fachlichenRegeln der Anwender werden hier in den unterschiedlichenSichten implementiert und bedeuten Datenaufbereitung,Zeitsichten, BI-temporale Sichten, Point-In-Time und BridgeTabellen für dimensionale Sichten und vieles mehr. Hierkonzentriert sich die fachliche Arbeit der Beteiligten.Entsprechend sind wir dann auf die Möglichkeiten des ETL-Werkzeuges oder des zugehörigen Metadatenservers zurNachvollziehbarkeitderDatenangewiesen.Der letzteSchritt istdannwiedereineModelltransformationvom Data Vault Modell des Business Vault in eindimensionales Modell oder andere Berichtsstrukturen, aufdenendasBIFrontendaufsetzt.Wenn man sich diesen Prozess anhand der Grafik und derDatenmodellierung vorstellt, wird denke ich klar, dass aucheineAnnäherungvonFachbereichenundIT-Personalerreichtwerden kann. Die Quellsystemintegration rückt durch dieAutomatisierungkomplett indenHintergrundundandessenStellerückendieDatenmodellierungunddieGeschäftsregeln.Als gemeinsame Kommunikationsgrundlage sollte diekonzeptionelleoderlogischeEbenedesDatenmodellsdienen.Gleichermaßen steuert auch die Automatisierung zurKommunikationsförderung bei. Denn durch die schnelleBereitstellung der Daten können Feedbackschleifen mitFachanwendern sehr schnell erfolgen. Hierzu können zumBeispielauchsogenanntevirtualisierteMartserstelltwerden,die ein Star Schema mit SQL-Views abbilden. DiesetemporärenSichtendienendannalsGrundlagefürGesprächebei denen man bereits konkrete Fälle basierend aufintegrierten Daten durchspielen kann, anstatt auf dasVorstellungsvermögen der Beteiligten alleine angewiesen zusein.MetadatenundDatenqualitätUm nun die vollständige Dokumentation zu erreichen, diegemäß BCBS 239 gefordert ist, bedarf es mehr als derDatenmodelle und derGeschäftsregeln in ETLMappings desBusiness Vaults. Einige Metadatenserver auf dem MarktkönnendieBIFrontendmodelle,Datenmodelle,Glossaryundandere fachliche Beschreibungen importieren. Anschließendlassen sich Verbindungen zwischen diesen Elementenherstellen und somit fachliche und technische Metadatengemeinsam darstellen. Das bedeutet dann manuellenAufwand, kann aber ausreichen, um die Anforderungen vonBCBS 239 zu erfüllen. Hier stellt sich dannwieder die FragenachderGovernanceunddenentsprechendenprozessualenVorgabenzurUmsetzungdieserMaßnahmen.

Durch die „Single Version of Facts“ im Raw Vault könnenDatenprobleme der Quellsysteme nachvollzogen undüberprüft werden. Die Entscheidung im Data WarehousezunächstalleDatenohneHarmonisierungoderBereinigungenzu laden ermöglicht die GAP-Analyse. Hier kann auch einehistorischeEntwicklungderDatenqualitätdargestelltwerden,weilimRawVaulthistorisiertwird.Diessetztnatürlichimmervoraus, dass die Datenqualitätsprobleme in denQuellsystemen auch behoben worden sind und nicht nurentsprechendeGeschäftsregelnimDWHimplementiertsind.DieklareEmpfehlungkanndahernur seindieKorrekturvonDatenqualitätsproblemen und auch die Erzeugung vonStammdaten – also MDM – außerhalb des DWH zurealisieren. Der Raw Vault ist als historisierte „System ofRecord“ der Quellsysteme als Quelle für diese Art vonVorhaben geeignet – nicht aber als Ziel. Im Idealfallwerdenkorrigierte Quelldaten aus dem MDM oder direkt aus derQuelle zurück in das DWH geladen, was dann auch dieGrundlage für die zuvor erwähnte Darstellung der(hoffentlich)positivenEntwicklungderDatenqualitätist.FazitZum Schluss kann man sagen, dass vor allem dieAutomatisierung und die anforderungsgetriebeneAusrichtung von Data Vault die Einstiegsbarrieren für dieseMethodik recht niedrig aufhängen. Schließlich ist es sogarempfohlen klein zu starten und dann iterativ vor zu gehen.Auch eine parallele und schrittweise Einführung zumbestehendenSystemistmöglich.Natürlich gibt es auch eine Anfangsinvestition für dieAusbildung, Etablierung der Methoden in der Infrastrukturund eventuell auch neue Werkzeuge. ErfahrungsgemäßkönnendurchdenEinsatzvonAutomatisierungimDataVaultUmfeld die Entwicklungsaufwände der ETL-Strecken imCoreWarehouse auf 1/4 sinken – verglichen mit der manuellenErstellungdergleichenMappingsimWerkzeug.DakannmanvoneinerschnellenAmortisationausgehen.Angesichts der weiteren Regulierungsrunden, die nocherwartet werden, ist es nicht zuletzt auch eine sinnvolleInvestition die Anpassungsfähigkeit des Data Warehouse zuerhöhen und somit die Kosten dauerhaft zu senken, daserreichtmansicherdurchdieses,agileVorgehen.

In Bezug auf die Anforderungen für BCBS 239 erfüllt DataVault die Anforderungen zur Integration der Daten mittelseines einheitlichen Datenmodells und auch die ForderungenzurNachvollziehbarkeitderZahlenindenQuellsystemen.DieDatenqualität kann imRawVault gemessenwerdenundentsprechendeineGAP-Analysedurchgeführtwerden.BeidenAnforderungenzurDataLineageundMetadatenhilftDataVaultdurchdieFokussierungaufdieDatenmodellierung,diemaßgeblichwirdfürdieErstellungvonBeladungsstreckenund somit auch zu einer Standardisierung in diesemBereichführt. Es gibt am Markt eine gute Unterstützung für dieseWerkzeuge.Die Anforderung zur Performance ist kaum zu bewerten.AufgrundderVereinfachungundAufteilungderProzesskette(RawVaultundBusinessVault)undderTatsachedassnurdieGeschäftsregeln und nicht die Basisdaten neu berechnetwerden müssen, ist aber alleine dadurch von einerPerformanceverbesserungauszugehen.Ein wesentlicher Erfolgsfaktor ist aus meiner Sicht dieFörderung der Kommunikation zwischen den Beteiligten,denn Projekterfahrung zeigt doch immer wieder dass dieMenschendasWichtigsteimProjektsind.DieKommunikationkann mittels des Quadrantenmodells auch über die reinenDataVault Interessentenhinausbis insManagementgenutztwerden. Die (Re-)Fokussierung aller Beteiligten auf fachlicheInhalte und die Geschäftsregeln wird sich mehrfachauszahlen.Literatur(1) Linstedt D., Olschimke M. „Building a Scalable DataWarehouseWithDataVault2.0“(2) Damhoff R., Data Quadrant Model,http://prudenza.typepad.com/dwh/2015/05/data-quadrant-model-decreasing-entropy.html(3) Bachinger S., Arnsberg T., TME-AG „WhitepaperModernisierung der Risikosteuerung in Banken“,http://www.tme-ag.de/fileadmin/customer/documents/Whitepaper_-_Modernisierung_der_Risikosteuerung_in_Banken.pdf(4)PrellwithC.,NicklasM.,msGiilardon,„BCBS239machteffizient,transparent&krisenfest“http://www.it-finanzmagazin.de/bcbs-239-macht-effizient-transparent-krisenfest-9566/

TorstenGlunde istMitgründerundCEOderAlligatorCompanyGmbHinBremenundalsBusinessIntelligenceBeraterseitüber20JahrenimProjektgeschäfttätig.E-Mail:t.glunde@alligator-company.de