Zweck

Das Portal unterstützt tägliche Arbeitsabläufe für Bewertung, Risiko und Validierung. Anwender können Portfolios auswählen, Marktdaten prüfen, Simulationen starten, Ergebnisse analysieren und Validierungsevidenzen lesen, ohne die aktuelle Fachansicht zu verlassen.

Typischer Arbeitsablauf

• Wählen Sie den passenden Bereich in der linken Navigation.
• Setzen Sie Portfolio, Bewertungsdatum und Berechnungstyp.
• Verwenden Sie Filter, bevor Sie einen Lauf starten oder Ergebnisse prüfen.
• Öffnen Sie Details, um Aggregate, Positionsergebnisse und Fehler zu analysieren.
• Verwenden Sie diese Hilfe, wenn Felder, Statuswerte oder Ergebnisse unklar sind.

Wichtige Felder

Feld	Bedeutung
Bewertungsdatum	Geschäftstag für Positionen, Kurven, Quotes und Fixings.
Portfolio	Ausgewählte Positionsmenge oder Hierarchieebene.
Laufstatus	Aktueller Verarbeitungszustand einer Simulation oder Validierung.
Ergebnislevel	Aggregationsebene, zum Beispiel Portfolio, Desk, Book oder Position.
Filter	Kriterien zur Einschränkung von Tabellen und Diagrammen.

Ergebnisinterpretation

Beginnen Sie mit den Summary Cards und öffnen Sie danach Tabellen oder Detailansichten. Ein Ergebnis kann vollständig sein, obwohl Warnungen angezeigt werden. Warnungen bedeuten meist, dass die Berechnung abgeschlossen wurde, aber Daten-, Modell- oder Validierungseinschränkungen geprüft werden sollten.

Häufige Probleme

Problem	Bedeutung	Mögliche Aktion
Leere Tabelle	Kein Ergebnis passt zu den aktuellen Filtern oder zur Ebene.	Filter zurücksetzen und Bewertungsdatum sowie Portfolio prüfen.
Fehlende Details	Für den gewählten Lauf gibt es keine Detaildaten in dieser Ansicht.	Prüfen, ob der Lauftyp die gewünschte Detailtiefe unterstützt.
Unerwartete Sprache	Die Sprache wurde in einer Komponente noch nicht aktualisiert.	Sprache erneut wechseln oder Seite neu laden.

Empfohlene Praxis

Halten Sie das Bewertungsdatum sichtbar, während Sie Ergebnisse prüfen. Beim Vergleich von Läufen sollten Portfolio, Marktdatenset und Aggregationsebene identisch sein.

Zweck

Konfigurationseditoren sind die Stammdatenmasken für Instrumente, Marktdatenobjekte, Mappings, Schedules und Profile. Sie folgen demselben Aufbau: unten eine pageable Grid-Tabelle und nach Auswahl einer Zeile ein Detaileditor darüber.

Arbeit mit dem Grid

Mit + legen Sie einen neuen Datensatz an. Das Zeilenmenü öffnet Editieren, Löschen und Favoriten. Spaltenfilter werden serverseitig angewendet, sofern die Ziel-API das Feld unterstützt.

Die Spalte State zeigt, ob ein Datensatz unverändert, neu, geändert oder gelöscht ist. Save schreibt offene Änderungen über den Zielservice. Cancel verwirft ungespeicherte Änderungen am ausgewählten Objekt.

Detaileditor

Der Detailbereich enthält Tabs für das ausgewählte Objekt. Der Haupttab enthält meist direkte Felder; weitere Tabs zeigen Child-Collections oder Mappings. Child-Zeilen gehören zum ausgewählten Aggregate und werden, sofern vom Service unterstützt, gemeinsam mit dem Parent gespeichert.

Deep Links

Einige Editoren unterstützen den Query-Parameter id. Eine URL wie ...?id=<guid> öffnet den passenden Datensatz direkt nach dem Laden der Daten. Das ist hilfreich für Links aus verwandten Entitäten, Audit Views und Supportnotizen.

Praktische Prüfungen

Vor dem Speichern sollten Name, fachlicher Typ, Aktivstatus und Mappings geprüft werden. Änderungen an gemeinsam genutzten Objekten können viele Bewertungen, Simulationen und Reports beeinflussen.

Zweck

Die globale Konfiguration enthält anwendungsweite Einstellungen, die von Services zur Laufzeit gelesen werden. Änderungen sollten wie Produktionskonfiguration behandelt werden: Speichern Sie nur geprüfte Werte und laden Sie betroffene Workflows neu, wenn das Verhalten sofort geändert werden muss.

Globale Einstellungen

Verwenden Sie Global Settings für gemeinsame Defaults wie Geschäftskalender und Berichtswährung. Der Kalender steuert Datumslogik für Workflows mit gemeinsamer Business-Day-Konvention. Die Berichtswährung ist die Standardanzeige- oder Aggregationswährung, wenn keine spezifischere Einstellung vorhanden ist.

Notifications

Verwenden Sie Notifications, um ausgehende Workflow-Nachrichten zu steuern. Das oberste Aktivierungsflag schaltet die Benachrichtigungsfunktion insgesamt, das Email-Flag steuert die E-Mail-Zustellung.

E-Mails können über SMTP oder Azure Communication Services versendet werden. SMTP verwendet Host, Port, SSL, Benutzername, verschlüsseltes Passwort, Sender und Standardempfänger. Azure Communication Services verwendet eine verschlüsselte Connection String und Senderadresse.

Default Recipient Groups werden verwendet, wenn ein Ereignis keine spezifischere Zuordnung hat. Recipient Groups ordnen einen Gruppennamen einer oder mehreren E-Mail-Adressen zu. Event Groups routen Workflow-Ereignisse nach Event Type, Workflow Type, Workflow Name und Model auf eine oder mehrere Recipient Groups.

Speichern

Save schreibt den ausgewählten Abschnitt in den globalen Konfigurationsspeicher. Reload verwirft lokale Änderungen und liest die persistierte Konfiguration erneut.

Zweck

Simulationen berechnen Bewertungen, Sensitivitäten, Cashflows, VaR oder Szenarioergebnisse für ausgewählte Positionen. Das Portal unterstützt das Starten, Überwachen und Prüfen erfolgreicher oder fehlgeschlagener Elemente.

Typischer Arbeitsablauf

• Wählen Sie ein Portfolio oder eine Hierarchieebene.
• Setzen Sie das Bewertungsdatum.
• Wählen Sie die Berechnung oder das Szenariopaket.
• Starten Sie den Lauf und beobachten Sie den Status.
• Prüfen Sie zuerst Aggregate und danach fehlgeschlagene Positionen oder Batches.

Wichtige Felder

Feld	Bedeutung
Portfolio	Positionsmenge, die in den Lauf einbezogen wird.
Bewertungsdatum	Datum für Marktdaten, Fixings und Positionsgültigkeit.
Marktdaten	Kurven, Quotes, FX-Kurse, Volatilitäten und Fixings.
Szenario	Schock, historisches Szenario oder Modellscenario der Berechnung.
Run ID	Eindeutige Kennung des Laufs, hilfreich bei Rückfragen.

Ergebnisinterpretation

Statuswerte zeigen den Verarbeitungsfortschritt:

Status	Bedeutung
Created	Der Lauf wurde angenommen, aber noch nicht verarbeitet.
Running	Worker oder Services verarbeiten den Lauf.
Completed	Die Verarbeitung ist beendet. Warnungen und fehlgeschlagene Instrumente sollten geprüft werden.
Failed	Ein kritischer Fehler hat den Lauf oder einen erforderlichen Batch gestoppt.

Häufige Probleme

Problem	Bedeutung	Mögliche Aktion
Missing Market Data	Benötigte Quotes, Kurven, Volatilitäten oder Fixings fehlen.	Marktdaten für Bewertungsdatum und Instrumenttyp prüfen.
No Positions Found	Portfolio und Datum liefern keine gültigen Positionen.	Portfoliozuordnung und Positionsgültigkeit prüfen.
Pricing Failed	Mindestens ein Instrument konnte nicht bewertet werden.	Fehlgeschlagene Instrumente öffnen und Modell, Marktdaten sowie Stammdaten prüfen.

Empfohlene Praxis

Bewerten Sie Aggregate erst, wenn Ebene und Filter klar sind. Bei fehlgeschlagenen Läufen sollten Run ID und Instrumentkennungen für die Analyse sichtbar bleiben.

Zweck

Portfolioansichten helfen bei der Auswahl der Positionen für Bewertung, Risiko und Reporting. Ein Portfolio kann eine rechtliche Einheit, einen Desk, ein Book oder eine fachliche Positionsmenge abbilden.

Typischer Arbeitsablauf

• Wählen Sie das Bewertungsdatum.
• Setzen Sie Portfolio-, Desk-, Book- oder Positionsfilter.
• Prüfen Sie Positionsanzahl und Instrumenttypen.
• Öffnen Sie Positionsdetails vor großen Berechnungsläufen.
• Vergleichen Sie die gewählte Hierarchie mit dem gewünschten Reporting-Scope.

Wichtige Felder

Feld	Bedeutung
Portfolio	Oberste Gruppierung der Positionen.
Desk	Fachlicher Eigentümer oder Risikomanagement-Desk.
Book	Handels- oder Accounting-Book.
Position ID	Eindeutige Positionsreferenz für Detailergebnisse.
Instrumenttyp	Produktklassifikation für Modellwahl und Validierung.

Ergebnisinterpretation

Positionszahlen müssen immer zusammen mit den aktiven Filtern betrachtet werden. Eine niedrige Anzahl ist nicht automatisch falsch, wenn Desk-, Book- oder Instrumentfilter aktiv sind. Prüfen Sie die Instrumenttyp-Verteilung, wenn unerwartete Modell- oder Marktdatenfehler auftreten.

Häufige Probleme

Problem	Bedeutung	Mögliche Aktion
Leeres Portfolio	Keine aktive Position passt zu Datum und Filtern.	Datum, Hierarchie und Positionsstatus prüfen.
Fehlender Instrumenttyp	Stammdaten sind unvollständig oder nicht gemappt.	Positionsdetail und Data-Quality-Hinweise prüfen.
Unerwartete Aggregation	Ergebnisse werden auf einer anderen Hierarchieebene angezeigt.	Dashboard-Ebene auf Portfolio, Desk, Book oder Position setzen.

Empfohlene Praxis

Prüfen Sie vor großen Simulationen, ob das Portfolio die erwarteten Books und Instrumenttypen enthält. So vermeiden Sie, leere oder teilweise Ergebnisse als Berechnungsfehler zu interpretieren.

Zweck

Marktdatenansichten zeigen, ob Bewertungsinputs für das gewählte Bewertungsdatum vollständig und plausibel sind. Fehlende oder inkonsistente Marktdaten gehören zu den häufigsten Ursachen für fehlerhafte oder unzuverlässige Ergebnisse.

Typischer Arbeitsablauf

• Wählen Sie das Bewertungsdatum.
• Prüfen Sie Kurven, FX-Kurse, Volatilitätsflächen und Fixings.
• Vergleichen Sie die Datenvollständigkeit mit den Instrumenten im Portfolio.
• Klären Sie fehlende, veraltete oder unplausible Quotes vor einem erneuten Lauf.

Wichtige Felder

Feld	Bedeutung
Kurve	Discount-, Projection-, Spread- oder Inflationskurve für Bewertungsmodelle.
FX-Kurs	Umrechnungskurs für Ergebnisse in Reporting-Währung.
Volatilität	Optionsinput, meist nach Laufzeit, Tenor, Strike oder Moneyness.
Fixing	Historische Indexbeobachtung für Coupons oder inflationsgebundene Auszahlungen.
Datendatum	Datum, für das die Marktdatenbeobachtung gültig ist.

Ergebnisinterpretation

Ein Kurvenname allein reicht nicht aus. Die Kurve muss die benötigten Stützstellen, Daten und Konventionen für das Instrument enthalten. Bei Optionen und Inflationsprodukten sollten relevante Volatilitäten oder Indexfixings für das Beobachtungsdatum geprüft werden.

Häufige Probleme

Problem	Bedeutung	Mögliche Aktion
Fehlende Kurve	Das Instrument kann eine benötigte Kurve nicht auflösen.	Kurvenmapping sowie Währungs- und Indexkonventionen prüfen.
Fehlendes Fixing	Coupon oder Indexzahlung benötigt eine fehlende historische Beobachtung.	Fixing-Kalender und Beobachtungsverzug prüfen.
Ungültige Volatilität	Eine Volatilität fehlt, ist negativ oder verletzt Konventionen.	Volatilitätsfläche und Produktkonvention prüfen.
Veralteter Quote	Der verfügbare Quote ist älter als erwartet.	Klären, ob stale Daten für den Lauf zulässig sind.

Empfohlene Praxis

Wenn ein Ergebnis auffällig wirkt, vergleichen Sie zuerst die Instrumentanforderungen mit den verfügbaren Marktdaten. Das ist besonders wichtig für Inflation, Volatilität und Cross-Currency-Produkte.

Zweck

Die Quoting-Konfiguration steuert, wie externe und interne Preise bezogen, normalisiert, verteilt und mit Verbrauchern verknüpft werden. Dazu gehören Price Sources, Proxies, Quote Links, Distributors und Price-Finding Rule Sets.

Wichtige Objekte

Objekt	Verwendung
Price Source	Herkunft eines Quotes oder Price Feeds.
Proxy	Fallback- oder Ableitungslogik, wenn direkte Quotes fehlen.
Quote Link	Verbindung von Preisen zu Instrumenten, Kurven oder Verbrauchern.
Distributor	Ziel, an das Preise oder Quotes publiziert werden.
Price Finding Rule Set	Geordnete Matching-Regeln für Quote-Auswahl.

Operatives Verhalten

Die Reihenfolge von Regeln ist wichtig. Die erste passende Regel kann entscheiden, welcher Preis verwendet wird. Breite Fallback-Regeln sollten daher nach spezifischen Regeln stehen. Proxies müssen so nachvollziehbar sein, dass Support und Fachbereich erklären können, warum ein Quote verwendet wurde.

Data-Quality-Prüfungen

Prüfen Sie Quote-Identifier, Instrument-Symbole, Währungen und Gültigkeitsfenster gegen das Zielobjekt. Veraltete oder mehrdeutige Quote Links können plausibel wirkende, aber falsche Bewertungen erzeugen.

Zweck

Analytics-Konfiguration definiert Datenquellen, Data-Quality-Profile und AI-Profile für Dashboards, Reports, Erklärungen und automatisierte Kontrollen.

Datenquellen

Datenquellen bündeln KPIs, Aggregationsdefinitionen und Result-Set-Referenzen. Namen und Provider-Metadaten sollten stabil sein, weil Dashboards und Reports darauf aufbauen.

Data-Quality-Profile

Data-Quality-Profile definieren Checks, Toleranzen und Ausnahmebehandlung. Profilnamen sollten dem kontrollierten Prozess entsprechen, zum Beispiel Marktdatenvollständigkeit, Bewertungsbereitschaft oder Reportfreigabe.

AI-Konfiguration

AI Provider beschreiben den technischen Zugriff auf Modellanbieter. AI Profile definieren fachliche Rolle und Leitplanken für generierte Insights. AI Directions steuern Stil, Fokus und Einsatzzweck der generierten Kommentare.

Governance

Behandeln Sie diese Datensätze als Produktionskontrollen. Kleine Änderungen können Reportinterpretation, Exception Routing oder generierte Management-Kommentare verändern.

Zweck

Das Validation Dashboard zeigt, ob Modelle, Instrumente oder Methoden für einen definierten Scope bereit sind. Es bündelt Status, Toleranzen, Evidenzreferenzen und bekannte Einschränkungen.

Typischer Arbeitsablauf

• Öffnen Sie das Dashboard, das zur Fragestellung passt.
• Prüfen Sie Summary Cards für Passed, Warning, Failed und Unknown.
• Öffnen Sie Matrixzeilen oder Zellen mit Amber, Red oder Unknown.
• Lesen Sie Evidenz, Toleranz und Einschränkungen in der Detailansicht.
• Folgen Sie Data-Quality-Links, wenn Inputdaten ein fehlendes, instabiles oder fehlgeschlagenes Ergebnis erklären könnten.
• Nutzen Sie Report-Abschnitte für die fachliche Zusammenfassung.

Wichtige Felder

Feld	Bedeutung
Validation Run	Generiertes Evidenzpaket zu einem bestimmten Zeitpunkt.
Status	Green, Amber, Red oder Unknown als Readiness-Signal.
Toleranz	Zulässige numerische Abweichung zwischen Erwartung und Ergebnis.
Evidenzreferenz	Link oder Dateireferenz auf generierte Detailnachweise.
DQ-Referenz	Link auf Data-Quality-Prüfungen oder Findings, die mit dem Validierungseintrag verbunden sind.
Einschränkung	Bekannte Begrenzung bei Interpretation oder Nutzung.

Ergebnisinterpretation

Green bedeutet, dass die dokumentierten Prüfungen für den genannten Scope bestanden wurden. Amber steht meist für teilweise, toy-only oder eingeschränkte Evidenz. Red zeigt eine fehlgeschlagene kritische Prüfung. Unknown bedeutet, dass keine ausführbare Evidenz vorhanden ist oder der Eintrag nur inventarisiert wurde.

Data Quality kann zusätzlich Accepted zeigen, wenn ein Finding durch eine aktive Exception Rule abgedeckt ist. Accepted DQ Findings sind dokumentierte Ausnahmen, keine sauberen Passes. Behandeln Sie sie als Teil der Limitation-Prüfung bei der Interpretation von Model- oder Instrument-Readiness.

Wenn mehrere Exception Rules auf dasselbe DQ Finding passen, wird die Regel mit der niedrigsten Priority-Zahl angewendet. Die angewendete Regel ist im DQ-Result-Metadata-Feld AcceptedByExceptionRule sichtbar, inklusive Owner, Reason und Gültigkeitsdaten.

Data-Quality-Links

Instrument Validation und Model Validation können Links auf zugehörige Data-Quality-Evidenz anzeigen. Diese Links helfen zu unterscheiden, ob ein auffälliges Validierungsergebnis durch die Berechnungsmethode selbst oder durch fehlende, veraltete, inkonsistente oder unvollständige Inputdaten verursacht wurde.

Veröffentlichte Evidenz

Validierungsevidenz wird als kompaktes Evidenzpaket veröffentlicht, damit das Dashboard große Instrumenten- und Modellpacks effizient laden kann. Das Dashboard zeigt den zuletzt veröffentlichten Run je Pack und behält eine Version für Vergleichszwecke. Ältere generierte Versionen können aus dem Help-/Demo-Evidenzspeicher entfernt werden und sind kein dauerhaftes Archiv.

Nutzen Sie den DQ-Link, wenn:

• eine Validierungszelle Amber, Red oder Unknown ist;
• ein Ergebnis fehlt, obwohl Instrument oder Modell vorhanden sind;
• ein Ergebnis nach Markt- oder Portfoliodatenänderungen unerwartet abweicht;
• die Evidenz fehlende Quotes, fehlende Curve Mappings, stale Data, ungültige Stammdaten oder unvollständige Szenarioinputs erwähnt.

Der Link ist kontextabhängig:

Bereich	Was der DQ-Link typischerweise prüft
Instrument Validation	Instrumentstammdaten, Marktdaten-Mappings, erforderliche Quotes, capability-spezifische Inputs und bekannte Produkteinschränkungen.
Model Validation	Inputs des Modellpacks, Szenariovektoren, Benchmark-Datasets, modellspezifische Annahmen und packbezogene DQ-Prüfungen.

Data-Quality-Evidenz ersetzt keine Modell- oder Instrumentenvalidierung. Sie erklärt, ob der Inputzustand zuverlässig genug ist, um die Validierungsevidenz zu interpretieren. Ein Modell kann methodisch korrekt sein und dennoch Amber oder Red sein, wenn die Validierungsinputdaten unvollständig sind.

Analyseablauf

Wenn ein Validierungsergebnis auffällig ist, prüfen Sie in dieser Reihenfolge:

• Status und Limitation lesen.
• Evidenzreferenz öffnen und Expected, Actual und Toleranz vergleichen.
• DQ-Referenz öffnen und zuerst Critical Findings prüfen.
• Datenprobleme von Berechnungsproblemen trennen.
• Validierung erst erneut laufen lassen oder neu veröffentlichen, nachdem die Daten- oder Modellursache korrigiert wurde.

Hilfreiche Interpretation:

Beobachtung	Wahrscheinliche Bedeutung	Nächster Schritt
Red Validation und Critical DQ Finding	Das Ergebnis kann durch ungültige oder fehlende Inputdaten verursacht sein.	Zuerst DQ-Problem beheben, danach Validierung neu erzeugen.
Red Validation ohne DQ Finding	Berechnung, Benchmark, Toleranz oder Modelllogik muss geprüft werden.	Evidenz und Modellannahmen prüfen.
Amber Validation und Warning DQ Finding	Ergebnis kann nur unter dokumentierten Einschränkungen nutzbar sein.	Limitationen vor Nutzung lesen.
Green Validation und Accepted DQ Finding	Berechnungsevidenz hat bestanden, aber eine Input-Quality-Exception wurde angewendet.	Owner, Reason und Gültigkeitszeitraum prüfen, bevor das Ergebnis genutzt wird.
Unknown Validation und fehlende DQ-Evidenz	Modell oder Instrument kann für diesen Scope nur inventarisiert sein.	Als nicht validiert behandeln, bis Evidenz existiert.

Häufige Probleme

Problem	Bedeutung	Mögliche Aktion
Warning-Status	Evidenz ist vorhanden, aber eingeschränkt.	Details öffnen und Einschränkung vor Nutzung lesen.
Fehlgeschlagene Validierung	Erwartung und Ergebnis liegen außerhalb der Toleranz oder eine kritische Prüfung ist fehlgeschlagen.	Evidenz prüfen und erst nach Daten- oder Modellkorrektur erneut laufen lassen.
Fehlende Evidenz	Das Evidenzpaket enthält keinen Nachweis für den Eintrag.	Eintrag für den aktuellen Scope als nicht validiert behandeln.
DQ-Link zeigt Critical Findings	Inputs sind für eine belastbare Interpretation nicht sicher genug.	Datenproblem beheben, bevor das Validierungsergebnis verwendet wird.
DQ-Link zeigt Accepted Findings	Eine Exception Rule hat ein bekanntes Finding akzeptiert.	Rule Name, Owner, Reason und Ablaufdatum prüfen.

Empfohlene Praxis

Interpretieren Sie einen Dashboard-Status nie ohne Scope und Einschränkungen. Validierungsevidenz gilt für ein bestimmtes Modell, Instrument, Dataset und Datum; sie ist keine pauschale Freigabe.

Zweck

Die Systemübersicht ist die Live-Operations-Seite für Worker- und Message-Broker-Gesundheit. Nutze sie, um zu prüfen, ob Services verbunden sind, Worker leben und RabbitMQ Queues verarbeitet werden.

Die Seite wird von PushNotifier gespeist und aktualisiert sich normalerweise alle paar Sekunden. Wenn die Push-Verbindung getrennt ist, kann die Anzeige veraltete Daten zeigen, obwohl das Backend weiterläuft.

Kopfbereich

Feld	Bedeutung
Workers	Anzahl der Worker, die PushNotifier aktuell kennt.
Idle	Worker, die leben und keine Nachricht verarbeiten.
Busy	Worker, die aktive Arbeit melden.
Broker	Erreichbarkeit des RabbitMQ Management Endpoints.
Connected	SignalR-Verbindungsstatus zwischen Portal und PushNotifier.

Broker-Verfügbarkeit und Worker-Verfügbarkeit sind nicht dasselbe. Ein Worker-Heartbeat kann noch sichtbar sein, während Broker-Statistiken nicht gelesen werden können.

Message Broker

Die Message-Broker-Tabelle zeigt RabbitMQ Queues. Sie ist nicht dieselbe Queue wie die Workflow-Queue-Admission-Seite.

Spalte	Bedeutung
Queue	RabbitMQ Queue-Name.
Owner	Service-Bereich, dem die Queue gehört.
Health	Portal-Einschätzung des Queue-Zustands.
State	Broker-Zustand der Queue.
Ready	Nachrichten, die auf Verarbeitung warten.
Unacked	Nachrichten, die an einen Consumer geliefert, aber noch nicht bestätigt wurden.
Total	Gesamte Nachrichtenanzahl laut Broker.
Rates/s	Publish- und Acknowledge-Rate.
Last Minute	Verlauf der Queue-Größe der letzten Minute.
Consumers	Anzahl aktiver Consumer.
Actions	Inspect, Peek oder Purge für wartende Nachrichten.

Queue-Muster lesen

Muster	Interpretation
Ready wächst und Consumers ist null	Der Zielservice oder Worker konsumiert nicht.
Ready wächst, obwohl Consumers existieren	Consumer sind langsamer als Producer oder blockiert.
Unacked bleibt hoch	Ein Consumer hat Arbeit erhalten, aber nicht bestätigt. Logs dieses Services prüfen.
Total steigt kurz und fällt wieder	Ein Last-Burst wurde normal verarbeitet.
Queue fehlt	Queue wurde nicht deklariert oder Monitoring kann sie nicht lesen.

