DefinitionsDefinitionen
Controlled limit definitionsKontrollierte Limitdefinitionen
Limit governance keeps thresholds, owner, scope, currency, hierarchy level and applicable risk measure explicit. Definitions cover VaR, ES, stress loss, outright exposure, SensiEquiv, DeltaAbs, notional and factor-group-specific sensitivity limits. Each definition links to the aggregation profile and result source used by the workflow, so users can see which measure is tested, which desk or book is in scope and which threshold version was active on the result date. Threshold changes stay governed through effective dates, status and audit history, which makes recalculated results explainable without losing the original decision context.Limit Governance hält Schwellenwert, Owner, Scope, Währung, Hierarchieebene und relevante Risikokennzahl explizit. Definitionen decken VaR, ES, Stressverlust, Outright Exposure, SensiEquiv, DeltaAbs, Notional und faktorgruppenspezifische Sensitivitätslimits ab. Jede Definition verweist auf Aggregation Profile und Result Source des Workflows, sodass sichtbar bleibt, welche Kennzahl geprüft wird, welcher Desk oder Book Scope gilt und welche Schwellenversion am Ergebnisstichtag aktiv war. Schwellenwertänderungen bleiben über Effective Dates, Status und Audit History kontrolliert, damit neu berechnete Ergebnisse erklärbar sind, ohne den ursprünglichen Entscheidungskontext zu verlieren.
BreachesBreaches
Breach state and utilization dashboardBreach-Status und Auslastungsdashboard
Users see current utilization, headroom, severity and active exceptions close to the risk result. KPI cards show breach counts by hierarchy level, severity split, max utilization and approval state; filters keep desk, book, category, measure and source selection available in the same exception view. The same dashboard keeps owner, status and source beside the KPI layer so reviewers can move from a group signal to the affected desk or portfolio without switching tools.Nutzer sehen aktuelle Auslastung, Headroom, Schweregrad und aktive Exceptions nahe am Risikoergebnis. KPI-Karten zeigen Breach-Anzahlen nach Hierarchieebene, Severity Split, maximale Auslastung und Approval-Status; Filter halten Desk, Book, Kategorie, Kennzahl und Source in derselben Exception-Ansicht verfügbar. Dasselbe Dashboard hält Owner, Status und Source neben der KPI-Ebene, damit Reviewer vom Gruppen-Signal zum betroffenen Desk oder Portfolio wechseln können, ohne das Tool zu verlassen.
HierarchyHierarchie
Group-level aggregationGroup-Level-Aggregation
Limits often apply above a single trade or desk. CENARYX supports checks across desks, books, portfolios, asset classes, factor groups and overallocation views so teams understand whether a breach is local, inherited or caused by aggregation. Inherited group limits remain traceable down to the contributing hierarchy level, which keeps root-cause analysis practical for risk control and desk owners.Limits gelten häufig oberhalb einzelner Trades oder Desks. CENARYX unterstützt Checks über Desks, Bücher, Portfolios, Assetklassen, Faktorgruppen und Overallocation Views, damit Teams erkennen, ob ein Breach lokal, vererbt oder aggregationsgetrieben ist. Vererbte Gruppenlimits bleiben bis zur beitragenden Hierarchieebene nachvollziehbar, sodass Root-Cause-Analyse für Risk Control und Desk Owner praktikabel bleibt.
WorkflowWorkflow
Exception lifecycle and ownershipException Lifecycle und Ownership
Limit governance connects breach review to operational action. Open exceptions can be managed through assignment, comments, acknowledgment, escalation, acceptance, temporary approval, rejection and closure, with each action retained against the affected limit and result date. The ownership model keeps risk control, desk owner and reporting status aligned: accepted or temporarily approved exceptions stay visible, but no longer look like unresolved operational noise.Limit Governance verbindet Breach Review mit operativer Maßnahme. Offene Exceptions können über Assignment, Kommentare, Acknowledgment, Eskalation, Acceptance, temporäre Freigabe, Ablehnung und Closure gesteuert werden; jede Aktion bleibt am betroffenen Limit und Ergebnisstichtag erhalten. Das Ownership-Modell hält Risk Control, Desk Owner und Reporting-Status synchron: akzeptierte oder temporär freigegebene Exceptions bleiben sichtbar, wirken aber nicht mehr wie ungeklärtes operatives Rauschen.
EvidenceEvidenz
Development history and report statusEntwicklungshistorie und Report-Status
Limit changes, acknowledgments, approvals and breach-state transitions connect back to audit history. Exception development retains first seen, last seen, latest utilization, maximum utilization, comments and approval validity, and the Market Risk Report can distinguish exceedance, trigger, ok, no data and acknowledged or accepted exceptions. This keeps regulatory evidence, management action and daily dashboard state aligned across recalculation, reporting and sign-off cycles.Limitänderungen, Acknowledgments, Approvals und Breach-State-Übergänge werden mit Audit History verbunden. Die Exception-Entwicklung hält First Seen, Last Seen, aktuelle Auslastung, maximale Auslastung, Kommentare und Approval-Gültigkeit fest; der Market Risk Report kann Exceedance, Trigger, Ok, No Data und acknowledged beziehungsweise accepted Exceptions unterscheiden. Damit bleiben regulatorische Evidenz, Management-Aktion und täglicher Dashboard-Status über Recalculation, Reporting und Sign-off hinweg synchron.