Purpose

The portal supports day-to-day risk and valuation workflows. It helps users select portfolios, review market data, start simulations, inspect results and follow validation evidence without leaving the business screen.

Typical workflow

• Select the business area from the left navigation.
• Choose the portfolio, valuation date and calculation type.
• Apply filters before starting or reviewing a run.
• Open result details to inspect aggregates, position results and errors.
• Use this help drawer when a field, status or result needs clarification.

Important fields

Field	Meaning
Valuation date	The business date used for positions, curves, quotes and fixings.
Portfolio	The selected position set or hierarchy level.
Run status	Current processing state of a simulation or validation run.
Result level	The aggregation level, such as portfolio, desk, book or position.
Filters	Criteria used to reduce tables and charts to the relevant data.

Result interpretation

Start with the summary cards, then drill into tables and details. A result can be complete even when warnings are present. Warnings usually mean that the calculation finished but a data, model or validation limitation should be reviewed.

Common issues

Issue	Meaning	Possible action
Empty table	No result matches the current filters or level.	Reset filters and confirm the valuation date and portfolio.
Missing details	The selected run has no detail payload for that view.	Check whether the run type supports the requested detail level.
Unexpected language	The portal language has not refreshed for the current component.	Switch language again or reload the page.

Recommended practice

Keep the selected valuation date visible while reviewing results. When comparing runs, confirm that portfolio, market data set and aggregation level are identical.

Purpose

Configuration editors are the master-data screens used to maintain entities such as instruments, market-data definitions, mappings, schedules and profiles. They all follow the same pattern: a pageable grid at the bottom and, after selecting a row, an expandable detail editor above it.

Working with the grid

Use the + action to create a new record. The row menu opens edit, delete and favorite actions. Column filters are applied server-side where the underlying API supports the field.

The State column shows whether the record is unchanged, added, modified or deleted in the local repository. Save commits pending changes through the target service. Cancel discards unsaved edits for the selected item.

Detail editor

The detail panel contains tabs for the selected entity. The main tab usually contains direct fields; additional tabs show child collections or mappings. Child rows are part of the selected aggregate and are saved together with the parent where the service model supports aggregate updates.

Deep links

Some editors support the id query parameter. A URL such as ...?id=<guid> opens the matching record directly after the data is loaded. Use this for links from related entities, audit views and support notes.

Practical checks

Before saving, verify the record name, business type, active flag and related mappings. Changes to shared objects can affect many valuations, simulations and reports.

Purpose

Global configuration stores application-wide settings that are read by services at runtime. Changes should be treated like production configuration: save only reviewed values and reload affected workflows when behavior must change immediately.

Global settings

Use Global Settings for shared defaults such as the business calendar and reporting currency. The calendar drives date handling for workflows that need a common business-day convention; the reporting currency is the default display or aggregation currency where no more specific setting is supplied.

Notifications

Use Notifications to control outbound workflow messages. The top-level enabled flag controls the notification feature, while the email enabled flag controls email delivery specifically.

Email can be sent by SMTP or Azure Communication Services. SMTP uses host, port, SSL, user name, encrypted password, sender and default recipients. Azure Communication Services uses an encrypted connection string and sender address.

Default recipient groups are used when an event has no more specific mapping. Recipient groups map a group name to one or more email addresses. Event groups route workflow events by event type, workflow type, workflow name and model to one or more recipient groups.

Saving

Save writes the selected section back to the global configuration store. Reload discards local edits and reads the persisted configuration again.

Purpose

Simulations calculate valuation, sensitivity, cashflow, VaR or scenario results for selected positions. The portal lets you start runs, monitor progress and inspect successful or failed items.

Typical workflow

• Select a portfolio or hierarchy level.
• Set the valuation date.
• Choose the calculation or scenario pack.
• Start the run and monitor its status.
• Review aggregates first, then inspect failed positions or batches.

Important fields

Field	Meaning
Portfolio	The position universe included in the run.
Valuation date	Date used for market data, fixings and position eligibility.
Market data	Curves, quotes, FX rates, volatilities and fixings required by the instruments.
Scenario	Shock, historical or model scenario used by the calculation.
Run ID	Unique identifier for the run, useful when discussing issues.

Result interpretation

Status values indicate processing progress:

Status	Meaning
Created	The run has been accepted but has not started processing.
Running	Workers or services are processing the run.
Completed	Processing finished. Review warnings and failed instruments if shown.
Failed	A critical error stopped the run or one of its required batches.

Common issues

Issue	Meaning	Possible action
Missing Market Data	Required quotes, curves, volatilities or fixings are unavailable.	Check the market data view for the valuation date and instrument type.
No Positions Found	The selected portfolio/date combination has no eligible positions.	Verify portfolio membership and position effective dates.
Pricing Failed	One or more instruments could not be valued.	Open failed instruments and check model, market data and instrument static data.

Recommended practice

Review aggregate results only after confirming the run level and filters. For failed runs, keep the Run ID and failed instrument identifiers visible when raising a follow-up.

Purpose

Portfolio views help you select the population of positions used for valuation, risk and reporting. A portfolio may represent a legal entity, desk, book or custom position set.

Typical workflow

• Choose the valuation date.
• Select the portfolio, desk, book or position filter.
• Review position counts and instrument types.
• Open position details before starting a material run.
• Compare the selected hierarchy with the intended reporting scope.

Important fields

Field	Meaning
Portfolio	Top-level position grouping.
Desk	Business owner or risk management desk.
Book	Trading or accounting book.
Position ID	Unique position reference used in result drilldowns.
Instrument type	Product classification used for model selection and validation.

Result interpretation

Position counts should be interpreted together with filters. A small count is not necessarily wrong if a desk, book or instrument filter is active. Review instrument type distribution when a run contains unexpected model or market data errors.

Common issues

Issue	Meaning	Possible action
Empty portfolio	No active positions match the selected date and filters.	Check date, hierarchy and position status.
Missing instrument type	Static data is incomplete or unmapped.	Review the position detail and data quality findings.
Unexpected aggregation	Results are shown at a different hierarchy level.	Set the dashboard level to portfolio, desk, book or position as needed.

Recommended practice

Before a large simulation, confirm that the selected portfolio contains the expected books and instrument types. This prevents misinterpreting empty or partial results as calculation failures.

Purpose

Market data views help users check whether valuation inputs are complete and plausible for the selected valuation date. Missing or inconsistent market data is one of the most common causes of failed or unreliable results.

Typical workflow

• Select the valuation date.
• Review curves, FX rates, volatility surfaces and fixings.
• Check completeness for the instruments in the selected portfolio.
• Investigate stale, missing or implausible quotes before rerunning calculations.

Important fields

Field	Meaning
Curve	Discount, projection, spread or inflation curve used by pricing models.
FX rate	Currency conversion input for reporting currency results.
Volatility	Option pricing input, usually by expiry, tenor, strike or moneyness.
Fixing	Historical index observation required for coupons or inflation-linked payoffs.
Data date	Date on which the market data observation is valid.

Result interpretation

The presence of a curve name is not enough. The curve must contain the required pillars, dates and conventions for the instrument. For options and inflation products, verify that the relevant volatility or index fixing exists for the required observation date.

Common issues

Issue	Meaning	Possible action
Missing curve	The instrument cannot resolve a required curve.	Check curve mapping and currency/index conventions.
Missing fixing	A coupon or index payoff needs an unavailable historical observation.	Confirm the fixing calendar and observation lag.
Invalid volatility	A volatility is missing, negative or outside accepted conventions.	Check the volatility surface and product convention.
Stale quote	The available quote is older than expected for the valuation date.	Confirm whether stale data is permitted for the run.

Recommended practice

When a result looks wrong, compare instrument requirements with available market data first. This is especially important for inflation, volatility and cross-currency products.

Purpose

Quoting configuration controls how external and internal prices are sourced, normalized, distributed and linked to downstream consumers. These pages are used for price sources, proxies, quote links, distributors and price-finding rule sets.

Main objects

Object	Use
Price Source	Defines where a quote or price feed originates.
Proxy	Describes fallback or derived pricing logic when direct quotes are unavailable.
Quote Link	Connects source prices to instruments, curves or downstream consumers.
Distributor	Defines where a price or quote should be published.
Price Finding Rule Set	Controls ordered matching rules for quote selection.

Operational behavior

Rule order matters. The first matching rule can determine which price is used, so broad fallback rules should be placed after specific mappings. Proxies should be transparent enough that support users can explain why a quote was used.

Data quality checks

Check that quote identifiers, instrument symbols, currencies and validity windows match the target market-data object. Stale or ambiguous quote links can produce plausible but wrong valuations.

Purpose

Analytics configuration defines the data sources, data-quality profiles and AI profiles used by dashboards, reports, explanations and automated controls.

Data sources

Data sources group KPIs, aggregation definitions and result-set references. They should use stable names and clear provider metadata because dashboards and reports depend on them.

Data-quality profiles

Data-quality profiles define checks, tolerances and exception handling. Keep profile names aligned with the process they control, for example market-data completeness, valuation readiness or report publication.

AI configuration

AI providers describe technical access to model providers. AI profiles define the business role and guardrails for generated insight. AI directions steer the style, focus and intended use of generated commentary.

Governance

Treat these records as production controls. A small configuration change can change report interpretation, exception routing or generated management commentary.

Purpose

The Validation Dashboard summarizes whether models, instruments or methods are ready for a defined scope. It presents status, tolerances, evidence references and limitations in one place.

Typical workflow

• Select the validation dashboard relevant to the question.
• Review summary cards for passed, warning, failed and unknown items.
• Open matrix rows or cells with Amber, Red or Unknown status.
• Inspect evidence, tolerance and limitation details.
• Follow Data Quality links when input data may explain a missing, unstable or failed result.
• Use report sections to summarize findings for review.

Important fields

Field	Meaning
Validation run	A generated evidence pack for a point in time.
Status	Green, Amber, Red or Unknown readiness signal.
Tolerance	Accepted numerical difference between expected and actual values.
Evidence reference	Link or file reference to detailed generated evidence.
DQ reference	Link to Data Quality checks or findings connected with the validation item.
Limitation	Known restriction on interpretation or usage.

Result interpretation

Green means the stated checks passed for the documented scope. Amber usually means partial, toy-only or restricted evidence. Red indicates a failed critical check. Unknown means no executable evidence was available or the item is inventory-only.

Data Quality can also show Accepted for findings covered by an active exception rule. Accepted DQ findings are documented exceptions, not clean passes. Treat them as part of the limitation review when interpreting model or instrument readiness.

If several exception rules match the same DQ finding, the rule with the lowest priority number is applied. The applied rule is visible in the DQ result metadata under AcceptedByExceptionRule, including owner, reason and validity dates.

Data Quality links

Instrument Validation and Model Validation can expose links to related Data Quality evidence. These links help determine whether an unexpected validation result is caused by the calculation method itself or by missing, stale, inconsistent or incomplete input data.

Published evidence

Validation evidence is published as compact evidence bundles so the dashboard can load large instrument and model packs efficiently. The dashboard shows the latest published run for each pack and keeps one retained version for comparison. Older generated versions may be pruned from the help/demo evidence store and should not be treated as a permanent archive.

Use the DQ link when:

• a validation cell is Amber, Red or Unknown;
• a calculation result is missing although the instrument or model exists;
• a result changed unexpectedly after market data or portfolio changes;
• the evidence mentions missing quotes, missing curve mappings, stale data, invalid static data or incomplete scenario inputs.

The link is contextual:

Area	What the DQ link usually checks
Instrument Validation	Instrument static data, market data mappings, required quotes, capability-specific inputs and known product restrictions.
Model Validation	Inputs required by the model pack, scenario vectors, benchmark datasets, model-specific assumptions and pack-level DQ checks.

Data Quality evidence does not replace model or instrument validation. It explains whether the input state is reliable enough for the validation evidence to be interpreted. A model can have correct methodology and still be Amber or Red because its validation input data is incomplete.

Investigation workflow

When a validation result is unexpected, review it in this order:

• Check the status and limitation text.
• Open the evidence reference and compare Expected, Actual and Tolerance.
• Open the DQ reference and check Critical findings first.
• Distinguish data issues from calculation issues.
• Rerun or republish validation only after the data or model cause has been corrected.

Useful interpretation:

Observation	Likely meaning	Next step
Red validation and Critical DQ finding	The result may be caused by invalid or missing input data.	Fix DQ issue first, then rerun validation.
Red validation and no DQ finding	Calculation, benchmark, tolerance or model logic needs review.	Inspect evidence and model assumptions.
Amber validation and Warning DQ finding	Result may be usable only under documented restrictions.	Read limitations before using the result.
Green validation and Accepted DQ finding	Calculation evidence passed, but an input-quality exception was applied.	Confirm owner, reason and validity window before relying on the result.
Unknown validation and missing DQ evidence	The model or instrument may be inventory-only for this scope.	Treat as not validated until evidence exists.

Common issues

Issue	Meaning	Possible action
Warning status	Evidence exists but has limitations.	Open details and read the limitation before using the result.
Failed validation	Expected and actual values differ beyond tolerance or a critical check failed.	Review evidence and rerun only after data or model issues are resolved.
Missing evidence	The validation pack has no evidence for the item.	Treat the item as not validated for the current scope.
DQ link shows Critical findings	Inputs are not safe enough for interpretation.	Resolve the data issue before relying on the validation result.
DQ link shows Accepted findings	An exception rule accepted a known finding.	Check rule name, owner, reason and expiry date.

Recommended practice

Do not interpret a dashboard status without its scope and limitations. Validation evidence supports a specific model, instrument, dataset and date; it is not a blanket approval.

Purpose

System Overview is the live operations page for worker and message-broker health. Use it when you need to know whether services are connected, workers are alive, and RabbitMQ queues are moving.

The page is fed by PushNotifier and normally refreshes every few seconds. If the Push connection is disconnected, the screen can show stale data even when the backend is still running.

Header

Field	Meaning
Workers	Number of workers currently known to PushNotifier.
Idle	Workers that are alive and not processing a message.
Busy	Workers that report active work.
Broker	Availability of the RabbitMQ management endpoint.
Connected	SignalR connection state between portal and PushNotifier.

Broker availability and worker availability are related but not identical. A worker heartbeat can still be visible while broker statistics cannot be read.

Message Broker

The Message Broker table shows RabbitMQ queues. It is not the same as the Workflow Queue admission page.

Column	Meaning
Queue	RabbitMQ queue name.
Owner	Service area that owns the queue.
Health	Portal interpretation of queue state.
State	Broker-reported queue state.
Ready	Messages waiting to be consumed.
Unacked	Messages delivered to a consumer but not acknowledged yet.
Total	Broker-reported total message count.
Rates/s	Publish and acknowledge rate.
Last Minute	Recent queue-size sparkline.
Consumers	Number of active consumers.
Actions	Inspect, peek, or purge ready messages.

Reading Queue Patterns

Pattern	Interpretation
Ready grows and consumers are zero	The target service or worker is not consuming.
Ready grows while consumers exist	Consumers are slower than producers or are blocked.
Unacked remains high	A consumer received work but has not acknowledged it. Check that service's logs.
Total spikes and falls	A burst of work was processed normally.
Queue is missing	The queue has not been declared or broker monitoring cannot read it.

Use purge only for messages that are known to be stale or abandoned. Purge normally removes ready messages, not work already delivered as unacknowledged.

Worker State

Workers send heartbeat events through the priority/control channel.

