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

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

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

Der Systembereich hilft Operatoren und Fachanwendern zu verstehen, ob die Workflow-Verarbeitung gesund ist. Er trennt drei unterschiedliche Sichten:

Seite	Zweck
System Overview	Live-Zustand von Workern und Message Broker.
Statistiken	Historische Workflow-Runs mit Größe, Laufzeit und Metadaten.
Workflow Queue	Admission-Zustand von Workflow-Batches: queued, running, failed und kürzlich completed.

Die wichtigste Unterscheidung: Die Message Broker Tabelle zeigt RabbitMQ Queues. Die Workflow Queue Seite zeigt die Workflow-Admission-Queue des Portals. Beide hängen zusammen, sind aber nicht dieselbe Queue.

System Overview

System Overview ist eine Live-Sicht über PushNotifier. Updates kommen ungefähr alle zwei Sekunden.

Der Kopfbereich zeigt:

Feld	Bedeutung
Workers	Anzahl der Worker, die PushNotifier kennt.
Idle	Worker, die keine Nachricht verarbeiten.
Busy	Worker mit aktiver Arbeit.
Broker	Ob der RabbitMQ Management Endpoint erreichbar ist.
Push connection	SignalR-Verbindung zwischen Portal und PushNotifier.

Wenn die Push-Verbindung getrennt ist, kann die Ansicht alte Daten zeigen. Wenn der Broker offline ist, können Worker-Heartbeats sichtbar bleiben, aber Queue-Größen nicht gelesen werden.

Worker State Tabelle

Worker senden Heartbeat Events über den Priority/Control Channel. Das Heartbeat-Intervall beträgt zwei Sekunden.

Spalte	Bedeutung
State	Idle, Busy oder Stale.
Core Load	Single-Core-äquivalente CPU-Last des Worker-Prozesses.
Service	Service- oder Queue-Name des Workers.
Build	Build-Version des Worker-Prozesses.
Machine	Container- oder Hostname.
Process	Betriebssystem-Prozess-ID.
Current Work	Aktuelle Aktivität, z. B. valuation, pricing oder cashflow extraction.
Last Seen	Zeitpunkt des letzten Heartbeats bei PushNotifier.

Worker States

State	Bedeutung	Typische Interpretation
Idle	Worker lebt und verarbeitet keine Arbeit.	Für neue Nachrichten verfügbar.
Busy	Worker lebt und hat aktive Arbeit.	Verarbeitet eine Nachricht.
Stale	Seit mehr als dem Stale-Threshold kam kein Heartbeat.	Worker ist evtl. gestoppt, neu gestartet oder getrennt.

Der Stale-Threshold ist kurz, aktuell etwa 15 Sekunden. Forget stale workers entfernt stale Einträge aus der In-Memory-Übersicht. Es stoppt oder startet keinen Worker.

Core Load

Core Load ist bewusst nicht host-normalisierte CPU. Worker verarbeiten jeweils eine Nachricht zur Zeit, daher zeigt die UI single-core-äquivalente Auslastung.

Das bedeutet:

Anzeige	Bedeutung
Nahe 0%	Worker ist meist idle oder wartet.
40-70%	Worker leistet relevante CPU-Arbeit, sättigt aber keinen Core vollständig.
80-100%	Worker sättigt seine Verarbeitungsthread nahezu.

Auf einem Host mit vielen Cores kann ein einzelner beschäftigter Worker in Systemtools nur wenige Prozent zeigen. In dieser Tabelle kann er korrekt nahe 100% erscheinen, weil der Worker selbst single-threaded arbeitet.

Das Liniendiagramm zeigt die letzten 30 Last-Samples. Bei zwei Sekunden Heartbeat entspricht das ungefähr einer Minute.

Message Broker Tabelle

Diese Tabelle liest RabbitMQ Queue-Zustand über die RabbitMQ Management API.

Spalte	Bedeutung
Queue	RabbitMQ Queue-Name.
State	Queue-Zustand laut Broker.
Ready	Nachrichten, die in der Queue warten.
Unacked	Nachrichten, die an Consumer geliefert, aber noch nicht bestätigt wurden.
Total	Gesamte Nachrichten laut Broker, normalerweise Ready plus Unacked.
Last Minute	Queue-Size-Sparkline für die letzten 30 Broker-Samples.
Consumers	Anzahl aktiver Queue-Consumer.
Actions	Operative Aktion wie Purge von Ready Messages.