Purge nur für Nachrichten verwenden, die sicher stale oder aufgegeben sind. Purge entfernt normalerweise wartende Nachrichten, nicht bereits ausgelieferte unacknowledged Arbeit.

Worker State

Worker senden Heartbeat Events über den Priority/Control Channel.

Spalte	Bedeutung
State	Idle, Busy oder Stale.
Core Load	Single-Core-äquivalente CPU-Last des Worker-Prozesses.
Memory	Vom Worker-Prozess gemeldeter Speicher.
Service	Service- oder Queue-Name des Workers.
Build	Kurze Build-ID des Worker-Prozesses.
Machine	Container- oder Hostname.
Process	Betriebssystem-Prozess-ID.
Current Work	Aktuelle Aktivität, z. B. Pricing oder Cashflow Extraction.
Last Seen	Zeitpunkt des letzten Heartbeats bei PushNotifier.

Stale bedeutet, dass kein aktueller Heartbeat empfangen wurde. Forget stale workers entfernt nur stale Einträge aus der In-Memory-Übersicht. Es startet oder stoppt keinen Worker.

Core Load

Core Load ist bewusst worker-lokal. Ein Worker verarbeitet eine Nachricht zur Zeit; 100% bedeutet, dass der Verarbeitungsthread des Workers nahezu ausgelastet ist, auch wenn die Host-CPU auf einem Multi-Core-System niedrig wirkt.

Praktische Nutzung

Symptom	Zuerst prüfen
Neue Arbeit startet nicht	Broker Consumers und Ready Counts.
Ein Workflow wirkt blockiert	Unacked Queue und Logs des zuständigen Consumers.
Worker verschwinden	Worker State und Service-/Container-Gesundheit.
UI aktualisiert nicht mehr	Push-Verbindung und Last-Update-Zeitpunkt.

Zweck

Statistiken zeigen historische Workflow-Run-Metadaten aus PushNotifier. Nutze die Seite, um aktuelle Runs zu vergleichen, eine Simulation-ID zu finden und zu verstehen, ob ein Run durch Instrumente, Szenarien, Dimensionen oder geschätzte Observations groß wurde.

Diese Seite ist historisch. Für live blockierte Arbeit zuerst Systemübersicht und Workflow Queue verwenden.

Kopfbereich und Filter

Der Modellfilter grenzt die Tabelle auf ein Modell ein, z. B. VaR95, StressScenario, Sensitivity oder Valuation. Refresh lädt die neuesten Workflow-Run-Statistiken.

Zusammenfassung

Karte	Bedeutung
Runs	Anzahl sichtbarer Workflow-Runs nach Filter.
Completed	Sichtbare Runs mit abgeschlossenem Status.
Largest Instrument Set	Maximale Instrumentenanzahl in den sichtbaren Runs.
Max Estimated Observations	Größte geschätzte Anzahl von Valuation Observations.

Tabelle

Spalte	Bedeutung
Started	Startzeit des Workflows.
Model	Modell- oder Workflow-Modellbezeichnung.
Date	Referenzdatum / COB.
Status	Aktueller oder finaler Workflow-Status.
Duration	Laufzeit, lesbar formatiert.
Instruments	Anzahl der Instrumente im Run.
Scenarios	Anzahl der Scenario States.
Dimensions	Anzahl der Shock-Analytics-Dimensionen.
Estimated Observations	Ungefähre Größe der Valuation Observations.

Details

Die Detailansicht zeigt Simulation-ID, Currency, Portfolio Count, Aggregation Flag, Measure Type, Finish-Zeit, kompakte Statistiken und Raw-JSON.

Die Simulation-ID ist der wichtigste Schlüssel für Korrelation mit Analyzer-, Pricer-, PushNotifier-, Redis- oder Datenbanklogs.

Operative Interpretation

Frage	Nutzung
Ist der letzte Run fertig?	Status und Started-Spalten.
Warum war der Run größer als üblich?	Instruments, Scenarios, Dimensions und Estimated Observations.
Welche ID soll ich in Logs suchen?	Simulation-ID im Detailpanel.
Wurde Aggregation angefordert?	Aggregation Flag im Detailpanel.

Zweck

Workflow Queue zeigt die PushNotifier Admission Queue. Sie steuert, welcher Workflow-Batch laufen darf und welche Batches warten müssen. Sie ist getrennt von den RabbitMQ Broker Queues in der Systemübersicht.

Die Admission Queue verhindert unkontrolliert überlappende Workflow-Batches. Ein queued oder running Batch kann spätere Batches blockieren, bis er terminal ist.

Zusammenfassung

Karte	Bedeutung
Active Schedules	Aktivierte Workflow-Schedules.
Queued	Batches, die auf Admission warten.
Running	Aktuell zugelassene/laufende Batches.
Failed	Fehlgeschlagene oder teilweise fehlgeschlagene Batches.

Admission Queue

Spalte	Bedeutung
Status	Batch-Zustand, z. B. Queued, Running, Completed, Failed, PartiallyFailed oder Cancelled.
Queued	Zeitpunkt, zu dem der Batch in die Admission Queue kam.
Started	Zeitpunkt, zu dem Dispatch gestartet wurde.
Batch	Kurze Batch-ID und interne Row-ID.
COB	Referenzdatum.
Currency	Reporting Currency.
Models	Angeforderte Modelle aus dem Batch Payload.
Workflows	Dispatchte Workflows im Verhältnis zu angeforderten Workflows.
Last Progress	Letzter Progress-Zeitpunkt des Batches.
Actions	Child Workflows anzeigen oder Queue unblocken.

Beim Öffnen eines Batches werden Child Workflows mit Workflow-Typ, Modell, Referenzdatum, Start-/Finish-Zeit, Status und Workflow-ID angezeigt.

Unblock Queue

Unblock ist eine Operator-Aktion für aufgegebene Admission-Batches.

Aktueller Zustand	Ergebnis
Queued	Batch wird als Cancelled markiert.
Running	Batch wird als Failed markiert.

Nicht-terminale Child Workflows werden als failed markiert, und der Admission Service versucht, den nächsten queued Batch zu starten.

Unblock nur verwenden, wenn der Batch sicher aufgegeben ist. Die Aktion ändert persistierten Workflow-Zustand.

Diagnose

Symptom	Prüfen
Neue Workflows starten nicht	Blockiert ein queued oder running Batch davor?
Running Batch hat alten Last Progress	Service-Logs und Broker-Unacked-Nachrichten prüfen.
RabbitMQ ist leer, UI zeigt aber running	Admission State ist noch nicht terminal.
Mehrere Batches warten	Zuerst den ältesten blockierenden Batch lösen oder unblocken.

Zweck

Operations enthält konfigurierte Workflow-Schedules und deren Run-Historie. Nutze die Seite, um Workflow-Automation zu prüfen, einen Schedule manuell zu starten und geplante Ausführung zu aktivieren oder zu deaktivieren.

Workflow Schedules

Jeder Schedule definiert, wann und wie ein Workflow-Batch ausgelöst wird.

Spalte	Bedeutung
Actions	Run now, Activate oder Deactivate für den Schedule.
Name	Schedule-Name.
IsActive	Ob der Schedule automatisch ausgeführt werden darf.
Cron	Cron-Ausdruck des Schedulers.
Mode	Reference-Date-Modus für den Run.
LastRunUtc	Letzter Trigger-Zeitpunkt.
LastSuccessUtc	Letzter erfolgreicher Run.
Duration	Dauer des letzten abgeschlossenen Runs, falls verfügbar.

Aktionen

Aktion	Wirkung
Run now	Startet den ausgewählten Schedule sofort.
Activate	Aktiviert zukünftige geplante Ausführung.
Deactivate	Deaktiviert geplante Ausführung, ohne den Schedule zu löschen.

Manuelle Runs erzeugen normale Workflow-Batches und können durch die Workflow Queue Admission verzögert werden.

Runs Tab

Der Runs Tab zeigt schedule-getriggerte Ausführungen mit Trigger-Zeit, Trigger-Quelle, Referenzdatum, Status und Fehlertext.

Damit lässt sich prüfen, ob Automation ausgelöst wurde, ob der letzte Run fehlgeschlagen ist und welches Referenzdatum eingereicht wurde.

Workflow States Tab

Workflow States zeigt die Child Workflow States der Schedule Runs. Das hilft, wenn ein Schedule erfolgreich gestartet ist, aber ein Modell oder Workflow im Batch fehlgeschlagen oder running geblieben ist.

Operative Hinweise

Operations konfiguriert und startet Schedules. Workflow Queue steuert Admission. Systemübersicht zeigt Broker- und Worker-Gesundheit. Bei Automation-Problemen alle drei Sichten zusammen verwenden.

Zweck

Die AI-Insights-Konfiguration steuert, wie das Portal erklärende Texte aus konfigurierten Analytics-Daten erzeugt. Der Aufbau trennt technischen Modellzugriff, fachliche Anweisungen und den Gültigkeitsbereich der Insights.

Verwenden Sie diese Konfiguration, wenn Modell, Endpoint, Prompt-Verhalten, verfügbare Insight-Fähigkeiten oder deren Anwendung in Analyzer-Workflows geändert werden müssen.

Konfigurationsmodell

Ein AI-Insight-Lauf wird aus diesen Datensätzen zusammengesetzt:

• AI Provider definiert Endpoint, Modell, Token-Limit, Temperatur und Secret-Referenz.
• AI Direction definiert wiederverwendbare Anweisungen und Versionierung für Prompts.
• AI Profile verbindet genau einen Provider mit einer Direction.
• AI Skill gehört zu einem Profil und beschreibt eine konkrete Prompt-Fähigkeit, zum Beispiel Ergebnis erklären, Exceptions zusammenfassen oder Kommentar entwerfen.
• AI Insight Binding gehört zu einem Profil und ordnet einen Skill einem Analytics-Scope zu, etwa Aggregation Set, Modell, Dimension oder Scope Pattern.

Halten Sie technische Schlüssel stabil. ProviderKey, DirectionKey und SkillKey sind Integrationskennungen; Name ist die Anzeige im Editor.

AI Provider

Öffnen Sie Analyzer / AI Insights / AI Providers.

Felder:

• Active aktiviert den Provider für Profile.
• Temperature steuert die Variabilität der Ausgabe. Niedrige Werte sind deterministischer und für regulierte Erklärungen vorzuziehen.
• MaxTokens begrenzt die Antwortlänge.
• ApiKeySecretRef verweist auf das Secret mit dem API-Key. Tragen Sie hier keine Roh-Credentials ein.
• Endpoint ist der API-Endpunkt der Integration, zum Beispiel der OpenAI Responses API Endpoint.
• Model ist die exakte Modellkennung.
• Name ist der Anzeigename.
• ProviderKey ist der stabile technische Provider-Schlüssel, zum Beispiel OpenAI.

Legen Sie bei Modellfamilien- oder Endpoint-Wechseln einen neuen Provider an. Alte Provider sollten eher deaktiviert als gelöscht werden, wenn Profile, Historie oder erzeugte Inhalte darauf verweisen.

AI Directions

Öffnen Sie Analyzer / AI Insights / AI Directions.

Felder:

• Active aktiviert die Direction.
• DirectionKey ist der stabile technische Schlüssel.
• InstructionTemplate enthält die wiederverwendbare Anweisung für Ton, Grenzen und Struktur.
• Name ist der Anzeigename.
• VersionTag kennzeichnet die Anweisungsversion.

Direction Templates sollten Aufgabe, Zielgruppe, Evidenzanforderungen und Grenzen beschreiben. Für Risikoerklärungen sollte die Anweisung festlegen, dass nur konfigurierte Daten verwendet werden, fehlende Inputs markiert werden und numerische Aussagen an sichtbare Ergebnisse gebunden bleiben.

AI Profiles

Öffnen Sie Analyzer / AI Insights / AI Profiles.

Felder:

• Active aktiviert das Profil.
• Name ist der Profilname für Analyzer-Workflows.
• DirectionConfig wählt die Anweisungs-Direction.
• ProviderConfig wählt Provider und Modell.

Profile trennen fachliche Anwendungsfälle. Ein Validierungsprofil kann strengere Anweisungen und eine niedrigere Temperatur nutzen als ein exploratives Analytics-Profil.

Skills

Skills werden im Profil auf dem Tab Skills gepflegt.

Felder:

• Active aktiviert den Skill.
• Name ist der Anzeigename.
• PromptTemplate ist der skill-spezifische Prompt.
• SkillKey ist der stabile Schlüssel für Bindings und Workflows.
• VersionTag kennzeichnet die Prompt-Version.
• AIInsightsProfile verknüpft den Skill mit dem Profil.

Verwenden Sie einen Skill pro klar abgegrenzter Fähigkeit. Ändert sich das Verhalten wesentlich, aktualisieren Sie VersionTag.

Insight Bindings

Insight Bindings werden im Profil auf dem Tab Insight Bindings gepflegt.

Felder:

• Active aktiviert das Binding.
• AggregationSet begrenzt das Binding auf ein Aggregation Set.
• DimensionKey begrenzt es auf eine Dimension oder Ergebnisachse.
• Models begrenzt es auf konfigurierte Modellnamen.
• Name ist der Anzeigename.
• ScopePattern begrenzt den Gültigkeitsbereich über ein Pattern.
• SkillKey wählt den anzuwendenden Skill.
• AIInsightsProfile verknüpft das Binding mit dem Profil.

Bindings verhindern, dass ein Skill zu breit verwendet wird. Nutzen Sie die engste sinnvolle Kombination aus Aggregation Set, Modell, Dimension und Scope Pattern.

Empfohlener Ablauf

• AI Provider anlegen oder prüfen: Endpoint, Modell, Token-Limit und Secret-Referenz.
• AI Direction mit klarer Instruction und VersionTag anlegen.
• AI Profile anlegen und Provider sowie Direction auswählen.
• Skills zum Profil hinzufügen.
• Insight Bindings für die vorgesehenen Analytics-Scopes anlegen.
• Aktivierung von außen nach innen: Provider und Direction, dann Profil, danach Skills und Bindings.
• Generierte Ausgaben nach Prompt- oder Modelländerungen prüfen.

Governance und Audit

AI-Konfigurationsdatensätze enthalten State, Version, Timestamp und Änderungshistorie. Nutzen Sie Info und History, um technische IDs und Änderungen zu prüfen.

Behandeln Sie Prompt Templates und Instruction Templates als Modell-Governance-Artefakte. Dokumentieren Sie die Wahl von Temperature, MaxTokens, Modell und Endpoint. Secrets werden nur im Secret Store gehalten und über ApiKeySecretRef referenziert.

Fehlerbehebung

Wenn ein Insight nicht verfügbar ist, prüfen Sie, ob Profil, Provider, Direction, Skill und Binding aktiv sind. Prüfen Sie anschließend, ob Aggregation Set, Modell, Dimension und Scope zum Binding passen.

Bei Modellfehlern prüfen Sie Endpoint, Modellkennung und ApiKeySecretRef. Ist die Ausgabe zu variabel, senken Sie Temperature. Ist die Ausgabe zu kurz, erhöhen Sie MaxTokens oder präzisieren Sie den Prompt.

Zweck

Discounted Cashflow Bewertung überführt erwartete Zahlungen in einen Barwert. Dafür werden Discount Factors aus der relevanten Kurve verwendet.

Typischer Arbeitsablauf

• Alle zukünftigen Cashflows nach dem Bewertungsdatum bestimmen.
• Discount Curve und Währung auflösen.
• Day Count, Settlement und Business-Day-Konventionen anwenden.
• Jeden Cashflow auf das Bewertungsdatum diskontieren.
• Diskontierte Cashflows summieren und Clean/Dirty Price ausweisen.

Beispielrechnung

Schritt	Beispiel
Cashflow	EUR 1.000.000 in einem Jahr
Discount Factor	0,970873786
Barwert	\(1{.}000{.}000 \times 0{,}970873786 = \text{EUR }970{.}873{,}79\)

Formel

$$ PV = \sum_i CF_i \cdot DF(t_i) $$

$$ DirtyPrice = \frac{PV}{Notional} \cdot 100 $$

$$ CleanPrice = DirtyPrice - AccruedInterest $$

Wichtige Felder

Feld	Bedeutung
Discount Curve	Kurve zur Diskontierung zukünftiger Cashflows.
Accrued Interest	Aufgelaufener, aber noch nicht gezahlter Couponzins.
Dirty Price	Clean Price plus Accrued Interest.
Settlement Date	Datum der wirtschaftlichen Abwicklung.

Empfohlene Praxis

Wenn der Barwert auffällig ist, prüfen Sie zuerst Cashflow-Daten, danach Kurvenmapping, Discount Factors, Accrued Interest und Vorzeichen des Nominals.

Zweck

Sensitivitäten zeigen, wie sich ein Ergebnis bei einer Änderung eines Marktdateninputs verhält. PV01 ist die Barwertänderung für eine Bewegung der Kurve um einen Basispunkt.

Typischer Arbeitsablauf

• Base PV berechnen.
• Relevante Kurve um die konfigurierte Bump Size nach oben und unten verschieben.
• Barwert für beide verschobenen Kurven neu berechnen.
• Finite-Difference-Ergebnis mit dem berichteten PV01 vergleichen.

Beispielrechnung

Position	Wert
Base PV	1.000.000,00
PV nach +1 bp	999.200,00
PV nach -1 bp	1.000.800,00
Central-Difference PV01	\(\frac{1{.}000{.}800 - 999{.}200}{2} = 800{,}00\)

Formel

$$ PV01 = \frac{PV_{down} - PV_{up}}{2} $$

$$ CentralDelta = \frac{PV_{up} - PV_{down}}{2 \cdot bump} $$

Das angezeigte Vorzeichen hängt von der Reporting-Konvention ab. Einige Reports zeigen die Wertänderung bei einem Rate Increase, andere die Risikoposition für einen Basispunkt.

Ergebnisinterpretation

Ein positiver PV01 bedeutet häufig, dass der Wert steigt, wenn Zinsen fallen. Prüfen Sie immer die Sign Convention im Ergebnisdetail.

Für Non-Maturity Deposits ist zusätzlich zu unterscheiden, ob die Sensitivität aus der Kurve oder aus der optionalen Floor-Komponente stammt.

Sensitivität	NMD-Interpretation
IR Delta / PV01	Reaktion des Runoff-Barwerts auf die Diskontkurve und die modellierte Behavioral Duration.
IrVega	Reaktion des Zero-Floor-Werts auf die gemappte Normal-Volatilitätsfläche.
Null-Vega	Nur unauffällig, wenn der Floor deaktiviert ist oder keine relevante Optionsexponierung besteht. Bei aktivem Floor Surface Mapping und FloorStrike prüfen.

Häufige Probleme

Problem	Bedeutung	Mögliche Aktion
Falsches Vorzeichen	Bump- oder Reporting-Konvention unterscheidet sich.	Sign Convention und Payer/Receiver-Richtung vergleichen.
Keine Sensitivität	Verschobene Kurve oder Bewertungsmodell fehlt.	Kurvenmapping und Instrumentunterstützung prüfen.
Sehr große Sensitivität	Quantity, Notional oder Kurvenbucket kann falsch sein.	Positionsgröße und Risk-Factor-Mapping prüfen.
NMD-Vega fehlt	Normal-Volatilitätsfläche oder Strike-Mapping passt nicht zur Floor-Bewertung.	IncludeFloorValue, Surface Mapping, Surface Nodes und FloorStrike prüfen.

Zweck

VaR und Expected Shortfall beschreiben Tail-Verluste aus einer Szenario-PnL-Verteilung. Es sind Risikokennzahlen, keine Bewertungskennzahlen.

Typischer Arbeitsablauf

• Szenario-PnL-Werte erzeugen oder laden.
• Verluste gemäß Sign Convention sortieren.
• Quantil für VaR auswählen.
• Tail für Expected Shortfall mitteln.
• Aggregationsebene und Portfoliofilter prüfen.

Beispielrechnung

Position	Beispiel
Sortierte Verluste	10, 20, 35, 50, 80
Konfidenzniveau	80%
VaR	50 bei Nearest-Rank-Auswahl
ES	Durchschnitt des Tails, abhängig von der Konvention

Formel

$$ VaR_{\alpha} = Q_{\alpha}(L) $$

$$ ES_{\alpha} = \mathbb{E}\left[L \mid L \ge VaR_{\alpha}\right] $$

Bei PnL-Vektoren muss die Sign Convention zuerst PnL in Verluste überführen. Negative PnL ist in der Regel ein positiver Verlust.

Ergebnisinterpretation

VaR beantwortet die Frage, wie groß ein Verlust bei einem Konfidenzniveau sein kann. ES beschreibt den durchschnittlichen Verlust im Tail. Vergleichen Sie Ergebnisse nur bei gleichem Konfidenzniveau, Horizont, Vorzeichen und Aggregationslevel.

Empfohlene Praxis

Wenn das Dashboard keine VaR-Daten zeigt, prüfen Sie Aggregationsebene, Run-Datum, Portfolio und ob der Lauf für das relevante Szenariopaket abgeschlossen wurde.

Zweck des Dashboards

Das Stress-Testing-Dashboard zeigt Szenario-PnL nach Szenariofamilie, Aggregationsebene und Instrument. Es dient dem Vergleich deterministischer Schocks, nicht der Schätzung statistischer Tail-Wahrscheinlichkeiten.

Szenariofamilien

Szenariofamilie	Was passiert	Charakter	Typische Interpretation
Basic	Einzelne oder einfache kombinierte Risikofaktor-Schocks werden angewendet.	Mechanischer Sensitivitätsstress.	Gut zur Erklärung, welches Portfolio, Desk oder Instrument von einem Treiber abhängt.
EBA	Aufsichtliche Schocks werden konsistent über konfigurierte Marktrisikotreiber angewendet.	Regulatorischer Benchmark-Stress.	Gut für Vergleiche unter einem standardisierten severe-but-plausible Setup.
Macro	Historische oder narrative Krisenvorlagen bewegen mehrere Assetklassen gemeinsam.	Multi-Faktor-Krisenszenario.	Gut zur Analyse von Cross-Asset-Verlusten und Diversifikationsbruch.

Szenariokatalog

Szenarioset	Enthaltene Szenarien	Charakter
Basic	Relative Schocks für EqDelta, FxDelta und CmDelta: -50%, -20%, -15%, -10%, -5%, -2.5%, +2.5%, +5%, +10%, +15%, +20%, +50%.	Einzelfaktor-Preisstress als Ladder.
Basic	Absolute Schocks für IrDelta und CsDelta: -200 bp, -100 bp, -50 bp, -20 bp, -10 bp, -5 bp, +5 bp, +10 bp, +20 bp, +50 bp, +100 bp, +200 bp.	Einzelfaktor-Kurven- oder Spreadstress als Ladder.
EBA	EBA2025/Adverse.	EZB-Szenario für den EU-weiten EBA-Stresstest 2025; Schocks werden aus dem EBA-Workbook für Equity, Commodity, Funds, Rates, FX, Sovereign Credit und Corporate Credit gelesen.

Macro-Szenariokatalog

Jeder Macro-Eintrag ist eine Cross-Asset-Vorlage. Die Varianten teilen die gleiche Krisenlogik, nutzen aber eigene Szenario-Keys und unterschiedliche Severity-Skalierung.

Familie	Charakter	Varianten
GFC	Kredit- und Liquiditätsfreeze nach Vorbild der globalen Finanzkrise 2007-09.	LehmanSevere, MortgageCreditCrash, BankFundingFreeze, InterbankTrustBreak, SecuritizationCollapse, GlobalDeleveraging, CounterpartyPanic, CreditMarketShutdown, SystemicBankStress, GfcReplayExtreme
COVID	Pandemieartiger Sudden Stop und Liquiditätsstress.	SuddenStop, LockdownShock, LiquidityDash, OilDemandCollapse, TravelShutdown, SupplyChainFreeze, EmergencyCuts, CreditDrawdown, PandemicSecondWave, CovidReplayExtreme
Dotcom	Growth-Equity-Crash und Investitionsrückgang.	TechCrash, GrowthMultipleReset, IPOFreeze, TelecomDebtStress, ProfitlessTechUnwind, NasdaqStyleDrawdown, VentureFundingStop, SoftwareDerating, EquityVolSpike, DotcomReplayExtreme
EuroSov	Euro-Staatsschulden- und Bank-Sovereign-Feedback-Stress.	PeripheryCrisis, SovereignBankLoop, EuroBreakupFear, ItalianSpreadShock, SpanishSpreadShock, BankRecapitalization, CollateralHaircutShock, BundFlightToQuality, EuroFundingStress, EuroSovReplayExtreme
UkraineEnergy	Energieangebotsschock, Inflationsimpuls und Europe Risk-off.	GasSupplyShock, OilEmbargo, SanctionsEscalation, EuropeTermsOfTrade, EnergyMarginCalls, WinterShortage, IndustrialCurtailment, FoodEnergyInflation, PipelineDisruption, UkraineReplayExtreme
OilStagflation	Ölgetriebene Inflation bei schwachem Wachstum und Risk-Asset-Repricing.	OilEmbargo, WagePriceSpiral, PersistentInflation, RealRateShock, CommoditySupplyShock, StagflationRecession, CentralBankBehindCurve, EnergyRationing, InflationRiskPremium, SeventiesReplayExtreme
BlackMonday	Abrupter Equity-Gap und Volatilitätsschock.	EquityGap, VolatilityExplosion, PortfolioInsuranceUnwind, IndexLiquidityGap, CrossAssetVaRShock, RiskParityUnwind, MarginCallCascade, EquityCircuitBreak, VolControlSelling, BlackMondayReplayExtreme
LTCM	Leveraged Relative-Value-Unwind und EM-Contagion.	RussiaDefault, RelativeValueUnwind, EMContagion, SwapSpreadBlowout, LiquidityPremiumShock, HedgeFundDeleveraging, BasisTradeUnwind, FlightToTreasuries, FundingMarketStress, LtcmReplayExtreme
TaperTantrum	Abrupte globale Rates-Neubewertung und USD-Unterstützung.	RatesSelloff, TermPremiumJump, UsdRatesReprice, EMOutflow, MortgageConvexity, CurveBearSteepener, BondFundOutflow, DurationShock, CarryUnwind, TaperReplayExtreme
UKGilt	GBP-Kurvenschock und Collateral-/Liquiditätsstress.	GiltCurveShock, LdiCollateralCall, SterlingCrisis, PensionDeleveraging, LongEndRatesGap, FiscalCredibilityShock, GbpFundingStress, LiabilityHedgeUnwind, GiltLiquidityGap, GiltReplayExtreme