Column	Meaning
State	Idle, Busy, or Stale.
Core Load	Single-core-equivalent CPU load for the worker process.
Memory	Memory reported by the worker process.
Service	Service or queue name reported by the worker.
Build	Short build id of the worker process.
Machine	Container or host name.
Process	Operating-system process id.
Current Work	Current activity, for example pricing or cashflow extraction.
Last Seen	Time of the latest heartbeat received by PushNotifier.

Stale means no recent heartbeat was received. The Forget stale workers action only removes stale entries from the in-memory overview registry. It does not restart or stop any worker.

Core Load

Core Load is intentionally worker-local. A worker processes one message at a time, so 100% means the worker's processing thread is close to saturated, even if host-level CPU still looks low on a many-core machine.

Practical Use

Use System Overview to decide where a live problem sits:

Symptom	First place to check
No new work starts	Broker consumers and ready counts.
One workflow seems stuck	Unacked queue and service logs for the owning consumer.
Workers disappeared	Worker State and service/container health.
UI stopped updating	Push connection chip and Last Update timestamp.

Purpose

Statistics shows historical workflow-run metadata collected by PushNotifier. Use it to compare recent runs, find a simulation id, and understand whether a run was large because of instruments, scenarios, dimensions, or estimated observations.

This page is historical. For live stuck work, start with System Overview and Workflow Queue.

Header and Filters

The model filter narrows the table to one model, such as VaR95, StressScenario, Sensitivity, or Valuation. Refresh reloads the latest workflow-run statistics.

Summary Cards

Card	Meaning
Runs	Number of visible workflow runs after filtering.
Completed	Visible runs with completed status.
Largest Instrument Set	Maximum instrument count in the visible runs.
Max Estimated Observations	Largest estimated valuation observation count.

Table

Column	Meaning
Started	Workflow start time.
Model	Model or workflow model label.
Date	Reference date / COB.
Status	Current or final workflow status.
Duration	Runtime in seconds, formatted for readability.
Instruments	Number of instruments included in the run.
Scenarios	Scenario-state count.
Dimensions	Shock analytics dimension count.
Estimated Observations	Approximate scale of valuation observations.

Details

Selecting a row shows simulation id, currency, portfolio count, aggregation flag, measure type, finish time, compact statistics, and raw statistics JSON.

Use the simulation id when correlating with Analyzer, Pricer, PushNotifier, Redis snapshot, or database logs.

Operational Interpretation

Question	Use
Did the latest run finish?	Status and Started columns.
Why was this run larger than usual?	Instruments, Scenarios, Dimensions, and Estimated Observations.
Which id should I search in logs?	Details panel simulation id.
Was aggregation requested?	Details panel aggregation flag.

Purpose

Workflow Queue shows the PushNotifier admission queue. It controls which workflow batch may run and which batches must wait. It is separate from RabbitMQ broker queues shown on System Overview.

The admission queue prevents uncontrolled overlapping workflow batches. A queued or running batch can block later batches until it becomes terminal.

Summary Cards

Card	Meaning
Active Schedules	Enabled workflow schedules.
Queued	Batches waiting for admission.
Running	Batches currently admitted/running.
Failed	Failed or partially failed batches.

Admission Queue

Column	Meaning
Status	Batch state, for example Queued, Running, Completed, Failed, PartiallyFailed, or Cancelled.
Queued	Time when the batch entered the admission queue.
Started	Time when dispatch started.
Batch	Short batch id and internal row id.
COB	Reference date.
Currency	Reporting currency.
Models	Requested models from the batch payload.
Workflows	Dispatched workflow count versus requested workflow count.
Last Progress	Latest progress timestamp for the batch.
Actions	Show child workflows or unblock the queue.

Opening a batch shows child workflows with workflow type, model, reference date, start/finish timestamps, status, and workflow id.

Unblock Queue

Unblock is an operator action for abandoned admission batches.

Current batch state	Result
Queued	Batch is marked Cancelled.
Running	Batch is marked Failed.

Any non-terminal child workflows are marked failed, and the admission service tries to start the next queued batch.

Only unblock a batch when it is known to be abandoned. It changes persisted workflow state.

Diagnosis Flow

Symptom	Check
New workflows do not start	Is a batch queued or running ahead of them?
A running batch has old Last Progress	Check service logs and broker unacked messages.
RabbitMQ is empty but UI says running	The admission state has not reached a terminal status.
Multiple batches are waiting	Resolve or unblock the oldest blocking batch first.

Purpose

Operations contains configured workflow schedules and their run history. Use it to inspect scheduled workflow automation, run a schedule manually, and activate or deactivate scheduled execution.

Workflow Schedules

Each schedule defines when and how a workflow batch should be triggered.

Column	Meaning
Actions	Run now, activate, or deactivate the schedule.
Name	Schedule name.
IsActive	Whether the schedule is eligible for automatic execution.
Cron	Cron expression used by the scheduler.
Mode	Reference-date mode used when creating the run.
LastRunUtc	Last trigger time.
LastSuccessUtc	Last successful run time.
Duration	Duration of the last completed run when available.

Actions

Action	Effect
Run now	Triggers the selected schedule immediately.
Activate	Enables future scheduled execution.
Deactivate	Disables future scheduled execution without deleting the schedule.

Manual runs still create normal workflow batches and can be delayed by the Workflow Queue admission state.

Runs Tab

The Runs tab shows schedule-triggered executions, including trigger time, trigger source, reference date, status, and error text.

Use it to answer whether automation fired, whether the last run failed, and which reference date was submitted.

Workflow States Tab

Workflow States shows the child workflow states created by schedule runs. It is useful when a schedule started successfully but one model or workflow inside the batch failed or stayed running.

Operational Notes

Operations configures and triggers schedules. Workflow Queue controls admission. System Overview shows broker and worker health. Use all three together when diagnosing automation issues.

Purpose

AI Insights configuration controls how the portal creates governed explanatory text from configured analytics data. The setup is split into providers, directions, profiles, skills and insight bindings so technical model access, prompt intent and business scope can be maintained independently.

Use the AI Insights configuration pages when you need to change which model is called, how it is instructed, which generated insight capabilities are available, or where those capabilities are applied in Analyzer workflows.

Configuration model

An AI insight run is assembled from these records:

• AI Provider defines the technical model endpoint, model name, token limit, temperature and secret reference.
• AI Direction defines the reusable instruction style and versioned guidance used by prompts.
• AI Profile combines one provider and one direction into a business-facing profile.
• AI Skill belongs to a profile and defines one prompt capability, such as explaining a result, summarising exceptions or drafting commentary.
• AI Insight Binding belongs to a profile and maps a skill to a concrete analytics scope, such as an aggregation set, model, dimension or scope pattern.

Keep the keys stable. ProviderKey, DirectionKey and SkillKey are intended to be integration identifiers, while Name is the human-readable label shown in the editor.

AI Providers

Open Analyzer / AI Insights / AI Providers to maintain provider records.

Fields:

• Active enables the provider for use by profiles. Keep inactive providers for history or staged changes.
• Temperature controls output variability. Lower values are more deterministic and are preferred for regulated explanations. Higher values can produce more varied wording but should be used carefully.
• MaxTokens caps the generated response length. Set this high enough for the expected explanation but low enough to prevent unexpectedly long responses.
• ApiKeySecretRef is the reference to the secret containing the API key. Do not paste raw credentials into this field.
• Endpoint is the API endpoint used by the integration, for example the OpenAI Responses API endpoint.
• Model is the exact model identifier sent to the provider.
• Name is the display name, usually combining provider and model.
• ProviderKey is the stable technical provider key, such as OpenAI.

Operational guidance:

• Create a new provider record when changing model families or endpoints.
• Prefer deactivating old providers over deleting them when existing profiles, audit history or historical generated content may still refer to them.
• Keep secret rotation outside the portal by updating the referenced secret rather than changing the provider record unless the secret reference itself changes.

AI Directions

Open Analyzer / AI Insights / AI Directions to maintain instruction direction records.

Fields:

• Active enables the direction for profile use.
• DirectionKey is the stable technical key for this direction.
• InstructionTemplate is the reusable instruction text that sets the tone, constraints and expected structure of generated insights.
• Name is the display name.
• VersionTag identifies the instruction version. Use it when changing prompt behavior so generated outputs can be traced back to the active direction version.

Direction templates should describe the task boundary, expected audience, evidence requirements and restrictions. For risk explanations, include requirements such as using configured data only, avoiding unsupported causality, flagging missing inputs and keeping numeric statements tied to visible results.

AI Profiles

Open Analyzer / AI Insights / AI Profiles to maintain business profiles.

Fields:

• Active enables the profile.
• Name is the profile name used by Analyzer workflows and configuration screens.
• DirectionConfig selects the instruction direction.
• ProviderConfig selects the technical provider and model.

Use profiles to separate business use cases. For example, a validation profile can use stricter instructions and lower temperature than an exploratory analytics profile while still sharing the same provider.

Skills

Skills are edited inside an AI Profile on the Skills tab.

Fields:

• Active enables the skill.
• Name is the display name.
• PromptTemplate is the skill-specific prompt body.
• SkillKey is the stable key used by bindings and workflow integrations.
• VersionTag identifies the prompt version.
• AIInsightsProfile links the skill to its owning profile.

Use one skill per distinct capability. Keep the prompt template focused on the expected output and inputs for that capability. If the prompt behavior changes materially, update VersionTag so results can be traced and compared.

Insight Bindings

Insight bindings are edited inside an AI Profile on the Insight Bindings tab.

Fields:

• Active enables the binding.
• AggregationSet restricts the binding to a named aggregation set.
• DimensionKey restricts the binding to a dimension or result axis.
• Models restricts the binding to one or more model names as configured for the consuming workflow.
• Name is the display name.
• ScopePattern restricts the binding by configured scope pattern.
• SkillKey selects the skill that should be used for the matching scope.
• AIInsightsProfile links the binding to its owning profile.

Bindings are the control layer that prevents a broad skill from being applied everywhere. Use the narrowest practical combination of aggregation set, model, dimension and scope pattern. If several bindings can match a scenario, keep their names explicit enough for operators to understand why a skill was available.

Recommended setup workflow

• Create or verify the AI Provider and confirm the endpoint, model, token limit and secret reference.
• Create the AI Direction with a clear instruction template and version tag.
• Create the AI Profile and select the provider and direction.
• Add one or more Skills to the profile.
• Add Insight Bindings that expose each skill only to the intended analytics scope.
• Activate records from the outside in: provider and direction first, then profile, then skills and bindings.
• Review generated output after each prompt or model change before using it for operational commentary.

Governance and audit

AI configuration records include state, version, timestamp and change history. Use the Info and History tabs to review technical identifiers and previous changes.

For controlled environments:

• Treat prompt templates and instruction templates as model governance artifacts.
• Record why Temperature, MaxTokens, model and endpoint values were selected.
• Use VersionTag whenever the wording, structure or constraints of a prompt change.
• Keep inactive historical records when they are needed for explainability.
• Store secrets only in the configured secret store and reference them through ApiKeySecretRef.

Troubleshooting

If an insight is not available where expected, check that the profile, provider, direction, skill and binding are all active. Then confirm that the binding fields match the current aggregation set, model, dimension and scope.

If the model call fails, verify the provider endpoint, model identifier and ApiKeySecretRef. Also check that MaxTokens is large enough for the requested output and that the provider integration supports the configured endpoint.

If output wording is too variable, lower Temperature. If output is too short, increase MaxTokens or tighten the prompt so the response budget is used for the required content.

Purpose

Discounted cashflow valuation converts expected payments into present value by applying discount factors from the relevant curve.

Typical workflow

• Identify all future cashflows after the valuation date.
• Resolve the discount curve and currency.
• Apply day-count, settlement and business-day conventions.
• Discount each cashflow to the valuation date.
• Sum discounted cashflows and report clean/dirty price where applicable.

Sample calculation

Step	Example
Cashflow	EUR 1,000,000 in one year
Discount factor	0.970873786
Present value	\(1{,}000{,}000 \times 0.970873786 = \text{EUR }970{,}873.79\)

Formula

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

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

$$ CleanPrice = DirtyPrice - AccruedInterest $$

Important fields

Field	Meaning
Discount curve	Curve used to discount future cashflows.
Accrued interest	Coupon interest earned but not yet paid.
Dirty price	Clean price plus accrued interest.
Settlement date	Date on which the trade economically settles.

Recommended practice

If the present value is unexpected, check cashflow dates first, then curve mapping, discount factors, accrued interest and notional sign.

Purpose

Sensitivities explain how a result changes when a market input changes. PV01 is the present-value change for a one basis point curve move.

Typical workflow

• Calculate the base present value.
• Shift the relevant curve up and down by the configured bump size.
• Recalculate present value under each shifted curve.
• Compare the finite-difference result with the reported PV01.

Sample calculation

Item	Value
Base PV	1,000,000.00
PV after +1 bp	999,200.00
PV after -1 bp	1,000,800.00
Central-difference PV01	\(\frac{1{,}000{,}800 - 999{,}200}{2} = 800.00\)

Formula

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

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

The displayed sign can differ by convention. Some reports show the value change for a rate increase, while others show the value change for a one basis point risk exposure.

Result interpretation

A positive PV01 usually means value increases when rates fall. Always confirm the sign convention in the result details before comparing systems.

For non-maturity deposits, also distinguish whether the sensitivity comes from the curve or from the optional floor component.

Sensitivity	NMD interpretation
IR Delta / PV01	Runoff present-value reaction to the discount curve and modelled behavioural duration.
IrVega	Zero-floor value reaction to the mapped normal-volatility surface.
Zero Vega	Unsuspicious only when the floor is disabled or there is no relevant option exposure. With an active floor, check surface mapping and FloorStrike.

Common issues

Issue	Meaning	Possible action
Wrong sign	The bump or reporting convention differs.	Compare sign convention and payer/receiver direction.
No sensitivity	Required shifted curve or pricing model is missing.	Check curve mapping and instrument support.
Large sensitivity	Quantity, notional or curve bucket may be wrong.	Inspect position size and risk factor mapping.
Missing NMD Vega	Normal-volatility surface or strike mapping does not match floor valuation.	Check IncludeFloorValue, surface mapping, surface nodes and FloorStrike.

Purpose

VaR and Expected Shortfall summarize tail losses from a scenario PnL distribution. They are risk measures, not valuation measures.

Typical workflow

• Generate or load scenario PnL values.
• Sort losses according to the configured sign convention.
• Select the quantile for VaR.
• Average the selected tail for Expected Shortfall.
• Review aggregation level and portfolio filters.

Sample calculation

Item	Example
Sorted losses	10, 20, 35, 50, 80
Confidence level	80%
VaR	50 under nearest-rank selection
ES	Average of tail beyond threshold, depending on configured convention

Formula

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

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

For PnL vectors, the sign convention must first map PnL into losses. A negative PnL is usually a positive loss.

Result interpretation

VaR answers "how bad can loss be at this confidence level". ES answers "how large is the average loss in the tail". Compare results only when confidence level, horizon, sign convention and aggregation level match.

Recommended practice

If the dashboard shows no VaR data, verify the selected aggregation level, run date, portfolio and whether the run completed for the relevant scenario pack.

Dashboard Purpose

The Stress Testing dashboard shows scenario PnL by scenario family, aggregation level and instrument. It is used to compare how portfolios react to deterministic shocks rather than to estimate statistical tail probabilities.

Scenario Families

