Bank- und Risikoanalytics
Stand 2026-09-03
Banking ist die regulierungsdichteste SAP-Branche und der größte EMEA-Nachfragepool (22 %). Vier Risikodomänen mit unterschiedlichen Latenz-/Granularitäts-/Audit-Profilen: Kredit (IFRS 9 ECL 3-stufig, AnaCredit), Markt (VaR, FRTB), Liquidität (LCR/NSFR — die einzige near-real-time), operationell. BCBS-239-Lineage ist das Governance-Rückgrat — jede Risiko-KPI muss durchgängig von S/4HANA-Nebenbuch → Datasphere → SAC nachvollziehbar sein, sonst ist es ein aufsichtsrechtlicher Befund. RWA/CET1-Kapital + parametrisierte Stresstests sind das eigentliche Ergebnis. Das Premium geht an regulierungskompetente Architekten, nicht an reine Umsetzungsberater.
Was Sie lernen
- Kredit-, Markt-, Liquiditäts- und operationelles Risiko als vier separate Datenformen modellieren — nicht als einen verschmolzenen Risk Mart
- BCBS-239-Lineage von Tag eins an in die Datasphere-Datenprodukte einbauen, von der Quelle bis zum SAC-Dashboard
- Entscheiden, wann AnaCredit-/FRTB-Daten repliziert versus föderiert werden, und wann Liquiditätsreporting near-real-time sein muss
- Ein parametrisiertes, wiederholt lauffähiges Stresstest-Modell und eine abgestimmte RWA-/CET1-Zahl unter Regulatorprüfung verteidigen
Modulüberblick
Banking-Analytics ist die regulierungsdichteste Branche im SAP-Umfeld und der größte Nachfragepool — Banking & Insurance ist mit 22 % der größte Anteil an der EMEA-SAP-Analytics-Nachfrage. Ein Berater, der die regulatorische Sprache fließend spricht — nicht nur Dashboards baut —, erzielt die stärkste Tagessatzprämie im Feld.
Vier Risikodomänen, vier Datenformen. (1) Kreditrisiko — Ausfallwahrscheinlichkeit, Exposure at Default, Loss Given Default; das IFRS-9-Expected-Credit-Loss-(ECL)-Modell mit seiner dreistufigen Staging-Logik; granulares Kredit-für-Kredit-Reporting an die EZB via AnaCredit. (2) Marktrisiko — Value-at-Risk, Sensitivitäten, das FRTB-(Fundamental Review of the Trading Book)-Kapitalframework. (3) Liquiditätsrisiko — LCR (Liquidity Coverage Ratio), NSFR, untertägige Liquidität — die einzige Domäne, die tatsächlich Near-Real-Time braucht, nicht Batch. (4) Operationelles Risiko — Verlustereignisdaten, Szenarioanalyse. Jede Domäne hat ein anderes Latenz-, Granularitäts- und Auditprofil; sie als einen einzigen „Risk Mart“ zu behandeln, ist der klassische Anfängerfehler.
Voraussetzungen
- Fortgeschrittene praktische Erfahrung mit SAP-Analytics-Projekten
- Zunächst die Kernkonzepte wiederholen: C087, C083, C046
Lernergebnisse
- Ein realistisches Szenario durcharbeiten: europäische Mid-Tier-Bank, S/4HANA-Nebenbuch für Finanzprodukte, IFRS-9- + AnaCredit- + LCR-Berichtspflichten, Regulator fordert BCBS-239-Lineage-Nachweise.
- Das Anti-Pattern erkennen und vermeiden: ein verschmolzener 'Risk Mart' für alle vier Domänen — falsche Latenz/Granularität pro Domäne; Audit-Albtraum.
- Die Kernentscheidung des Moduls anwenden: Struktur des Risk Mart — separate Marts pro Risikodomäne wählen (unterschiedliche Formen), nicht ein 'Risk Mart', der Kredit/Markt/Liquidität verschmilzt.
- Die Beherrschung mit der Kennzahl verfolgen: Abdeckung der Risiko-KPI-Lineage (Ziel: 100 % Rückverfolgbarkeit zur Quelle (BCBS 239); Warnsignal: jede Vorstands-/Regulator-KPI ohne rückverfolgbare Quelle).
Vollständiges Modul für Mitglieder. Das vollständige Modul ergänzt: den Entscheidungsrahmen · das durchgehende Szenario · die KPI-Scorecard · die Anti-Muster · die Codeblöcke · die Wissenskontrolle · die Schemata.