Broker Queue Werte lesen

Muster	Bedeutung	Mögliche Aktion
Ready wächst, Consumers ist null	Kein Service konsumiert die Queue.	Prüfen, ob Service oder Worker Container läuft.
Ready wächst, Consumers existieren	Consumer kommen nicht nach oder sind blockiert.	Worker State, Logs und Current Work prüfen.
Unacked bleibt hoch	Nachrichten wurden geliefert, aber nicht bestätigt.	Prüfen, ob Consumer hängen oder langsam sind.
Total steigt und fällt wieder	Workload Burst wurde verarbeitet.	Normalerweise unkritisch.
Queue fehlt	Queue wurde nicht deklariert oder Monitor kann sie nicht lesen.	Service-Startup und Broker-Konfiguration prüfen.

Die Last-Minute-Kurve ist grün, wenn die Queue leer ist, und warnfarben, wenn Nachrichten vorhanden sind.

Broker Queues purgen

Purge entfernt Ready Messages aus einer überwachten Queue. Das sollte vorsichtig verwendet werden.

Purge entfernt normalerweise keine Nachrichten, die bereits an Consumer geliefert und unacknowledged sind. Wenn Arbeit bereits läuft, kann der relevante Worker oder Service sie weiterhin abschließen oder fehlschlagen lassen.

Eine Queue nicht nur deshalb purgen, weil Nachrichten sichtbar sind. Zuerst klären, ob die Nachrichten veraltet, doppelt oder bewusst aufgegeben sind.

Statistiken

Die Statistikseite zeigt historische Workflow-Run-Datensätze aus PushNotifier. Sie lädt die letzten Workflow Run Statistics und aktualisiert nach Workflow-State-Updates.

Karten:

Karte	Bedeutung
Runs	Anzahl sichtbarer Runs nach Filter.
Completed	Runs mit Status Completed.
Largest Instrument Set	Größte Instrumentenanzahl in den sichtbaren Runs.
Max Estimated Observations	Größte geschätzte Valuation Observation Count.

Der Modellfilter grenzt die Liste auf ein Modell ein, z. B. VaR95, Hybrid95, Valuation oder ein anderes Workflow-Modell.

Statistik-Tabelle

Spalte	Bedeutung
Started	Startzeit des Workflows.
Model	Modell- oder Workflow-Model-Label.
Date	Referenzdatum / COB.
Status	Completed, Failed, Running oder anderer Workflow-Status.
Duration	Laufzeit in Sekunden.
Instruments	Anzahl der Instrumente.
Scenarios	Scenario-State Count.
Dimensions	Shock Analytics Dimension Count.
Estimated Observations	Grobe Skalenschätzung der Bewertungsbeobachtungen.

Das Detailpanel zeigt Simulation Id, Currency, Portfolio Count, Aggregation Flag, Measure Type, Finish Time sowie kompakte und rohe Statistik-JSON.

Statistiken nutzen

Statistiken beantworten Fragen wie:

Frage	Wo prüfen
Ist der letzte VaR-Run fertig?	Status und Started Spalten.
Warum war der Run langsamer als üblich?	Instruments, Scenarios, Dimensions und Estimated Observations.
Welche Simulation Id soll ich prüfen?	Detailpanel und Copy Button.
Wurde Aggregation angefordert?	Detailpanel.

Statistiken sind nicht die beste Sicht für live hängende Arbeit. Dafür System Overview und Workflow Queue verwenden.

Workflow Queue

Workflow Queue zeigt die von PushNotifier verwaltete Workflow-Admission-Queue. Diese Queue steuert, welcher Workflow-Batch laufen darf.

Sie ist nicht die RabbitMQ Broker Queue.

Die Admission Queue verhindert unkontrolliert überlappende Workflow-Batches. Queued und Running Batches können nachfolgende Batches blockieren, bis sie terminal sind.

Karten:

Karte	Bedeutung
Active Schedules	Aktive cron-artige Workflow Schedules.
Queued	Batches, die auf Admission warten.
Running	Aktuell zugelassener/laufender Batch.
Failed	Failed oder PartiallyFailed Batches.

Admission Queue Tabelle