Scenario family	What happens	Scenario character	Typical interpretation
Basic	Single or simple combined risk-factor shocks are applied to expose directional sensitivities.	Mechanical sensitivity stress.	Best for explaining which portfolio, desk or instrument is exposed to a specific driver.
EBA	Supervisory-style shocks are applied consistently across configured market-risk drivers.	Regulatory benchmark stress.	Best for comparing portfolios under a standardized severe-but-plausible setup.
Macro	Historical or narrative crisis templates move several asset classes together.	Multi-factor crisis scenario.	Best for understanding cross-asset losses and diversification breakdown.

Scenario Catalog

Scenario set	Included scenarios	Character
Basic	EqDelta, FxDelta and CmDelta relative shocks: -50%, -20%, -15%, -10%, -5%, -2.5%, +2.5%, +5%, +10%, +15%, +20%, +50%.	Single-factor price stress ladder.
Basic	IrDelta and CsDelta absolute shocks: -200 bp, -100 bp, -50 bp, -20 bp, -10 bp, -5 bp, +5 bp, +10 bp, +20 bp, +50 bp, +100 bp, +200 bp.	Single-factor curve or spread stress ladder.
EBA	EBA2025/Adverse.	ECB-provided 2025 EU-wide adverse market-risk scenario; shocks are read from the EBA workbook across equity, commodity, fund, interest-rate, FX, sovereign credit and corporate credit sheets.

Macro Scenario Catalog

Each Macro entry is a cross-asset template. The listed variants share the family narrative but use different scenario keys and severity scaling.

Family	Character	Variants
GFC	Credit and liquidity freeze inspired by the 2007-09 global financial crisis.	LehmanSevere, MortgageCreditCrash, BankFundingFreeze, InterbankTrustBreak, SecuritizationCollapse, GlobalDeleveraging, CounterpartyPanic, CreditMarketShutdown, SystemicBankStress, GfcReplayExtreme
COVID	Pandemic-style sudden stop and liquidity stress.	SuddenStop, LockdownShock, LiquidityDash, OilDemandCollapse, TravelShutdown, SupplyChainFreeze, EmergencyCuts, CreditDrawdown, PandemicSecondWave, CovidReplayExtreme
Dotcom	Growth equity collapse and investment slowdown.	TechCrash, GrowthMultipleReset, IPOFreeze, TelecomDebtStress, ProfitlessTechUnwind, NasdaqStyleDrawdown, VentureFundingStop, SoftwareDerating, EquityVolSpike, DotcomReplayExtreme
EuroSov	Euro sovereign and bank-sovereign feedback stress.	PeripheryCrisis, SovereignBankLoop, EuroBreakupFear, ItalianSpreadShock, SpanishSpreadShock, BankRecapitalization, CollateralHaircutShock, BundFlightToQuality, EuroFundingStress, EuroSovReplayExtreme
UkraineEnergy	Energy supply shock, inflation impulse and Europe risk-off.	GasSupplyShock, OilEmbargo, SanctionsEscalation, EuropeTermsOfTrade, EnergyMarginCalls, WinterShortage, IndustrialCurtailment, FoodEnergyInflation, PipelineDisruption, UkraineReplayExtreme
OilStagflation	Oil-led inflation with weak growth and risk-asset repricing.	OilEmbargo, WagePriceSpiral, PersistentInflation, RealRateShock, CommoditySupplyShock, StagflationRecession, CentralBankBehindCurve, EnergyRationing, InflationRiskPremium, SeventiesReplayExtreme
BlackMonday	Abrupt equity gap and volatility shock.	EquityGap, VolatilityExplosion, PortfolioInsuranceUnwind, IndexLiquidityGap, CrossAssetVaRShock, RiskParityUnwind, MarginCallCascade, EquityCircuitBreak, VolControlSelling, BlackMondayReplayExtreme
LTCM	Leveraged relative-value unwind and EM contagion.	RussiaDefault, RelativeValueUnwind, EMContagion, SwapSpreadBlowout, LiquidityPremiumShock, HedgeFundDeleveraging, BasisTradeUnwind, FlightToTreasuries, FundingMarketStress, LtcmReplayExtreme
TaperTantrum	Abrupt global rates repricing and USD support.	RatesSelloff, TermPremiumJump, UsdRatesReprice, EMOutflow, MortgageConvexity, CurveBearSteepener, BondFundOutflow, DurationShock, CarryUnwind, TaperReplayExtreme
UKGilt	GBP curve shock and collateral/liquidity stress.	GiltCurveShock, LdiCollateralCall, SterlingCrisis, PensionDeleveraging, LongEndRatesGap, FiscalCredibilityShock, GbpFundingStress, LiabilityHedgeUnwind, GiltLiquidityGap, GiltReplayExtreme

Reading the Widgets

Widget	How to read it
KPI strip	Shows total loss and main drivers for the selected scenario set.
Diverging bar chart	Compares positive and negative scenario impact across groups.
Scenario exposure table	Breaks scenario PnL down by the selected level: group, book, desk or portfolio.
Instrument table	Shows instrument-level drivers for the selected row.

Compare stress results only for the same reference date, currency, scenario set and aggregation level.

Purpose

This article explains the main market-risk measures used in the model validation views: VaR, Expected Shortfall, historical simulation, hybrid historical simulation, delta-normal VaR and Monte Carlo simulation. The concepts are aligned with the FRM Notes v0.37 material and with the portal convention that VaR/ES evidence must always state whether it is based on loss values or PnL values.

Loss and PnL convention

Most risk texts define VaR on a loss variable \(L\). The portal often stores scenario results as PnL \(P\). The link is:

$$ L = -P $$

For a loss distribution with cumulative distribution function \(F_L\), the confidence-level VaR is:

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

When the portal displays VaR on a PnL vector, the result can be shown as the adverse lower-tail PnL value. This is why sign convention is part of the evidence and should not be inferred from the model name alone.

Expected Shortfall

Expected Shortfall is the average loss beyond the VaR threshold:

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

For a continuous distribution:

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

In a historical simulation pack, ES is calculated from the selected tail scenarios. The evidence should show the confidence level, tail size, scenario count and sign convention.

Historical simulation

Historical simulation revalues the portfolio under historical market moves and uses the resulting scenario PnL vector directly. It does not assume a normal distribution.

Typical workflow:

Step	Meaning
Build shocks	Market moves are created from historical market data.
Reprice positions	Each position is valued under each shock.
Build scenario vectors	Position-level PnL is aggregated by asset class and total loss.
Calculate tail measure	VaR, ES, best case and worst case are read from the sorted vector.

For a sorted loss vector \(L_{(1)} \le \ldots \le L_{(n)}\), a simple empirical quantile can be written as:

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

Different production systems use different interpolation and index conventions. Validation evidence therefore records the exact aggregator or benchmark convention.

Hybrid historical simulation

Hybrid historical simulation applies age weights to historical observations. Recent scenarios usually receive higher weight.

With decay factor \(\lambda\), one normalized convention is:

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

where larger \(i\) means newer observation. The weighted VaR is found by sorting scenarios by loss or PnL convention and accumulating weights until the target tail probability is reached:

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

In the portal model validation pack, the hybrid TL view shows the weighted tail contribution for the total-loss vector because that is the clearest place to audit the cumulative weight logic.

Delta-normal VaR

Delta-normal VaR approximates portfolio changes with linear sensitivities and a covariance matrix. For exposure vector \(x\) and covariance matrix \(\Sigma\):

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

If returns are assumed normal, the loss VaR can be written as:

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

where \(z_\alpha\) is the normal quantile. A common time-scaling approximation is:

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

This square-root rule is only appropriate when the return process and independence assumptions are acceptable for the use case.

Option approximation

For options and nonlinear products, a first-order delta approximation is:

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

A second-order delta-gamma approximation is:

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

Historical revaluation is preferred in validation packs when the production engine can run the same pricing path used in live simulation.

Monte Carlo VaR

Monte Carlo VaR generates simulated market scenarios from a stochastic model, reprices the portfolio and reads the risk measure from the simulated PnL vector.

Control	Why it matters
Random seed	Makes validation reproducible.
Distribution assumption	Drives tail behavior and stress severity.
Correlation model	Controls diversification and concentration.
Number of paths	Controls sampling error.
Revaluation model	Must match the model being validated.

Result interpretation

Result	Interpretation
Worst Case	Most adverse scenario in the published vector.
VaR95 / VaR99	Tail percentile under the selected convention.
ES95 / ES99	Average of tail scenarios beyond VaR.
Best Case	Most favorable scenario in the published vector.
Hybrid VaR/ES	Tail measure using age-weighted scenarios.

Common issues

Issue	Meaning	Possible action
Positive/negative sign surprise	Loss and PnL conventions are mixed.	Check the evidence convention and whether values are shown as losses or PnL.
Too few scenarios	Tail measures are unstable.	Check scenario window and observation count.
Hybrid result differs from plain VaR	Recent observations receive different weights.	Review the decay factor and cumulative weights.
Option VaR too small	Volatility or nonlinear shocks may be missing.	Check IR, equity and volatility shock tables for the option.

Recommended practice

Review the shock table first, then the scenario vector, then portfolio aggregation and finally the result table. A VaR number without the underlying vector is not sufficient validation evidence.

Purpose

Volatility and correlation models convert market observations into risk inputs. They are used in parametric VaR, option pricing, volatility-surface validation and stress design. This article summarizes the core formulas used in the FRM Notes v0.37 material and explains how to read them in the portal.

Returns

For a market price or index level \(S_t\), the continuously compounded return is:

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

For small moves, log returns and simple percentage returns are close, but they are not identical. Validation evidence should state which return convention was used.

Sample volatility

For daily returns \(u_t\), the sample variance is:

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

Daily volatility is annualized with:

$$ \sigma_{\text{annual}} = \sigma_{\text{daily}}\sqrt{252} $$

The factor 252 is a trading-day convention. It should not be silently applied to monthly, weekly or irregular observation windows.

EWMA volatility

Exponentially weighted moving average volatility gives more weight to recent returns:

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

where \(\lambda\) is the decay factor. A high \(\lambda\) reacts slowly; a low \(\lambda\) reacts quickly.

EWMA covariance uses the same idea:

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

GARCH(1,1)

A GARCH(1,1) model includes a long-run component, the latest squared return and the previous variance:

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

The long-run variance is:

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

The usual stability condition is:

$$ \alpha + \beta < 1 $$

If this condition is not met, the model can produce unstable long-run behavior.

Correlation

For two return series \(x\) and \(y\):

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

Correlation is not a guarantee of diversification in stressed markets. Validation should check whether correlations are estimated from the same window and convention as the volatility model.

Portfolio variance

For asset weights or exposures \(x\) and covariance matrix \(\Sigma\):

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

For two assets this becomes:

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

The same structure appears in delta-normal VaR and in sensitivity aggregation models.

Portal interpretation

Area	What to check
Volatility surfaces	Exact grid lookup, interpolation, negative-vol handling and missing quotes.
Hybrid VaR	Decay factor, cumulative weights and observation order.
Parametric results	Return convention, annualization factor and covariance matrix.
Option validation	Whether implied volatility shocks are present for the underlying.

Common issues

Issue	Meaning	Possible action
Volatility jumps unexpectedly	Observation window or decay factor changed.	Compare the latest market data and model parameters.
Correlation matrix is invalid	Matrix may not be positive semidefinite.	Check data quality and repair method.
Annualization mismatch	Daily, weekly or monthly data mixed.	Check frequency and scaling assumption.
Missing vol shock	Option scenario PnL is incomplete.	Review volatility shock inputs and surface mapping.

Recommended practice

Treat volatility and correlation as model inputs, not passive data. The validation pack should expose the observation window, return convention, weighting method and any repair or interpolation applied before a risk result is accepted.

Purpose

Fixed income models explain how cashflows, discount curves and yield changes affect valuation and sensitivity. This article summarizes bond pricing, duration, DV01, KR01 and convexity concepts used in FRM Notes v0.37 and connects them to the portal validation views.

Discounting

With continuously compounded rate \(r\), the discount factor for time \(t\) is:

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

With nominal rate \(r\), compounding frequency \(m\) and maturity \(n\):

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

The present value of deterministic cashflows is:

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

In the DCF validation pack, the evidence should show the cashflow schedule, discount inputs and resulting PV aggregation.

Yield and bond price

For a simple fixed-rate bond with yield \(y\):

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

In production valuation, the portal normally uses curve discounting rather than a single yield. Yield-based formulas remain useful for benchmark checks and sensitivity intuition.

Duration

Macaulay duration is the cashflow-weighted average time to payment:

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

Modified duration adjusts Macaulay duration for the compounding convention:

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

The first-order price change approximation is:

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

Duration is most reliable for small parallel yield shifts.

DV01 and PV01

DV01 is the price change for a one basis point move in yield:

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

Finite-difference PV01 is often calculated by bumping the curve:

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

Some systems divide by the bump size and some report the one-basis-point value directly. The evidence must state the sign and scaling convention.

Key-rate risk

Key-rate sensitivity measures exposure to a specific curve tenor:

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

where \(PV_k^-\) and \(PV_k^+\) are values after down and up shifts at key rate \(k\). Key-rate vectors are more informative than a single parallel DV01 when the curve shape matters.

Convexity

Convexity improves the approximation for larger rate moves:

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

Effective convexity can be measured by:

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

Callable bonds and products with optionality can have materially different convexity behavior from plain fixed-rate bonds.

Portal interpretation

View	What it proves
Cashflows	The instrument was decomposed into the expected payment schedule.
DCF evidence	Discounting and PV aggregation are reproducible.
Sensitivity shifts	Up/down scenario values are available and sign convention is explicit.
Model validation row	The model links valuation evidence, sensitivity evidence and limitations.

Common issues

Issue	Meaning	Possible action
PV is zero	Instrument mapping or valuation path may not have produced a valuation instrument.	Check instrument support and market-data requirements.
PV01 sign differs	Sign convention differs between price-change and risk-loss views.	Check evidence metrics before comparing numbers.
Cashflows missing	Schedule construction failed or unsupported product type.	Review static data, calendar, day count and coupon conventions.
KR01 incomplete	Curve tenor mapping is missing.	Check curve seed and shock construction.

Recommended practice

For fixed income validation, inspect the cashflow table before the PV number. A correct PV is only meaningful when the schedule, discount curve and valuation date are all visible and consistent.

Purpose

Option pricing models convert underlying price, strike, time, rates and volatility into value and sensitivities. This article summarizes binomial trees, Black-Scholes-Merton pricing and Greeks from the FRM Notes v0.37 material and shows how to interpret option validation evidence.

Payoff

For a European call:

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

For a European put:

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

The pricing model estimates the discounted expected value of the payoff under the model assumptions.

Binomial tree

A one-step binomial tree uses an up factor and a down factor:

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

The risk-neutral probability with dividend or foreign-rate yield \(q\) is:

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

The option value is found by backward induction:

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

Trees are useful for products where early exercise or path features matter.

Black-Scholes-Merton

For a European call with continuous dividend yield \(q\):

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

For a European put:

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

where:

$$ 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} $$

For FX options, \(q\) is commonly interpreted as the foreign interest rate and \(r\) as the domestic interest rate.

Greeks

Greeks measure option sensitivity to inputs.

Greek	Definition	Interpretation
Delta	\(\Delta=\frac{\partial V}{\partial S}\)	Sensitivity to underlying price.
Gamma	\(\Gamma=\frac{\partial^2 V}{\partial S^2}\)	Curvature of delta.
Vega	\(\nu=\frac{\partial V}{\partial \sigma}\)	Sensitivity to volatility.
Theta	\(\Theta=\frac{\partial V}{\partial t}\)	Time decay.
Rho	\(\rho=\frac{\partial V}{\partial r}\)	Sensitivity to interest rates.

Under simple Black-Scholes-Merton assumptions without dividends:

$$ \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} $$

Scenario validation

Option scenario PnL usually needs more than one shock type:

Shock type	Why it matters
Equity or underlying shock	Drives delta and gamma effects.
Interest-rate shock	Changes discounting and forwards.
Volatility shock	Drives vega and model-implied value.
FX shock	Required when payoff, underlying or reporting currency differs.

If volatility shocks are missing, option VaR and ES can be materially understated.

Common issues

Issue	Meaning	Possible action
Option value is flat under scenarios	Underlying or volatility shocks are not connected.	Check shock table by risk factor.
Vega missing	Vol surface mapping failed or product is not linked to vol model.	Check surface id and underlying mapping.
Delta-only VaR looks too low	Gamma and vega effects are ignored.	Prefer full revaluation validation if available.
FX option mismatch	Domestic and foreign rates may be reversed.	Check currency convention and curve mapping.

Recommended practice

For option validation, review price, Greeks and scenario PnL together. A correct closed-form price does not prove that VaR is correct unless shocks are applied to all relevant risk factors.

Purpose

Credit and operational risk models estimate losses from default, downgrade, recovery uncertainty, failed processes and external events. This article summarizes the main FRM Notes v0.37 model concepts relevant for portal methodology and validation documentation.

Expected credit loss

The standard expected loss formula is:

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

Term	Meaning
\(PD\)	Probability of default.
\(LGD\)	Loss given default.
\(EAD\)	Exposure at default.

The formula is simple, but each input is a model output or calibrated estimate. Validation should therefore document input source, observation window, segmentation and overrides.

Unexpected loss

Unexpected loss is the loss variability around expected loss. A simplified view is:

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

For a loan portfolio, unexpected loss depends on obligor concentration, default correlation, exposure size and recovery uncertainty. It is not validated by checking expected loss alone.

Ratings and score models

Rating models map borrower or exposure information to a risk grade. Common controls include:

Control	Validation question
Calibration	Do observed defaults match grade-level PDs?
Discrimination	Does the model rank risk correctly?
Stability	Are grade migrations explainable?
Override governance	Are manual changes justified?
Data quality	Are financials, country, sector and collateral fields complete?

Country and concentration risk

Country risk models consider sovereign conditions, transfer risk, political risk and macroeconomic stress. Concentration risk appears when a portfolio is exposed to a small set of obligors, sectors, regions or currencies.

A concentration-sensitive model should expose:

Input	Why it matters
Group exposure	Identifies connected-name risk.
Sector and country	Identifies correlated default drivers.
Collateral and guarantees	Affects recovery and transferability.
Maturity	Affects exposure horizon.

Operational loss severity

Operational loss models often use skewed severity distributions because rare events can dominate loss. Common candidates include exponential, Weibull, lognormal and extreme-value or peaks-over-threshold models.

For an exponential severity model with rate \(\lambda\):

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

The loss quantile is:

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

Extreme-tail models require careful threshold selection and should not be accepted without sensitivity analysis.

Stress testing

Stress testing complements statistical models by asking what happens under severe but plausible events. It is especially important when historical data does not contain the relevant scenario.

Stress type	Example
Sensitivity stress	Single risk driver is shocked.
Scenario stress	Multiple drivers move consistently.
Reverse stress	Find a scenario that breaks a limit or solvency threshold.
Narrative stress	Macro or event story translated into risk factors.

Portal interpretation

Credit and operational risk sections in the help system are methodology references for future model packs. If a dashboard model is inventory-only or marked Unknown, it means executable validation evidence has not yet been connected.

Common issues

Issue	Meaning	Possible action
EL looks correct but tail is wrong	Expected loss does not validate unexpected loss.	Check distribution, correlation and concentration assumptions.
Rating grade has no defaults	Calibration sample may be sparse.	Use conservative treatment and document uncertainty.
Operational VaR unstable	Tail distribution or threshold is sensitive.	Review threshold, sample size and stress overlays.
DQ findings ignored	Missing static data can bias risk grade or exposure.	Resolve critical DQ findings before relying on the result.

Recommended practice

Separate expected-loss validation from tail-loss validation. A model can be useful for provisioning or monitoring while still being restricted for capital, limit or stress-testing use.

Purpose

Model validation answers whether a model is fit for its stated purpose, not whether it is universally correct. This article explains how to read model assumptions, limitations, benchmark evidence and Data Quality links in the portal.

Model risk

Model risk arises when a model is wrong, misused or used with unsuitable data. It can be separated into practical sources:

$$ \text{Model Error} \approx \text{Data Error} + \text{Method Error} + \text{Implementation Error} + \text{Use Error} $$

This decomposition is not a formal accounting identity. It is a review checklist.

Validation evidence types

Evidence type	What it demonstrates
Closed-form benchmark	Result matches an independent formula.
Frozen baseline	Result remains stable against an accepted reference output.
Toy benchmark	Mechanics work on a small deterministic dataset.
Regression evidence	Current output matches prior validated behavior.
Data Quality evidence	Inputs satisfy required completeness and sanity checks.
Inventory-only	Model is catalogued but executable evidence is not connected.

Tolerance

Tolerance defines acceptable numerical difference:

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

For absolute tolerance:

$$ \Delta \le \epsilon $$

For relative tolerance:

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

Evidence should state which convention is used. Small values often require absolute tolerance because relative error can become unstable near zero.

Readiness statuses

Status	Meaning
Green	Executable evidence passed for the stated scope.
Amber	Evidence is partial, toy-only or subject to important restrictions.
Red	A critical validation check failed.
Unknown	No executable evidence exists or model is inventory-only.

Green does not imply regulatory approval. It only means the model passed the published evidence scope.

Assumptions and limitations

Every model validation row should make these points visible:

Field	Review question
Purpose	What result is the model intended to produce?
Inputs	Are all required market and static data available?
Outputs	Are the outputs meaningful for the business use case?
Benchmark	Is there an independent or deterministic reference?
Limitations	Where should the model not be used?
DQ link	Are input quality checks passed or still open?

Data Quality link

The model validation dashboard links model evidence to Data Quality findings. This is important because a model can be mathematically correct and still produce a wrong result if the input data is wrong.

Typical examples:

DQ finding	Model impact
Missing curve mapping	Valuation and sensitivity cannot be trusted.
Missing fixing	Inflation or floating-rate cashflows may be wrong.
Missing volatility quote	Option pricing and vega VaR may be incomplete.
Invalid maturity or coupon	Cashflow model can construct the wrong schedule.

Validation workflow

• Check the model purpose and family.
• Review the validation portfolio and market data.
• Open the evidence table for the relevant model.
• Compare expected, actual and tolerance.
• Review limitations and DQ findings.
• Confirm whether the readiness status matches the evidence.

Common issues

Issue	Meaning	Possible action
Green but limitation exists	The model passed only within a stated scope.	Read the limitation before using the result.
Unknown model	Inventory exists but validation evidence is not connected.	Treat as not validated for use.
Benchmark mismatch	Expected and actual differ beyond tolerance.	Check data, convention and implementation path.
DQ link is red	Inputs are not clean enough for reliance.	Resolve DQ issue before accepting model output.

Recommended practice

Use model validation as an evidence trail. The most important question is not whether a model name appears in the catalog, but whether the published evidence supports the exact result you want to rely on.

Purpose

Risk configuration defines the risk factors available to the platform, how they are grouped, and which models use them to generate scenarios, sensitivities, curvature results or historical simulations. It connects market data, scenario logic, model dependencies and reporting dimensions.

Object	Purpose
Risk Source	Origin or family of risk information, such as market data, stress definitions or FRTB metadata.
Risk Factor Group	Business bucket of risk factors with a FactorType, optional currency and metadata.
Risk Factor	Individual factor that can be shifted, filtered, reported or aggregated.
Risk Model	Model configuration containing period settings, measure type, scenario count, shift types, shifts and dependencies.
Shift Type Map	Defines how a FactorType is shifted in a model.
Shift	Concrete shock for a factor, a factor group or a filtered scope.

Risk Sources

Risk Sources describe where risk information comes from. They are intentionally generic because different model families require different metadata. The most important details are often stored in MetadataJson.

Typical contents include FRTB position metadata, market-data origin, scenario origin and model-family context. A Risk Source is context, not automatically an active shockable factor. Shockable factors are configured through Risk Factor Groups and Risk Factors.

Risk Factor Groups

Risk Factor Groups are business buckets such as rates, FX, equity, credit spread, commodity, volatility or theta. The group carries the FactorType, optional Currency and metadata.

Field	Meaning
Name	Stable business-readable group name.
IsActive	Controls whether the group is considered for selection, model setup and checks.
FactorType	Technical and business risk type. Must match shifts and result processing.
Currency	Currency context, especially relevant for IR, FX, credit and reporting.
MetadataJson	Additional classification, especially FRTB/SBA/IMA metadata.

FactorType

FactorType	Typical meaning
EqDelta	Equity price or index delta.
FxDelta	FX spot or FX curve risk.
IrDelta	Interest-rate curve delta, including tenor structure.
CmDelta	Commodity delta.
CsDelta	Credit-spread delta.
EqVega	Equity volatility risk.
FxVega	FX volatility risk.
CmVega	Commodity volatility risk.
IrVega	Interest-rate volatility risk.
CsVega	Credit-spread volatility risk.
Theta	Time-decay or valuation-date risk.
Epsilon	Residual or model-internal factor. Use only when model logic expects it.
None	Not suitable for productive risk factors.

FactorType must remain consistent across Risk Factor Group, Shift Type Map, Shift and result processing.

Risk Factors

A Risk Factor is the concrete factor inside a group. It can be referenced by shifts and appears in results, aggregation and FRTB/NMRF analysis.

Field	Meaning
Name	Display name and often a result dimension.
Key	Stable technical key.
MarketKey	Link to the market-data object such as curve, index, quote or surface.
InternalKey	Engine-specific key.
Bucket	Business bucket such as tenor, sector, currency pair or rating bucket.
RiskFactorKind	Describes how the factor is applied.
MetadataJson	Additional classification such as FRTB SBA/IMA attributes.

RiskFactorKind

RiskFactorKind	Use
Quote	Directly derived from a quote or market-data point.
Shift	Primarily a shock target.
Spread	Spread risk such as credit spread or basis spread.
Volatility	Volatility or surface-point risk.

RiskFactorKind is not the same as FactorType: FactorType says which risk class is affected; RiskFactorKind says how the factor is applied.

Risk Models

Risk Models define how results are generated. A model can run historical simulation, stress, sensitivities or curvature.

Field	Meaning
Name	Model name visible in workflows, results and reports.
IsActive	Only active models should be used in production workflows.
Reference	Optional reference name for model family or methodology.
MeasureType	Main calculation type.
SimulationPassMode	Special pass logic such as FRTB IMA liquidity horizons.
PeriodStart	Start date for historical windows or periodic models.
FixedPeriod	Fixed observation-period length where used by the model.
HoldingPeriod	Holding period for VaR/ES or scenario scaling.
ScenarioCount	Number of scenarios generated or read.
ScenarioPopulation	Population from which scenarios are sampled or filtered.
IgnoreFilters	Allows a model to ignore selection filters; use only with explicit business justification.

MeasureType

MeasureType	Meaning
HistSim	Historical simulation, typically VaR/ES or historical scenario distribution.
StressSim	Stress simulation using explicit stress scenarios or scenario sets.
Sensitivity	Single- or multi-factor sensitivities such as PV01, delta or vega.
Curvature	Up/down shocks and nonlinear risk contributions.

SimulationPassMode

SimulationPassMode	Meaning
Default	Normal model run without special pass splitting.
FrtbImaLiquidityHorizon	Special pass logic for FRTB IMA liquidity horizons.

Shift Type Maps

Shift Type Maps define how each FactorType is shifted by the model.

ShiftType	Meaning
None	Placeholder or disabled configuration.
Absolute	Additive shock, for example +1 bp or +0.01.
Relative	Multiplicative or percentage shock.
Compressed	Compressed scenario vector or serialized scenario payload.
Log	Log-return or logarithmic shift.

The map is model-wide. If IrDelta is configured as Absolute, concrete IR shifts should follow that convention.

Shifts

Shifts are concrete scenario or sensitivity definitions. They may reference one Risk Factor or affect multiple factors through a filter.

Field	Meaning
ScenarioSet	Groups shifts into a scenario or scenario family.
Name	Readable shock name.
FactorType	Risk class of the shock.
Abs	Absolute shock value.
Rel	Relative shock value.
Scale	Multiplier for horizon, volatility or period adjustment.
RiskFactor	Explicit affected factor.
FilterBody	Filter expression for factor or instrument selection.

Do not mix Abs, Rel and Scale casually. In most models exactly one of Abs or Rel is the leading shock value, while Scale is a documented multiplier.

Dependencies

The Dependencies tab lets one Risk Model reference other models. This is used when one model needs previous results, for example prices before sensitivities or base scenarios before curvature. Dependencies should be complete and cycle-free.

FRTB and metadata

MetadataJson can carry SBA and IMA classification: GIRR category, equity sector/economy/size, commodity sector, FX pair classification, credit sector, credit quality, securitisation attributes, DRC type and liquidity horizon. These fields affect bucketing, capital formulas, NMRF analysis and reporting.

Common issues

Issue	Effect
Inactive group with active factors	Factors may disappear from selection or model setup.
FactorType mismatch	Shifts can be ignored or interpreted incorrectly.
Duplicate factor keys	Aggregation and result attribution become ambiguous.
Missing RiskFactor on a specific shift	Shift can apply too broadly or only via FilterBody.
IgnoreFilters enabled without reason	Workflows may include unexpected positions or factors.
Missing FRTB metadata	SBA/IMA/NMRF reports may bucket results incorrectly.

Recommended checks

Before using a model in production, verify active groups, stable factor keys, matching Shift Type Maps, consistent scenario sets, complete dependencies and regulatory metadata.

Purpose

Machine learning models can support classification, prediction, anomaly detection and segmentation in risk workflows. FRM Notes v0.37 covers common supervised and unsupervised methods. This article explains the main concepts that matter for model validation.

Feature scaling

Standardization transforms a feature \(x\) into a z-score:

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

Min-max normalization maps values into a fixed range:

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

Scaling must be fitted on training data and then applied consistently to validation and production data.

Regression regularization

Ridge regression penalizes large coefficients:

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

LASSO uses an absolute-value penalty and can drive coefficients to zero:

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

Elastic Net combines both:

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

Logistic models

For binary outcomes, logistic regression maps a score into a probability:

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

where:

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

In risk applications, the output probability must be calibrated and monitored over time.

Trees and classification

Decision trees split data into groups. Common split criteria include Gini impurity:

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

and entropy:

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

Tree-based models are easy to inspect locally but can overfit without depth, leaf-size or ensemble controls.

Distance-based models

For observations \(x\) and \(y\), Euclidean distance is:

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

Manhattan distance is:

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

Distance-based models are sensitive to feature scaling and missing data.

Validation controls

Control	Why it matters
Train/validation split	Prevents testing on the same data used for fitting.
K-fold cross-validation	Tests stability across samples.
Calibration	Ensures predicted probabilities match observed frequencies.
Drift monitoring	Detects changes in input distribution or target behavior.
Explainability	Supports review, challenge and business use.
DQ checks	Prevents missing or out-of-range features from driving false predictions.

Common issues

Issue	Meaning	Possible action
High training accuracy, poor validation accuracy	Overfitting.	Simplify model or strengthen regularization.
Probability buckets miscalibrated	Scores rank risk but do not estimate probability correctly.	Recalibrate and retest.
Feature drift	Production data differs from training data.	Review population stability and retrain policy.
Unexplained decision	Model is hard to challenge.	Add explainability and override review.