Widgets lesen

Widget	Interpretation
KPI Strip	Zeigt Gesamtverlust und Haupttreiber für das gewählte Szenarioset.
Diverging Bar Chart	Vergleicht positive und negative Szenarioeffekte zwischen Gruppen.
Scenario Exposure Table	Bricht Szenario-PnL nach Group, Book, Desk oder Portfolio herunter.
Instrument Table	Zeigt instrumentbezogene Treiber für die ausgewählte Zeile.

Vergleichen Sie Stress-Ergebnisse nur bei gleichem Referenzdatum, gleicher Währung, gleichem Szenarioset und gleicher Aggregationsebene.

Zweck

Dieser Artikel erklärt die wichtigsten Marktrisikokennzahlen in der Model Validation: VaR, Expected Shortfall, historische Simulation, hybride historische Simulation, Delta-Normal-VaR und Monte-Carlo-Simulation. Die Inhalte orientieren sich an den Konzepten aus FRM Notes v0.37 und an der Portal-Konvention, dass Evidenzen die Verlust- oder PnL-Richtung ausdrücklich dokumentieren müssen.

Verlust- und PnL-Konvention

Viele Risikotexte definieren VaR auf einer Verlustvariable \(L\). Das Portal speichert Szenarioergebnisse häufig als PnL \(P\). Der Zusammenhang ist:

$$ L = -P $$

Für eine Verlustverteilung mit Verteilungsfunktion \(F_L\) lautet der VaR zum Konfidenzniveau \(\alpha\):

$$ VaR_\alpha = F_L^{-1}(\alpha) $$

Wenn das Portal VaR auf einem PnL-Vektor zeigt, kann der Wert als ungünstiges Lower-Tail-PnL dargestellt werden. Deshalb gehört die Vorzeichenkonvention in die Evidenz und darf nicht aus dem Modellnamen abgeleitet werden.

Expected Shortfall

Expected Shortfall ist der durchschnittliche Verlust jenseits der VaR-Schwelle:

$$ ES_\alpha = E[L \mid L \ge VaR_\alpha] $$

Für eine stetige Verteilung:

$$ ES_\alpha = \frac{1}{1-\alpha}\int_\alpha^1 F_L^{-1}(u)\,du $$

In einem historischen Simulationspack wird ES aus den ausgewählten Tail-Szenarien berechnet. Die Evidenz sollte Konfidenzniveau, Tail-Größe, Szenarioanzahl und Vorzeichenkonvention zeigen.

Historische Simulation

Die historische Simulation bewertet das Portfolio unter historischen Marktschocks und verwendet den resultierenden Szenario-PnL-Vektor direkt. Sie setzt keine Normalverteilung voraus.

Typischer Ablauf:

Schritt	Bedeutung
Schocks erzeugen	Marktbewegungen werden aus historischen Marktdaten erstellt.
Positionen bewerten	Jede Position wird unter jedem Schock bewertet.
Szenariovektoren bilden	Positions-PnL wird nach Assetklasse und Total Loss aggregiert.
Tail-Kennzahl berechnen	VaR, ES, Best Case und Worst Case werden aus dem sortierten Vektor gelesen.

Für einen sortierten Verlustvektor \(L_{(1)} \le \ldots \le L_{(n)}\) kann ein einfacher empirischer Quantilwert so geschrieben werden:

$$ VaR_\alpha = L_{(\lceil \alpha n \rceil)} $$

Produktionssysteme verwenden unterschiedliche Interpolations- und Indexkonventionen. Deshalb dokumentiert die Validierung den exakten Aggregator oder die Benchmark-Konvention.

Hybride historische Simulation

Die hybride historische Simulation gewichtet historische Beobachtungen nach Alter. Jüngere Szenarien erhalten typischerweise ein höheres Gewicht.

Mit Decay-Faktor \(\lambda\) lautet eine normalisierte Konvention:

$$ w_i = \frac{(1-\lambda)\lambda^{n-i}}{\sum_{j=1}^{n}(1-\lambda)\lambda^{n-j}} $$

wobei ein größeres \(i\) eine neuere Beobachtung bezeichnet. Der gewichtete VaR wird bestimmt, indem Szenarien nach Verlust- oder PnL-Konvention sortiert und Gewichte bis zur Ziel-Tail-Wahrscheinlichkeit kumuliert werden:

$$ \sum_{i \in \text{Tail}} w_i \ge 1-\alpha $$

Im Portal zeigt die hybride TL-Ansicht den gewichteten Tail-Beitrag für den Total-Loss-Vektor, weil dort die kumulative Gewichtung am besten prüfbar ist.

Delta-Normal-VaR

Delta-Normal-VaR approximiert Portfoliowertänderungen mit linearen Sensitivitäten und einer Kovarianzmatrix. Für Exposure-Vektor \(x\) und Kovarianzmatrix \(\Sigma\):

$$ \sigma_P^2 = x^\top \Sigma x $$

Bei normalverteilten Renditen kann der Verlust-VaR geschrieben werden als:

$$ VaR_\alpha = \mu_P + z_\alpha \sigma_P $$

Eine übliche Zeit-Skalierung ist:

$$ VaR_{h} \approx VaR_{1d}\sqrt{h} $$

Diese Wurzel-Zeit-Regel ist nur sinnvoll, wenn Renditeprozess und Unabhängigkeitsannahmen zum Anwendungsfall passen.

Optionsapproximation

Für Optionen und nichtlineare Produkte lautet eine Delta-Approximation erster Ordnung:

$$ \Delta V \approx \Delta \cdot \Delta S $$

Eine Delta-Gamma-Approximation zweiter Ordnung lautet:

$$ \Delta V \approx \Delta \cdot \Delta S + \frac{1}{2}\Gamma(\Delta S)^2 $$

Historische Vollbewertung ist für Validierungspacks vorzuziehen, wenn die Produktionsengine denselben Pricing-Pfad ausführen kann.

Monte-Carlo-VaR

Monte Carlo VaR erzeugt simulierte Marktszenarien aus einem stochastischen Modell, bewertet das Portfolio neu und liest die Risikokennzahl aus dem simulierten PnL-Vektor.

Kontrolle	Warum sie wichtig ist
Zufallsseed	Macht die Validierung reproduzierbar.
Verteilungsannahme	Bestimmt Tail-Verhalten und Stress-Schwere.
Korrelationsmodell	Steuert Diversifikation und Konzentration.
Anzahl der Pfade	Steuert Stichprobenfehler.
Bewertungsmodell	Muss zum validierten Modell passen.

Ergebnisinterpretation

Ergebnis	Interpretation
Worst Case	Ungünstigstes Szenario im publizierten Vektor.
VaR95 / VaR99	Tail-Perzentil unter der gewählten Konvention.
ES95 / ES99	Durchschnitt der Tail-Szenarien jenseits des VaR.
Best Case	Günstigstes Szenario im publizierten Vektor.
Hybrid VaR/ES	Tail-Kennzahl mit altersgewichteten Szenarien.

Häufige Probleme

Problem	Bedeutung	Mögliche Aktion
Unerwartetes Vorzeichen	Verlust- und PnL-Konventionen werden gemischt.	Evidenzkonvention prüfen.
Zu wenige Szenarien	Tail-Kennzahlen sind instabil.	Szenariofenster und Beobachtungsanzahl prüfen.
Hybrid-Ergebnis weicht stark ab	Jüngere Beobachtungen sind anders gewichtet.	Decay-Faktor und kumulative Gewichte prüfen.
Options-VaR zu klein	Volatilitäts- oder nichtlineare Schocks fehlen.	IR-, Equity- und Volatilitätsschocks prüfen.

Empfohlene Praxis

Zuerst die Schocktabelle prüfen, danach Szenariovektor, Portfolioaggregation und Ergebnistabelle. Eine VaR-Zahl ohne zugrunde liegenden Vektor ist keine ausreichende Validierungsevidenz.

Zweck

Volatilitäts- und Korrelationsmodelle überführen Marktbeobachtungen in Risikoinputs. Sie werden in parametrischem VaR, Optionsbewertung, Volatilitätsflächenvalidierung und Stressdesign verwendet. Dieser Artikel fasst zentrale Formeln aus FRM Notes v0.37 zusammen und erklärt ihre Interpretation im Portal.

Renditen

Für einen Marktpreis oder Indexstand \(S_t\) ist die stetig kompoundierte Rendite:

$$ u_t = \ln\left(\frac{S_t}{S_{t-1}}\right) $$

Bei kleinen Bewegungen sind Logrenditen und einfache Prozentänderungen ähnlich, aber nicht identisch. Die Validierung sollte die verwendete Renditekonvention dokumentieren.

Stichprobenvolatilität

Für tägliche Renditen \(u_t\) ist die Stichprobenvarianz:

$$ s^2 = \frac{1}{n-1}\sum_{t=1}^{n}(u_t-\bar{u})^2 $$

Tägliche Volatilität wird annualisiert mit:

$$ \sigma_{\text{Jahr}} = \sigma_{\text{Tag}}\sqrt{252} $$

Der Faktor 252 ist eine Handelstage-Konvention und sollte nicht stillschweigend auf wöchentliche, monatliche oder unregelmäßige Daten angewandt werden.

EWMA-Volatilität

Exponentially Weighted Moving Average gewichtet jüngere Renditen stärker:

$$ \sigma_t^2 = \lambda\sigma_{t-1}^2 + (1-\lambda)u_{t-1}^2 $$

Ein hohes \(\lambda\) reagiert langsam, ein niedriges \(\lambda\) reagiert schnell.

EWMA-Kovarianz verwendet dieselbe Logik:

$$ cov_t(x,y)=\lambda cov_{t-1}(x,y)+(1-\lambda)x_{t-1}y_{t-1} $$

GARCH(1,1)

Ein GARCH(1,1)-Modell kombiniert Langfristkomponente, letzte quadrierte Rendite und vorherige Varianz:

$$ \sigma_t^2 = \omega + \alpha u_{t-1}^2 + \beta\sigma_{t-1}^2 $$

Die langfristige Varianz ist:

$$ V_L = \frac{\omega}{1-\alpha-\beta} $$

Eine übliche Stabilitätsbedingung ist:

$$ \alpha + \beta < 1 $$

Wenn diese Bedingung verletzt ist, kann das Modell instabiles Langfristverhalten zeigen.

Korrelation

Für zwei Renditereihen \(x\) und \(y\):

$$ \rho_{xy}=\frac{cov(x,y)}{\sigma_x\sigma_y} $$

Korrelation garantiert in Stressphasen keine Diversifikation. Validierung sollte prüfen, ob Korrelation und Volatilität aus demselben Fenster und derselben Konvention stammen.

Portfoliovarianz

Für Exposures \(x\) und Kovarianzmatrix \(\Sigma\):

$$ \sigma_P^2 = x^\top \Sigma x $$

Für zwei Assets:

$$ \sigma_P^2 = x_1^2\sigma_1^2 + x_2^2\sigma_2^2 + 2x_1x_2\rho_{12}\sigma_1\sigma_2 $$

Dieselbe Struktur erscheint in Delta-Normal-VaR und Sensitivitätsaggregation.

Interpretation im Portal

Bereich	Was zu prüfen ist
Volatilitätsflächen	Exakter Grid-Lookup, Interpolation, negative Volatilitäten und fehlende Quotes.
Hybrid VaR	Decay-Faktor, kumulative Gewichte und Beobachtungsreihenfolge.
Parametrische Ergebnisse	Renditekonvention, Annualisierung und Kovarianzmatrix.
Optionsvalidierung	Ob implizite Volatilitätsschocks für den Underlying vorhanden sind.

Häufige Probleme

Problem	Bedeutung	Mögliche Aktion
Volatilität springt unerwartet	Beobachtungsfenster oder Decay-Faktor geändert.	Marktdaten und Modellparameter vergleichen.
Korrelationsmatrix ungültig	Matrix ist möglicherweise nicht positiv semidefinit.	Datenqualität und Reparaturmethode prüfen.
Annualisierung falsch	Tages-, Wochen- oder Monatsdaten gemischt.	Frequenz und Skalierung prüfen.
Vol-Schock fehlt	Options-Szenario-PnL ist unvollständig.	Volatilitätsschocks und Surface-Mapping prüfen.

Empfohlene Praxis

Volatilität und Korrelation sind Modellinputs, keine passiven Daten. Ein Validierungspack sollte Beobachtungsfenster, Renditekonvention, Gewichtungsmethode und Reparatur- oder Interpolationsschritte offenlegen.

Zweck

Fixed-Income-Modelle erklären, wie Cashflows, Diskontkurven und Zinsänderungen Bewertung und Sensitivität beeinflussen. Dieser Artikel fasst Bond Pricing, Duration, DV01, KR01 und Konvexität aus FRM Notes v0.37 zusammen und verbindet sie mit den Portal-Validierungsansichten.

Diskontierung

Bei stetiger Verzinsung \(r\) ist der Diskontfaktor für Zeit \(t\):

$$ DF(t)=e^{-rt} $$

Bei nominalem Zinssatz \(r\), Kompoundierungsfrequenz \(m\) und Laufzeit \(n\):

$$ DF(n)=\left(1+\frac{r}{m}\right)^{-mn} $$

Der Barwert deterministischer Cashflows ist:

$$ PV = \sum_{i=1}^{N} CF_i \cdot DF(t_i) $$

Im DCF-Validierungspack sollte die Evidenz Cashflowplan, Diskontinputs und PV-Aggregation zeigen.

Yield und Bondpreis

Für einen einfachen Fixed-Rate Bond mit Yield \(y\):

$$ P = \sum_{i=1}^{N}\frac{CF_i}{(1+y)^{t_i}} $$

In der Produktionsbewertung verwendet das Portal normalerweise Kurvendiskontierung statt eines einzelnen Yields. Yield-Formeln bleiben für Benchmark-Checks und Sensitivitätsintuition hilfreich.

Duration

Macaulay Duration ist die cashflowgewichtete durchschnittliche Zahlungszeit:

$$ D = \sum_i t_i \frac{CF_i e^{-yt_i}}{P} $$

Modified Duration passt Macaulay Duration an die Kompoundierung an:

$$ D_{\text{mod}} = \frac{D}{1+y/m} $$

Die Approximation erster Ordnung lautet:

$$ \frac{\Delta P}{P} \approx -D_{\text{mod}}\Delta y $$

Duration ist vor allem für kleine parallele Yield-Änderungen zuverlässig.

DV01 und PV01

DV01 ist die Preisänderung für einen Basispunkt Yield-Bewegung:

$$ DV01 \approx \frac{D_{\text{mod}}P}{10{,}000} $$

Finite-Difference-PV01 wird häufig durch Kurvenbumps berechnet:

$$ PV01 \approx \frac{PV(y-\Delta y)-PV(y+\Delta y)}{2} $$

Manche Systeme teilen zusätzlich durch die Bumpgröße, andere berichten direkt den Ein-Basispunkt-Wert. Evidenz muss Vorzeichen und Skalierung nennen.

Key-Rate-Risiko

Key-Rate-Sensitivität misst Exposure zu einem bestimmten Kurventenor:

$$ KR01_k \approx \frac{PV_k^- - PV_k^+}{2} $$

wobei \(PV_k^-\) und \(PV_k^+\) Werte nach Down- und Up-Shift am Key Rate \(k\) sind. Key-Rate-Vektoren sind informativer als ein einzelner Parallel-DV01, wenn die Kurvenform relevant ist.

Konvexität

Konvexität verbessert die Approximation bei größeren Zinsbewegungen:

$$ \frac{\Delta P}{P} \approx -D\Delta y + \frac{1}{2}C(\Delta y)^2 $$

Effective Convexity kann gemessen werden mit:

$$ C_{\text{eff}}=\frac{P^-+P^+-2P_0}{P_0(\Delta y)^2} $$

Callable Bonds und Produkte mit Optionalität können sich deutlich anders verhalten als einfache Fixed-Rate Bonds.

Interpretation im Portal

Ansicht	Was sie belegt
Cashflows	Das Instrument wurde in den erwarteten Zahlungsplan zerlegt.
DCF-Evidenz	Diskontierung und PV-Aggregation sind reproduzierbar.
Sensitivitäts-Shifts	Up/Down-Szenariowerte sind vorhanden und Vorzeichen sind explizit.
Model Validation Row	Das Modell verknüpft Bewertungsevidenz, Sensitivitätsevidenz und Limitationen.

Häufige Probleme

Problem	Bedeutung	Mögliche Aktion
PV ist null	Instrument-Mapping oder Bewertungspfad hat kein Bewertungsinstrument erzeugt.	Instrumentunterstützung und Marktdaten prüfen.
PV01-Vorzeichen weicht ab	Konventionen für Preisänderung und Risikoverlust unterscheiden sich.	Evidenzmetriken vor Zahlenvergleich prüfen.
Cashflows fehlen	Schedule-Konstruktion ist fehlgeschlagen oder Produkt wird nicht unterstützt.	Stammdaten, Kalender, Day Count und Coupon prüfen.
KR01 unvollständig	Kurventenor-Mapping fehlt.	Kurvenseed und Schockkonstruktion prüfen.

Empfohlene Praxis

Bei Fixed-Income-Validierung zuerst die Cashflowtabelle prüfen. Ein korrekter PV ist nur aussagekräftig, wenn Schedule, Diskontkurve und Bewertungsdatum sichtbar und konsistent sind.

Zweck

Optionsmodelle überführen Underlying-Preis, Strike, Zeit, Zinsen und Volatilität in Wert und Sensitivitäten. Dieser Artikel fasst Binomialbäume, Black-Scholes-Merton und Greeks aus FRM Notes v0.37 zusammen und erklärt die Interpretation von Optionsevidenz.

Payoff

Für einen europäischen Call:

$$ C_T=\max(S_T-K,0) $$

Für einen europäischen Put:

$$ P_T=\max(K-S_T,0) $$

Das Pricing-Modell schätzt den diskontierten Erwartungswert des Payoffs unter den Modellannahmen.

Binomialbaum

Ein einstufiger Binomialbaum verwendet einen Up- und Down-Faktor:

$$ u=e^{\sigma\sqrt{\Delta t}}, \qquad d=e^{-\sigma\sqrt{\Delta t}} $$

Die risikoneutrale Wahrscheinlichkeit mit Dividendenrendite oder ausländischem Zinssatz \(q\) ist:

$$ p=\frac{e^{(r-q)\Delta t}-d}{u-d} $$

Der Optionswert wird durch Rückwärtsinduktion berechnet:

$$ V=e^{-r\Delta t}\left(pV_u+(1-p)V_d\right) $$

Bäume sind hilfreich bei Produkten mit Early Exercise oder Pfadabhängigkeit.

Black-Scholes-Merton

Für einen europäischen Call mit kontinuierlicher Dividendenrendite \(q\):

$$ c=S_0e^{-qT}N(d_1)-Ke^{-rT}N(d_2) $$

Für einen europäischen Put:

$$ p=Ke^{-rT}N(-d_2)-S_0e^{-qT}N(-d_1) $$

wobei:

$$ d_1=\frac{\ln(S_0/K)+(r-q+\frac{1}{2}\sigma^2)T}{\sigma\sqrt{T}} $$

$$ d_2=d_1-\sigma\sqrt{T} $$

Bei FX-Optionen wird \(q\) häufig als ausländischer Zinssatz und \(r\) als inländischer Zinssatz interpretiert.

Greeks

Greeks messen die Sensitivität einer Option gegenüber Inputs.

Greek	Definition	Interpretation
Delta	\(\Delta=\frac{\partial V}{\partial S}\)	Sensitivität gegenüber Underlying-Preis.
Gamma	\(\Gamma=\frac{\partial^2 V}{\partial S^2}\)	Krümmung des Delta.
Vega	\(\nu=\frac{\partial V}{\partial \sigma}\)	Sensitivität gegenüber Volatilität.
Theta	\(\Theta=\frac{\partial V}{\partial t}\)	Zeitwertverfall.
Rho	\(\rho=\frac{\partial V}{\partial r}\)	Sensitivität gegenüber Zinsen.

Unter einfachen Black-Scholes-Merton-Annahmen ohne Dividenden:

$$ \Delta_{\text{Call}}=N(d_1), \qquad \Delta_{\text{Put}}=N(d_1)-1 $$