Spalte	Bedeutung
Status	Batch-Zustand: Queued, Running, Completed, Failed, PartiallyFailed oder Cancelled.
Queued	Zeitpunkt, an dem der Batch in die Admission Queue kam.
Started	Zeitpunkt, an dem Dispatch startete.
Batch	Kurze Batch Id und interne Row Id.
COB	Referenzdatum.
Currency	Reporting Currency.
Models	Modelle aus dem Batch Payload.
Workflows	Dispatchte Workflow-Anzahl gegenüber angeforderter Workflow-Anzahl.
Last Progress	Letzter Fortschrittszeitpunkt des Batches.
Actions	Child Workflows öffnen oder Queue unblocken.

Das Öffnen eines Batches zeigt Child Workflows mit Workflow Type, Model, COB, Start/Finish-Zeit und Workflow Id.

Unblock Queue

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

Aktueller Batch State	Ergebnis von Unblock
Queued	Batch wird Cancelled.
Running	Batch wird Failed.

Alle nicht-terminalen Child Workflows werden ebenfalls failed markiert, und der Admission Service versucht, den nächsten queued Batch zu starten.

Unblock nur verwenden, wenn der Batch sicher verlassen wurde. Die Aktion verändert persistierten Workflow-Zustand.

Active Schedules

Active Schedules zeigen konfigurierte zeitgesteuerte Workflow-Auslöser.

Spalte	Bedeutung
Name	Schedule Name.
Cron	Cron Expression.
Time Zone	Zeitzone für die Auswertung des Schedules.
Last Run	Letzter Triggerzeitpunkt.
Last Success	Letzter erfolgreicher Scheduled Run.
Last Failure	Letzter fehlgeschlagener Scheduled Run und Fehler.

Recent Scheduled Runs

Recent Scheduled Runs zeigen die letzten schedule-getriggerten Workflow-Batches. Nicht abgeschlossene Runs und Completed Runs aus dem jüngeren Zeitfenster sind enthalten.

Spalte	Bedeutung
Status	Status des Scheduled Runs.
Schedule	Schedule Name.
Triggered	Triggerzeit.
Source	Manual oder Scheduler Source.
COB	Referenzdatum.
Finished	Finish Time.
Batch	Batch Id, die in Admission eingegangen ist.

Troubleshooting

Symptom	Wahrscheinliche Ursache	Erste Prüfung
Dashboard zeigt keine neuen Ergebnisse	Workflow ist nicht fertig oder Aggregation lief nicht.	Statistics und Workflow Queue.
Workflow Queue hat lange einen Running Batch	Batch läuft noch oder ist verlassen.	Child Workflows öffnen, danach Worker und Logs prüfen.
RabbitMQ Ready wächst	Consumer fehlen oder sind langsamer als Producer.	Broker Consumers und Worker States.
Unacked bleibt hoch	Consumer hat Arbeit erhalten, aber nicht bestätigt.	Worker Current Work und Service Logs.
Worker verschwinden oder werden stale	Heartbeats stoppen.	Containerstatus und PushNotifier-Verbindung.
Core Load ist hoch ohne Fortschritt	Worker ist CPU-bound oder steckt in Berechnung.	Current Work, Logs und Batch Progress.

Empfohlene Praxis

Die Seiten in dieser Reihenfolge nutzen:

• System Overview: prüfen, ob Worker und Broker leben.
• Workflow Queue: prüfen, ob ein alter Batch Admission blockiert.
• Statistiken: prüfen, ob der Run abgeschlossen ist und wie groß er war.
• Fachliches Dashboard: Business-Ergebnisse und Evidenz prüfen.

Diese Reihenfolge trennt Infrastrukturzustand, Workflow Admission, historische Run-Fakten und fachliche Interpretation.

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

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

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

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.

Empfohlene Praxis

Nutzen Sie Model Validation für die Frage, welche Methode ein Ergebnis erzeugt hat und wie sie geprüft wurde. Nutzen Sie Instrument Validation für die Frage, ob ein Instrument für eine Capability verwendet werden kann.

Dokumentieren Sie in Reviews sowohl den Modellstatus als auch den DQ-Status. Ein Green-Modell mit offenen Critical DQ Findings sollte nicht als uneingeschränkt bereit interpretiert werden.

Zweck

Marktdatenvollständigkeit prüft, ob die erforderlichen Inputs für einen Bewertungs- oder Risikolauf vorhanden sind.

Benötigte Daten