Recommended practice

For risk use, machine learning validation should combine statistical performance, stability, explainability and data-quality evidence. A predictive model should not be promoted only because it has a good headline accuracy metric.

Source and scope

This article summarizes the sensitivities-based approach under the Basel Committee's 2019 market risk standardised approach. It is based on the local PDF resources/d457.pdf and the BIS publication page:

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

The focus here is SBA/SBM only: delta, vega and curvature. It does not summarize IMA, P&L attribution, backtesting, default risk charge or residual risk add-on.

Terminology

Term	Meaning
FRTB SBA	Common shorthand for the sensitivities-based approach under the standardised approach.
SBM	Sensitivities-based method; the terminology used in the Basel text.
Risk class	GIRR, CSR, Equity, Commodity or FX.
Bucket	Regulatory grouping within a risk class, such as currency, sector or commodity type.
Weighted sensitivity	Net sensitivity multiplied by a prescribed risk weight.

Calculation structure

For every risk class, the approach calculates:

Component	Applies to	Main input
Delta	Linear exposure to prescribed risk factors	Net sensitivities
Vega	Optionality exposure to implied volatility	Vega sensitivities
Curvature	Additional nonlinear loss beyond delta	Up/down shock revaluations

The overall SBA charge is calculated under medium, high and low correlation scenarios. The reported capital requirement is the largest scenario result.

Core formulas

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 scenarios:

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

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

The same high/low transformation is applied to bucket correlations \( \gamma_{bc} \).

SBA capital:

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

Curvature formula

Curvature measures incremental loss after removing the delta effect. For a 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] $$

The bucket charge selects the larger upward or downward scenario after regulatory correlation aggregation.

GIRR

General interest rate risk is bucketed by currency. Each currency is a separate bucket. Delta GIRR uses risk-free yield curve tenors, plus inflation and cross-currency basis 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%

Specified major currencies may use the Basel square-root-of-two reduction where permitted.

CSR non-securitisation

Credit spread risk non-securitisation is bucketed by credit quality and sector. Investment grade, high yield/non-rated and index buckets receive different risk weights.

CSR non-securitisation risk weights

Bucket range	Description	Risk weights
1-8	Investment grade sectors and covered bonds	0.5% to 5.0%
9-16	High yield, non-rated and other sector	2.0% to 12.0%
17	IG indices	1.5%
18	HY indices	5.0%

Notable high weights include 12.0% for financials in HY/non-rated and 12.0% for other sector.

Equity

Equity risk is bucketed by market capitalisation, economy and sector. The framework distinguishes large versus small market cap, advanced versus emerging market and 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 and curvature apply to option-like exposure. Equity repo rates do not receive vega or curvature capital in the same way as equity spot optionality.

Commodity

Commodity risk is bucketed into 11 commodity groups. The distinctions matter because energy, freight, metals, agriculture and other commodities have materially different prescribed shocks.

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 and freight are treated distinctly because delivery interval, region, route and week can materially change risk.

FX

FX risk uses one bucket for each exchange rate between the instrument currency and the reporting currency.

FX item	Value
Delta FX risk weight	15%
Across-bucket correlation	60%

Specified currency pairs and first-order crosses may use the Basel square-root-of-two reduction where permitted.

Vega risk

Vega uses the same bucket definitions as delta. The main distinction is the liquidity horizon by 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 replicate the delta buckets unless specified otherwise. FX and equity curvature shocks are relative shifts equal to their delta risk weights. For GIRR, CSR and commodity, curvature shocks are applied to the corresponding curve or risk factor and then the delta component is deducted.

Asset-class distinctions

Risk class	Bucket basis	Delta distinction	Vega/curvature distinction
GIRR	Currency	Tenor, curve, inflation, cross-currency basis	No curvature for inflation and cross-currency basis
CSR	Credit quality and sector	Tenor and issuer spread	Separate non-sec, securitisation CTP and non-CTP treatment
Equity	Market cap, economy, sector	Spot and repo rates	Repo rates excluded from vega/curvature focus
Commodity	Commodity group	Spot risk by commodity bucket	Delivery, route and region can matter
FX	Currency pair	Exchange rate to reporting/base currency	FX options follow FX vega and curvature rules

User interpretation

SBA results should be read as regulatory standardised charges under prescribed shocks and correlations. They are not the same as desk VaR, historical simulation loss, model approval or an internal capital model result.

Source and scope

This article summarizes the Basel Committee's 2016 standard for interest rate risk in the banking book. It is based on the local PDF resources/d368.pdf and the BIS publication page:

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

The focus is user interpretation: EVE, NII, prescribed interest-rate shocks, behavioural assumptions and standardised-framework calculations. It does not describe internal model governance or local supervisory reporting templates.

Purpose

IRRBB measures how banking-book earnings and economic value react to changes in interest rates. It is separate from trading-book market risk. The central question is whether assets, liabilities and off-balance-sheet positions reprice at different times, under different conventions or with embedded customer options.

Measure	Meaning	Typical use
EVE	Economic value of equity; present-value change of banking-book cashflows under interest-rate shocks.	Structural value sensitivity and supervisory outlier review.
NII	Net interest income; earnings impact over a forward horizon.	Earnings sensitivity and planning under shocked rates.
Delta EVE	Difference between base EVE and shocked EVE, including option add-ons where applicable.	Main standardised-framework value metric.
Delta NII	Difference between base NII and shocked NII.	Earnings metric disclosed with prescribed scenarios.

Standardised framework stages

The Basel standardised framework can be read as a five-step process:

Stage	What happens
1	Classify banking-book positions as amenable, less amenable or not amenable to standardisation.
2	Slot notional repricing cashflows into maturity buckets.
3	Calculate EVE changes for prescribed shock scenarios in each material currency.
4	Add the change in value of automatic interest-rate options.
5	Use the worst aggregated EVE reduction across the prescribed scenarios.

Repricing cashflows

The standardised EVE calculation uses notional repricing cashflows. Fixed-rate positions are generally slotted to contractual maturity. Floating-rate positions are generally slotted at the next reset or repricing date.

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

Non-maturity deposits

Non-maturity deposits are split into retail and wholesale categories. Retail deposits are further split into transactional and non-transactional balances. Stable balances can be treated as core deposits subject to caps; non-core balances are treated as overnight.

Category	Cap on core balance	Average maturity cap
Retail transactional	90%	5.0Y
Retail non-transactional	70%	4.5Y
Wholesale	50%	4.0Y

In the portal, NMDs are interpreted as behavioural rates instruments. The runoff profile creates the cashflow distribution for the stable balance; segment cap and average maturity cap constrain the allowed behavioural maturity. If a zero floor is enabled, a normal/Bachelier floor value is added and requires a mapped normal-volatility surface.

Result	NMD-specific interpretation
EVE	Strongly driven by core balance, runoff profile and weighted average maturity.
NII	Depends on customer rate, pass-through and repricing assumption.
PV01	Measures curve exposure from runoff duration and discounting.
IrVega	Measures the value contribution of the normal-volatility surface used by the floor component.

When NMD results look suspicious, check core-balance cap, runoff WAL, IncludeFloorValue, FloorStrike and surface mapping first.

Behavioural option assumptions

Behavioural options are important because customer behaviour changes when rates move. The standardised framework prescribes scenario scalars for loan prepayments and term-deposit redemptions.

Prepayment rate under scenario \(i\), portfolio \(p\), currency \(c\):

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

Scenario	Prepayment scalar \( \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-adjusted 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) $$

Scenario	Term-deposit scalar \(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 formulas

Discount factor for shocked scenario \(i\), currency \(c\), bucket midpoint \(t_k\):

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

Net EVE under scenario \(i\):

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

EVE loss under scenario \(i\), including the automatic-option add-on \(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} $$

The standardised EVE metric uses the largest positive aggregated loss across the six scenarios:

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

Only currencies with positive EVE loss contribute to the aggregated loss in the standardised calculation.

Prescribed EVE shock scenarios

The six EVE scenarios are parallel up, parallel down, steepener, flattener, short-rate up and short-rate down.

Currency	Parallel shock	Short-rate shock	Long-rate shock
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 shock:

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

Short-rate shock, with \(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 shock:

$$ 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|

$$

Supervisors may define post-shock interest-rate floors. The Basel text limits those floors so they cannot exceed zero.

Portfolio and asset distinctions

Area	Interpretation
Fixed-rate loans and bonds	Main risk is maturity mismatch and discount-curve shock.
Floating-rate instruments	Main risk is reset timing and basis between funding and asset curves.
Non-maturity deposits	Behavioural maturity assumptions can dominate EVE.
Prepayable loans	Lower rates can increase prepayments and shorten asset duration.
Term deposits	Higher rates can increase early redemption pressure.
Automatic options	Option valuation must include the shocked curve and prescribed volatility stress.

Outlier and disclosure context

The Basel standard compares a bank's maximum \( \Delta EVE \) with Tier 1 capital. The outlier threshold in d368 is 15% of Tier 1 capital. Banks also disclose changes in EVE and NII under the prescribed shocks.

This is not a statement of local regulatory approval. Portal results should be read as model, data and scenario evidence under the scope shown on the relevant result page.

Recommended practice

Check the curve currency, repricing buckets, NMD assumptions, behavioural-option inputs and sign convention before interpreting an IRRBB result. For large changes, compare base and shocked cashflow buckets first; then review whether the movement is caused by true duration risk, customer-option assumptions or missing market data.

Purpose

These examples show the kind of small calculations used to validate valuation mechanics. They are simplified and intended for interpretation, not for reproducing production runs.

Bond DCF example

Input	Value
Notional	1,000,000
Annual coupon	3.00%
Discount factor to coupon date	0.9800
Discount factor to maturity	0.9400

Cashflows are discounted independently. A final coupon of 30,000 and redemption of 1,000,000 at maturity contribute:

$$ 1{,}030{,}000 \times 0.9400 $$

Swap par-rate example

Leg	Interpretation
Floating leg	Projected index coupons discounted to today.
Fixed leg	Fixed coupons discounted to today.
Fair rate	Fixed rate that makes both legs equal in present value.

Option Black-style example

Input	Meaning
Forward	Expected underlying level under the pricing measure.
Strike	Exercise level.
Volatility	Annualized uncertainty input.
Expiry	Time to option exercise.

Higher volatility usually increases option value, especially for options near the strike.

Curve example

A curve turns market quotes into discount or projection factors. A one-year zero rate of 3% with annual compounding implies a discount factor close to:

$$ \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)} $$

Recommended practice

Use these examples to check direction and magnitude. Production results also depend on calendars, day counts, interpolation, settlement, fixings and model-specific conventions.

Purpose

Bonds and swaps are rates instruments whose results are mainly driven by cashflows, discount curves and projection curves.

Important fields

Field	Meaning
Notional	Principal amount used for coupons and redemption.
Coupon or fixed rate	Rate applied to the notional.
Payment schedule	Dates on which cashflows occur.
Curve mapping	Discount and projection curves selected for valuation.

Result interpretation

For bonds, compare clean price, dirty price, accrued interest and present value. For swaps, compare leg NPVs, total NPV, fair rate and sensitivities.

Common issues

Issue	Meaning	Possible action
Zero PV	Instrument expired, quantity is zero, or valuation object was not built.	Check maturity, position quantity and instrument support.
Unexpected accrued	Day count or settlement convention differs.	Review coupon schedule and settlement date.
Missing curve	Curve mapping is incomplete.	Check market data and instrument static data.

Purpose

This article explains the instrument types currently represented in the portal validation packs and production-facing validation samples. Instruments are grouped by asset class. Each section lists prerequisites, important configuration fields and a sample configuration.

The examples are intentionally compact. Real production positions also need portfolio, book, legal entity, counterparty and source-system metadata.

Common prerequisites

Every instrument needs enough static data, market data and model mapping to select the correct valuation and simulation path.

Requirement	Meaning
Instrument type	Canonical type such as FixedRateBond, InterestRateSwap, EuropeanVanillaOption or HICPYYCap.
Trade id / name	Stable id and readable name used in validation evidence and dashboards.
Asset class	Rates, Equity, FX, Commodity, Inflation or Hybrid.
Currency	Valuation/reporting currency.
Notional or quantity	Economic size. Large quantities can dominate PV and scenario PnL.
Issue / start date	Schedule start or trade start.
Maturity	Final maturity, expiry or delivery date.
Day count	Accrual convention where applicable.
Business day convention	Date adjustment convention where applicable.
Market-data mapping	Curves, quotes, volatility surfaces, fixings or index levels.
Model mapping	Production builder/model path used for valuation and simulation.

Validation evidence capabilities

Instrument validation packs normally test these capabilities where available:

Capability	Meaning
Pricing	Base valuation / PV / price.
Cashflows	Extracted schedule or payment view.
Sensis	Shifted valuation and finite-difference sensitivity.
Scenarios	Deterministic scenario valuation.
VaR	Historical simulation scenario vector and tail measure.
DQ	Data Quality checks on static and market-data requirements.

Not every instrument has the same coverage. Unsupported or partially connected instruments should be marked Amber, Red or Unknown in validation, not Green.

Rates: Bonds

Implemented bond-like instruments include:

Instrument type	Use case	Current validation focus
FixedRateBond	Vanilla fixed-coupon bond.	Pricing, cashflows, sensis, scenarios, VaR, DQ.
FloatingRateBond	Floating-rate note.	Basic bond portfolio coverage and readiness.
ZeroBond	Zero-coupon bond.	Basic bond portfolio coverage and readiness.
CallableBond	Bond with issuer call optionality.	Readiness section; coverage gaps documented.
ConvertibleBond	Bond with equity conversion feature.	Hybrid/readiness section; coverage gaps documented.

Instrument descriptions

Instrument type	Description
FixedRateBond	A fixed-rate bond pays a known coupon schedule and principal repayment. It addresses deterministic rates valuation, accrued interest, cashflow validation, curve discounting and bond PV01/VaR use cases.
FloatingRateBond	A floating-rate bond links coupons to a reference index or forward curve. It addresses projection-curve setup, reset/fixing handling and floating cashflow readiness.
ZeroBond	A zero-coupon bond has no periodic coupon and is valued mainly through discounting to maturity. It addresses pure discount-factor validation and simple curve sensitivity.
CallableBond	A callable bond gives the issuer the right to redeem before maturity. It addresses optionality in rates products, but needs call schedule and optionality model evidence before unrestricted use.
ConvertibleBond	A convertible bond combines bond cashflows with an equity conversion feature. It addresses hybrid rates/equity risk and requires both bond valuation inputs and equity-option style inputs.

Prerequisites

Data	Required for
Discount curve	Pricing, PV01, scenario revaluation and VaR.
Cashflow schedule fields	Coupon dates, maturity, day count and frequency.
Settlement convention	Clean/dirty price and accrued-interest interpretation.
Credit/spread curve	Required if spread-discounting or credit valuation is enabled.
Optionality data	Callable and convertible features.
Equity data	Convertible conversion feature.

Fixed-rate bond sample fields

Field	Value
Trade id	VAL-BOND-FIXED-001
Instrument	FixedRateBond
Asset class	Rates
Currency	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 checks

Typical bond DQ checks include positive notional, maturity after issue date, valid coupon, discount-curve mapping and required market-data references.

Rates: Interest Rate Swaps

Implemented swap-like instruments include:

Instrument type	Use case	Current validation focus
InterestRateSwap	Vanilla fixed-vs-floating IRS.	Pricing, cashflows, sensis, scenarios, VaR, DQ.
NonMaturingDeposit	Deposit without contractual final maturity.	IRRBB, pricing, cashflows, sensis, VaR, DQ with behavioural assumptions.

Instrument description

Instrument type	Description
InterestRateSwap	An interest-rate swap exchanges fixed and floating interest cashflows. It addresses hedge valuation, fixed/floating curve setup, swap PV01, key-rate sensitivity and IR historical simulation.
NonMaturingDeposit	A non-maturity deposit models stable and unstable deposit balances without contractual maturity. It addresses IRRBB EVE, behavioural maturity, core-balance caps, runoff cashflows and optional zero-floor Vega. Details are in the Non-Maturity Deposits article.

Prerequisites

Data	Required for
Discount curve	PV and discounting of both legs.
Forward curve	Floating leg projection.
Fixed leg frequency	Fixed coupon schedule.
Floating leg frequency	Reset and payment schedule.
Fixed rate and spread	Coupon economics.
Swap direction	Payer or receiver interpretation.
NMD segment and runoff profile	For NMDs: segment cap, core balance, weighted average maturity and cashflow distribution.
Normal-volatility surface	For NMDs with active floor: mapped normal-volatility surface, not an instrument-local substitute.

IRS sample fields

Field	Value
Trade id	VAL-IRS-PAYER-ANNUAL-001
Trade name	IRS/EUR/PAYER/5Y/ANN-3M
Instrument	InterestRateSwap
Currency	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

Data Quality checks

Typical IRS DQ checks include positive notional, maturity after issue date, finite fixed rate and both legs configured.

Rates: Caps, Floors and Collars

Implemented optionlet instruments include:

Instrument type	Use case	Current validation focus
VanillaCapFloor	Interest-rate cap or floor.	Pricing, cashflows, sensis, scenarios, VaR, DQ.
VanillaCollar	Long cap / short floor or equivalent collar structure.	Pricing, cashflows, sensis, scenarios, VaR, DQ.

Instrument descriptions

Instrument type	Description
VanillaCapFloor	A cap or floor is a strip of optionlets on a floating interest-rate index. It addresses rate optionality, optionlet volatility, vega-sensitive valuation and nonlinear IR scenario risk.
VanillaCollar	A collar combines a cap and floor to limit floating-rate exposure within a range. It addresses hedging structures where upside and downside rate moves are bounded by two strikes.

Prerequisites

Data	Required for
Discount curve	PV discounting.
Forward curve	Floating index projection.
Cap/floor volatility	Optionlet valuation.
Strike	Cap/floor strike.
Floating frequency	Optionlet schedule.
Low/high barrier	Collar lower and upper strikes.

Cap and collar sample fields

Field	Cap value
Trade id	VAL-CAP-3Y-ATM-001
Trade name	CAP/EUR/3Y/ATM
Instrument	VanillaCapFloor
Cap/floor type	Cap
Notional	1,000,000
Strike	2.00%
Floating frequency	Quarterly
Issue date	2026-02-15
Maturity	2029-02-15
Day count	Actual360
Volatility	25.00%

Field	Collar value
Trade id	VAL-COLLAR-5Y-001
Trade name	COLLAR/EUR/1.00-3.00/5Y
Instrument	VanillaCollar
Notional	1,000,000
Floating frequency	Quarterly
Lower strike	1.00%
Upper strike	3.00%
Issue date	2026-02-15
Maturity	2031-02-15
Volatility	25.00%

Both samples use EUR currency and 1,000,000 notional.

Rates: Bond Futures

Implemented future/forward coverage includes:

Instrument type	Use case	Current validation focus
BondFuture	Rates future with deliverable bond basket.	CTD basket validation, pricing, sensis, scenarios, VaR, DQ.

Instrument description

Instrument type	Description
BondFuture	A bond future is a standardized futures contract referencing a deliverable government-bond basket. It addresses futures pricing, cheapest-to-deliver selection, conversion factors and rates scenario exposure.

Prerequisites

Data	Required for
Futures price	Base future value.
Deliverable basket	Conversion factors and forward clean prices.
Cheapest-to-deliver logic	Bond future valuation and risk.
IR curve shocks	Scenario and VaR risk.

Bond future sample fields

Field	Value
Trade id	VAL-FUT-BUND-SEP26-001
Trade name	FUT/BOND/BUND/202609
Instrument	BondFuture
Currency	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 and Indices

Implemented basic quote instruments include:

Instrument type	Use case	Current validation focus
Stock	Listed equity position.	Quote instrument pricing and scenario readiness.
EquityIndex	Equity index exposure.	Quote instrument pricing and scenario readiness.

Instrument descriptions

Instrument type	Description
Stock	A stock position is direct exposure to an equity spot price. It addresses simple quote valuation, quantity scaling, equity shocks and equity PnL vectors.
EquityIndex	An equity index position references a basket index level rather than a single issuer. It addresses index quote valuation, broad-market equity shocks and index-level scenario exposure.

Prerequisites

Data	Required for
Spot quote	Base valuation.
Quantity	Position size.
Currency	Reporting and FX conversion.
Equity shock set	Scenario and VaR.

Stock sample fields

Field	Value
Trade id	VAL-BASIC-STOCK-SAP-001
Trade name	EQU/STK/SAP
Instrument	Stock
Currency	EUR
Quantity	1,000
Spot	176.42

Equity: Vanilla Options

Implemented vanilla option coverage includes:

Instrument type	Use case	Current validation focus
EuropeanVanillaOption	European call/put, ITM/ATM/OTM.	Pricing, cashflows, sensis, scenarios, VaR, DQ.

Instrument description

Instrument type	Description
EuropeanVanillaOption	A European vanilla option gives the right to buy or sell the underlying at expiry. It addresses option pricing, delta/gamma/vega risk, volatility surface mapping and nonlinear scenario valuation.

Prerequisites

Data	Required for
Underlying spot	Option value and delta/gamma risk.
Strike and expiry	Payoff definition.
Option type	Call or put.
Volatility surface or flat vol	Pricing and vega risk.
Risk-free curve	Discounting and forward.
Dividend yield or forward adjustment	Equity option forward.
Equity, IR and vol shocks	Full scenario/VaR coverage.

European option sample fields

Field	Value
Trade id	VAL-OPT-CALL-ATM-001
Trade name	OPT/EUR/CALL/ATM
Instrument	EuropeanVanillaOption
Currency	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

Equity: Exotic Options

Readiness coverage includes:

Instrument type	Use case
BarrierOption	Single-barrier option.
DoubleBarrierOption	Double-barrier option.
AsianOption	Average-price option.
DigitalOption	Cash-or-nothing or binary payoff.
FixedLookbackOption	Fixed-strike lookback.
LookbackOption	Floating-strike lookback.
PartialFixedLookbackOption	Partial fixed lookback.
PartialFloatingLookbackOption	Partial floating lookback.
HolderExtensibleOption	Holder extension feature.
MagrabeOption	Asset-exchange option.
SimpleChooserOption	Simple chooser payoff.
ComplexChooserOption	Complex chooser payoff.

Instrument descriptions

Instrument type	Description
BarrierOption	A barrier option activates or extinguishes depending on whether the underlying reaches a barrier. It addresses path-dependent optionality and barrier-level data requirements.
DoubleBarrierOption	A double-barrier option has both lower and upper barrier conditions. It addresses bounded path-dependent payoffs and sensitivity to barrier placement.
AsianOption	An Asian option uses an average underlying level rather than only the terminal price. It addresses averaging-period configuration and reduced sensitivity to one terminal observation.
DigitalOption	A digital option pays a fixed amount if a condition is met. It addresses discontinuous payoff behavior and high sensitivity around the strike.
FixedLookbackOption	A fixed-strike lookback option depends on the best or worst observed underlying level over time. It addresses observation-window setup and path-dependent extrema.
LookbackOption	A floating-strike lookback option sets the effective strike from observed path extrema. It addresses floating payoff definition and historical path capture.
PartialFixedLookbackOption	A partial fixed lookback observes extrema only during a defined subperiod. It addresses products where path dependency starts or stops before final expiry.
PartialFloatingLookbackOption	A partial floating lookback combines floating strike behavior with a restricted observation window. It addresses more specialized path-dependent payoff validation.
HolderExtensibleOption	A holder-extensible option allows the holder to extend the option under defined terms. It addresses extension rights and conditional maturity behavior.
MagrabeOption	A Margrabe option exchanges one asset for another. It addresses two-underlying exposure, relative volatility and correlation-sensitive payoff behavior.
SimpleChooserOption	A simple chooser lets the holder choose whether the product becomes a call or put at a decision date. It addresses choice-date configuration and combined call/put optionality.
ComplexChooserOption	A complex chooser allows richer call/put choice terms, potentially with different strikes or expiries. It addresses multi-parameter chooser payoff validation.

Prerequisites

Exotic options need the vanilla option inputs plus product-specific fields such as barrier levels, averaging period, observation dates, extension terms or second-underlying data. If those fields are not connected to production valuation, validation must show limitations rather than Green readiness.

Exotic option sample configurations

These are the exotic option types currently represented by the validation portfolio.

Trade id	Trade name	Instrument type	Option	Moneyness	Strike	Volatility	What it addresses
VAL-EXOTIC-BARRIER-001	OPT/EUR/BARRIER/DOWN-OUT-CALL	BarrierOption	Call	OTM	110.0	0.24	Single barrier activation/knock-out behavior.
VAL-EXOTIC-DOUBLE-BARRIER-001	OPT/EUR/DOUBLE-BARRIER/KNOCK-OUT-CALL	DoubleBarrierOption	Call	ATM	100.0	0.24	Lower and upper barrier conditions.
VAL-EXOTIC-ASIAN-001	OPT/EUR/ASIAN/AVG-PRICE-CALL	AsianOption	Call	ATM	100.0	0.22	Average-price payoff and averaging-period setup.
VAL-EXOTIC-DIGITAL-001	OPT/EUR/DIGITAL/CASH-OR-NOTHING	DigitalOption	Call	ATM	100.0	0.20	Binary payoff around strike.
VAL-EXOTIC-LOOKBACK-FIXED-001	OPT/EUR/LOOKBACK/FIXED-STRIKE	FixedLookbackOption	Call	ATM	100.0	0.26	Fixed-strike path extrema.
VAL-EXOTIC-LOOKBACK-FLOATING-001	OPT/EUR/LOOKBACK/FLOATING-STRIKE	LookbackOption	Call	ATM	100.0	0.26	Floating-strike path extrema.
VAL-EXOTIC-LOOKBACK-PARTIAL-FIXED-001	OPT/EUR/LOOKBACK/PARTIAL-FIXED	PartialFixedLookbackOption	Call	ATM	100.0	0.27	Restricted-window fixed lookback behavior.
VAL-EXOTIC-LOOKBACK-PARTIAL-FLOATING-001	OPT/EUR/LOOKBACK/PARTIAL-FLOATING	PartialFloatingLookbackOption	Call	ATM	100.0	0.27	Restricted-window floating lookback behavior.
VAL-EXOTIC-HOLDER-EXTENSIBLE-001	OPT/EUR/HOLDER-EXTENSIBLE/CALL	HolderExtensibleOption	Call	ATM	100.0	0.23	Holder extension right.
VAL-EXOTIC-MAGRABE-001	OPT/EUR/MAGRABE/EXCHANGE	MagrabeOption	Call	ATM	100.0	0.25	Exchange option on two assets.
VAL-EXOTIC-CHOOSER-SIMPLE-001	OPT/EUR/CHOOSER/SIMPLE	SimpleChooserOption	Call	ATM	100.0	0.21	Choice between call and put at decision date.
VAL-EXOTIC-CHOOSER-COMPLEX-001	OPT/EUR/CHOOSER/COMPLEX	ComplexChooserOption	Call	ATM	100.0	0.21	Richer chooser terms with multiple payoff parameters.

Common configuration fields for these samples:

Field	Common value
Asset class	Equity
Currency	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

Product-specific fields such as barriers, observation windows, averaging dates, extension terms, second-underlying data and chooser decision dates must be present in production static data when the production model requires them.

Equity: Equity Futures

Instrument type	Use case	Current validation focus
EquityFuture	Cost-of-carry equity future.	Pricing, sensis, scenarios, VaR, DQ.

Instrument description

Instrument type	Description
EquityFuture	An equity future is a forward-style exposure to an equity underlying with standardized maturity terms. It addresses cost-of-carry pricing, forward level checks and equity scenario PnL.

Equity future sample fields

Field	Value
Trade id	VAL-FWD-EQU-SAP-SEP26-001
Trade name	FUT/EQU/SAP/202609
Instrument	EquityFuture
Currency	EUR
Quantity	100
Spot	176.42
Strike/reference price	178.50
Risk-free rate	2.50%
Dividend yield	1.20%
Maturity	2026-09-18

FX

Implemented FX instruments include:

Instrument type	Use case	Current validation focus
CurrencyPair	Spot FX quote exposure.	Quote instrument pricing and scenario readiness.
FxForward	FX forward.	Domestic/foreign discounting, scenario and VaR readiness.

Instrument descriptions

Instrument type	Description
CurrencyPair	A currency pair represents spot FX exposure between two currencies. It addresses FX quote validation, conversion rates and FX shock impact.
FxForward	An FX forward locks an exchange rate for a future settlement date. It addresses domestic/foreign discounting, forward points and FX scenario exposure.

Prerequisites

Data	Required for
Spot FX rate	Base valuation.
Domestic curve	Discounting/reporting currency leg.
Foreign curve	Foreign currency leg.
Forward points or implied forward	Forward validation.
FX shocks	Scenario and VaR.

FX forward sample fields

Field	Value
Trade id	VAL-FWD-FX-EURUSD-6M-001
Trade name	FWD/FX/EURUSD/6M
Instrument	FxForward
Currency	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

Implemented commodity coverage includes:

Instrument type	Use case	Current validation focus
Commodity	Commodity quote exposure, for example Brent.	Quote instrument pricing and scenario readiness.

Instrument description

Instrument type	Description
Commodity	A commodity position references a commodity spot or quoted market level such as Brent. It addresses commodity quote valuation, quantity scaling and commodity scenario shocks.

Commodity sample fields

Field	Value
Trade id	VAL-BASIC-CMDTY-BRENT-001
Trade name	CMDTY/BRENT
Instrument	Commodity
Currency	USD
Quantity	1,000
Spot	82.35

Inflation

Implemented inflation validation instruments include CPI, HICP zero-coupon and HICP year-on-year products.

Instrument type	Family	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.

Instrument descriptions

Instrument type	Description
CPIBond	A CPI bond links bond cashflows or principal to a consumer price index. It addresses CPI fixing usage, base index handling and inflation-linked bond valuation.
CPISwap	A CPI swap exchanges fixed or nominal payments against CPI-linked inflation payments. It addresses inflation swap curve setup, index projection and CPI payoff validation.
HICPZCBond	An HICP zero-coupon bond uses cumulative HICP inflation from base date to maturity. It addresses zero-coupon inflation curve construction and final inflation uplift.
HICPZCCapFloor	An HICP zero-coupon cap/floor applies optionality to cumulative inflation over the instrument life. It addresses inflation optionality, zero-coupon inflation volatility and strike validation.
HICPYYBond	An HICP year-on-year bond-like position references annual inflation changes. It addresses YoY index treatment and recurring inflation-linked cashflow behavior.
HICPYYCap	An HICP year-on-year cap limits annual inflation exposure above a strike. It addresses YoY inflation optionality and caplet-style inflation volatility.
HICPYYFloor	An HICP year-on-year floor protects against annual inflation below a strike. It addresses downside inflation optionality and floorlet-style payoff validation.