$$ \Gamma=\frac{N'(d_1)}{S_0\sigma\sqrt{T}} $$

$$ \nu=S_0N'(d_1)\sqrt{T} $$

Szenariovalidierung

Options-Szenario-PnL benötigt meist mehrere Schockarten:

Schockart	Warum sie wichtig ist
Equity- oder Underlying-Schock	Treibt Delta- und Gamma-Effekte.
Zins-Schock	Verändert Diskontierung und Forwards.
Volatilitäts-Schock	Treibt Vega und modellimpliziten Wert.
FX-Schock	Erforderlich bei abweichender Payoff-, Underlying- oder Reporting-Währung.

Wenn Volatilitätsschocks fehlen, können VaR und ES für Optionen deutlich zu niedrig sein.

Häufige Probleme

Problem	Bedeutung	Mögliche Aktion
Optionswert bleibt in Szenarien flach	Underlying- oder Volatilitätsschocks sind nicht verbunden.	Schocktabelle nach Risikofaktor prüfen.
Vega fehlt	Vol Surface Mapping fehlt oder Produkt ist nicht mit Vol-Modell verbunden.	Surface-Id und Underlying-Mapping prüfen.
Delta-only-VaR ist zu niedrig	Gamma- und Vega-Effekte werden ignoriert.	Vollbewertungsvalidierung bevorzugen.
FX-Option passt nicht	Inländischer und ausländischer Zinssatz könnten vertauscht sein.	Währungs- und Kurvenkonvention prüfen.

Empfohlene Praxis

Bei Optionsvalidierung Preis, Greeks und Szenario-PnL gemeinsam prüfen. Ein korrekter Closed-Form-Preis beweist nicht, dass VaR korrekt ist, wenn Schocks nicht auf alle relevanten Risikofaktoren wirken.

Zweck

Kredit- und operationelle Risikomodelle schätzen Verluste aus Ausfall, Downgrade, Recovery-Unsicherheit, Prozessfehlern und externen Ereignissen. Dieser Artikel fasst zentrale Modellkonzepte aus FRM Notes v0.37 zusammen, die für Portal-Methodik und Validierungsdokumentation relevant sind.

Erwarteter Kreditverlust

Die Standardformel für erwarteten Verlust lautet:

$$ EL = PD \times LGD \times EAD $$

Term	Bedeutung
\(PD\)	Ausfallwahrscheinlichkeit.
\(LGD\)	Verlustquote bei Ausfall.
\(EAD\)	Exposure zum Ausfallzeitpunkt.

Die Formel ist einfach, aber jeder Input ist ein Modelloutput oder eine kalibrierte Schätzung. Validierung sollte daher Inputquelle, Beobachtungsfenster, Segmentierung und Overrides dokumentieren.

Unerwarteter Verlust

Unexpected Loss beschreibt die Verluststreuung um den erwarteten Verlust. Vereinfacht:

$$ UL = \sqrt{Var(L)} $$

In einem Kreditportfolio hängt unerwarteter Verlust von Konzentration, Ausfallkorrelation, Exposuregröße und Recovery-Unsicherheit ab. Er wird nicht durch einen EL-Check allein validiert.

Ratings und Score-Modelle

Ratingmodelle überführen Kreditnehmer- oder Exposure-Informationen in Risikoklassen. Wichtige Kontrollen sind:

Kontrolle	Validierungsfrage
Kalibrierung	Stimmen beobachtete Ausfälle mit Klassen-PDs überein?
Diskriminierung	Ordnet das Modell riskantere Fälle korrekt höher ein?
Stabilität	Sind Ratingmigrationen erklärbar?
Override Governance	Sind manuelle Änderungen begründet?
Datenqualität	Sind Finanzdaten, Land, Sektor und Sicherheiten vollständig?

Länder- und Konzentrationsrisiko

Länderrisikomodelle betrachten Sovereign-Bedingungen, Transferrisiko, politisches Risiko und makroökonomischen Stress. Konzentrationsrisiko entsteht bei Exposure gegenüber wenigen Namen, Sektoren, Regionen oder Währungen.

Ein konzentrationssensitives Modell sollte offenlegen:

Input	Warum er wichtig ist
Gruppenexposure	Erkennt verbundene Namen.
Sektor und Land	Erkennt korrelierte Ausfalltreiber.
Sicherheiten und Garantien	Beeinflussen Recovery und Transferierbarkeit.
Laufzeit	Beeinflusst Exposure-Horizont.

Operationelle Verlustschwere

Operationelle Verlustmodelle verwenden oft schiefe Verteilungen, weil seltene Ereignisse den Verlust dominieren können. Typische Kandidaten sind Exponential-, Weibull-, Lognormal- und Extreme-Value- oder Peaks-over-Threshold-Modelle.

Für ein Exponentialmodell mit Rate \(\lambda\):

$$ F(x)=1-e^{-\lambda x} $$

Das Verlustquantil ist:

$$ x_\alpha=-\frac{1}{\lambda}\ln(1-\alpha) $$

Extreme-Tail-Modelle benötigen sorgfältige Schwellenwertwahl und Sensitivitätsanalyse.

Stresstests

Stresstests ergänzen statistische Modelle, indem sie schwere, aber plausible Ereignisse prüfen. Sie sind besonders wichtig, wenn historische Daten das relevante Szenario nicht enthalten.

Stresstyp	Beispiel
Sensitivitätsstress	Einzelner Risikotreiber wird geschockt.
Szenariostress	Mehrere Treiber bewegen sich konsistent.
Reverse Stress	Szenario suchen, das ein Limit oder Solvenzschwelle bricht.
Narrativer Stress	Makro- oder Ereignisgeschichte wird in Risikofaktoren übersetzt.

Interpretation im Portal

Kredit- und operationelle Risikoartikel sind Methodikreferenzen für zukünftige Modellpacks. Wenn ein Dashboard-Modell inventory-only oder Unknown ist, ist noch keine ausführbare Validierungsevidenz angebunden.

Häufige Probleme

Problem	Bedeutung	Mögliche Aktion
EL wirkt korrekt, Tail ist falsch	Erwarteter Verlust validiert keinen unerwarteten Verlust.	Verteilung, Korrelation und Konzentration prüfen.
Ratingklasse hat keine Ausfälle	Kalibrierungsstichprobe ist möglicherweise dünn.	Konservative Behandlung und Unsicherheit dokumentieren.
Operational VaR instabil	Tail-Verteilung oder Schwelle ist sensitiv.	Schwelle, Stichprobe und Stress Overlays prüfen.
DQ Findings ignoriert	Fehlende Stammdaten können Rating oder Exposure verzerren.	Kritische DQ Findings vor Ergebnisnutzung lösen.

Empfohlene Praxis

Expected-Loss-Validierung und Tail-Loss-Validierung trennen. Ein Modell kann für Monitoring nützlich sein und dennoch für Kapital-, Limit- oder Stresstestzwecke eingeschränkt bleiben.

Zweck

Model Validation beantwortet, ob ein Modell für seinen angegebenen Zweck geeignet ist, nicht ob es universell richtig ist. Dieser Artikel erklärt Annahmen, Limitationen, Benchmark-Evidenz und Data-Quality-Links im Portal.

Modellrisiko

Modellrisiko entsteht, wenn ein Modell falsch ist, falsch genutzt wird oder mit ungeeigneten Daten arbeitet. Praktisch lässt es sich als Checkliste zerlegen:

$$ \text{Modellfehler} \approx \text{Datenfehler} + \text{Methodenfehler} + \text{Implementierungsfehler} + \text{Nutzungsfehler} $$

Das ist keine formale Bilanzgleichung, sondern ein Review-Raster.

Evidenztypen

Evidenztyp	Was er zeigt
Closed-form Benchmark	Ergebnis passt zu einer unabhängigen Formel.
Frozen Baseline	Ergebnis bleibt stabil gegen akzeptierten Referenzoutput.
Toy Benchmark	Mechanik funktioniert auf kleinem deterministischem Datensatz.
Regression Evidence	Aktueller Output passt zu früher validiertem Verhalten.
Data Quality Evidence	Inputs erfüllen Vollständigkeits- und Plausibilitätsprüfungen.
Inventory-only	Modell ist katalogisiert, aber ausführbare Evidenz ist nicht angebunden.

Toleranz

Toleranz definiert die akzeptable numerische Abweichung:

$$ \Delta = |Actual - Expected| $$

Für absolute Toleranz:

$$ \Delta \le \epsilon $$

Für relative Toleranz:

$$ \frac{|Actual - Expected|}{\max(|Expected|,\epsilon_0)} \le \epsilon_r $$

Die Evidenz sollte die Konvention nennen. Bei kleinen Werten ist absolute Toleranz oft robuster, weil relative Fehler nahe null instabil werden.

Readiness-Status

Status	Bedeutung
Green	Ausführbare Evidenz hat für den angegebenen Scope bestanden.
Amber	Evidenz ist teilweise, toy-only oder wesentlich eingeschränkt.
Red	Kritischer Validierungscheck ist fehlgeschlagen.
Unknown	Keine ausführbare Evidenz oder nur Inventareintrag.

Green bedeutet keine regulatorische Freigabe. Es bedeutet nur, dass das Modell den publizierten Evidenzscope bestanden hat.

Annahmen und Limitationen

Jede Model-Validation-Zeile sollte diese Punkte sichtbar machen:

Feld	Review-Frage
Zweck	Welches Ergebnis soll das Modell liefern?
Inputs	Sind alle benötigten Markt- und Stammdaten vorhanden?
Outputs	Sind die Outputs für den Business Use Case sinnvoll?
Benchmark	Gibt es eine unabhängige oder deterministische Referenz?
Limitationen	Wo darf das Modell nicht verwendet werden?
DQ-Link	Sind Inputqualitätschecks bestanden oder offen?

Data-Quality-Link

Das Model Validation Dashboard verknüpft Modellevidenz mit Data Quality Findings. Das ist wichtig, weil ein mathematisch korrektes Modell bei falschen Inputs trotzdem falsche Ergebnisse erzeugt.

Typische Beispiele:

DQ Finding	Auswirkung auf das Modell
Fehlendes Curve Mapping	Bewertung und Sensitivität sind nicht belastbar.
Fehlendes Fixing	Inflation- oder Floating-Rate-Cashflows können falsch sein.
Fehlender Volatilitätsquote	Optionsbewertung und Vega-VaR können unvollständig sein.
Ungültige Maturity oder Coupon	Cashflowmodell kann falschen Schedule erzeugen.

Validierungsablauf

• Modellzweck und Modellfamilie prüfen.
• Validierungsportfolio und Marktdaten prüfen.
• Evidenztabelle des relevanten Modells öffnen.
• Expected, Actual und Tolerance vergleichen.
• Limitationen und DQ Findings prüfen.
• Bestätigen, ob der Readiness-Status zur Evidenz passt.

Häufige Probleme

Problem	Bedeutung	Mögliche Aktion
Green mit Limitation	Modell hat nur innerhalb eines angegebenen Scopes bestanden.	Limitation vor Ergebnisnutzung lesen.
Unknown-Modell	Inventar existiert, Evidenz ist nicht angebunden.	Nicht als validiert verwenden.
Benchmark-Abweichung	Expected und Actual liegen außerhalb Toleranz.	Daten, Konvention und Implementierungspfad prüfen.
DQ-Link ist rot	Inputs sind nicht sauber genug.	DQ Issue vor Abnahme lösen.

Empfohlene Praxis

Model Validation als Evidenzspur nutzen. Entscheidend ist nicht, ob ein Modell im Katalog steht, sondern ob die publizierte Evidenz genau das Ergebnis unterstützt, auf das man sich verlassen möchte.

Zweck

Die Risikokonfiguration beschreibt, welche Risikofaktoren existieren, wie sie fachlich gruppiert werden und welche Modelle daraus Szenarien, Sensitivitäten, Curvature-Resultate oder historische Simulationen erzeugen. Sie verbindet Marktdaten, Szenariologik, Modellabhängigkeiten und Reporting-Dimensionen.

Die wichtigsten Objekte sind:

Objekt	Aufgabe
Risk Source	Herkunft oder Datenfamilie von Risikoinformationen, zum Beispiel Marktdaten, Stressdefinitionen oder FRTB-Metadaten.
Risk Factor Group	Fachliche Gruppe von Risikofaktoren mit einem FactorType, optionaler Währung und Metadaten.
Risk Factor	Einzelner schockbarer oder auswertbarer Faktor innerhalb einer Gruppe.
Risk Model	Modellkonfiguration, die Zeitraum, Measure Type, Scenario Count, Shift Types, Shifts und Abhängigkeiten bündelt.
Shift Type Map	Zuordnung, wie ein FactorType in einem Modell geschockt wird.
Shift	Konkreter Schock für einen Faktor, eine Faktorgruppe oder einen gefilterten Scope.

Risk Sources

Risk Sources beschreiben die Herkunft der Risikoinformation. Sie sind bewusst generisch gehalten, weil unterschiedliche Modellfamilien verschiedene Informationen benötigen. Der wichtigste fachliche Inhalt steckt häufig in MetadataJson.

Typische Inhalte sind:

Inhalt	Bedeutung
FRTB-Position-Metadaten	Securitisation, Credit Quality, DRC Type, LGD-Notional-Logik oder Asset Class.
Marktdatenquelle	Herkunft von Kurven, Volatilitäten, Credit Spreads oder Equity-Daten.
Szenarioquelle	Herkunft historischer oder synthetischer Szenarien.
Modellkontext	Hinweise, für welche Modellfamilie die Source gedacht ist.

Wichtig: Eine Risk Source ist nicht automatisch ein aktiver Faktor. Sie ist Kontext. Der schockbare Faktor entsteht über Risk Factor Groups und Risk Factors.

Risk Factor Groups

Risk Factor Groups bilden fachliche Buckets wie Rates, FX, Equity, Credit Spread, Commodity, Volatility oder Theta. Die Gruppe trägt den FactorType, optional eine Currency und Metadaten.

Feld	Bedeutung
Name	Fachlicher Gruppenname. Er sollte stabil und in Ergebnissen lesbar sein.
IsActive	Steuert, ob die Gruppe für Auswahl, Modellaufbau und Checks berücksichtigt werden soll.
FactorType	Technische und fachliche Risikofaktorart. Sie muss zu Shifts und Ergebnissen passen.
Currency	Währungskontext, relevant vor allem für IR, FX, Credit und Reporting.
MetadataJson	Zusatzinformationen, insbesondere FRTB/SBA/IMA-Klassifikationen.

FactorType

FactorType bestimmt, welche Ergebnisspalten, Shift-Logik und Dashboards den Faktor erwarten.

FactorType	Typische Bedeutung
EqDelta	Equity-Preis- oder Index-Delta.
FxDelta	FX-Spot- oder FX-Kurvenrisiko.
IrDelta	Zinskurven-Delta, inklusive Tenorstruktur.
CmDelta	Commodity-Delta.
CsDelta	Credit-Spread-Delta.
EqVega	Equity-Volatilitätsrisiko.
FxVega	FX-Volatilitätsrisiko.
CmVega	Commodity-Volatilitätsrisiko.
IrVega	Zinsvolatilitätsrisiko, zum Beispiel Caps/Floors/Swaptions.
CsVega	Credit-Spread-Volatilitätsrisiko.
Theta	Zeitablauf- oder Bewertungszeitrisiko.
Epsilon	Residual-, Cross- oder modellinterner Faktor, nur verwenden wenn die Modelllogik ihn explizit erwartet.
None	Nicht produktiv für echte Risikofaktoren.

Stolperstelle: FactorType muss konsistent über Risk Factor Group, Shift Type Map, Shift und Ergebnisverarbeitung sein. Ein IrDelta-Faktor mit einem EqDelta-Shift wird in der Regel nicht so verarbeitet, wie fachlich erwartet.

Risk Factors

Ein Risk Factor ist der konkrete Faktor innerhalb einer Gruppe. Er wird in Shifts referenziert und erscheint in Resultaten, Aggregationen oder FRTB-NMRF-Analysen.

Feld	Bedeutung
Name	Anzeigename und häufig auch Ergebnisdimension.
Key	Stabiler technischer Schlüssel.
MarketKey	Bezug zum Marktdatenobjekt, zum Beispiel Kurve, Index, Quote oder Surface.
InternalKey	Interner Schlüssel für Modell- oder Engine-spezifische Zuordnung.
Bucket	Fachlicher Bucket, z. B. Tenor, Sector, Currency Pair oder Rating Bucket.
RiskFactorKind	Beschreibt, welche Art von Faktor oder Schockanwendung vorliegt.
MetadataJson	Zusätzliche Klassifikation, z. B. FRTB-SBA/IMA-Attribute.

RiskFactorKind

RiskFactorKind	Verwendung
Quote	Faktor wird direkt aus einem Quote oder Marktdatenpunkt abgeleitet. Geeignet für einfache Preis-, FX- oder Spread-Faktoren.
Shift	Faktor ist primär ein Schockziel. Geeignet für Szenariodefinitionen, wenn die Marktdatenauflösung über Filter oder Engine-Logik erfolgt.
Spread	Faktor repräsentiert Spread-Risiko, z. B. Credit Spread oder Basis Spread.
Volatility	Faktor repräsentiert Volatilitätsrisiko oder Surface-Punkte.

Stolperstelle: RiskFactorKind ist nicht dasselbe wie FactorType. FactorType sagt, welche Risikoklasse betroffen ist; RiskFactorKind sagt, wie der Faktor fachlich/technisch angewendet wird.

Risk Models

Risk Models definieren, wie Resultate erzeugt werden. Ein Modell kann historische Simulation, Stress, Sensitivitäten oder Curvature berechnen. Es enthält globale Parameter und mehrere Detailtabs.

Feld	Bedeutung
Name	Modellname, der in Workflows, Resultaten und Reports sichtbar ist.
IsActive	Nur aktive Modelle sollten in produktiven Workflows verwendet werden.
Reference	Optionaler Referenzname für Modellfamilie oder Methodik.
MeasureType	Hauptart der Berechnung.
SimulationPassMode	Steuert spezielle Pass-Logik, z. B. FRTB-IMA-Liquidity-Horizon.
PeriodStart	Startpunkt für historische Fenster oder periodische Modelle.
FixedPeriod	Feste Länge des Beobachtungszeitraums, falls das Modell sie nutzt.
HoldingPeriod	Haltedauer für VaR/ES oder Szenarioskalierung.
ScenarioCount	Anzahl der generierten oder gelesenen Szenarien.
ScenarioPopulation	Grundgesamtheit, aus der Szenarien gezogen oder gefiltert werden.
IgnoreFilters	Modell ignoriert bestimmte Selektionsfilter; nur einsetzen, wenn fachlich gewollt.

MeasureType

MeasureType	Bedeutung
HistSim	Historische Simulation, typischerweise für VaR/ES oder historische Szenarioverteilung.
StressSim	Stresssimulation mit expliziten Stressszenarien oder Szenariosets.
Sensitivity	Einzel- oder Mehrfaktor-Sensitivitäten, z. B. PV01, Delta, Vega.
Curvature	Up/Down-Schocks und nichtlineare Risikobeiträge, z. B. FRTB Curvature.

SimulationPassMode

SimulationPassMode	Bedeutung
Default	Normale Modellberechnung ohne spezielle Pass-Aufteilung.
FrtbImaLiquidityHorizon	Spezielle Pass-Logik für FRTB IMA Liquidity Horizons. Ergebnisse können nach Horizon oder Pass aggregiert werden.

Shift Type Maps

Shift Type Maps definieren, wie ein FactorType im Modell geschockt wird.

ShiftType	Bedeutung
None	Kein produktiver Schocktyp; nur für Platzhalter oder deaktivierte Konfiguration geeignet.
Absolute	Additiver Schock, z. B. +1 bp, +0.01 oder absoluter Spread-Schock.
Relative	Multiplikativer/prozentualer Schock, z. B. +1% auf einen Quote.
Compressed	Komprimierter Vektor oder serialisierte Szenariodarstellung. Häufig für große historische Szenariosets.
Log	Logarithmischer Return- oder Log-Shift, typisch für Preis- oder FX-Zeitreihen.

Die Map ist modellweit. Wenn ein Modell IrDelta als Absolute definiert, sollten die konkreten IR-Shifts denselben fachlichen Ansatz verwenden.

Shifts

Shifts sind die konkreten Szenario- oder Sensitivitätsdefinitionen. Sie können an einen bestimmten Risk Factor gebunden sein oder über Filter mehrere Faktoren treffen.

Feld	Bedeutung
ScenarioSet	Gruppiert Shifts in ein Szenario oder eine Szenariofamilie.
Name	Lesbarer Name des Schocks.
FactorType	Risikoklasse des Schocks.
Abs	Absoluter Schockwert.
Rel	Relativer Schockwert.
Scale	Skalierungsfaktor, häufig für Horizon-, Volatilitäts- oder Periodenanpassung.
RiskFactor	Explizit betroffener Faktor. Fehlt er, kann der Shift über Filter oder auf alle Faktoren wirken.
FilterBody	Filterausdruck für faktor- oder instrumentbezogene Auswahl.

Abs, Rel und Scale

Abs und Rel sollten nicht beliebig kombiniert werden. In vielen Modellen ist genau einer der Werte fachlich führend. Scale ist ein Multiplikator und sollte dokumentiert sein, weil er Shocks still vergrößern oder verkleinern kann.

Beispiele:

Fall	Typische Konfiguration
PV01 für Zinskurven	FactorType = IrDelta, ShiftType = Absolute, kleiner absoluter bp-Schock.
Equity-Preis-Schock	FactorType = EqDelta, ShiftType = Relative, relativer Prozent-Schock.
FX-Historical Simulation	FactorType = FxDelta, ShiftType = Log oder Compressed, abhängig vom Vektorformat.
Vega-Sensitivität	Vega-FactorType, meist absoluter Volatilitätsschock.
FRTB Curvature	Up/Down-Shifts, MeasureType = Curvature, konsistente FactorType-Auswahl.

Modellabhängigkeiten

Im Tab Dependencies kann ein Risk Model andere Modelle referenzieren. Das ist wichtig, wenn ein Modell Vorresultate benötigt, z. B. Preise vor Sensitivitäten, Simulation vor Aggregation oder Basis-Szenarien vor Curvature.

Abhängigkeiten sollten zyklusfrei sein. Eine zirkuläre Abhängigkeit kann Workflows blockieren oder zu unklarer Reihenfolge führen.

FRTB- und Metadaten-Besonderheiten

MetadataJson kann FRTB/SBA/IMA-Informationen tragen:

Bereich	Typische Attribute
GIRR	Interest-rate category, Currency, Basis Reference Currency.
Equity	Sector, Economy, Size.
Commodity	Commodity Sector.
FX	Currency Pair oder Other Currency Pair.
Credit Spread	Sector, Credit Quality, Region, Tranche, Securitisation Asset Class.
IMA	Liquidity Horizon.
DRC	DRC Type, LGD-to-Notional-Verhalten.

Diese Metadaten beeinflussen Bucketing, Kapitalformeln, NMRF-Analysen und Reporting. Fehlende oder ungenaue Metadaten können fachlich korrekte Sensitivitätswerte in falsche regulatorische Buckets einsortieren.

Häufige Fehler

Fehler	Auswirkung
Risk Factor Group inaktiv, Risk Factors aktiv	Faktoren erscheinen eventuell nicht in Auswahl oder Modellaufbau.
FactorType passt nicht zum Shift Type Map	Shifts werden falsch interpretiert oder nicht angewendet.
Doppelte Factor Keys	Aggregation und Ergebniszuordnung werden mehrdeutig.
Fehlender RiskFactor bei spezifischem Shift	Shift wirkt zu breit oder nur über FilterBody.
IgnoreFilters aktiv ohne Begründung	Workflows können Positionen oder Faktoren einbeziehen, die der Benutzer nicht erwartet.
FRTB-Metadaten fehlen	SBA/IMA/NMRF-Reports können falsche Buckets oder unvollständige Ergebnisse zeigen.

Empfohlene Pflege

Ändern Sie Risikomodelle versioniert und mit klarer fachlicher Begründung. Prüfen Sie nach Änderungen mindestens:

• Sind Risk Factor Groups aktiv und FactorTypes korrekt?
• Haben alle produktiven Risk Factors stabile Keys?
• Stimmen Shift Type Maps mit den Shifts überein?
• Sind Szenariosets, Abs/Rel/Scale und Holding Period konsistent?
• Sind Modellabhängigkeiten vollständig und zyklusfrei?
• Sind FRTB- und IMA-Metadaten gepflegt, wenn regulatorische Reports betroffen sind?

Zweck

Machine-Learning-Modelle können Klassifikation, Prognose, Anomalieerkennung und Segmentierung in Risikoprozessen unterstützen. FRM Notes v0.37 behandelt typische überwachte und unüberwachte Methoden. Dieser Artikel erklärt die Validierungsaspekte, die für Risikomodelle wichtig sind.

Feature Scaling

Standardisierung transformiert ein Feature \(x\) in einen z-Score:

$$ z=\frac{x-\mu}{\sigma} $$

Min-Max-Normalisierung bildet Werte in einen festen Bereich ab:

$$ x'=\frac{x-\min(x)}{\max(x)-\min(x)} $$

Scaling muss auf Trainingsdaten gefittet und danach konsistent auf Validierungs- und Produktionsdaten angewandt werden.

Regularisierung in Regressionen

Ridge Regression bestraft große Koeffizienten:

$$ \min_\beta \left( \sum_i (y_i - x_i^\top\beta)^2 + \lambda \sum_j \beta_j^2 \right) $$

LASSO verwendet eine Absolutwertstrafe und kann Koeffizienten auf null setzen:

$$ \min_\beta \left( \sum_i (y_i - x_i^\top\beta)^2 + \lambda \sum_j |\beta_j| \right) $$

Elastic Net kombiniert beide:

$$ \lambda\left(\alpha\sum_j|\beta_j|+(1-\alpha)\sum_j\beta_j^2\right) $$

Logistische Modelle

Für binäre Zielgrößen bildet logistische Regression einen Score auf eine Wahrscheinlichkeit ab:

$$ p=\frac{1}{1+e^{-z}} $$

wobei:

$$ z=\beta_0+\beta_1x_1+\ldots+\beta_kx_k $$

In Risikoanwendungen muss die ausgegebene Wahrscheinlichkeit kalibriert und überwacht werden.

Bäume und Klassifikation

Decision Trees teilen Daten in Gruppen. Typische Split-Kriterien sind Gini Impurity:

$$ Gini = 1-\sum_k p_k^2 $$

und Entropie:

$$ H = -\sum_k p_k\ln(p_k) $$

Baummodelle sind lokal gut prüfbar, können aber ohne Tiefe-, Blattgrößen- oder Ensemble-Kontrollen überfitten.

Distanzbasierte Modelle

Für Beobachtungen \(x\) und \(y\) ist die euklidische Distanz:

$$ d(x,y)=\sqrt{\sum_i(x_i-y_i)^2} $$

Manhattan-Distanz lautet:

$$ d(x,y)=\sum_i |x_i-y_i| $$

Distanzbasierte Modelle sind empfindlich gegenüber Feature Scaling und fehlenden Daten.

Validierungskontrollen

Kontrolle	Warum sie wichtig ist
Train/Validation Split	Verhindert Testen auf denselben Daten, die fürs Fitten genutzt wurden.
K-fold Cross Validation	Prüft Stabilität über Stichproben.
Kalibrierung	Stellt sicher, dass Wahrscheinlichkeiten beobachteten Häufigkeiten entsprechen.
Drift Monitoring	Erkennt Änderungen der Input- oder Zielverteilung.
Explainability	Unterstützt Review, Challenge und fachliche Nutzung.
DQ Checks	Verhindert, dass fehlende oder unplausible Features falsche Vorhersagen treiben.

Häufige Probleme

Problem	Bedeutung	Mögliche Aktion
Hohe Trainingsgenauigkeit, schwache Validierung	Overfitting.	Modell vereinfachen oder Regularisierung erhöhen.
Wahrscheinlichkeitsklassen falsch kalibriert	Scores ranken Risiko, schätzen aber Wahrscheinlichkeit falsch.	Rekalibrieren und erneut testen.
Feature Drift	Produktionsdaten unterscheiden sich von Trainingsdaten.	Population Stability und Retrain-Policy prüfen.
Unerklärte Entscheidung	Modell ist schwer challengable.	Explainability und Override Review ergänzen.

Empfohlene Praxis

Für Risikoanwendungen sollte ML-Validierung statistische Performance, Stabilität, Erklärbarkeit und Datenqualität kombinieren. Ein Modell sollte nicht nur wegen einer guten Headline Accuracy produktiv genutzt werden.

Quelle und Scope

Dieser Artikel fasst den Sensitivities-based Approach aus dem Basel-Standardised-Approach für Marktrisiko zusammen. Grundlage sind die lokale PDF resources/d457.pdf und die BIS-Veröffentlichung:

<https://www.bis.org/bcbs/publ/d457.htm>

Der Fokus liegt ausschließlich auf SBA/SBM: Delta, Vega und Curvature. IMA, P&L Attribution, Backtesting, Default Risk Charge und Residual Risk Add-on werden hier nicht zusammengefasst.

Terminologie

Begriff	Bedeutung
FRTB SBA	Gebräuchliche Kurzform für den sensitivitätsbasierten Ansatz im Standardised Approach.
SBM	Sensitivities-based Method; Begriff im Basel-Text.
Risk Class	GIRR, CSR, Equity, Commodity oder FX.
Bucket	Regulatorische Gruppierung innerhalb einer Risk Class.
Weighted Sensitivity	Netto-Sensitivität multipliziert mit regulatorischem Risk Weight.

Berechnungsstruktur

Für jede Risk Class werden drei Komponenten berechnet:

Komponente	Gilt für	Wichtigster Input
Delta	Lineare Exponierung gegenüber vorgeschriebenen Risk Factors	Netto-Sensitivitäten
Vega	Optionalität gegenüber impliziter Volatilität	Vega-Sensitivitäten
Curvature	Nichtlinearer Verlust über Delta hinaus	Up/Down-Shock-Revaluations

Die gesamte SBA Charge wird unter Medium-, High- und Low-Correlation-Szenarien berechnet. Maßgeblich ist das größte Szenarioergebnis.

Kernformeln

Weighted Sensitivity:

$$ WS_k = RW_k \cdot s_k $$

Within-Bucket Aggregation:

$$ K_b = \sqrt{ \max\left( 0, \sum_k WS_k^2 + \sum_k \sum_{l \ne k} \rho_{kl} WS_k WS_l \right) } $$

Across-Bucket Aggregation:

$$ K = \sqrt{ \max\left( 0, \sum_b K_b^2 + \sum_b \sum_{c \ne b} \gamma_{bc} S_b S_c \right) } $$

Correlation-Szenarien:

$$ \rho^{high}_{kl} = \min(1, 1.25 \rho_{kl}) $$

$$ \rho^{low}_{kl} = \max(2\rho_{kl} - 1,\; 0.75\rho_{kl}) $$

Die gleiche High/Low-Transformation gilt für Bucket-Korrelationen \( \gamma_{bc} \).

SBA Capital:

$$ K_{SBA} = \max_{scenario \in \{low, medium, high\}} \sum_{risk\ classes} (K_{\Delta} + K_{Vega} + K_{Curvature}) $$

Curvature-Formel

Curvature misst den inkrementellen Verlust nach Abzug des Delta-Effekts. Für Risk Factor \(k\):

$$ CVR_k^+ = -\sum_i \left[ V_i(x_k^{+}) - V_i(x_k) - RW_k^{curv} \cdot s_{ik} \right] $$

$$ CVR_k^- = -\sum_i \left[ V_i(x_k^{-}) - V_i(x_k) + RW_k^{curv} \cdot s_{ik} \right] $$

Die Bucket Charge verwendet das größere Upward- oder Downward-Szenario nach regulatorischer Korrelationsaggregation.

GIRR

General Interest Rate Risk wird nach Währung gebucketed. Jede Währung ist ein eigener Bucket. Delta GIRR nutzt risikofreie Kurventenors sowie Inflation und Cross-Currency-Basis als zusätzliche Risk Factors.

GIRR Delta Shock Table

Tenor	0.25Y	0.5Y	1Y	2Y	3Y	5Y	10Y	15Y	20Y	30Y
Risk Weight	1.7%	1.7%	1.6%	1.3%	1.2%	1.1%	1.1%	1.1%	1.1%	1.1%

GIRR Special Factor	Risk Weight
Inflation	1.6%
Cross-currency basis	1.6%

Für spezifizierte Hauptwährungen kann die Basel-Square-Root-of-Two-Reduktion zulässig sein.

CSR Non-Securitisation

Credit Spread Risk Non-Securitisation wird nach Credit Quality und Sector gebucketed. Investment Grade, High Yield/Non-Rated und Index-Buckets erhalten unterschiedliche Risk Weights.

CSR Non-Securitisation Risk Weights

Bucket Range	Beschreibung	Risk Weights
1-8	Investment Grade Sectors und Covered Bonds	0.5% bis 5.0%
9-16	High Yield, Non-Rated und Other Sector	2.0% bis 12.0%
17	IG Indices	1.5%
18	HY Indices	5.0%

Auffällig hohe Gewichte sind 12.0% für Financials in HY/Non-Rated und 12.0% für Other Sector.

Equity

Equity Risk wird nach Market Cap, Economy und Sector gebucketed. Der Standard unterscheidet Large versus Small Market Cap, Advanced versus Emerging Market und Index Buckets.

Equity Delta Shock Table

Bucket	Equity Spot Risk Weight	Equity Repo Risk Weight
1	55%	0.55%
2	60%	0.60%
3	45%	0.45%
4	55%	0.55%
5	30%	0.30%
6	35%	0.35%
7	40%	0.40%
8	50%	0.50%
9	70%	0.70%
10	50%	0.50%
11	70%	0.70%
12	15%	0.15%
13	25%	0.25%

Equity Vega und Curvature betreffen optionale Exponierung. Equity Repo Rates werden nicht wie Equity-Spot-Optionalität behandelt.

Commodity

Commodity Risk wird in 11 Commodity Groups unterteilt. Die Unterscheidung ist wesentlich, weil Energy, Freight, Metals, Agriculture und Other Commodities sehr unterschiedliche Schocks haben.

Commodity Shock Table

Bucket	Commodity Group	Risk Weight
1	Energy - solid combustibles	30%
2	Energy - liquid combustibles	35%
3	Energy - electricity and carbon trading	60%
4	Freight	80%
5	Metals - non-precious	40%
6	Gaseous combustibles	45%
7	Precious metals including gold	20%
8	Grains and oilseed	35%
9	Livestock and dairy	25%
10	Softs and other agriculturals	35%
11	Other commodity	50%

Electricity und Freight werden gesondert betrachtet, weil Delivery Interval, Region, Route und Week das Risiko wesentlich verändern können.

FX

FX Risk verwendet einen Bucket je Wechselkurs zwischen Instrumentwährung und Reporting Currency.

FX Item	Value
Delta FX Risk Weight	15%
Across-Bucket Correlation	60%

Spezifizierte Currency Pairs und First-Order Crosses können die Basel-Square-Root-of-Two-Reduktion verwenden, sofern zulässig.

Vega Risk

Vega nutzt dieselben Bucket-Definitionen wie Delta. Der wesentliche Unterschied ist der Liquidity Horizon je Risk Class.

Vega Liquidity Horizon and Risk Weight Table

Risk Class	Liquidity Horizon	Vega Risk Weight
GIRR	60	100%
CSR non-securitisation	120	100%
CSR securitisation CTP	120	100%
CSR securitisation non-CTP	120	100%
Equity large cap and indices	20	77.78%
Equity small cap and other sector	60	100%
Commodity	120	100%
FX	40	100%

Vega Risk Weight Formula:

$$ RW_k = \min\left( RW_{\sigma} \sqrt{\frac{LH_{risk\ class}}{10}}, 100\% \right) ,\quad RW_{\sigma}=55\% $$

Curvature Risk

Curvature Buckets replizieren grundsätzlich die Delta Buckets, sofern nichts anderes festgelegt ist. FX- und Equity-Curvature-Schocks sind relative Shifts in Höhe der jeweiligen Delta Risk Weights. Für GIRR, CSR und Commodity werden Schocks auf Kurven oder Risk Factors angewendet und der Delta-Anteil danach abgezogen.

Asset-Class Distinctions

Risk Class	Bucket Basis	Delta Distinction	Vega/Curvature Distinction
GIRR	Currency	Tenor, Curve, Inflation, Cross-Currency Basis	Keine Curvature für Inflation und Cross-Currency Basis
CSR	Credit Quality und Sector	Tenor und Issuer Spread	Separate Behandlung für Non-Sec, Securitisation CTP und Non-CTP
Equity	Market Cap, Economy, Sector	Spot und Repo Rates	Repo Rates nicht im Fokus von Vega/Curvature
Commodity	Commodity Group	Spot Risk by Commodity Bucket	Delivery, Route und Region können relevant sein
FX	Currency Pair	Exchange Rate zu Reporting/Base Currency	FX Options folgen FX Vega und Curvature Rules

Interpretation für Anwender

SBA-Ergebnisse sind regulatorische Standardised Charges unter vorgeschriebenen Schocks und Korrelationen. Sie sind nicht identisch mit Desk VaR, Historical Simulation Loss, Model Approval oder einem internen Kapitalmodell.

Quelle und Scope

Dieser Artikel fasst den Basel-Standard 2016 für Interest Rate Risk in the Banking Book zusammen. Grundlage sind die lokale PDF resources/d368.pdf und die BIS-Veröffentlichung:

<https://www.bis.org/bcbs/publ/d368.htm>

Der Fokus liegt auf der fachlichen Interpretation im Portal: EVE, NII, vorgeschriebene Zins-Schocks, Verhaltensannahmen und Standardised-Framework-Rechnung. Interne Modellgovernance und lokale Meldeformate werden hier nicht beschrieben.

Zweck

IRRBB misst, wie Bankbuch-Erträge und ökonomischer Wert auf Zinsänderungen reagieren. Es ist vom Marktrisiko des Handelsbuchs zu trennen. Entscheidend ist, ob Assets, Liabilities und Off-Balance-Sheet-Positionen zu unterschiedlichen Zeitpunkten, nach unterschiedlichen Konventionen oder mit eingebetteten Kundenoptionen repricen.

Kennzahl	Bedeutung	Typische Verwendung
EVE	Economic Value of Equity; Barwertänderung der Bankbuch-Cashflows unter Zinsschocks.	Strukturelle Wert-Sensitivität und Outlier-Prüfung.
NII	Net Interest Income; Ergebniseffekt über einen Forward-Horizont.	Earnings-Sensitivität und Planung unter geschockten Zinsen.
Delta EVE	Differenz zwischen Base-EVE und Shocked-EVE, inklusive Options-Add-ons falls relevant.	Zentrale Wertkennzahl im Standardised Framework.
Delta NII	Differenz zwischen Base-NII und Shocked-NII.	Earnings-Kennzahl für vorgeschriebene Szenarien.

Standardised-Framework-Stufen

Das Basel Standardised Framework lässt sich als fünfstufiger Ablauf lesen:

Stufe	Inhalt
1	Bankbuchpositionen als standardisierbar, eingeschränkt standardisierbar oder nicht standardisierbar klassifizieren.
2	Notional Repricing Cashflows in Laufzeit-Buckets einsortieren.
3	EVE-Änderungen je wesentlicher Währung für die vorgeschriebenen Schocks berechnen.
4	Wertänderungen automatischer Zinsoptionen ergänzen.
5	Die schlechteste aggregierte EVE-Reduktion über die vorgeschriebenen Szenarien verwenden.

Repricing-Cashflows

Die standardisierte EVE-Rechnung verwendet Notional Repricing Cashflows. Fixed-Rate-Positionen werden typischerweise nach vertraglicher Fälligkeit einsortiert. Floating-Rate-Positionen werden typischerweise zum nächsten Reset- oder Repricing-Termin einsortiert.

Bucket	Mittelpunkt
Overnight	0.0028Y
O/N bis 1M	0.0417Y
1M bis 3M	0.1667Y
3M bis 6M	0.375Y
6M bis 9M	0.625Y
9M bis 1Y	0.875Y
1Y bis 1.5Y	1.25Y
1.5Y bis 2Y	1.75Y
2Y bis 3Y	2.5Y
3Y bis 4Y	3.5Y
4Y bis 5Y	4.5Y
5Y bis 6Y	5.5Y
6Y bis 7Y	6.5Y
7Y bis 8Y	7.5Y
8Y bis 9Y	8.5Y
9Y bis 10Y	9.5Y
10Y bis 15Y	12.5Y
15Y bis 20Y	17.5Y
Mehr als 20Y	25Y

Non-Maturity Deposits

Non-Maturity Deposits werden in Retail und Wholesale unterteilt. Retail wird zusätzlich in transactional und non-transactional getrennt. Stabile Bestände können als Core Deposits behandelt werden, jedoch nur innerhalb regulatorischer Caps. Nicht-Core-Bestände werden overnight behandelt.

Kategorie	Cap für Core Balance	Durchschnittliche Laufzeit-Cap
Retail transactional	90%	5.0Y
Retail non-transactional	70%	4.5Y
Wholesale	50%	4.0Y

Im Portal werden NMDs als behavioral Rates-Instrument interpretiert. Das Runoff-Profil erzeugt die Cashflow-Verteilung für den stabilen Anteil; Segment-Cap und durchschnittliche Laufzeit begrenzen die zulässige Behavioral Maturity. Wenn ein Zero-Floor aktiv ist, kommt ein Normal-/Bachelier-Floor-Wert hinzu, der eine gemappte Normal-Volatilitätsfläche benötigt.

Ergebnis	NMD-spezifische Lesart
EVE	Wird stark von Core Balance, Runoff-Profil und durchschnittlicher Laufzeit beeinflusst.
NII	Hängt von Kundensatz, Pass-through und Repricing-Annahme ab.
PV01	Misst Kurvenexposure aus Runoff-Duration und Diskontierung.
IrVega	Misst den Wertbeitrag der Normal-Volatilitätsfläche für die Floor-Komponente.

Wenn NMD-Ergebnisse auffällig sind, zuerst Core-Balance-Cap, Runoff-WAL, IncludeFloorValue, FloorStrike und Surface Mapping prüfen.

Verhaltensoptionen

Verhaltensoptionen sind wesentlich, weil Kundenverhalten bei Zinsänderungen anders ausfallen kann. Das Standardised Framework gibt Szenario-Skalare für Kredit-Prepayments und Term-Deposit-Redemptions vor.

Prepayment Rate im Szenario \(i\), Portfolio \(p\), Währung \(c\):

$$ CPR^p_{i,c} = \min\left(1,\gamma_i \cdot CPR^p_{0,c}\right) $$

Szenario	Prepayment-Skalar \( \gamma_i \)
Parallel up	0.8
Parallel down	1.2
Steepener	0.8
Flattener	1.2
Short-rate up	0.8
Short-rate down	1.2

Prepayment-adjustierter Cashflow:

$$ CF^p_{i,c}(k) = CF^S_{i,c}(k) + CPR^p_{i,c} \cdot N^p_{i,c}(k-1) $$

Term-Deposit-Redemption Rate:

$$ TDRR^p_{i,c} = \min\left(1,u_i \cdot TDRR^p_{0,c}\right) $$

Szenario	Term-Deposit-Skalar \(u_i\)
Parallel up	1.2
Parallel down	0.8
Steepener	0.8
Flattener	1.2
Short-rate up	1.2
Short-rate down	0.8

Early-Redemption-Repricing-Cashflow:

$$ CF^p_{i,c}(1) = TD^p_{0,c} \cdot TDRR^p_{i,c} $$

EVE-Formeln

Discount Factor für Schockszenario \(i\), Währung \(c\), Bucket-Mittelpunkt \(t_k\):

$$ DF_{i,c}(t_k) = \exp\left(-R_{i,c}(t_k)t_k\right) $$

Net EVE im Szenario \(i\):

$$ EVE^{net}_{i,c} = \sum_{k=1}^{K} CF_{i,c}(k) \cdot DF_{i,c}(t_k) $$

EVE-Verlust im Szenario \(i\), inklusive Add-on für automatische Optionen \(KAO_{i,c}\):

$$ \Delta EVE_{i,c} = \sum_{k=1}^{K} CF_{0,c}(k)DF_{0,c}(t_k) - \sum_{k=1}^{K} CF_{i,c}(k)DF_{i,c}(t_k) + KAO_{i,c} $$

Die standardisierte EVE-Kennzahl verwendet den größten positiven aggregierten Verlust über die sechs Szenarien:

$$ \Delta EVE = \max_i \left( \max\left(0,\sum_c \Delta EVE_{i,c}\right) \right) $$

In der standardisierten Aggregation tragen nur Währungen mit positivem EVE-Verlust zur aggregierten Verlustkennzahl bei.

Vorgeschriebene EVE-Schocks

Die sechs EVE-Szenarien sind Parallel up, Parallel down, Steepener, Flattener, Short-rate up und Short-rate down.

Währung	Parallel-Schock	Short-rate-Schock	Long-rate-Schock
EUR	200 bp	250 bp	100 bp
USD	200 bp	300 bp	150 bp
GBP	250 bp	300 bp	150 bp
CHF	100 bp	150 bp	100 bp
JPY	100 bp	100 bp	100 bp
AUD	300 bp	450 bp	200 bp
CAD	200 bp	300 bp	150 bp
SEK	200 bp	300 bp	150 bp

Parallel-Schock:

$$ \Delta R_{parallel,c}(t_k) = \pm \bar{R}_{parallel,c} $$

Short-rate-Schock, mit \(x=4\):

$$ S_{short}(t_k) = e^{-t_k/x} $$

$$ \Delta R_{short,c}(t_k) = \pm \bar{R}_{short,c}S_{short}(t_k) $$

Long-rate-Schock:

$$ S_{long}(t_k) = 1 - S_{short}(t_k) $$

$$ \Delta R_{long,c}(t_k) = \pm \bar{R}_{long,c}S_{long}(t_k) $$

Steepener:

$$ \Delta R_{steepener,c}(t_k) = -0.65\left|\Delta R_{short,c}(t_k)\right| +

• 9\left|\Delta R_{long,c}(t_k)\right|

$$

Flattener:

$$ \Delta R_{flattener,c}(t_k) = +0.8\left|\Delta R_{short,c}(t_k)\right| -

• 6\left|\Delta R_{long,c}(t_k)\right|

$$

Aufseher können Floors für Post-Shock-Zinsen definieren. Der Basel-Text begrenzt diese Floors so, dass sie nicht größer als null sein dürfen.

Portfolio- und Asset-Unterscheidungen

Bereich	Interpretation
Fixed-Rate-Loans und Bonds	Hauptrisiko sind Maturity Mismatch und Discount-Curve-Schock.
Floating-Rate-Instrumente	Hauptrisiko sind Reset-Zeitpunkt und Basis zwischen Funding- und Asset-Kurven.
Non-Maturity Deposits	Behavioural-Maturity-Annahmen können EVE dominieren.
Prepayable Loans	Niedrigere Zinsen können Prepayments erhöhen und Asset Duration verkürzen.
Term Deposits	Höhere Zinsen können Early Redemption verstärken.
Automatische Optionen	Optionsbewertung muss Shocked Curve und vorgeschriebenen Volatilitätsstress berücksichtigen.

Outlier- und Disclosure-Kontext

Der Basel-Standard vergleicht das maximale \( \Delta EVE \) einer Bank mit Tier-1-Kapital. Die Outlier-Schwelle in d368 beträgt 15% des Tier-1-Kapitals. Banken legen außerdem EVE- und NII-Änderungen unter den vorgeschriebenen Schocks offen.

Das ist keine Aussage über lokale regulatorische Genehmigung. Portal-Ergebnisse sind als Modell-, Daten- und Szenarioevidenz im jeweils angezeigten Scope zu lesen.

Empfohlene Prüfung

Prüfe Kurvenwährung, Repricing-Buckets, NMD-Annahmen, Inputs für Verhaltensoptionen und Sign Convention, bevor ein IRRBB-Ergebnis interpretiert wird. Bei großen Bewegungen zuerst Base- und Shocked-Cashflow-Buckets vergleichen; danach prüfen, ob die Bewegung aus echter Duration, Kundenoptionsannahmen oder fehlenden Marktdaten stammt.

Zweck

Diese Beispiele zeigen kleine Rechnungen, mit denen Bewertungsmechanik validiert werden kann. Sie sind vereinfacht und dienen der Interpretation, nicht der Reproduktion produktiver Läufe.

Bond DCF Beispiel

Input	Wert
Notional	1.000.000
Jährlicher Coupon	3,00%
Discount Factor zum Coupondatum	0,9800
Discount Factor zur Endfälligkeit	0,9400

Cashflows werden einzeln diskontiert. Ein finaler Coupon von 30.000 und die Rückzahlung von 1.000.000 zur Endfälligkeit tragen bei:

$$ 1{.}030{.}000 \times 0{,}9400 $$

Swap Par-Rate Beispiel

Leg	Interpretation
Floating Leg	Projizierte Index-Coupons, diskontiert auf heute.
Fixed Leg	Fixe Coupons, diskontiert auf heute.
Fair Rate	Fester Zinssatz, bei dem beide Legs denselben Barwert haben.

Option Black-Style Beispiel

Input	Bedeutung
Forward	Erwarteter Underlying-Level unter dem Bewertungsmaß.
Strike	Ausübungslevel.
Volatilität	Annualisierter Unsicherheitsinput.
Expiry	Zeit bis zur Optionsausübung.

Höhere Volatilität erhöht üblicherweise den Optionswert, besonders bei Optionen nahe am Strike.

Kurvenbeispiel

Eine Kurve wandelt Marktquotes in Discount oder Projection Factors um. Ein einjähriger Zero Rate von 3% mit jährlicher Verzinsung impliziert ungefähr:

$$ \frac{1}{1{,}03} = 0{,}970873786 $$

$$ DF(t) = \frac{1}{(1+r)^t} $$

$$ ForwardRate(t_1,t_2) = \frac{\frac{DF(t_1)}{DF(t_2)} - 1}{yearFraction(t_1,t_2)} $$

Empfohlene Praxis

Nutzen Sie diese Beispiele zur Prüfung von Richtung und Größenordnung. Produktive Ergebnisse hängen zusätzlich von Kalendern, Day Counts, Interpolation, Settlement, Fixings und Modellkonventionen ab.

Zweck

Bonds und Swaps sind Rates-Instrumente. Ihre Ergebnisse werden vor allem durch Cashflows, Discount Curves und Projection Curves bestimmt.

Wichtige Felder

Feld	Bedeutung
Notional	Kapitalbetrag für Coupons und Rückzahlung.
Coupon oder Fixed Rate	Zinssatz auf das Notional.
Payment Schedule	Daten, an denen Cashflows entstehen.
Curve Mapping	Discount- und Projection-Kurven für die Bewertung.

Ergebnisinterpretation

Bei Bonds vergleichen Sie Clean Price, Dirty Price, Accrued Interest und Present Value. Bei Swaps vergleichen Sie Leg NPVs, Gesamt-NPV, Fair Rate und Sensitivitäten.

Häufige Probleme

Problem	Bedeutung	Mögliche Aktion
PV ist null	Instrument ist abgelaufen, Quantity ist null oder Bewertungsobjekt fehlt.	Maturity, Positionsgröße und Instrumentunterstützung prüfen.
Accrued wirkt falsch	Day Count oder Settlement-Konvention unterscheidet sich.	Coupon Schedule und Settlement Date prüfen.
Kurve fehlt	Curve Mapping ist unvollständig.	Marktdaten und Instrument-Stammdaten prüfen.

Zweck

Dieser Artikel erklärt die Instrumenttypen, die aktuell in den Portal-Validation-Packs und produktionsnahen Validierungssamples vertreten sind. Die Instrumente sind nach Assetklasse gruppiert. Jede Gruppe nennt Voraussetzungen, wichtige Konfigurationsfelder und Beispielkonfigurationen.

Die Beispiele sind bewusst kompakt. Produktive Positionen benötigen zusätzlich Portfolio-, Book-, Legal-Entity-, Counterparty- und Source-System-Metadaten.

Gemeinsame Voraussetzungen

Jedes Instrument benötigt genug Stammdaten, Marktdaten und Model Mapping, damit der richtige Bewertungs- und Simulationspfad gewählt werden kann.

Voraussetzung	Bedeutung
Instrument type	Kanonischer Typ wie FixedRateBond, InterestRateSwap, EuropeanVanillaOption oder HICPYYCap.
Trade id / name	Stabile ID und lesbarer Name für Evidenz und Dashboards.
Asset class	Rates, Equity, FX, Commodity, Inflation oder Hybrid.
Currency	Bewertungs- oder Reportingwährung.
Notional oder Quantity	Ökonomische Größe. Große Quantities können PV und Szenario-PnL dominieren.
Issue / start date	Schedule-Start oder Trade-Start.
Maturity	Endfälligkeit, Expiry oder Lieferdatum.
Day count	Accrual-Konvention, falls relevant.
Business day convention	Datumsanpassung, falls relevant.
Market-data mapping	Kurven, Quotes, Volatilitätsflächen, Fixings oder Indexstände.
Model mapping	Produktiver Builder-/Modellpfad für Bewertung und Simulation.

Validierungskapazitäten

Instrument-Validation-Packs prüfen typischerweise diese Fähigkeiten, soweit verfügbar:

Capability	Bedeutung
Pricing	Basisbewertung / PV / Preis.
Cashflows	Extrahierter Schedule oder Zahlungsansicht.
Sensis	Shifted Valuation und finite-difference Sensitivität.
Scenarios	Deterministische Szenariobewertung.
VaR	Historischer Simulationsvektor und Tail-Kennzahl.
DQ	Data-Quality-Prüfungen auf Stammdaten und Marktdaten.

Nicht jedes Instrument hat dieselbe Abdeckung. Nicht unterstützte oder teilweise angebundene Instrumente müssen Amber, Red oder Unknown zeigen, nicht Green.

Rates: Bonds

Implementierte bond-ähnliche Instrumente:

Instrument type	Use case	Aktueller Validierungsfokus
FixedRateBond	Vanilla Fixed-Coupon Bond.	Pricing, Cashflows, Sensis, Scenarios, VaR, DQ.
FloatingRateBond	Floating Rate Note.	Basic Bond Portfolio Coverage und Readiness.
ZeroBond	Zero-Coupon Bond.	Basic Bond Portfolio Coverage und Readiness.
CallableBond	Bond mit Issuer Call Optionalität.	Readiness Section; Coverage Gaps dokumentiert.
ConvertibleBond	Bond mit Equity Conversion Feature.	Hybrid/Readiness Section; Coverage Gaps dokumentiert.

Instrumentbeschreibungen

Instrument type	Beschreibung
FixedRateBond	Ein Fixed-Rate Bond zahlt einen bekannten Couponplan und Tilgung bei Fälligkeit. Damit adressiert man deterministische Rates-Bewertung, Accrued Interest, Cashflow-Validierung, Kurvendiskontierung und Bond-PV01/VaR.
FloatingRateBond	Ein Floating-Rate Bond bindet Coupons an einen Referenzindex oder eine Forwardkurve. Damit adressiert man Projection Curve Setup, Reset/Fixing-Behandlung und Floating-Cashflow-Readiness.
ZeroBond	Ein Zero-Coupon Bond hat keine laufenden Coupons und wird im Wesentlichen über Diskontierung bis Maturity bewertet. Damit adressiert man reine Discount-Factor-Validierung und einfache Kurvensensitivität.
CallableBond	Ein Callable Bond gibt dem Emittenten das Recht, vor Endfälligkeit zurückzuzahlen. Damit adressiert man Optionalität in Rates-Produkten, benötigt aber Call Schedule und Optionality-Model-Evidenz für uneingeschränkte Nutzung.
ConvertibleBond	Ein Convertible Bond kombiniert Bond-Cashflows mit einem Equity Conversion Feature. Damit adressiert man hybrides Rates/Equity-Risiko und benötigt sowohl Bond-Inputs als auch equity-option-ähnliche Inputs.

Voraussetzungen

Daten	Benötigt für
Discount curve	Pricing, PV01, Szenariobewertung und VaR.
Cashflow schedule fields	Coupon Dates, Maturity, Day Count und Frequency.
Settlement convention	Clean/dirty Price und Accrued Interest.
Credit/spread curve	Wenn Spread Discounting oder Credit Valuation aktiv ist.
Optionality data	Callable und Convertible Features.
Equity data	Convertible Conversion Feature.

Fixed-rate bond Beispielfelder

Feld	Wert
Trade id	VAL-BOND-FIXED-001
Instrument	FixedRateBond
Assetklasse	Rates
Währung	EUR
Notional	1.000.000
Coupon	3,00%
Issue date	2026-01-01
Maturity	2031-01-01
Coupon frequency	Annual
Day count	Actual360
Business day convention	ModifiedFollowing
Model hint	QLNet FixedRateBond + DiscountingBondEngine

Data Quality

Typische Bond-DQ-Prüfungen sind positive Notional, Maturity nach Issue Date, gültiger Coupon, Discount-Curve-Mapping und benötigte Marktdatenreferenzen.

Rates: Interest Rate Swaps

Instrument type	Use case	Aktueller Validierungsfokus
InterestRateSwap	Vanilla fixed-vs-floating IRS.	Pricing, Cashflows, Sensis, Scenarios, VaR, DQ.
NonMaturingDeposit	Einlage ohne vertragliche Endfälligkeit.	IRRBB, Pricing, Cashflows, Sensis, VaR, DQ mit Verhaltensannahmen.

Instrumentbeschreibung

Instrument type	Beschreibung
InterestRateSwap	Ein Interest Rate Swap tauscht feste und variable Zinscashflows. Damit adressiert man Hedge-Bewertung, Fixed/Floating Curve Setup, Swap-PV01, Key-Rate-Sensitivität und IR Historical Simulation.
NonMaturingDeposit	Ein Non-Maturity Deposit modelliert stabile und nicht stabile Einlagenbestände ohne vertragliche Fälligkeit. Damit adressiert man IRRBB-EVE, Behavioral Maturity, Core-Balance-Caps, Runoff-Cashflows und optionalen Zero-Floor-Vega. Details stehen im Artikel Non-Maturity Deposits.

Voraussetzungen

Daten	Benötigt für
Discount curve	Diskontierung beider Legs.
Forward curve	Floating Leg Projection.
Fixed leg frequency	Fixed Coupon Schedule.
Floating leg frequency	Reset- und Payment-Schedule.
Fixed rate und spread	Coupon Economics.
Swap direction	Payer- oder Receiver-Interpretation.
NMD segment und runoff profile	Für NMDs: Segment-Cap, Core Balance, gewichtete Laufzeit und Cashflow-Verteilung.
Normal-volatility surface	Für NMDs mit aktivem Floor: gemappte Normal-Volatilitätsfläche, kein instrument-lokaler Ersatz.

IRS Beispielfelder

Feld	Wert
Trade id	VAL-IRS-PAYER-ANNUAL-001
Trade name	IRS/EUR/PAYER/5Y/ANN-3M
Instrument	InterestRateSwap
Währung	EUR
Notional	1.000.000
Swap type	Payer
Fixed frequency	Annual
Floating frequency	Quarterly
Fixed rate	2,25%
Spread	0,10%
Issue date	2026-02-15
Maturity	2031-01-15
Day count	30E/360 fixed; Actual/360 floating

Rates: Caps, Floors und Collars

Instrument type	Use case	Aktueller Validierungsfokus
VanillaCapFloor	Zins-Cap oder Floor.	Pricing, Cashflows, Sensis, Scenarios, VaR, DQ.
VanillaCollar	Collar-Struktur.	Pricing, Cashflows, Sensis, Scenarios, VaR, DQ.

Instrumentbeschreibungen

Instrument type	Beschreibung
VanillaCapFloor	Ein Cap oder Floor ist ein Strip von Optionlets auf einen variablen Zinsindex. Damit adressiert man Zinsoptionalität, Optionlet-Volatilität, vega-sensitive Bewertung und nichtlineares IR-Szenariorisiko.
VanillaCollar	Ein Collar kombiniert Cap und Floor, um Floating-Rate-Exposure in einem Korridor zu begrenzen. Damit adressiert man Hedging-Strukturen, in denen Aufwärts- und Abwärtsbewegungen durch zwei Strikes begrenzt sind.

Voraussetzungen

Daten	Benötigt für
Discount curve	PV-Diskontierung.
Forward curve	Floating Index Projection.
Cap/floor volatility	Optionlet-Bewertung.
Strike	Cap/Floor Strike.
Floating frequency	Optionlet Schedule.
Low/high barrier	Collar-Unter- und Obergrenze.

Cap Beispielfelder

Feld	Wert
Trade id	VAL-CAP-3Y-ATM-001
Trade name	CAP/EUR/3Y/ATM
Instrument	VanillaCapFloor
Währung	EUR
Notional	1.000.000
Cap/floor type	Cap
Strike	2,00%
Floating frequency	Quarterly
Issue date	2026-02-15
Maturity	2029-02-15
Day count	Actual360
Volatility	25,00%

Rates: Bond Futures

Instrument type	Use case	Aktueller Validierungsfokus
BondFuture	Rates Future mit Deliverable Basket.	CTD Basket, Pricing, Sensis, Scenarios, VaR, DQ.

Instrumentbeschreibung

Instrument type	Beschreibung
BondFuture	Ein Bond Future ist ein standardisierter Futures-Kontrakt mit lieferbarem Anleihekorb. Damit adressiert man Futures Pricing, Cheapest-to-Deliver Auswahl, Conversion Factors und Rates-Szenarioexposure.

Bond Future Beispielfelder

Feld	Wert
Trade id	VAL-FUT-BUND-SEP26-001
Trade name	FUT/BOND/BUND/202609
Instrument	BondFuture
Währung	EUR
Notional	100.000
Futures price	112,50
Strike/reference price	112,50
Maturity	2026-09-18
Model hint	CTD basket bond future validation model

Equity: Stocks, Indices, Options und Futures

Instrument type	Use case	Aktueller Validierungsfokus
Stock	Listed Equity Position.	Quote Pricing und Scenario Readiness.
EquityIndex	Equity Index Exposure.	Quote Pricing und Scenario Readiness.
EuropeanVanillaOption	Europäische Calls/Puts.	Pricing, Cashflows, Sensis, Scenarios, VaR, DQ.
EquityFuture	Cost-of-carry Equity Future.	Pricing, Sensis, Scenarios, VaR, DQ.

Instrumentbeschreibungen

Instrument type	Beschreibung
Stock	Eine Stock-Position ist direktes Exposure auf einen Equity-Spotpreis. Damit adressiert man einfache Quote-Bewertung, Quantity Scaling, Equity-Schocks und Equity-PnL-Vektoren.
EquityIndex	Eine Equity-Index-Position referenziert einen Indexstand statt eines einzelnen Emittenten. Damit adressiert man Index-Quote-Bewertung, breite Marktschocks und indexbasiertes Szenarioexposure.
EuropeanVanillaOption	Eine europäische Vanilla Option gibt das Recht, den Underlying bei Fälligkeit zu kaufen oder zu verkaufen. Damit adressiert man Option Pricing, Delta/Gamma/Vega-Risiko, Vol-Surface-Mapping und nichtlineare Szenariobewertung.
EquityFuture	Ein Equity Future ist ein forward-ähnliches Exposure auf einen Equity-Underlying mit standardisierter Fälligkeit. Damit adressiert man Cost-of-Carry Pricing, Forward-Level-Checks und Equity-Szenario-PnL.

Voraussetzungen

Daten	Benötigt für
Underlying spot	Bewertung, Delta/Gamma-Risiko.
Strike und expiry	Payoff-Definition.
Volatility surface oder flat vol	Pricing und Vega-Risiko.
Risk-free curve	Diskontierung und Forward.
Dividend yield oder Forward Adjustment	Equity Option Forward.
Equity, IR und Vol Shocks	Vollständige Scenario/VaR-Abdeckung.

European option Beispielfelder

Feld	Wert
Trade id	VAL-OPT-CALL-ATM-001
Trade name	OPT/EUR/CALL/ATM
Instrument	EuropeanVanillaOption
Währung	EUR
Notional	10.000
Option type	Call
Moneyness	ATM
Spot	100,00
Strike	100,00
Volatility	20,00%
Dividend yield	0,00%
Risk-free rate	2,00%
Maturity	2027-01-15

Exotic Options

Readiness Coverage umfasst BarrierOption, DoubleBarrierOption, AsianOption, DigitalOption, FixedLookbackOption, LookbackOption, PartialFixedLookbackOption, PartialFloatingLookbackOption, HolderExtensibleOption, MagrabeOption, SimpleChooserOption und ComplexChooserOption.

Instrumentbeschreibungen

Instrument type	Beschreibung
BarrierOption	Eine Barrier Option wird aktiviert oder gelöscht, wenn der Underlying eine Barriere erreicht. Damit adressiert man pfadabhängige Optionalität und Barrier-Level-Daten.
DoubleBarrierOption	Eine Double-Barrier Option hat untere und obere Barrier-Bedingungen. Damit adressiert man begrenzte pfadabhängige Payoffs und Sensitivität zur Barrier-Platzierung.
AsianOption	Eine Asian Option nutzt einen Durchschnittskurs statt nur den Terminalpreis. Damit adressiert man Averaging-Period-Konfiguration und geringere Abhängigkeit von einer einzelnen Endbeobachtung.
DigitalOption	Eine Digital Option zahlt einen festen Betrag, wenn eine Bedingung erfüllt ist. Damit adressiert man diskontinuierliches Payoff-Verhalten und hohe Sensitivität um den Strike.
FixedLookbackOption	Eine Fixed-Strike Lookback Option hängt vom besten oder schlechtesten beobachteten Underlying-Level ab. Damit adressiert man Observation-Window Setup und pfadabhängige Extrema.
LookbackOption	Eine Floating-Strike Lookback Option setzt den effektiven Strike aus den beobachteten Pfadextrema. Damit adressiert man Floating-Payoff-Definition und historische Pfaderfassung.
PartialFixedLookbackOption	Eine Partial Fixed Lookback beobachtet Extrema nur in einer definierten Teilperiode. Damit adressiert man Produkte, bei denen Pfadabhängigkeit vor Endfälligkeit beginnt oder endet.
PartialFloatingLookbackOption	Eine Partial Floating Lookback kombiniert Floating-Strike-Verhalten mit begrenztem Beobachtungsfenster. Damit adressiert man spezialisierte pfadabhängige Payoff-Validierung.
HolderExtensibleOption	Eine Holder Extensible Option erlaubt dem Holder, die Option unter definierten Bedingungen zu verlängern. Damit adressiert man Extension Rights und bedingtes Maturity-Verhalten.
MagrabeOption	Eine Margrabe Option tauscht ein Asset gegen ein anderes. Damit adressiert man Zwei-Underlying-Exposure, relative Volatilität und korrelationssensitives Payoff-Verhalten.
SimpleChooserOption	Eine Simple Chooser Option erlaubt die Wahl, ob das Produkt Call oder Put wird. Damit adressiert man Choice-Date-Konfiguration und kombinierte Call/Put-Optionalität.
ComplexChooserOption	Eine Complex Chooser Option erlaubt reichere Call/Put-Wahlbedingungen, etwa unterschiedliche Strikes oder Expiries. Damit adressiert man Multi-Parameter-Chooser-Payoff-Validierung.

Exotic Options benötigen zusätzlich produktspezifische Felder wie Barrier Levels, Averaging Period, Observation Dates, Extension Terms oder zweiten Underlying. Wenn diese Felder nicht produktiv angebunden sind, muss die Validierung Einschränkungen zeigen.

Exotic Option Beispielkonfigurationen

Diese Exotic Option Types sind aktuell im Validation Portfolio vertreten.

Trade id	Trade name	Instrument type	Option	Moneyness	Strike	Volatility	Was adressiert wird
VAL-EXOTIC-BARRIER-001	OPT/EUR/BARRIER/DOWN-OUT-CALL	BarrierOption	Call	OTM	110.0	0.24	Single-Barrier Aktivierung oder Knock-out.
VAL-EXOTIC-DOUBLE-BARRIER-001	OPT/EUR/DOUBLE-BARRIER/KNOCK-OUT-CALL	DoubleBarrierOption	Call	ATM	100.0	0.24	Untere und obere Barrier-Bedingung.
VAL-EXOTIC-ASIAN-001	OPT/EUR/ASIAN/AVG-PRICE-CALL	AsianOption	Call	ATM	100.0	0.22	Average-Price Payoff und Averaging Period.
VAL-EXOTIC-DIGITAL-001	OPT/EUR/DIGITAL/CASH-OR-NOTHING	DigitalOption	Call	ATM	100.0	0.20	Binärer Payoff um den Strike.
VAL-EXOTIC-LOOKBACK-FIXED-001	OPT/EUR/LOOKBACK/FIXED-STRIKE	FixedLookbackOption	Call	ATM	100.0	0.26	Fixed-Strike Pfadextrema.
VAL-EXOTIC-LOOKBACK-FLOATING-001	OPT/EUR/LOOKBACK/FLOATING-STRIKE	LookbackOption	Call	ATM	100.0	0.26	Floating-Strike Pfadextrema.
VAL-EXOTIC-LOOKBACK-PARTIAL-FIXED-001	OPT/EUR/LOOKBACK/PARTIAL-FIXED	PartialFixedLookbackOption	Call	ATM	100.0	0.27	Fixed Lookback mit begrenztem Beobachtungsfenster.
VAL-EXOTIC-LOOKBACK-PARTIAL-FLOATING-001	OPT/EUR/LOOKBACK/PARTIAL-FLOATING	PartialFloatingLookbackOption	Call	ATM	100.0	0.27	Floating Lookback mit begrenztem Beobachtungsfenster.
VAL-EXOTIC-HOLDER-EXTENSIBLE-001	OPT/EUR/HOLDER-EXTENSIBLE/CALL	HolderExtensibleOption	Call	ATM	100.0	0.23	Verlängerungsrecht des Holders.
VAL-EXOTIC-MAGRABE-001	OPT/EUR/MAGRABE/EXCHANGE	MagrabeOption	Call	ATM	100.0	0.25	Exchange Option auf zwei Assets.
VAL-EXOTIC-CHOOSER-SIMPLE-001	OPT/EUR/CHOOSER/SIMPLE	SimpleChooserOption	Call	ATM	100.0	0.21	Wahl zwischen Call und Put am Decision Date.
VAL-EXOTIC-CHOOSER-COMPLEX-001	OPT/EUR/CHOOSER/COMPLEX	ComplexChooserOption	Call	ATM	100.0	0.21	Erweiterte Chooser-Bedingungen mit mehreren Payoff-Parametern.

Gemeinsame Konfigurationsfelder dieser Beispiele:

Feld	Gemeinsamer Wert
Assetklasse	Equity
Währung	EUR
Notional	10.000
Spot	100,00
Risk-free rate	2,00%
Dividend yield	0,00%
Issue date	2026-01-15
Maturity	2027-01-15
Day count	Actual360
Business day convention	ModifiedFollowing

Produktspezifische Felder wie Barriers, Observation Windows, Averaging Dates, Extension Terms, zweiter Underlying und Chooser Decision Dates müssen in produktiven Stammdaten vorhanden sein, wenn das Produktionsmodell sie benötigt.

FX

Instrument type	Use case	Aktueller Validierungsfokus
CurrencyPair	Spot FX Quote Exposure.	Quote Pricing und Scenario Readiness.
FxForward	FX Forward.	Domestic/foreign Discounting, Scenarios, VaR.

Instrumentbeschreibungen

Instrument type	Beschreibung
CurrencyPair	Ein Currency Pair repräsentiert Spot-FX-Exposure zwischen zwei Währungen. Damit adressiert man FX-Quote-Validierung, Umrechnungskurse und FX-Schockwirkung.
FxForward	Ein FX Forward fixiert einen Wechselkurs für einen zukünftigen Settlement-Termin. Damit adressiert man Domestic/Foreign Discounting, Forward Points und FX-Szenarioexposure.

FX Forward Beispielfelder

Feld	Wert
Trade id	VAL-FWD-FX-EURUSD-6M-001
Trade name	FWD/FX/EURUSD/6M
Instrument	FxForward
Währung	EUR
Notional	1.000.000
Spot	1,0825
Forward/strike	1,0900
Domestic rate	2,25%
Foreign rate	4,75%
Maturity	2026-09-18

Commodity

Instrument type	Use case	Aktueller Validierungsfokus
Commodity	Commodity Quote Exposure, z. B. Brent.	Quote Pricing und Scenario Readiness.

Instrumentbeschreibung

Instrument type	Beschreibung
Commodity	Eine Commodity-Position referenziert einen Commodity Spot oder Marktquote, z. B. Brent. Damit adressiert man Commodity-Quote-Bewertung, Quantity Scaling und Commodity-Szenarioschocks.

Commodity Beispielfelder

Feld	Wert
Trade id	VAL-BASIC-CMDTY-BRENT-001
Trade name	CMDTY/BRENT
Instrument	Commodity
Währung	USD
Quantity	1.000
Spot	82,35

Inflation

Implementierte Inflationsinstrumente umfassen CPI, HICP Zero-Coupon und HICP Year-on-Year Produkte.

Instrument type	Familie	Use case
CPIBond	CPI	CPI-linked Bond.
CPISwap	CPI	CPI Swap.
HICPZCBond	HICP Zero-Coupon	HICP Zero-Coupon Bond.
HICPZCCapFloor	HICP Zero-Coupon	Zero-Coupon Inflation Cap/Floor.
HICPYYBond	HICP Year-on-Year	Year-on-Year Inflation Bond-like Position.
HICPYYCap	HICP Year-on-Year	Year-on-Year Inflation Cap.
HICPYYFloor	HICP Year-on-Year	Year-on-Year Inflation Floor.

Instrumentbeschreibungen

Instrument type	Beschreibung
CPIBond	Ein CPI Bond bindet Bond-Cashflows oder Principal an einen Verbraucherpreisindex. Damit adressiert man CPI-Fixing-Nutzung, Base-Index-Behandlung und inflationsgebundene Bond-Bewertung.
CPISwap	Ein CPI Swap tauscht feste oder nominale Zahlungen gegen CPI-gebundene Inflationszahlungen. Damit adressiert man Inflation-Swap-Kurven, Indexprojektion und CPI-Payoff-Validierung.
HICPZCBond	Ein HICP Zero-Coupon Bond nutzt kumulierte HICP-Inflation von Base Date bis Maturity. Damit adressiert man Zero-Inflation-Curve Construction und finalen Inflations-Uplift.
HICPZCCapFloor	Ein HICP Zero-Coupon Cap/Floor legt Optionalität auf kumulierte Inflation über die Laufzeit. Damit adressiert man Inflationsoptionalität, Zero-Coupon-Inflationsvolatilität und Strike-Validierung.
HICPYYBond	Eine HICP Year-on-Year bond-like Position referenziert jährliche Inflationsänderungen. Damit adressiert man YoY-Indexbehandlung und wiederkehrende inflation-linked Cashflows.
HICPYYCap	Ein HICP Year-on-Year Cap begrenzt jährliches Inflations-Exposure oberhalb eines Strikes. Damit adressiert man YoY-Inflationsoptionalität und caplet-artige Inflationsvolatilität.
HICPYYFloor	Ein HICP Year-on-Year Floor schützt gegen jährliche Inflation unterhalb eines Strikes. Damit adressiert man Downside-Inflationsoptionalität und floorlet-artige Payoff-Validierung.

CPI vs Zero-Coupon vs Year-on-Year

Familie	Indexinterpretation
CPI	Nutzt CPI Index Levels und Base CPI für index-linked Payments.
HICP Zero-Coupon	Nutzt kumulierte Inflationsratio zwischen Base und Maturity Observation.
HICP Year-on-Year	Nutzt jährliche Inflationsraten zwischen aufeinanderfolgenden Beobachtungsperioden.

Zero-Coupon- und Year-on-Year-Inflationsindizes nicht mischen. Curve Construction, Fixings und Payoff-Konventionen unterscheiden sich.

Voraussetzungen

Daten	Benötigt für
Inflation index id	Beispiel EUR_CPI oder EUR_HICPXT.
Base CPI	Start-Indexlevel.
Observation lag	Typischer Lag, z. B. drei Monate.
Inflation fixings	Historische Indexstände.
Zero inflation curve	Zero-Coupon-Produkte.
YoY inflation curve	Year-on-Year-Produkte.
Nominal discount curve	Diskontierung.
Inflation volatility	Inflation Cap/Floor Optionalität.

HICP zero-coupon cap/floor Beispielfelder

Feld	Wert
Trade id	VAL-INF-HICPZC-CAPFLOOR-001
Trade name	INF/HICPZC/CAPFLOOR/5Y
Instrument	HICPZCCapFloor
Währung	EUR
Notional	1.000.000
Inflation index	EUR_HICPXT
Base CPI	100,00
Observation lag	3 Monate
Cap/floor type	Cap
Strike	2,00%
Issue date	2026-02-15
Maturity	2031-02-15
Day count	Actual365Fixed
Volatility	1,00%

HICP year-on-year cap Beispielfelder

Feld	Wert
Trade id	VAL-INF-HICPYY-CAP-001
Trade name	INF/HICPYY/CAP/5Y
Instrument	HICPYYCap
Währung	EUR
Notional	1.000.000
Inflation index	EUR_HICPXT
Base CPI	100,00
Observation lag	3 Monate
Cap/floor type	Cap
Strike	2,50%
Fixed frequency	Annual
Floating frequency	Annual
Maturity	2031-02-15

Hybrid und Convertibles

Instrument type	Asset class	Use case
ConvertibleBond	Hybrid	Bond mit Equity Conversion Feature.

Instrumentbeschreibung

Instrument type	Beschreibung
ConvertibleBond	Ein Convertible Bond ist ein Schuldinstrument mit eingebettetem Recht zur Umwandlung in Equity. Damit adressiert man Credit/Rates-Cashflows und Equity-Optionalität in einem Produkt, daher müssen Bond- und Optiondaten valide sein.

Convertible Bonds benötigen Rates-/Bond-Daten und Equity-Option-Daten. Dazu gehören Discount Curve, Bond Schedule, Conversion Ratio oder Strike, Underlying Equity, Volatility und optionale Call/Put Features. Aktuelle Validierung ist als Readiness Coverage zu lesen, sofern keine explizite ausführbare Evidenz gezeigt wird.

Empfohlene Praxis

Beim Anlegen oder Prüfen einer Position:

• Kanonischen Instrument Type bestätigen.
• Assetklasse gegen die Risikotreiber prüfen.
• Erforderliche Marktdaten-Mappings prüfen.
• DQ Findings vor Nutzung der Bewertung prüfen.
• Im Validation Dashboard prüfen, ob Evidenz für die benötigte Capability existiert.
• Readiness-only oder inventory-only Instrumente als eingeschränkt behandeln, bis Produktionsevidenz angebunden ist.

Zweck

Non-Maturity Deposits (NMDs) modellieren Einlagen ohne vertragliche Endfälligkeit. Das Portal verwendet sie für IRRBB-nahe Bankbuchsicht, Sensitivitäten und historische Simulationen, wenn der wirtschaftliche Repricing-Zeitpunkt nicht aus einem vertraglichen Maturity Date abgeleitet werden kann.

NMDs sind keine normalen Term Deposits. Der Wert hängt von Verhaltensannahmen, Core-Balance-Caps, Runoff-Profil, Kundensatz, Marktzins und optionaler Zero-Floor-Komponente ab.

Wichtige Felder

Feld	Bedeutung
Segment	Kundensegment wie Retail Transactional, Retail Non-Transactional oder Wholesale. Steuert Core-Balance- und Laufzeit-Caps.
CurrentBalance	Aktueller Einlagenbestand. Das ist die ökonomische Ausgangsgröße.
StableBalanceRatio	Anteil des Bestands, der als stabil modelliert werden kann, bevor regulatorische Caps angewendet werden.
PassThroughRate	Anteil der Marktzinsbewegung, der an den Kundensatz weitergegeben wird. Niedriger Pass-through erhöht typischerweise die ökonomische Stabilität.
DepositRate	Aktueller Kundensatz der Einlage.
FloorStrike	Strike der optionalen Kundensatz-Floor-Komponente. Für Zero-Floor-NMDs ist der Strike typischerweise 0.0.
IncludeFloorValue	Aktiviert die optionale Floor-Bewertung. Dafür ist eine gemappte Normal-Volatilitätsfläche erforderlich.
RunoffProfile	Zeitgewichtete Abflussannahmen für den stabilen Anteil. Daraus ergeben sich Cashflows und gewichtete durchschnittliche Laufzeit.

Segment-Caps

Segment	Maximaler Core-Anteil	Maximale durchschnittliche Laufzeit
Retail transactional	90%	5.0Y
Retail non-transactional	70%	4.5Y
Wholesale	50%	4.0Y

Die tatsächliche Core Balance ist der kleinere Wert aus angenommener stabiler Balance und Segment-Cap. Nicht-Core-Bestände werden ökonomisch kurzlaufend beziehungsweise overnight interpretiert.

Bewertungslogik

Die deterministic NMD-Komponente bewertet die modellierten Runoff-Cashflows über die relevante Diskontkurve. Optional wird eine Kundensatz-Floor-Komponente als Normal-/Bachelier-Option berücksichtigt.

Komponente	Interpretation
Core runoff PV	Barwert der stabilen Einlagen-Cashflows entlang des Runoff-Profils.
Non-core treatment	Kurzfristiges oder overnight Repricing des nicht stabilen Anteils.
Floor value	Wert des eingebetteten Floors, wenn IncludeFloorValue aktiv ist.
Total PV	Summe aus deterministischer Einlagenkomponente und optionalem Floor-Beitrag gemäß Modellkonvention.

Für die Floor-Komponente wird eine gemappte Normal-Volatilitätsfläche verwendet. Ein lokaler Skalar im Instrument ersetzt diese Fläche nicht. Wenn IncludeFloorValue aktiv ist und keine passende Fläche vorhanden ist, ist das ein Data-Quality- oder Mapping-Problem und kein valider Null-Vega-Fall.

Marktdaten und Risikofaktoren

Marktdatum	Benötigt für
Discount curve	PV, IR-Sensitivität, IRRBB-EVE und historische Simulation.
Normal-volatility point surface	Floor-Wert, Vega, volatilitätsgetriebene VaR-Beiträge.
Surface node quotes	Historische Shock-Vektoren und Szenariobewertung.
Risk-factor mapping	Verbindung zwischen Oberfläche, Benchmarks und Sensitivitäts-/VaR-Faktoren.

Für NMD-Floor-Vega sollte ein gemappter Volatilitätsfaktor wie EUR/IR/NORMALVOL.Shift.1Y erscheinen. Instrument-lokale synthetische Faktoren wie .../NMD_NORMAL_VOL... sind kein erwarteter Produktionspfad.

Sensitivitäten und VaR

Ergebnis	Richtige Interpretation
PV01 / IR Delta	Wertänderung aus Diskontkurve und Repricing-Duration des Runoff-Profils.
IrVega	Wertänderung aus der Normal-Volatilitätsfläche für die Floor-Komponente.
VaR	Historische Revaluation über Kurven- und Volatilitätsfaktoren, wenn die Oberfläche in der Szenariohistorie vorhanden ist.
Zero Vega	Nur plausibel, wenn Floor deaktiviert ist, die Option wertlos ist oder das Exposure tatsächlich außerhalb der gemappten Surface-Nodes liegt. Bei aktivem Floor zuerst Surface Mapping prüfen.

NMD-Vega verwendet den Floor Strike, nicht einen generischen ATM-Strike. Für Zero-Floor-NMDs ist das normalerweise 0.0. Wenn Sensitivität und Pricing unterschiedliche Strikes verwenden, kann das Ergebnis fälschlich null erscheinen.

Validierungschecks

Check	Bedeutung
Positive balance	Bestand muss positiv und wirtschaftlich sinnvoll sein.
Segment cap	Core Balance darf das Segment-Cap nicht überschreiten.
Average maturity cap	Runoff-Profil darf die zulässige durchschnittliche Laufzeit nicht überschreiten.
Runoff profile	Gewichte, Termine und Restbestand müssen konsistent sein.
Curve mapping	Währung und Diskontkurve müssen zur Position passen.
Vol surface mapping	Bei aktivem Floor muss eine Normal-Volatilitätsfläche vorhanden sein.
Scenario coverage	VaR und Sensitivitäten benötigen historische Werte für die verwendeten Risikofaktoren.

Häufige Probleme

Problem	Wahrscheinliche Ursache	Aktion
NMD fehlt in Instrument Validation	Instrumenttyp, Feature-Mapping oder Seed-Daten fehlen.	Instrumenttyp und Feature-Daten prüfen.
PV vorhanden, Vega null	Floor deaktiviert, fehlende Vol-Fläche oder falscher Strike im Risikofaktorpfad.	IncludeFloorValue, Surface Mapping und FloorStrike prüfen.
VaR bricht mit fehlendem Faktor ab	Oberfläche oder Risk-Factor-Group ist nicht konsistent gemappt.	Quotable Factor, Surface Name und Scenario History vergleichen.
EVE wird von NMD dominiert	Core-Anteil oder WAL ist hoch.	Segment-Cap, Stable Balance Ratio und Runoff-Profil prüfen.
Ergebnisse springen nach Marktdaten-Reload	Surface Nodes oder historische Quotes haben sich geändert.	verwendete Benchmarks und Valuation Date vergleichen.

Zweck

Optionswerte hängen von Underlying-Level, Strike, Zeit bis Expiry, Zinsen, Dividenden oder Forwards und Volatilität ab.

Wichtige Felder

Feld	Bedeutung
Strike	Ausübungspreis oder Ausübungslevel.
Expiry	Datum der Ausübung oder Beobachtung.
Volatilität	Marktdateninput für das Optionsmodell.
Delta, Vega, Gamma	Sensitivitäten auf Underlying, Volatilität und Krümmung.

Ergebnisinterpretation

Optionen nahe am Strike reagieren häufig besonders stark auf Volatilität und Underlying-Bewegungen. Deep-in-the-money Optionen können sich ähnlich wie das Underlying verhalten.

Häufige Probleme

Problem	Bedeutung	Mögliche Aktion
Vol fehlt	Erforderlicher Expiry/Strike-Punkt fehlt.	Abdeckung der Volatilitätsfläche prüfen.
Sehr hohe Vega	Expiry, Quantity oder Vol-Konvention kann falsch sein.	Input-Einheiten und Positionsgröße prüfen.
Intrinsic Value wirkt falsch	Optionstyp oder Buy/Sell-Richtung kann falsch sein.	Call/Put und Richtung prüfen.

Zweck

Inflationsprodukte hängen von Indexkonventionen, Observation Lag, Fixings und Inflationskurven ab. YoY- und Zero-Coupon-Inflation dürfen nicht als identische Indexexponierung interpretiert werden.

YoY versus Zero-Coupon

Produkttyp	Interpretation
Year-on-year Inflation	Coupon hängt von Inflation über eine einjährige Beobachtungsperiode ab.
Zero-coupon Inflation	Payoff hängt von kumulierter Inflation zwischen Base Date und Maturity ab.
Inflation Cap/Floor	Optionaler Payoff auf Inflationsrate oder Indexratio.

Wichtige Felder

Feld	Bedeutung
Index	CPI, HICP oder andere Inflationsindexfamilie.
Observation Lag	Verzögerung zwischen Valuation/Payment Date und beobachtetem Indexdatum.
Base CPI	Startwert für ratio-basierte Payoffs.
Fixings	Historisch beobachtete Indexwerte.

Häufige Probleme

Problem	Bedeutung	Mögliche Aktion
Falsche Größenordnung	YoY- und Zero-Coupon-Konvention können vermischt sein.	Produktfamilie und Indexkurve prüfen.
Fixing fehlt	Beobachtungsdatum hat keinen Indexwert.	Fixing-Kalender und Lag prüfen.
Options-PV ist null	Volatilität oder Modellinput für Inflation Optionality fehlt.	Inflation Vol und Kurvensetup prüfen.

Zweck

Das Report Framework fasst Portfolio-, Marktrisiko-, PnL-, Cashflow-, Sensitivitäts-, Limit- und Provision-Informationen in einem kontrollierten Fachreport zusammen. Es unterstützt tägliche Reviews, Sign-off-Vorbereitung und Verteilung an Desks, Books oder Portfolios. Der Report ersetzt keine Bewertungs- oder Risikoworkflows; er liest persistierte Ergebnisse und stellt sie in einer einheitlichen Reporting-Struktur dar.

Zentrale Konzepte

Konzept	Bedeutung
Report Definition	Wiederverwendbare Report-Vorlage, zum Beispiel Daily Market Risk Report.
Report Section	Benannter Block im Report, zum Beispiel PnL Summary, VaR Table, Sensitivities oder Provisions.
Exposure Selection	Gespeicherter Filter, der definiert, welche fachliche Scope oder Ergebnisquelle verwendet wird.
Report Artifact	Erzeugte Ausgabedatei, typischerweise ein PDF oder ein anderer gespeicherter Report-Artefakt.
Recipient Group	Gepflegte Empfängerliste für To, Cc und Bcc.
Subscription	Regel, die Report, Scope, Empfänger, Delivery Format und Schedule verbindet.
Comment	Fachlicher Kommentar zu einem erzeugten Report oder Review-Zyklus.

Typischer Ablauf

• Report-Vorlage und benötigte Sections definieren.
• Fachlichen Scope konfigurieren: Group, Desk, Book, Portfolio oder Instrument.
• Reference Date, Reporting Currency und Model auswählen.
• Report View erzeugen oder öffnen.
• PnL Summary, VaR/ES-Ergebnisse, Sensitivitäten, Cashflow Buckets und Provisions prüfen.
• Kommentare für Erklärungen, Breaches, fehlende Daten oder manuelle Anpassungen ergänzen.
• Artifact speichern und über die konfigurierte Subscription verteilen, wenn der Report freigegeben ist.

Report Definitions

Report Definitions beschreiben Identität und Standardverhalten eines Reports. Die Definition sollte stabil und fachlich lesbar sein. Typische Felder sind Display Name, Report Type, Default Currency, Active Flag und Description.

Feld	Bedeutung
Name	Technischer Identifier zur Report-Anforderung. Stabil halten.
Display Name	Sichtbarer Report-Titel.
Report Type	Fachliche Familie, zum Beispiel MarketRisk.
Default Currency	Währung, falls keine Reporting Currency explizit gewählt ist.
Is Active	Steuert, ob die Definition operativ verwendet werden soll.
Description	Fachliche Erklärung von Scope und Zweck.

Report Sections

Sections definieren, was im Report erscheint und in welcher Reihenfolge. Eine Section kann Tabelle, Summary, Chart, Textblock oder query-basierter Ergebnisblock sein. Sections sollten klein genug sein, um unabhängig geprüft werden zu können.

Feld	Bedeutung
Key	Stabiler Section-Identifier innerhalb der Report Definition.
Title	Angezeigter Titel.
Sort Order	Reihenfolge im Report.
Section Type	Darstellungsart, zum Beispiel Table, Summary oder Text.
Query Target	Ergebnisquelle, die abgefragt wird.
Dimensions	Gruppierungsfelder wie Desk, Book, Portfolio oder Risk Factor Group.
Measures	Kennzahlen wie PnL, VaR, ES oder PV.
Filter Body	Optionaler Filterausdruck für die Section.
Having Body	Optionaler Filter nach Aggregation.
Display Options	JSON-basierte Anzeigehinweise wie Formatierung oder Tabellenoptionen.

Häufige Report Sections

Section	Was geprüft werden sollte
Executive Summary	Gesamtstatus, Schlüsselzahlen und Kommentare.
PnL Summary	Gross PnL, MtD, YtD, Provision-Bewegungen und Net PnL after Provisions.
Value at Risk	VaR, ES sowie Worst/Best Scenario Measures nach Assetklasse und Total.
Sensitivities	Risk-Factor-Exposure, Tenor-Struktur, Veränderungen und Limit Usage.
Cashflow Buckets	Zukünftige Cashflows und Present Value nach Laufzeitbucket.
Provisions	Manuelle oder kontrollierte Adjustments und deren diskontierte Present Values.
Limit Utilization	Exposure gegen Limit, Usage Percentage und Breach Status.

Exposure Selections

Exposure Selections machen Report-Filter wiederverwendbar und auditierbar. Sie sollten fachliche Absicht ausdrücken, nicht temporäre Screen-Filter. Eine Selection kann beispielsweise alle Positionen eines Desks, eine Produktfamilie, ein Reporting-Portfolio oder Ergebnisse aus einer bestimmten Data Source beschreiben.

Feld	Bedeutung
Name	Stabiler Selection-Name.
Description	Warum die Selection existiert und wer sie verantwortet.
Filter Body	Filterlogik auf der Report-Quelle.
Applies To Data Sources	Data Sources, für die die Selection sinnvoll ist.
Is Active	Ob die Selection für neue Reports genutzt werden darf.

Subscriptions und Recipients

Subscriptions verbinden Reports mit Delivery-Verhalten. Recipient Groups sollten zentral gepflegt werden, damit dieselbe Gruppe über Desks und Books wiederverwendet werden kann. Direct Recipients sollten nur für Ausnahmen genutzt werden.

Feld	Bedeutung
Level	Scope Level, zum Beispiel Group, Desk oder Book.
Group / Desk / Book	Scope-Werte der Subscription.
Recipient Groups	Benannte Empfängergruppen für Distribution.
Direct Recipients	Zusätzliche direkte Empfänger.
Send When	Manuelles oder geplantes Senden.
Delivery Format	Link, Attachment oder anderes konfiguriertes Delivery-Format.
Attach PDF	Ob ein PDF Artifact angehängt wird, wenn es verfügbar ist.
Schedule Cron	Optionaler Schedule-Ausdruck für automatische Verteilung.

Artifacts und Kommentare

Artifacts sind gespeicherte Report-Ausgaben. Ein Report Artifact ist eine Point-in-Time-Sicht auf Report Context, Reference Date und verfügbare Daten zum Erzeugungszeitpunkt. Kommentare sollten klarstellen, ob ein Effekt aus Marktbewegung, Datenproblem, Modelllimitation, operativer Ausnahme oder manueller Anpassung stammt.

Ergebnisinterpretation

Reports kombinieren Daten aus mehreren Workflow-Ergebnissen. Eine fehlende Section bedeutet meist, dass die zugrunde liegende Quelle für Reference Date, Model oder Scope nicht verfügbar war. Ein Nullwert ist nicht automatisch fehlende Datenqualität; prüfen Sie Section Status, Kommentare, DQ Findings und den Simulation State.

Häufige Probleme

Problem	Bedeutung	Mögliche Aktion
Leere Report Section	Quelldaten fehlen für Scope oder Datum.	Workflow Completion und Model prüfen.
Unerwartete Währung	Reporting Currency weicht von Source Currency ab.	Currency-Auswahl und FX-Marktdaten prüfen.
PDF Artifact fehlt	Report View existiert, aber Rendering hat kein Artifact erzeugt.	Neu erzeugen oder Artifact Status prüfen.
Empfänger fehlt	Subscription nutzt Recipient Groups, nicht beliebige Screen-User.	Recipient Group prüfen.
Section-Reihenfolge falsch	Sort Order oder Active-Flag der Section ist falsch.	Report Sections in der Definition prüfen.
Zahlen weichen vom Dashboard ab	Dashboard und Report verwenden unterschiedliche Filter.	Reference Date, Level, Model und Currency vergleichen.

Empfohlene Praxis

Report Definitions stabil halten und Änderungen über Description und Kommentare nachvollziehbar machen. Subscriptions für regelmäßige Verteilung nutzen, nicht für einmalige Reviews. Vor Distribution Reference Date, Scope, Model, Currency, Workflow Completion, Data Quality Findings und Provision Status prüfen.

Zweck

Das VaR Models Dashboard zeigt Value-at-Risk, Expected Shortfall, Market Risk Capital und Modelldiagnostik fuer den ausgewaehlten Stichtag, die Waehrung, das Modell und die Business-Ebene. Es dient zur taeglichen Pruefung von Risikobewegungen, Limitdruck und Modellqualitaet.

Selektoren

Selektor	Bedeutung
Reference Date	Stichtag der angezeigten Ergebnisse.
Currency	Reporting-Waehrung der Werte.
Model	VaR- oder Stressed-VaR-Modell fuer KPIs, Charts und Tabellen.
Dashboard Level	Business-Hierarchie fuer Breakdowns, typischerweise Desk im Tagesreview.

Wichtige Widgets

Widget	Review-Fokus
VaR	Aktueller VaR und Bewegungen gegen Vorperioden.
ES	Expected Shortfall und Veraenderungen gegen Vorperioden.
MRC	Market Risk Capital, Multiplikator und VaR/SVaR-Kapitalanteile.
Backtesting	Best/Worst-Kalibrierung und Exception-Kontext.
Limit	Auslastung, Breaches und relevante Limitzeilen.
History	Year-to-date Verlauf von VaR und ES je Modell.
Szenario- und Portfolio-Tabellen	Konzentrationen, Ratios und Szenariotreiber auf der ausgewaehlten Ebene.

Review-Ablauf

• Modell, Datum und Waehrung pruefen.
• KPI-Karten auf Richtung, Groessenordnung und Limitdruck pruefen.
• Desk fuer den Tagesreview nutzen und bei Auffaelligkeiten auf Book oder Portfolio wechseln.
• History, Best/Worst-Ratios und Szenariotabellen vergleichen, bevor eine Bewegung eskaliert wird.

Typische Probleme

Problem	Moegliche Ursache	Aktion
Leere Widgets	Kein Aggregationsergebnis fuer Modell oder Datum.	Workflow-Abschluss und Modellauswahl pruefen.
Limitdaten fehlen	Limitresultat fehlt oder ist nicht auf die Hierarchie gemappt.	Limit-Workflow und Scope pruefen.
Unerwartete Modellunterschiede	Abweichendes Szenarioset, Konfidenzniveau, Haltedauer oder Stressfenster.	Modellkonfiguration und Selektoren vergleichen.
Grosse Bewegung	Portfolioaenderung, Marktdatenbewegung oder Szenarioverteilungswechsel.	Szenario-, Faktor- und Portfolio-Breakdowns pruefen.

Zweck

Das Limits Dashboard ist die taegliche Kontrollsicht fuer das neue Limit-Monitoring. Es zeigt offene und genehmigte Limit Exceptions, den Severity-Split, maximale Auslastung und Approvals mit Handlungsbedarf. Die Tabelle unter den KPIs ist die Arbeitsliste fuer Analyse, Acknowledgement, Eskalation, temporaere Genehmigung und Schliessung.

Das Dashboard nutzt generierte LimitObservation-Zeilen und aktive LimitBreach-Cases. Observations werden fuer Stichtag und Simulation Run berechnet. Breach Cases bleiben ueber mehrere Tage offen, bis sie geschlossen oder abgelehnt werden; der Manage Dialog zeigt deshalb den aktuellen Case-Status und die Observation-Historie.

Selektoren

Selektor	Bedeutung
Reference Date	Business Date fuer Observations und Historie.
Currency	Observation-Waehrung, meist Limit-Waehrung oder Waehrung des Aggregationsergebnisses.
Dashboard Level	Business-Hierarchie: Group, Book, Desk oder Portfolio.
Status	Case-Status, zum Beispiel Open, Acknowledged, Escalated, Approved oder TemporarilyApproved.
Severity	Manuelle Case-Severity: Critical, High, Medium oder Low.
Category	Limit-Kategorie aus Definition und Source.
Source	Datenquelle oder Modell, zum Beispiel Sensitivity, VaR99, VaR95 oder StressScenario.
Owner	Zugewiesener Owner des Breach Case.

KPI-Karten

Karte	Bedeutung
Breaches	Group-Level Exception Count oberhalb der Linie, Book-, Desk- und Portfolio-Counts darunter.
Severity	Group-Level Critical Count oberhalb der Linie, High, Medium und Low darunter.
Max Utilization	Hoechste Auslastung im gefilterten Exception-Set, letzter Maximalwert, Durchschnitts-Maximum und Zeilen ueber 100%.
Approvals	Exceptions mit bald auslaufender temporaerer Genehmigung und Counts nach Approval-Ergebnis.

Exception Handling

Eine Zeile oeffnet den Manage Dialog. Dort sieht man letzte Auslastung, first/last seen, Observation-Historie, Kommentare und Approvals.

Aktion	Verwendung
Acknowledge	Risk Control hat die Exception gesehen und uebernimmt die Pruefung.
Escalate	Die Exception braucht Aufmerksamkeit von Management oder Model Owner.
Accept	Der Breach wird mit dokumentiertem Grund akzeptiert.
Temp Approve	Der Breach wird temporaer bis zu einem Valid-Until-Datum erlaubt.
Reject	Die beantragte Genehmigung wird abgelehnt.
Close	Der Case ist nicht mehr aktiv und wird mit Grund geschlossen.

Kommentare koennen intern, Risk-Control- oder Report-Kommentare sein. Die Visibility steuert, ob ein Kommentar nur operativ sichtbar ist, an Management geht oder fuer Reporting gedacht ist.

Wie Limits bewertet werden

Der Evaluator laedt aktive LimitDefinition-Datensaetze fuer Datenquelle und Stichtag. SourceMode = Legacy wird ignoriert; New und Shadow werden bewertet. Die aktive LimitDefinitionVersion liefert Limitwert und Warning-/Breach-Schwellen fuer den Stichtag.

Fuer jedes Limit liest der Evaluator passende Aggregation Rows ueber:

Feld	Anforderung
DataSource	Muss zum Modell oder zur Source des Workflows passen.
Aggregation	Waehlt den Measure-Namen aus den Aggregation Result Values.
AggregationProfile	Definiert Result Set und Dimension Key.
Reference Date	Muss dem Simulation-Stichtag entsprechen.
SimulationId	Muss der Analyzer Run Id entsprechen.

Actual Values werden als Absolutwerte bewertet. Die Auslastung ist abs(actual) / limit value * 100. Unterhalb der Warning-Schwelle ist der Status Clean, ab WarningThresholdPercent Warning und ab BreachThresholdPercent Breach.

Limit konfigurieren

Die Pflege liegt unter Analyzer Configuration > Limit Definitions. Ein vollstaendiges Limit besteht aus einer Definition, mindestens einer aktiven Version und optionalen Constraints.

Definition

Feld	Empfehlung
Name	Stabiler fachlicher Name. Sinnvoll sind Namen mit Measure, Scope und Level, zum Beispiel DeltaAbs/ALL/Default/Desk/STD.
DataSource	Source oder Modell des Workflows, zum Beispiel Sensitivity, VaR99, VaR95, SVaR99 oder StressScenario.
Aggregation	Measure aus den Aggregation Result Values, zum Beispiel LIMIT_NG_SENSI_ABS oder LIMIT_NG_VAR_IR.
AggregationProfile	Bestimmt Result Set und Dimensionen, zum Beispiel Desk-, Book-, Portfolio-, FactorType- oder Risk-Factor-Group-Profile.
LimitLevel	Reporting-Hierarchie fuer Dashboard-Filter und KPI-Counts.
LimitValue	Aktueller Headline-Wert. Mit der aktiven Version synchron halten.
WarningThresholdPercent	Typisch 80. Ab dieser Auslastung entsteht eine Warning Observation.
BreachThresholdPercent	Typisch 100. Ab dieser Auslastung entsteht oder aktualisiert sich ein Breach Case.
Unit und Currency	Anzeige- und Filterwerte, typischerweise EUR.
ValidFrom und ValidTo	Gueltigkeit der Definition. Der Evaluator laedt nur Definitionen, die am Stichtag gueltig sind.
IsActive	Muss fuer Bewertung aktiv sein.
SourceMode	New fuer produktive Next-Gen-Limits oder Shadow fuer migrierte/parallele Limits. Legacy wird uebersprungen.

Versions

Versions enthalten die wirksamen Limitwerte. Lege eine neue Version an, wenn Betrag oder Schwellen geaendert werden. ValidFrom und ValidTo sollten so gesetzt sein, dass fuer einen Stichtag genau die gewuenschte Version aktiv ist. Wenn mehrere Versionen gueltig sind, wird die hoechste VersionNumber verwendet.

Definition Value und neueste Version sollten synchron bleiben. Fuer die Berechnung nutzt der Evaluator die aktive Version.

Constraints

Constraints begrenzen, welche Aggregation Rows bewertet werden.

Rolle	Bedeutung
EvaluationScope	Schraenkt den fachlichen Scope ein, zum Beispiel Desk = STD. Der Scope hilft auch, Observations ueber Zeit zu einem Breach Case zu gruppieren.
PopulationFilter	Schraenkt die Population innerhalb des Scopes ein, zum Beispiel FactorType Contains Vega oder FactorType = IrDelta.

Unterstuetzte Operatoren sind Equals, NotEquals, In, NotIn, Contains, GreaterThan, LessThan, GreaterOrEqual und LessOrEqual. Fuer In und NotIn koennen komma-separierte Werte in Value oder ein JSON-String-Array in ValueListJson verwendet werden.

Dimension Names muessen exakt zu den Dimensionen des Aggregation Profile passen, zum Beispiel Desk, Book, Portfolio, FactorType oder FactorGroup. Wenn keine Aggregation Row matched, erzeugt der Evaluator eine MissingData Observation mit Diagnostic Message.

Konfigurations-Checkliste

• Source oder Modell waehlen, das der Workflow berechnet.
• Aggregation Measure waehlen, das den Risikowert enthaelt.
• Aggregation Profile waehlen, dessen Dimensionen alle geplanten Constraints enthalten.
• Level, Currency, Unit, Active Flag und Source Mode setzen.
• Aktive Version mit Wert, Warning Threshold, Breach Threshold und Gueltigkeit anlegen.
• EvaluationScope Constraints fuer den fachlichen Scope anlegen.
• PopulationFilter Constraints fuer Faktor- oder Kategorie-Subsets anlegen.
• Workflow laufen lassen und im Limits Dashboard Clean, Warning, Breach, MissingData oder EvaluationError pruefen.

Typische Probleme

Problem	Moegliche Ursache	Aktion
Keine Exception sichtbar	Auslastung liegt unter Breach Threshold oder Filter fuer Status, Level, Currency oder Datum schliessen den Case aus.	Selektoren und Observation-Historie pruefen.
MissingData Observation	Keine Aggregation Row passt zu Source, Result Set, Dimension Key oder Constraints.	Aggregation Profile Dimensions und Constraint-Namen vergleichen.
EvaluationError Observation	Das konfigurierte Measure fehlt oder der Limitwert ist nicht positiv.	Aggregation Measure und aktive Version pruefen.
Breach erscheint auf spaeterem Datum	Breach Cases halten die neueste Observation, die Historie enthaelt fruehere Observations.	Zeile oeffnen und Development Tab pruefen.
Zeilen wirken doppelt	Scope oder Population Constraints unterscheiden sich; fachlich sind es andere Controls.	Constraints und Source-Aggregation-Dimensionen vergleichen.

Zweck

Das Sensitivities Dashboard zeigt Marktrisiko-Sensitivitaeten nach Faktortyp, Portfolio, Instrumenttyp und Limitkontext. Es hilft zu erkennen, wo Delta-, Vega- und verwandte Exposures konzentriert sind, wie sie sich bewegen und ob Limits belastet werden.

Selektoren

Selektor	Bedeutung
Reference Date	Stichtag der angezeigten Sensitivitaeten.
Currency	Reporting-Waehrung der Werte.
Dashboard Level	Business-Hierarchie fuer Breakdowns, typischerweise Desk im Tagesreview.

Wichtige Widgets

Widget	Review-Fokus
EQ, IR, FX, CS, CM	Net, Gross und kurzfristige Bewegung je Risikoart.
Group Limit	Wichtigste Sensitivitaets-Limitauslastungen und Breaches.
Sensitivities by Portfolio	Faktortyp-Verteilung ueber Portfolios.
Faktor- und Instrument-Breakdowns	Konzentrationen nach Faktorgruppe, Instrumenttyp, Rating und Valuation Group.
Instrument detail	Instrumentbezogene Sensitivitaetszeilen fuer Detailpruefung und Filterung.

Review-Ablauf

• KPI-Zeile pruefen und dominante Risikoart identifizieren.
• Portfolio- und Faktorcharts zur Konzentrationsanalyse nutzen.
• Limitauslastung pruefen, wenn eine Risikoart gross ist oder schnell steigt.
• Instrumentdetails nach groesstem Portfolio, Faktortyp oder Instrumenttyp filtern.

Typische Probleme

Problem	Moegliche Ursache	Aktion
Leeres Dashboard	Sensitivitaets-Workflow hat fuer das Datum keine Ergebnisse erzeugt.	Workflow-Abschluss und Data Provider pruefen.
Limit-Widget leer	Limitresultate fehlen oder sind nicht auf das Sensitivitaetsmodell gemappt.	Limitkonfiguration und Ergebnisgenerierung pruefen.
Gross hoch, Net klein	Gegenlaeufige Positionen ueber Instrumente oder Portfolios.	Gross Exposure und Instrumentzeilen pruefen.
Unerwarteter Faktortyp	Instrumentmapping, Marktdatenkurve oder Valuation Group geaendert.	Instrumentsetup und Faktorzuordnung pruefen.

Zweck

Provisions sind kontrollierte fachliche Anpassungen, die in Reporting und PnL-Erklärungen einfließen. Sie können Reserven, Bewertungsanpassungen, operative Korrekturen, Releases oder andere dokumentierte Adjustments abbilden. Jede Provision sollte transparent, verantwortet, datiert und prüfbar sein.

Zentrale Konzepte

Konzept	Bedeutung
Provision	Kopfsatz mit Scope, Type, Amount, Status, Owner und Reason.
Provision Entry	Zahlungsdatumsbezogene Zeile mit Future Value, Discount Factor und Present Value.
Scope Level	Fachliche Ebene: Group, Desk, Book, Portfolio oder Instrument.
Provision Type	Fachliche Klassifikation wie Valuation Adjustment, Reserve, Release oder Other.
Status	Lifecycle State wie Draft, Approved oder Released.
Discount Curve	Kurve zur Diskontierung zukünftiger Provision Entries.
Release Reason	Erklärung bei Release oder Reduktion einer Provision.

Typischer Ablauf

• Fachlichen Grund für die Provision identifizieren.
• Reference Date und fachlichen Scope auswählen.
• Provision Type, Currency, Amount und Owner erfassen.
• Provision Entries anlegen, wenn der Betrag eine Payment-Date-Struktur hat.
• Discount Curve, Day Counter und Discount Point Type prüfen.
• Present Value und Day-to-Day Change prüfen.
• Provision gemäß Governance approven oder releasen.
• Im Report Framework prüfen, ob die Provision in PnL- und Provision-Sections sichtbar ist.

Provision Header

Feld	Bedeutung
Reference Date	Datum, für das die Provision im Reporting gilt.
Scope Level	Ebene, auf der die Provision gilt.
Group / Desk / Book / Portfolio / Instrument	Fachliche Schlüssel für den genauen Scope.
Currency	Währung des Provision Amount.
Provision Type	Fachliche Klassifikation.
Amount	Aktueller Provision-Betrag.
Previous Amount	Vorheriger Betrag für Change Analysis.
Change DtD	Day-to-Day-Bewegung.
Discount Curve	Kurve zur PV-Berechnung.
Day Counter	Day-Count-Konvention für Diskontierung.
Discount Point Type	Interpretation des Discount Points, zum Beispiel DiscountFactor.
Reason	Fachlicher Grund für die Provision.
Owner	Verantwortliche Person oder Team.
Effective From / To	Gültigkeitsfenster, falls relevant.
Status	Draft, Approved, Released oder anderer konfigurierter Status.
Comment	Zusätzliche Erklärung für Reviewer.

Provision Entries

Provision Entries zerlegen die Provision in datierte Future Values. Dadurch kann der Report Laufzeit-Buckets und diskontierte Present Values zeigen, statt nur einen flachen Betrag.

Feld	Bedeutung
Payment Date	Datum des Provision-Cashflows oder Adjustments.
Future Value	Undiskontierter Betrag zum Payment Date.
Discount Factor	Discount Factor aus der gewählten Kurve.
Present Value	Diskontierter Wert im Reporting.
Comment	Erklärung auf Entry-Ebene.

Die einfache Present-Value-Beziehung lautet:

$$ PV_i = FV_i \times DF(t_i) $$

Für eine Provision mit mehreren Entries:

$$ PV_{provision} = \sum_i FV_i \times DF(t_i) $$

PnL-Wirkung

Provision-Bewegungen werden getrennt von Gross PnL gezeigt, damit Reviewer Marktbewegungen von fachlichen Adjustments unterscheiden können. Typisch ist:

$$ NetPnL = GrossPnL + ProvisionIncrease - ProvisionRelease $$

Die genaue Sign Convention muss in der Report Section geprüft werden. Eine Provision Increase reduziert wirtschaftlich häufig das Ergebnis, während ein Release es verbessert; Reports können Increases und Releases aber als separate signed Columns darstellen.

Statusinterpretation

Status	Bedeutung	Aktion
Draft	Erfasst, aber nicht für Reporting freigegeben.	Inputs und Reason prüfen.
Approved	Für Reference Date und Scope akzeptiert.	Sichtbarkeit im Report prüfen.
Released	Nicht mehr aktiv oder aus dokumentiertem Grund reduziert.	Release Reason und Release Date prüfen.
Rejected	Nicht für Reporting akzeptiert.	Korrigieren oder aus operativem Scope entfernen.

Data-Quality-Prüfungen

Check	Warum wichtig
Scope-Vollständigkeit	Fehlende Desk-, Book- oder Portfolio-Werte können den Report falsch zuordnen.
Currency-Konsistenz	Falsche Währung verzerrt Net PnL nach FX-Umrechnung.
Discount Curve Availability	Fehlende Kurvendaten verhindern zuverlässige PV-Berechnung.
Payment Date Validity	Vergangene oder inkonsistente Payment Dates erzeugen falsche Buckets.
Amount und Sign	Falsches Vorzeichen dreht Provision Increase/Release um.
Status Governance	Draft Provisions sollten nicht ungeprüft final berichtet werden.

Häufige Probleme

Problem	Bedeutung	Mögliche Aktion
Provision fehlt im Report	Scope, Status oder Reference Date passt nicht zum Report Request.	Provision Keys mit Report Level und Datum vergleichen.
Present Value ist null	Keine Entries, Nullbetrag, fehlender Discount Factor oder Kurvensetup.	Entries und Marktdaten prüfen.
Unerwarteter DtD Change	Previous Amount weicht ab oder Release wurde angewendet.	Previous Amount, Change DtD und Release Details prüfen.
Falscher Bucket	Payment Dates oder Scope Keys sind falsch.	Entry Dates und Scope Level korrigieren.
Provision wirkt doppelt	Ähnliche Scope-Werte können unterschiedliche Type, Owner oder Reason haben.	Nur nach fachlichem Review konsolidieren.

Empfohlene Praxis

Jede Provision braucht einen klaren Reason und Owner. Payment-Date Entries sollten zur erwarteten wirtschaftlichen Fälligkeit passen. Provisions dürfen fehlende Marktdaten oder fehlgeschlagene Valuation Workflows nicht verdecken; solche Fälle gehören in Data Quality oder Workflow-Diagnose. Vor Distribution Gross PnL, Provision Movements und Net PnL after Provisions abstimmen.

Zweck

Audit- und Änderungshistorien helfen Anwendern zu verstehen, wer Fach- oder Konfigurationsdaten geändert hat, wann die Änderung passiert ist, welche Felder betroffen waren und ob die Änderung ein übergeordnetes Geschäftsobjekt wie Instrument, Trade, Portfolio, Kurve, Risikomodell oder Report Definition betrifft. Die Funktion unterstützt tägliche Prüfung, operativen Support, Modellgovernance und Ursachenanalyse.

Auditdaten ersetzen keinen Freigabeprozess. Sie liefern die Evidenz, wie der aktuelle Zustand entstanden ist und welche Änderungen Review, Neuberechnung oder Nachverfolgung benötigen können.

Was erfasst wird

Jeder Audit-Eintrag speichert die geänderte Entität, die Operation, den Akteur, den Zeitstempel und die Quelle der Änderung. Soweit verfügbar werden zusätzlich Felddifferenzen sowie Snapshots vor und nach der Änderung gespeichert.

Bereich	Bedeutung
Geänderte Entität	Die Zeile, die direkt angelegt, geändert oder gelöscht wurde.
Root-Entität	Das übergeordnete Objekt für den fachlichen Review, zum Beispiel ein Instrument mit Legs oder Underlying Mappings.
Geänderte Felder	Alte und neue Werte auf Feldebene.
Benutzer	User Id oder Benutzername aus dem Command-Kontext.
Quelle	UI, API, Import, Batch, Migration oder System, soweit verfügbar.
Command	Command Handler oder Operation, die die Änderung erzeugt hat.
Materialität	Kennzeichen für Felder mit Relevanz für Bewertung, Risiko, Reporting oder operativen Review.

History Tab

Konfigurationsseiten enthalten einen History Tab. Die obere Tabelle zeigt aktuelle Audit-Einträge für das ausgewählte Objekt und bei übergeordneten Objekten auch Änderungen an verknüpften Kindobjekten. Eine Instrumentenhistorie kann zum Beispiel Änderungen an Legs, Underlying Mappings oder anderen instrumentbezogenen Zeilen enthalten, wenn die Änderung das Instrument als Root-Entität trägt.

Wählen Sie eine Zeile aus, um die Felddetails unterhalb der Tabelle zu sehen. Die Detailtabelle zeigt Feldname, alten Wert, neuen Wert und Materialität. Nutzen Sie diese Ansicht, wenn ein Instrument, Trade, eine Kurve oder Report Definition vom erwarteten Zustand abweicht.

Audit Dashboard

Das Audit Dashboard fasst Änderungen über einen Datumsbereich zusammen. Im Filterpanel können Benutzer, Änderungsart, Quelle und Entitätstyp eingeschränkt werden. Das Dashboard zeigt Gesamtänderungen, materielle Änderungen, geänderte Entitäten, aktive Benutzer, Tagestrend, Buckets nach Entitätstyp, Änderungsart, Quelle und Benutzer, aktuelle Änderungen sowie die am häufigsten geänderten Entitäten.

Top Changed Entities werden nach Root-Entität gruppiert. Dadurch können Änderungen an Kindobjekten unter dem fachlich zugehörigen Objekt geprüft werden, während die Recent Changes Tabelle weiterhin die direkt geänderte Entität zeigt.

Eine Änderung untersuchen

• Starten Sie beim fachlichen Objekt, das auffällig ist, zum Beispiel Instrument oder Report Definition.
• Öffnen Sie History und prüfen Sie die neuesten Einträge.
• Wählen Sie einen Eintrag aus und lesen Sie alte und neue Werte auf Feldebene.
• Prüfen Sie Benutzer, Quelle, Command und Zeitstempel.
• Wenn die Änderung materiell ist, klären Sie, ob Bewertung, Sensitivitäten, PnL Explain, Reports oder Datenqualitätsprüfungen erneut laufen müssen.
• Nutzen Sie das Audit Dashboard für breitere Fragen wie "was wurde heute geändert" oder "welcher Benutzer hat viele Instrumente geändert".

Änderungen an verknüpften Entitäten

Das Auditmodell trennt direkte Änderung und Root-Kontext. Eine Leg-Änderung bleibt eine Leg-Änderung, kann aber für Historie und Dashboard-Gruppierung zum Instrument hochgerollt werden. So bleibt die technische Präzision erhalten und Fachanwender erhalten gleichzeitig die objektbezogene Sicht.

Wenn ein Kindobjekt nur ein anderes Kindobjekt referenziert und keine Top-Level-Id trägt, kann der Audit-Eintrag nur bis zum unmittelbaren Parent hochgerollt werden. Nutzen Sie dann die direkt geänderte Entität und den Command-Kontext für die Nachverfolgung.

Empfohlene Praxis

Prüfen Sie materielle Änderungen vor Reportverteilung oder Risiko-Sign-off. Bei bewertungsrelevanten Feldern sollten betroffene Workflows erneut ausgeführt werden, statt alte Ergebnisse weiterzuverwenden. Verwenden Sie klare Kommentare und Änderungsgründe, wenn Commands diese Informationen unterstützen, und bevorzugen Sie stabile Business Keys wie Trade Number, Instrument Code, ISIN oder Reportname.

Häufige Probleme

Problem	Bedeutung	Mögliche Aktion
Keine Historie gefunden	Für die ausgewählte Entität oder den Root-Kontext existiert kein Audit-Eintrag.	Objekt-Id, Datumsbereich und Aktivierungszeitpunkt des Audits prüfen.
Kindänderung erscheint beim Parent	Die geänderte Zeile trägt Root-Kontext, zum Beispiel ein Leg unter einem Instrument.	Spalte der direkt geänderten Entität für die genaue Zeile prüfen.
Benutzer ist system	Änderung wurde durch Batch, Migration oder Command ohne Benutzerkontext erzeugt.	Quelle, Command Name und Zeitstempel prüfen.
Feldliste ist leer	Der Command hat ein Entity-Level Event ohne Felddifferenzen gespeichert.	Snapshots, Command Name und Quelle verwenden.
Dashboard-Zahl weicht von Entity History ab	Das Dashboard gruppiert Top Entities nach Root-Kontext und nutzt Datumsfilter.	Filter, Datumsbereich und Entitätstyp vergleichen.

Zweck

Readiness Status fasst zusammen, ob ein Modell, Instrument oder Validierungseintrag für den dokumentierten Scope nutzbar ist.

Statuswerte

Status	Bedeutung
Green	Prüfungen für den dokumentierten Scope bestanden.
Amber	Evidenz ist vorhanden, aber teilweise, eingeschränkt oder mit wichtigen Limitationen.
Red	Eine kritische Prüfung ist fehlgeschlagen.
Unknown	Keine ausführbare Evidenz vorhanden oder nur Inventareintrag.

Empfohlene Praxis

Lesen Sie Limitationen immer, bevor Sie Green- oder Amber-Ergebnisse verwenden. Status ersetzt nicht Scope, Evidenz und fachliche Modellprüfung.

Zweck

Evidenzen dokumentieren Expected Values, Actual Values, Toleranzen und Referenzen, die einen Validierungsstatus unterstützen.

Wichtige Felder

Feld	Bedeutung
Expected	Benchmark oder Referenzwert.
Actual	Vom System erzeugter Wert.
Tolerance	Maximal akzeptierte Abweichung.
Evidence Reference	Link oder Referenz auf Detailnachweise.
Dataset Reference	Eingabedaten für die Validierungsprüfung.

Häufige Probleme

Problem	Bedeutung	Mögliche Aktion
Abweichung innerhalb Toleranz	Ergebnis ist für diese Prüfung akzeptabel.	Scope und Limitation prüfen.
Abweichung außerhalb Toleranz	Validierung ist fehlgeschlagen oder braucht Analyse.	Inputdaten und Benchmark-Annahmen vergleichen.
Evidenz fehlt	Es wurde keine Prüfung generiert.	Readiness für diesen Scope als Unknown behandeln.

Zweck

Model Validation fokussiert auf die Methode, die ein Ergebnis erzeugt hat: Annahmen, Inputs, Outputs, Benchmarks, Evidenz und Limitationen.

Wichtige Felder

Feld	Bedeutung
Model ID	Stabile Kennung für Modell oder Methode.
Family	Gruppierung wie Pricing, VaR, ES, FRTB, Volatility oder Data Quality.
Validation Method	Wie das Modell geprüft wurde.
Benchmark Source	Referenz für den Vergleich mit Actual Results.
DQ Checks	Data-Quality-Prüfungen, die für das Modellpack oder seine Validierungsinputs gelten.
Limitation	Scope-Einschränkung, die auch bei bestandener Evidenz sichtbar bleibt.

Verbindung zu Data Quality

Model Validation beantwortet, ob eine Methode für den dokumentierten Scope bereit ist. Data Quality beantwortet, ob die von dieser Methode verwendeten Inputs vollständig und zuverlässig genug sind, um die Evidenz zu interpretieren.

Das Model Validation Dashboard kann deshalb DQ-Links neben Pack-Aktionen wie Shocks, Scenario, Portfolio, Results und Status anzeigen. Diese Links sollten Teil des normalen Validierungsablaufs sein und nicht erst nach einem Fehler genutzt werden.

Beispiele:

Modellpack	DQ-Evidenz kann erklären
VaR / ES	Fehlende Szenarioinputs, unvollständige Shock-Vektoren, stale Referenzdaten oder inkonsistente Portfolio-Szenariovektoren.
DCF / Pricing	Fehlende Cashflow-Inputs, Curve Mappings, Datums-Konventionen oder Stammdatenprobleme.
Sensitivities	Fehlende Base- oder Shifted-Prices, inkonsistentes Bump-Setup oder nicht verfügbare Risikofaktoren.
FRTB	Fehlende Sensitivity-Inputs, Bucket-Mappings, Risk-Class-Inputs oder unvollständige Testportfoliodaten.
Volatility	Fehlende Surface Nodes, ungültige Vol Quotes, nicht unterstützte Interpolationspunkte oder Konventionsabweichungen.

NMD-Validierung

Non-Maturity Deposits verbinden Instrument Validation, IRRBB-Methodik, Sensitivitäten und Marktdatenvalidierung. Ein Green-Status ist nur aussagekräftig, wenn die Verhaltensannahmen und Marktdaten zum getesteten Scope passen.

Prüffeld	Was zu lesen ist
Segment und Core Balance	Segment-Cap, Stable Balance Ratio und berechneter Core-Anteil müssen konsistent sein.
Runoff und WAL	Cashflow-Profil und gewichtete durchschnittliche Laufzeit müssen innerhalb der Cap liegen.
Floor-Komponente	Bei IncludeFloorValue muss die Normal-Volatilitätsfläche vorhanden und zum FloorStrike passend sein.
Sensitivitäten	PV01 kommt aus Kurvenexposure; IrVega kommt aus dem NMD-Floor und darf nicht mit IR Delta verwechselt werden.
VaR	Historische Szenarien benötigen dieselben gemappten Kurven- und Volatilitätsfaktoren wie die Bewertung.

Typische Red- oder Amber-Ursachen sind fehlende Surface Nodes, fehlende historische Vol-Quotes, ein zu langes Runoff-Profil, ein überschrittenes Core-Balance-Cap oder ein Sensitivitätslauf, der einen anderen Strike als die Bewertung verwendet.

Nutzung des Links

• Modellpack auswählen.
• Die Action-Spalte öffnen, die fehlgeschlagen ist oder auffällig wirkt.
• DQ-Ansicht oder DQ-Referenz öffnen.
• Zuerst Critical Findings prüfen.
• Betroffenen Input mit der Modellevidenz vergleichen.
• Entscheiden, ob es ein Daten-Readiness-, Modell-Readiness- oder Benchmark-/Toleranzproblem ist.

Wenn DQ unvollständig oder für ein Pack nicht anwendbar ist, kann das Dashboard einen Platzhalter anzeigen. Daraus darf nicht abgeleitet werden, dass Data Quality bestanden wurde; es bedeutet nur, dass aktuell keine dedizierte DQ-Evidenz an dieses Pack angebunden ist.

Accepted DQ Exceptions

Einige Modellpacks können DQ-Ergebnisse mit Status Accepted zeigen. Das bedeutet, dass eine aktive Data-Quality-Exception-Rule auf das Finding gepasst hat. Der wichtigste aktuelle Fall ist RfValue: Fehlende Risk-Factor Values in nicht-null Sensitivity-Vector-Einträgen können akzeptiert werden, wenn die konfigurierte Regel auf Instrument- oder Risk-Factor-Fakten passt.

Accepted DQ ist als dokumentierte Ausnahme zu lesen:

Reviewpunkt	Was zu prüfen ist
Rule Name	Beschreibt der Name die konkrete Ausnahme?
Priority	Wurde bei mehreren passenden Regeln die gewünschte Regel gezogen? Kleinere Priority-Werte werden zuerst angewendet.
Owner	Ist eine Person oder Gruppe verantwortlich?
Reason	Ist der fachliche oder modellvalidierungsbezogene Grund klar?
Gültigkeit	Ist ValidTo gesetzt, wenn die Exception auslaufen soll?
Scope	Sind die Bedingungen eng genug, damit keine unabhängigen DQ-Probleme verdeckt werden?

Die angewendete Regel steht im DQ-Result-Metadata-Feld AcceptedByExceptionRule. Accepted Findings werden getrennt von Pass und Fail gezählt; ein Green-Modell mit Accepted DQ muss deshalb weiterhin mit seinen Limitationen geprüft werden.