Input	Typische Nutzung
Discount Curve	Barwert und Diskontierung von Cashflows.
Projection Curve	Floating Coupons und Forward Rates.
FX Rate	Umrechnung in Reporting-Währung.
Volatility Surface	Optionsbewertung und Vega.
Fixings	Historische indexgebundene Cashflows.

Empfohlene Praxis

Prüfen Sie Vollständigkeit nach Bewertungsdatum und Produkttyp. Ein Lauf kann fehlschlagen, obwohl die meisten Marktdaten vorhanden sind, wenn genau ein benötigtes Fixing, ein Kurvenpunkt oder ein Vol-Punkt fehlt.

Zweck

Instrument-Stammdaten bestimmen, welches Modell ausgewählt wird und welche Marktdaten benötigt werden.

Wichtige Felder

Feld	Bedeutung
Instrument Type	Produktklassifikation für Modellwahl.
Currency	Steuert Diskontierung und Reporting-Verhalten.
Index	Floating-Rate- oder Inflationsindexfamilie.
Maturity	Enddatum für Eligibility und Cashflow-Generierung.
Quantity	Positionsmenge, die auf Unit Valuation angewendet wird.

Häufige Probleme

Problem	Bedeutung	Mögliche Aktion
Maturity fehlt	Cashflows können nicht zuverlässig generiert werden.	Instrument-Stammdaten korrigieren.
Negative oder extreme Quantity	Ergebnisse können unplausibel groß wirken.	Positionsgröße und Vorzeichen bestätigen.
Curve Mapping fehlt	Modell kann benötigte Kurve nicht auflösen.	Marktdatenmapping aktualisieren.

Zweck

Data Quality Findings erklären, warum eine Position, ein Instrument oder ein Marktdatenpunkt unsicher für eine Berechnung sein kann.

Severity

Severity	Bedeutung
Info	Nützlicher Kontext, normalerweise nicht blockierend.
Warning	Berechnung kann laufen, sollte aber geprüft werden.
Critical	Berechnung ist nicht vertrauenswürdig oder kann fehlschlagen.

Links aus Validierungsdashboards

Data Quality Findings können direkt aus Instrument Validation und Model Validation geöffnet werden. Der Link soll den Analyseweg verkürzen, wenn ein Validierungseintrag Amber, Red, Unknown oder unerwartet leer ist.

Nutzen Sie verlinkte DQ-Evidenz, um folgende Fragen zu beantworten:

• Waren die Stammdaten der Position vollständig?
• Waren alle benötigten Marktdateninputs verfügbar?
• Waren Curve-, Volatility-, FX- oder Szenarioreferenzen korrekt gemappt?
• War das Validierungsportfolio für das ausgewählte Modellpack vollständig?
• Betrifft ein DQ Finding nur ein Instrument, einen Modellinput oder das gesamte Validierungspack?

Instrumenten- und Modellkontext

Linkquelle	Typischer DQ-Scope
Instrument-Matrix-Zelle	Produktstammdaten, erforderliche Quotes, Curve Mappings und capability-spezifische Checks für Instrument und Capability.
Model-Matrix-Zeile	Modellpack-Inputs, Benchmark-Datasets, Szenariovektoren, Validierungsportfolio und modellspezifische Annahmen.
Evidenzdetail	Dataset oder Evidenzeintrag, der von einer bestimmten Validierungsprüfung verwendet wurde.

Dieselbe Ursache kann an mehreren Stellen sichtbar werden. Ein fehlender Curve Quote kann zum Beispiel Bond Pricing, PV01, Szenarioerzeugung und VaR betreffen. In diesem Fall sollte die Datenursache einmal korrigiert und danach die betroffenen Validierungspacks neu erzeugt werden.

Häufige DQ-verknüpfte Situationen

Finding	Auswirkung auf Validierung	Mögliche Aktion
Fehlender Market Quote	Pricing-, Sensitivity- oder Szenariovalidierung kann fehlen oder unzuverlässig sein.	Quote ergänzen oder korrigieren und Evidenz neu erzeugen.
Fehlendes Curve Mapping	Instrument existiert, kann aber nicht konsistent bewertet werden.	Curve-Zuordnung und Bewertungsdatum prüfen.
Stale Quote	Validierung kann mit veralteten Inputs laufen.	Prüfen, ob stale Data für den Testscope akzeptabel ist.
Ungültige Stammdaten	Instrumentenvalidierung kann fehlschlagen, bevor Modellevidenz sinnvoll ist.	Maturity, Coupon, Notional, Index, Currency oder Konvention korrigieren.
Unvollständiger Szenariovektor	VaR-, ES- oder Hybrid-Ergebnisse können fehlen oder nicht vergleichbar sein.	Szenarioinput-Abdeckung prüfen, bevor Quantile analysiert werden.