CPI vs zero-coupon vs year-on-year

Family	Index interpretation
CPI	Uses CPI index levels and base CPI for index-linked payments.
HICP zero-coupon	Uses the cumulative inflation ratio between base and maturity observation.
HICP year-on-year	Uses annual inflation rates between consecutive observation periods.

Do not mix zero-coupon and year-on-year inflation indexes. They have different curve construction, fixing and payoff conventions.

Inflation prerequisites

Data	Required for
Inflation index id	Example: EUR_CPI or EUR_HICPXT.
Base CPI	Starting index level.
Observation lag	Typical inflation lag, for example three months.
Inflation fixings	Historical observed index levels.
Zero inflation curve	Zero-coupon inflation products.
YoY inflation curve	Year-on-year products.
Nominal discount curve	Discounting.
Inflation volatility	Inflation cap/floor optionality.

HICP zero-coupon cap/floor sample fields

Field	Value
Trade id	VAL-INF-HICPZC-CAPFLOOR-001
Trade name	INF/HICPZC/CAPFLOOR/5Y
Instrument	HICPZCCapFloor
Currency	EUR
Notional	1,000,000
Inflation index	EUR_HICPXT
Base CPI	100.00
Observation lag	3 months
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 sample fields

Field	Value
Trade id	VAL-INF-HICPYY-CAP-001
Trade name	INF/HICPYY/CAP/5Y
Instrument	HICPYYCap
Currency	EUR
Notional	1,000,000
Inflation index	EUR_HICPXT
Base CPI	100.00
Observation lag	3 months
Cap/floor type	Cap
Strike	2.50%
Fixed frequency	Annual
Floating frequency	Annual
Maturity	2031-02-15

Inflation Data Quality checks

Typical inflation DQ checks include positive notional, valid maturity, configured inflation index, positive base CPI and valid strike for optionality products.

Hybrid and convertible instruments

Instrument type	Asset class	Use case
ConvertibleBond	Hybrid	Bond with equity conversion feature.

Instrument description

Instrument type	Description
ConvertibleBond	A convertible bond is a debt instrument with an embedded right to convert into equity. It addresses credit/rates cashflows and equity optionality in one product, so both bond and option data must be valid.

Convertible bonds require both rates/bond data and equity-option data. Required inputs include discount curve, bond schedule, conversion ratio or strike, underlying equity, volatility and optional call/put features. Current validation should be read as readiness coverage unless explicit executable evidence is shown.

Recommended practice

When adding or reviewing a position:

• Confirm the canonical instrument type.
• Check that the asset class matches the risk drivers.
• Confirm all required market-data mappings exist.
• Check DQ findings before trusting valuation.
• Verify the validation dashboard shows evidence for the required capability.
• Treat readiness-only or inventory-only instruments as restricted until production evidence is connected.

Purpose

Non-maturity deposits (NMDs) model deposits without a contractual final maturity. The portal uses them for IRRBB-style banking-book views, sensitivities and historical simulations when the economic repricing date cannot be inferred from a contractual maturity date.

NMDs are not ordinary term deposits. Their value depends on behavioural assumptions, core-balance caps, runoff profile, customer rate, market rate and the optional zero-floor component.

Important fields

Field	Meaning
Segment	Customer segment such as retail transactional, retail non-transactional or wholesale. Drives core-balance and maturity caps.
CurrentBalance	Current deposit balance. This is the economic base amount.
StableBalanceRatio	Share of the balance that may be treated as stable before regulatory caps are applied.
PassThroughRate	Share of market-rate moves passed through to the customer rate. Lower pass-through usually increases economic stability.
DepositRate	Current customer rate paid on the deposit.
FloorStrike	Strike of the optional customer-rate floor component. For zero-floor NMDs this is usually 0.0.
IncludeFloorValue	Enables optional floor valuation. A mapped normal-volatility surface is required.
RunoffProfile	Time-weighted runoff assumptions for the stable balance. These drive cashflows and weighted average maturity.

Segment caps

Segment	Maximum core share	Maximum average maturity
Retail transactional	90%	5.0Y
Retail non-transactional	70%	4.5Y
Wholesale	50%	4.0Y

The actual core balance is the lower of the assumed stable balance and the segment cap. Non-core balances are interpreted as short-dated or overnight repricing exposure.

Valuation logic

The deterministic NMD component values modelled runoff cashflows using the relevant discount curve. Optionally, a customer-rate floor component is valued as a normal/Bachelier option.

Component	Interpretation
Core runoff PV	Present value of stable deposit cashflows along the runoff profile.
Non-core treatment	Short-dated or overnight repricing of the unstable balance.
Floor value	Value of the embedded floor when IncludeFloorValue is enabled.
Total PV	Sum of deterministic deposit component and optional floor contribution under the model convention.

The floor component uses a mapped normal-volatility surface. An instrument-local scalar does not replace that surface. If IncludeFloorValue is enabled and no suitable surface exists, this is a data-quality or mapping issue, not a valid zero-vega result.

Market data and risk factors

Market datum	Required for
Discount curve	PV, IR sensitivity, IRRBB EVE and historical simulation.
Normal-volatility point surface	Floor value, Vega and volatility-driven VaR contributions.
Surface node quotes	Historical shock vectors and scenario revaluation.
Risk-factor mapping	Link between surface, benchmarks and sensitivity/VaR factors.

For NMD floor Vega, expect a mapped volatility factor such as EUR/IR/NORMALVOL.Shift.1Y. Instrument-local synthetic factors such as .../NMD_NORMAL_VOL... are not the expected production path.

Sensitivities and VaR

Result	Correct interpretation
PV01 / IR Delta	Value change from the discount curve and repricing duration of the runoff profile.
IrVega	Value change from the normal-volatility surface used by the floor component.
VaR	Historical revaluation across curve and volatility factors when the surface exists in scenario history.
Zero Vega	Plausible only when the floor is disabled, the option is worthless or the exposure is genuinely outside mapped surface nodes. With an active floor, check surface mapping first.

NMD Vega uses the floor strike, not a generic ATM strike. For zero-floor NMDs this is normally 0.0. If sensitivity extraction and valuation use different strikes, the result can incorrectly appear as zero.

Validation checks

Check	Meaning
Positive balance	Balance must be positive and economically meaningful.
Segment cap	Core balance must not exceed the segment cap.
Average maturity cap	Runoff profile must not exceed the allowed average maturity.
Runoff profile	Weights, dates and remaining balance must be consistent.
Curve mapping	Currency and discount curve must match the position.
Vol surface mapping	An active floor requires a normal-volatility surface.
Scenario coverage	VaR and sensitivities need historical values for the used risk factors.

Common issues

Issue	Likely cause	Action
NMD missing in instrument validation	Instrument type, feature mapping or seeded data is missing.	Check instrument type and feature data.
PV exists, Vega is zero	Floor disabled, missing vol surface or wrong strike in risk-factor path.	Check IncludeFloorValue, surface mapping and FloorStrike.
VaR fails with missing factor	Surface or risk-factor group is not mapped consistently.	Compare quotable factor, surface name and scenario history.
EVE dominated by NMD	Core share or WAL is high.	Check segment cap, stable balance ratio and runoff profile.
Results jump after market-data reload	Surface nodes or historical quotes changed.	Compare used benchmarks and valuation date.

Purpose

Option values depend on underlying level, strike, time to expiry, rates, dividends or forwards, and volatility.

Important fields

Field	Meaning
Strike	Exercise price or level.
Expiry	Date on which optionality is exercised or observed.
Volatility	Market input used by the option model.
Delta, Vega, Gamma	Sensitivities to underlying, volatility and curvature.

Result interpretation

Options near the strike are usually most sensitive to volatility and underlying moves. Deep in-the-money options can behave more like the underlying.

Common issues

Issue	Meaning	Possible action
Missing vol	Required expiry/strike point is absent.	Check volatility surface coverage.
Very high vega	Expiry, quantity or volatility convention may be wrong.	Review input units and position size.
Wrong intrinsic value	Option type or payer/receiver direction may be wrong.	Check call/put and buy/sell direction.

Purpose

Inflation products depend on inflation index conventions, observation lags, fixings and inflation curves. YoY and zero-coupon inflation should not be interpreted as the same index exposure.

YoY versus zero-coupon

Product type	Interpretation
Year-on-year inflation	Coupon depends on inflation over a one-year observation period.
Zero-coupon inflation	Payoff depends on cumulative inflation from base date to maturity.
Inflation cap/floor	Optional payoff on an inflation rate or index ratio.

Important fields

Field	Meaning
Index	CPI, HICP or another inflation index family.
Observation lag	Delay between valuation/payment date and observed index date.
Base CPI	Starting index level for ratio-based payoffs.
Fixings	Historical observed index values.

Common issues

Issue	Meaning	Possible action
Wrong magnitude	YoY and zero-coupon convention may be mixed.	Check product family and index curve.
Missing fixing	Observation date has no index value.	Review fixing calendar and lag.
Zero option PV	Volatility or inflation option model input may be missing.	Check inflation vol and curve setup.

Purpose

The report framework collects portfolio, market risk, PnL, cashflow, sensitivity, limit and provision information into a controlled business report. It is intended for daily review, sign-off preparation and distribution to desks, books or portfolios. The report does not replace the underlying valuation or risk workflows; it reads persisted results and presents them in a consistent reporting structure.

Main concepts

Concept	Meaning
Report Definition	The reusable report template, such as a daily market risk report.
Report Section	A named block inside the report, for example PnL summary, VaR table, sensitivities or provisions.
Exposure Selection	A saved filter that defines which business scope or result set a section should use.
Report Artifact	A generated output file, typically a PDF or another stored report artifact.
Recipient Group	A maintained list of To, Cc and Bcc recipients for controlled distribution.
Subscription	A rule connecting a report, scope, recipients, delivery format and schedule.
Comment	A business comment attached to a generated report or review cycle.

Typical workflow

• Define the report template and the sections that should appear.
• Configure the business scope: group, desk, book, portfolio or instrument where applicable.
• Select the reference date, reporting currency and model.
• Generate or open the report view.
• Review the PnL summary, VaR or ES results, sensitivity sections, cashflow buckets and provisions.
• Add comments for explanations, breaches, missing data or manual adjustments.
• Store the artifact and distribute it through the configured subscription when the report is ready.

Report definitions

Report definitions describe the identity and default behavior of a report. The definition should be stable and business-readable. A report definition usually contains a display name, report type, default currency, active flag and description.

Field	Meaning
Name	Technical identifier used to request the report. Keep it stable.
Display Name	User-facing report title.
Report Type	Functional family, for example market risk.
Default Currency	Currency used when no explicit reporting currency is selected.
Is Active	Controls whether the definition should be used operationally.
Description	Business explanation of report scope and intended use.

Report sections

Sections define what appears in the report and in which order. A section can represent a table, summary block, chart, text section or a query-driven result. Sections should be small enough to review independently.

Field	Meaning
Key	Stable section identifier within the report definition.
Title	Display title shown to the user.
Sort Order	Ordering of sections in the report.
Section Type	Presentation type, such as table, summary or text.
Query Target	Result source queried by the section.
Dimensions	Grouping fields, such as desk, book, portfolio or risk factor group.
Measures	Numeric values shown in the section, such as PnL, VaR, ES or PV.
Filter Body	Optional filter expression for the section.
Having Body	Optional post-aggregation filter.
Display Options	JSON-backed display hints such as formatting or table options.

Common report sections

Section	What to review
Executive Summary	Overall status, key numbers and comments.
PnL Summary	Gross PnL, month-to-date, year-to-date, provision movements and net PnL after provisions.
Value at Risk	VaR, ES and worst or best scenario measures by asset class and total.
Sensitivities	Risk factor exposure, tenor structure, changes and limit usage.
Cashflow Buckets	Future cashflows and present value by maturity bucket.
Provisions	Manual or controlled adjustments and their discounted present values.
Limit Utilization	Exposure versus limit, usage percentage and breach status.

Exposure selections

Exposure selections keep report filters reusable and auditable. They should express business intent, not temporary screen filters. For example, a selection can represent all positions for a desk, a product family, a reporting portfolio or a set of results from a specific data source.

Field	Meaning
Name	Stable selection name.
Description	Why the selection exists and who owns it.
Filter Body	Filter logic applied to the report source.
Applies To Data Sources	Data sources where this selection is meaningful.
Is Active	Whether the selection may be used for new reports.

Subscriptions and recipients

Subscriptions connect reports to delivery behavior. Recipient groups should be maintained centrally so the same group can be reused across desks and books. Direct recipients should be used sparingly for exceptions.

Field	Meaning
Level	Scope level such as group, desk or book.
Group / Desk / Book	Scope values for the subscription.
Recipient Groups	Named recipient groups used for distribution.
Direct Recipients	Additional direct recipients.
Send When	Manual or scheduled sending behavior.
Delivery Format	Link, attachment or other configured delivery style.
Attach PDF	Whether the PDF artifact should be attached when available.
Schedule Cron	Optional schedule expression for automated delivery.

Artifacts and comments

Artifacts are stored report outputs. A report artifact should be treated as a point-in-time representation of the report context, reference date and data available at generation time. Comments capture business explanations and should state whether an issue is a market move, data issue, model limitation, operational exception or manual adjustment.

Result interpretation

Reports combine data from several workflow results. A missing section usually means that the underlying source result was not available for the selected reference date, model or scope. A zero value should not automatically be treated as missing data; check the section status, comments, data quality findings and the underlying simulation state.

Common issues

Issue	Meaning	Possible action
Empty report section	Source data is missing for the selected scope or date.	Check workflow completion and selected model.
Unexpected currency	Reporting currency differs from source currency.	Verify currency selection and FX market data.
Missing PDF artifact	Report view exists but output rendering has not produced an artifact.	Regenerate or check artifact status.
Recipient not included	Subscription uses recipient groups, not ad hoc screen users.	Review recipient group configuration.
Section order looks wrong	Sort order or inactive section configuration may be incorrect.	Review report sections in the definition.
Numbers differ from dashboard	Dashboard and report may use different model, level or reference date filters.	Compare request parameters side by side.

Recommended practice

Keep report definitions stable and version changes through clear descriptions and comments. Use subscriptions for recurring distribution, not one-off reviews. Before distributing a report, verify the reference date, business scope, model, currency, workflow completion state, data quality findings and provision status.

Purpose

The PnL dashboard shows current profit and loss, period movements and explanation drivers for the selected reference date, currency and business level. It is intended for review and triage: start with the headline PnL, compare explained versus unexplained movement, then drill into portfolios and instruments that need attention.

Selectors

Selector	Meaning
Reference Date	Business date used for the displayed results.
Currency	Reporting currency for displayed values.
Dashboard Level	Aggregation level used by the main charts and summary tables: group, book, desk or portfolio.
Top unexplained minimum	Local filter for the Top Unexplained grid. Rows are shown only when abs(Unexplained) is at least this threshold.

The Top Unexplained threshold does not change the dashboard KPIs or charts. It only reduces noise in the Top Unexplained instrument grid.

PnL Widgets

Widget	What to review
Group PnL	Current day PnL and period windows such as week-to-date, month-to-date, quarter-to-date and year-to-date.
Explained	How much of total PnL is covered by explanation drivers, and how much remains unexplained.
IR / FX / EQ / CM	Main market drivers for rates, currency, equity and commodity impacts.
Theta / Gamma / Div / Vol	Carry, non-linear, dividend and volatility effects.
PnL Summary	Period PnL by the selected dashboard level.
PnL Explain Summary	Total, explained and unexplained PnL by the selected dashboard level.