DQ Exception Rules

Data Quality Profiles enthalten jetzt einen Exceptions Tab für kontrollierte Exception Rules. Nutzen Sie diese Regeln für bekannte und dokumentierte Fälle, in denen ein DQ Finding fachlich verstanden und temporär akzeptiert ist, nicht zum Verstecken ungelöster Datenprobleme.

Öffnen Sie die Konfiguration unter Analyzer / Config / Data Quality Profiles oder /app/analyzer/config/dataqualityprofiles, wählen Sie das relevante Profil und öffnen Sie danach Exceptions.

Feld	Bedeutung
Name	Kurzer, eindeutiger Regelname innerhalb des Data Quality Profile.
CheckType	DQ Check, auf den sich die Exception bezieht. Der aktuelle operative Schwerpunkt ist RfValue.
Priority	Deterministische Auswertungsreihenfolge. Kleinere Werte werden zuerst geprüft; Standardwert ist 100.
IsActive	Aktiviert oder deaktiviert die Regel, ohne sie zu löschen.
Owner	Verantwortliche Person oder Gruppe.
Reason	Fachlicher oder modellvalidierungsbezogener Grund für die Akzeptanz.
Valid From / Valid To	Zeitraum, in dem die Exception gelten darf. Offene Regeln sollten nur bewusst dauerhaft verwendet werden.
Condition JSON	Match-Bedingungen gegen DQ-Fakten wie Instrument, Book, Portfolio, Currency, RiskFactor, FactorType, Tenor und Werte.

Für RfValue prüft der Check Sensitivitätsvektoren. Wenn ein Sensitivity-Eintrag einen nicht-null Value, aber einen leeren oder nullnahen RfValue hat, schlägt der Check normalerweise fehl. Wenn eine aktive und datumsvalide Exception Rule alle Bedingungen trifft, wird das Ergebnis als Accepted ausgewiesen.

Accepted bedeutet, dass das Finding dokumentiert und unter der Regel akzeptiert wurde. Es bedeutet nicht, dass die ursprünglichen Daten sauber sind.

Wenn mehrere aktive Regeln auf dasselbe Finding passen, wird die Regel mit der niedrigsten Priority angewendet. Bei gleicher Priorität nutzt das System Rule Name und Rule Id als deterministische Tie-Breaker. Die angewendete Regel wird im DQ-Result-Metadata-Feld AcceptedByExceptionRule dokumentiert, inklusive Rule Id, Name, Owner, Reason, Priority und Gültigkeitsdaten.

Ein Accepted Result wird im DQ Run Summary weder als Pass noch als Fail gezählt. Es wird separat als akzeptierte Evidenz gezählt, damit Reviewer saubere Daten von dokumentierten Ausnahmen unterscheiden können.

Operatoren für Exception Conditions

Exception Conditions unterstützen einfache Field/Operator/Value-Prüfungen.

Operator	Typische Nutzung
Equals	Exaktes Instrument, Book, Currency, FactorType oder Tenor treffen.
NotEquals	Einen bekannten Wert ausschließen.
Contains	Teil eines Risk-Factor-Namens treffen.
StartsWith	Eine Risk-Factor-Familie treffen, zum Beispiel ein Dividend-Shift-Präfix.
Regex	Ein kontrolliertes Namensmuster treffen.
IsZero	Numerische Werte nahe null treffen.
IsNullOrEmpty	Fehlende Textfelder treffen.

Beispiel für eine Regelabsicht:

Regelteil	Beispiel
CheckType	RfValue
Owner	Model Validation
Reason	Bekannter Dividend-Shift Risk Factor trägt im aktuellen Sensitivitätsvektorformat keinen RF Value.
Conditions	RiskFactor beginnt mit EQU/QIA_FR/DIV.Shift. und FactorType ist IrDelta.
Erwartetes Ergebnis	Passende fehlende RF Values erscheinen als Accepted; nicht passende fehlende RF Values schlagen weiter fehl.

Governance-Erwartungen

Praxis	Grund
Exception-Namen spezifisch halten.	Reviewer müssen verstehen, was akzeptiert wurde, ohne jedes Detail zu öffnen.
Möglichst ValidTo setzen.	Exceptions sollen auslaufen, wenn Daten, Model Mapping oder Vektorformat korrigiert sind.
Priority bewusst nutzen.	Normale Exceptions bei 100 belassen; kleinere Werte nur für engere oder fachlich vorrangige Regeln verwenden.
Bedingungen eng halten.	Breite Exceptions können unabhängige DQ-Probleme verdecken.
Accepted Findings zusammen mit Validierungsevidenz prüfen.	Accepted DQ kann Model- oder Instrument-Readiness weiterhin einschränken.
Exceptions nicht für fehlende Marktdaten verwenden, die vorhanden sein müssen.	Fehlende Quotes, Curves, Vols oder Fixings sollten normalerweise korrigiert und nicht akzeptiert werden.

Empfohlene Praxis

Beginnen Sie mit Critical Findings und prüfen Sie danach wiederholte Warnings. Wenn ein Ergebnis fehlt, vergleichen Sie fehlgeschlagene Instrumente mit Data Quality Findings, bevor Sie erneut laufen lassen.

Behandeln Sie einen fehlenden DQ-Link nicht als Nachweis, dass Data Quality bestanden wurde. Es kann auch bedeuten, dass aktuell keine DQ-Evidenz an dieses Pack oder diesen Workflow angebunden ist.

Highlights

Bereich	Änderung
Help	In-Portal Hilfe mit bilingualem Drawer und geschütztem Markdown-Content.
Validation	Dashboard-orientierte Hinweise zu Evidenz und Readiness.
Data Quality	Zusätzliche Anwenderbeschreibungen für häufige Findings.
Instruments	Erste Produkthinweise für Rates, Optionen und Inflation.

Aktuelle Änderungen

Bereich	Änderung
Data Quality Exceptions	Data Quality Profiles enthalten jetzt einen Exceptions Tab. Exception Rules können passende Findings als Accepted markieren, inklusive Owner, Reason, Gültigkeitszeitraum und Condition-Konfiguration.
Exception Priority	DQ Exception Rules haben jetzt eine deterministische Priority. Kleinere Werte matchen zuerst; angewendete Regeln werden in AcceptedByExceptionRule dokumentiert.
Dashboard Queries	Analyzer-Dashboard-Paging nutzt jetzt eine deterministische Default-Sortierung, wenn die UI keine explizite Sort-Spalte sendet.
RfValue Check	Fehlende Risk-Factor Values in nicht-null Sensitivity-Vector-Einträgen werden vor einem Fail gegen Exception Rules geprüft.
Validation Dashboards	Die Hilfe unterscheidet jetzt Accepted DQ klar von sauberem Pass-Status und erklärt die Auswirkung auf Model- und Instrument-Readiness.
Model Validation	Die Model-Validation-Hilfe beschreibt DQ-Links, Accepted DQ Exceptions und Reviewpunkte für Exception Governance.
Instrumentendokumentation	Implementierte Instrumentbeispiele werden als zentrierte Field/Value-Tabellen statt als raw JSON angezeigt, inklusive Rates, Equity, FX, Commodity, Inflation und Exotic Options.
Help Layout	Markdown-Tabellen im Help Drawer werden, wo sinnvoll, als kompakte zentrierte Dokumentationstabellen dargestellt.

Empfohlene Praxis

Nutzen Sie die Hilfe, während Sie auf der aktuellen Fachansicht bleiben. Die Inhalte sind bewusst kompakt und werden mit reiferen Workflows erweitert.

Wichtige Einschränkungen

Bereich	Limitation
Help Search	Suche läuft aktuell clientseitig über Artikel-Metadaten.
Methodology	Beispiele sind vereinfacht und ersetzen keine Modelldokumentation.
Validation	Status gilt nur für den Scope des generierten Evidenzpakets.
Inflation	YoY- und Zero-Coupon-Konventionen müssen explizit geprüft werden.

Empfohlene Praxis

Behandeln Sie diese Hinweise als operative Orientierung. Für formale Modellfreigaben verwenden Sie Model-Validation-Evidenz und den Governance-Prozess.