PnL Explain

PnL Explain decomposes total PnL into driver buckets. The main driver buckets are interest-rate, FX, equity, credit-spread, commodity, volatility, theta, gamma, dividends, position-change and new-trade effects. A good explain result should make the unexplained component small relative to total movement and business materiality.

Use the bar charts for driver structure and the summary tables for numeric review. If one driver dominates unexpectedly, check the corresponding market data, instrument population and simulation workflow for the selected date.

Top Unexplained

The Top Unexplained grid lists instruments with the largest absolute unexplained amount. Use it to find individual instruments or portfolios that need follow-up. The grid supports search, column filters and sorting. The Portfolio column filter is the preferred way to narrow the grid to a specific portfolio.

Recommended review flow:

• Set the Dashboard Level to the business level you want to explain, usually desk or portfolio.
• Use the Top unexplained minimum slider to hide immaterial rows.
• Sort by Unexplained or use portfolio and instrument filters.
• Open or investigate the largest rows and compare their driver columns.

Common Issues

Issue	Possible cause	Action
High unexplained PnL	Missing driver, stale market data, instrument change or model limitation.	Check market data, data quality findings and workflow completion.
Empty grid	Threshold too high or no instrument-level explain data for the selected date.	Lower the threshold and verify workflow results.
Numbers differ from reports	Different date, currency, level, model or report section filters.	Compare selectors and report request parameters.
One driver dominates	Concentrated risk factor exposure or incorrect shock/input mapping.	Review the risk factor, instrument set and source market data.

Recommended Practice

Treat unexplained PnL as a triage signal, not automatically as an error. Small unexplained values can be acceptable depending on business materiality and model scope. Large or repeated unexplained values should be reviewed with workflow status, data quality findings and the underlying instrument setup.

Purpose

The VaR Models dashboard reviews value-at-risk, expected shortfall, market risk capital and related diagnostics for the selected reference date, currency, model and business level. Use it to compare current risk, recent movements, model quality and limit utilization before drilling into portfolios, scenarios and factor contributions.

Selectors

Selector	Meaning
Reference Date	Business date used for the displayed results.
Currency	Reporting currency for displayed values.
Model	VaR or stressed VaR model used by KPI cards, charts and tables.
Dashboard Level	Business hierarchy used for the main breakdowns, usually Desk for daily review.

Main Widgets

Widget	What to review
VaR	Current VaR and short window movements.
ES	Expected shortfall and changes versus prior windows.
MRC	Market risk capital, multiplier and VaR/SVaR capital components.
Backtesting	Best/worst calibration and exception context.
Limit	Current utilization, breaches and the most relevant limit rows.
History	Year-to-date VaR and ES movement by model.
Scenario and portfolio tables	Concentrations, ratios and scenario drivers at the selected level.

Review Flow

• Start with the selected model, date and currency.
• Check the KPI cards for direction, magnitude and limit pressure.
• Use Desk level for daily triage, then move to Book or Portfolio when a concentration needs explanation.
• Compare history, best/worst ratios and scenario tables before escalating a movement.

Common Issues

Issue	Possible cause	Action
Empty widgets	Missing aggregation result for the selected model/date.	Verify workflow completion and selected model.
Limit data missing	Limit result not generated or not mapped to the selected hierarchy.	Check limit workflow and hierarchy scope.
Unexpected model differences	Different scenario set, confidence level, holding period or stressed window.	Compare model configuration and selector state.
Large movement	Portfolio change, market data movement or scenario distribution shift.	Review scenario, factor and portfolio breakdowns.

Purpose

The Limits dashboard is the daily control view for next-generation limit monitoring. It shows open and approved limit exceptions, the severity split, maximum utilization and approvals that require attention. The table below the KPIs is the working list for investigation, acknowledgement, escalation, temporary approval and closure.

The dashboard uses generated LimitObservation rows and active LimitBreach cases. Observations are calculated for a reference date and simulation run. Breach cases remain open across dates until they are closed or rejected, so the management dialog shows both the current case state and the observation history.

Selectors

Selector	Meaning
Reference Date	Business date used for observations and history.
Currency	Observation currency, usually the limit currency or aggregation result currency.
Dashboard Level	Business hierarchy level: Group, Book, Desk or Portfolio.
Status	Case status, for example Open, Acknowledged, Escalated, Approved or TemporarilyApproved.
Severity	Manual case severity: Critical, High, Medium or Low.
Category	Limit category derived from the limit definition and source.
Source	Data source/model such as Sensitivity, VaR99, VaR95 or StressScenario.
Owner	Assigned owner of the breach case.

KPI Cards

Card	What it means
Breaches	Group-level exception count above the divider and Book, Desk and Portfolio counts below it.
Severity	Group-level Critical count above the divider and High, Medium and Low counts below it.
Max Utilization	Highest utilization in the filtered exception set, latest maximum, average maximum and rows over 100%.
Approvals	Exceptions with temporary approvals expiring soon and counts by approval outcome.

Exception Handling

Open a row to manage the exception. The management dialog shows the latest utilization, first and last seen dates, observation history, comments and approvals.

Action	Use when
Acknowledge	Risk control has seen the exception and accepts ownership for review.
Escalate	The exception needs management or model owner attention.
Accept	The breach is accepted with a documented reason.
Temp Approve	The breach is temporarily allowed until a valid-until date.
Reject	The requested approval is rejected.
Close	The case is no longer active and is closed with a reason.

Comments can be internal, risk-control or report comments. Visibility controls whether the comment is only operational, visible to management or intended for reporting.

How Limits Are Evaluated

The evaluator loads active LimitDefinition records for the data source and date. It ignores SourceMode = Legacy; New and Shadow limits are evaluated. The active LimitDefinitionVersion supplies the limit value and warning/breach thresholds for the reference date.

For each limit, the evaluator reads matching aggregation rows using:

Field	Requirement
DataSource	Must match the model/source passed by the workflow.
Aggregation	Selects the measure name from the aggregation result values.
AggregationProfile	Defines the result set and dimension key to read.
Reference Date	Must equal the simulation reference date.
SimulationId	Must equal the analyzer run id.

Actual values are evaluated as absolute values. Utilization is abs(actual) / limit value * 100. The observation status is Clean below the warning threshold, Warning from the warning threshold, and Breach from the breach threshold.

Configuring A Limit

Use Analyzer Configuration > Limit Definitions. A complete limit has one definition, at least one active version and optional constraints.

Definition

Field	Guidance
Name	Stable business name. Use names that include measure, scope and level, for example DeltaAbs/ALL/Default/Desk/STD.
DataSource	Source/model evaluated by the workflow, for example Sensitivity, VaR99, VaR95, SVaR99 or StressScenario.
Aggregation	Measure to read from the aggregation result values, for example LIMIT_NG_SENSI_ABS or LIMIT_NG_VAR_IR.
AggregationProfile	Determines result set and dimensions, for example desk, book, portfolio, factor type or risk-factor-group profiles.
LimitLevel	Reporting hierarchy level for dashboard filters and KPI counts.
LimitValue	Current headline value. Keep it aligned with the active version.
WarningThresholdPercent	Usually 80. A warning observation is created when utilization reaches this value.
BreachThresholdPercent	Usually 100. A breach observation creates or updates a breach case.
Unit and Currency	Display and filtering values, commonly EUR.
ValidFrom and ValidTo	Date range for the definition. The evaluator only loads definitions valid on the reference date.
IsActive	Must be enabled for evaluation.
SourceMode	Use New for productive next-gen limits or Shadow for migrated/parallel limits. Legacy is skipped.

Versions

Versions hold the effective limit values. Create a new version when the limit amount or thresholds change. Set ValidFrom and ValidTo so that only one intended version is active for a reference date. If multiple versions are valid, the highest VersionNumber is used.

Keep the definition value and the latest version value in sync. The evaluator uses the active version for calculation.

Constraints

Constraints restrict which aggregation rows are evaluated.

Role	Meaning
EvaluationScope	Narrows the business scope, for example Desk = STD. It also helps group observations into one breach case over time.
PopulationFilter	Narrows the population inside the scope, for example FactorType Contains Vega or FactorType = IrDelta.

Supported operators are Equals, NotEquals, In, NotIn, Contains, GreaterThan, LessThan, GreaterOrEqual and LessOrEqual. For In and NotIn, enter comma-separated values in Value or a JSON string array in ValueListJson.

Dimension names must match the aggregation profile dimensions exactly, for example Desk, Book, Portfolio, FactorType or FactorGroup. If no aggregation row matches the constraints, the evaluator creates a MissingData observation with a diagnostic message.

Configuration Checklist

• Pick the source/model that the workflow calculates.
• Pick the aggregation measure that contains the risk value.
• Pick an aggregation profile whose dimensions contain every planned constraint.
• Set level, currency, unit, active flag and source mode.
• Create an active version with value, warning threshold, breach threshold and validity dates.
• Add EvaluationScope constraints for the business scope.
• Add PopulationFilter constraints for factor/category subsets.
• Run the workflow and check the Limits dashboard for Clean, Warning, Breach, MissingData or EvaluationError observations.

Common Issues

Issue	Possible cause	Action
No exception appears	Utilization is below breach threshold or the case is filtered out by status, level, currency or date.	Check selectors and observation history.
MissingData observation	No aggregation row matched source, result set, dimension key or constraints.	Compare aggregation profile dimensions and constraint names.
EvaluationError observation	The configured measure is not present or the limit value is not positive.	Check aggregation measure and active version value.
Breach appears on a later date	Breach cases keep the latest observation while history contains earlier observations.	Open the row and review the Development tab.
Duplicate-looking rows	Scope or population constraints differ, so cases are not the same control.	Compare constraints and source aggregation dimensions.

Purpose

The Sensitivities dashboard reviews market risk sensitivities by factor type, portfolio, instrument type and limit context. It is used to understand where delta, vega and related exposures are concentrated, how they moved and whether they are close to configured limits.

Selectors

Selector	Meaning
Reference Date	Business date used for the displayed sensitivity results.
Currency	Reporting currency for displayed values.
Dashboard Level	Business hierarchy used for breakdowns, usually Desk for daily review.

Main Widgets

Widget	What to review
EQ, IR, FX, CS, CM	Net, gross and recent movement for each risk class.
Group Limit	Top sensitivity limit utilization and breaches.
Sensitivities by Portfolio	Factor-type distribution across portfolios.
Factor and instrument breakdowns	Concentrations by factor group, instrument type, rating and valuation group.
Instrument detail	Instrument-level sensitivity rows for investigation and filtering.

Review Flow

• Review the KPI row to identify the dominant risk class.
• Use the portfolio and factor charts to find concentrations.
• Check limit utilization when a risk class is large or moving quickly.
• Use instrument detail filters for the largest portfolio, factor type or instrument type.

Common Issues

Issue	Possible cause	Action
Empty dashboard	Sensitivity workflow has not produced results for the date.	Verify workflow completion and data provider status.
Limit widget empty	Limit results are missing or not mapped to the sensitivity model.	Check limit configuration and result generation.
Large gross but small net	Offsetting positions across instruments or portfolios.	Review gross exposure and instrument-level rows.
Unexpected factor type	Instrument mapping, market data curve or valuation group changed.	Check instrument setup and factor assignment.

Purpose

Provisions represent controlled business adjustments that are included in reporting and PnL explanations. They can capture reserves, valuation adjustments, operational adjustments, release amounts or other documented corrections. Provisions should be transparent, owned, dated and reviewable.

Main concepts

Concept	Meaning
Provision	Header record describing scope, type, amount, status, owner and reason.
Provision Entry	Payment-date level line with future value, discount factor and present value.
Scope Level	Business level where the provision applies: group, desk, book, portfolio or instrument.
Provision Type	Business classification such as valuation adjustment, reserve, release or other adjustment.
Status	Lifecycle state such as Draft, Approved or Released.
Discount Curve	Curve used to discount future provision entries.
Release Reason	Explanation when a provision is released or reduced.

Typical workflow

• Identify the business reason for the provision.
• Select the reference date and the business scope.
• Enter the provision type, currency, amount and owner.
• Add one or more provision entries when the amount has payment-date structure.
• Validate the discount curve, day count and discount point type.
• Review the present value and day-to-day change.
• Approve or release the provision according to governance.
• Check the report framework to confirm the provision is visible in PnL and provision sections.

Provision header fields

Field	Meaning
Reference Date	Date for which the provision is valid in reporting.
Scope Level	Level where the provision applies.
Group / Desk / Book / Portfolio / Instrument	Business keys defining the exact scope.
Currency	Currency of the provision amount.
Provision Type	Business classification.
Amount	Current provision amount.
Previous Amount	Prior amount used for change analysis.
Change DtD	Day-to-day movement.
Discount Curve	Curve used for present value calculation.
Day Counter	Day-count convention used for discounting.
Discount Point Type	Discount factor or other configured discount interpretation.
Reason	Business reason for creating the provision.
Owner	Person or team responsible for review.
Effective From / To	Validity window where applicable.
Status	Draft, approved, released or other configured state.
Comment	Additional explanation for reviewers.

Provision entries

Provision entries break the provision into dated future values. They allow the report to show maturity buckets and discounted present values rather than a single flat amount.

Field	Meaning
Payment Date	Date of the provision cashflow or adjustment.
Future Value	Undiscounted amount at the payment date.
Discount Factor	Discount factor from the selected curve.
Present Value	Discounted value included in reporting.
Comment	Entry-level explanation.

The basic present value relation is:

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

For a provision with several entries:

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

PnL impact

Provision movements are shown separately from gross PnL so reviewers can distinguish market movement from business adjustments. A typical report uses:

$$ NetPnL = GrossPnL + ProvisionIncrease - ProvisionRelease $$

The exact sign convention should be checked in the report section. A provision increase normally reduces economic result, while a release normally improves it, but reports may present increases and releases as separate signed columns.

Status interpretation

Status	Meaning	User action
Draft	Entered but not approved for reporting.	Review inputs and supporting reason.
Approved	Accepted for the selected reference date and scope.	Confirm it appears in the relevant report.
Released	No longer active or reduced for a documented reason.	Check release reason and release date.
Rejected	Not accepted for reporting.	Correct or remove from operational report scope.

Data quality checks

Check	Why it matters
Scope completeness	Missing desk, book or portfolio can place the provision in the wrong report.
Currency consistency	A wrong currency can distort net PnL after FX conversion.
Discount curve availability	Missing curve data prevents reliable present value calculation.
Payment date validity	Past or inconsistent payment dates can create misleading buckets.
Amount and sign	Wrong sign can reverse provision increase and release interpretation.
Status governance	Draft provisions should not be treated as final without review.

Common issues

Issue	Meaning	Possible action
Provision missing from report	Scope, status or reference date does not match the report request.	Compare provision keys with report level and date.
Present value is zero	Missing entries, zero discount factor, zero amount or invalid curve setup.	Check entries and market data.
Unexpected DtD change	Previous amount differs from the current amount or release was applied.	Review Previous Amount, Change DtD and release details.
Wrong report bucket	Payment dates or scope keys are incorrect.	Correct entry dates and scope level.
Duplicate-looking provision	Multiple provisions can exist for similar scope but different type, owner or reason.	Consolidate only after business review.

Recommended practice

Use clear reasons and owners for every provision. Keep payment-date entries aligned with the expected economic timing. Do not use provisions to hide missing market data or failed valuation workflows; document those as data quality or workflow issues. Before distributing a report, reconcile gross PnL, provision movements and net PnL after provisions.