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

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

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

The System area helps operators and business users understand whether workflow processing is healthy. It separates three different views:

Page	Purpose
System Overview	Live worker and message-broker health.
Statistics	Historical workflow-run size, duration and result metadata.
Workflow Queue	Workflow-batch admission state: queued, running, failed and recently completed batches.

The most important distinction is that the Message Broker table shows RabbitMQ queues, while the Workflow Queue page shows the portal's workflow admission queue. They are related, but they are not the same queue.

System Overview

System Overview is a live view fed by PushNotifier. It receives updates about every two seconds.

The header shows:

Field	Meaning
Workers	Number of workers currently known to PushNotifier.
Idle	Workers reporting that they are not processing a message.
Busy	Workers reporting active work.
Broker	Whether the RabbitMQ management endpoint is reachable.
Push connection	SignalR connection state between portal and PushNotifier.

If the Push connection is disconnected, the screen may show old data. If the broker is offline, worker heartbeats may still be visible but broker queue sizes cannot be read.

Worker state table

Workers publish heartbeat events through the priority/control channel. The worker heartbeat interval is two seconds.

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

Worker states

State	Meaning	Typical interpretation
Idle	Worker is alive and not processing work.	Available for new messages.
Busy	Worker is alive and has current work.	Processing one message.
Stale	No heartbeat was received for more than the stale threshold.	Worker may have stopped, restarted or lost connectivity.

The stale threshold is short, currently around 15 seconds. The Forget stale workers action removes stale entries from the in-memory overview registry. It does not stop or restart a worker.

Core Load

Core Load is intentionally not host-normalized CPU. Workers process a single message at a time, so the UI reports single-core-equivalent utilization.

That means:

Display	Meaning
Near 0%	Worker is mostly idle or waiting.
40-70%	Worker is doing meaningful CPU work but not fully saturating a core.
80-100%	Worker is close to saturating its processing thread.

On a many-core host, a single busy worker might look like only a few percent in system tools. In this table it can correctly appear near 100% because the worker itself is single-threaded.

The line chart shows the last 30 load samples. With a two-second heartbeat, this is roughly the last minute.

Message Broker table

This table reads RabbitMQ queue state through the RabbitMQ management API.

Column	Meaning
Queue	RabbitMQ queue name.
State	Broker-reported queue state.
Ready	Messages waiting in the queue.
Unacked	Messages delivered to a consumer but not acknowledged yet.
Total	Total broker-reported messages. Usually ready plus unacked.
Last Minute	Queue-size sparkline for the last 30 broker samples.
Consumers	Number of active queue consumers.
Actions	Operational action such as purging ready messages.

Reading broker queue values

Pattern	Meaning	Possible action
Ready grows, consumers are zero	No service is consuming the queue.	Check whether the service or worker container is running.
Ready grows, consumers exist	Consumers cannot keep up or are blocked.	Check worker state, logs and current work.
Unacked remains high	Messages were delivered but not acknowledged.	Check whether consumers are stuck or slow.
Total spikes and then falls	Workload burst was processed.	Usually normal.
Queue is missing	Queue has not been declared or broker monitor cannot read it.	Check service startup and broker configuration.

The Last Minute chart is colored green when the queue is empty and warning-colored when messages are present.

Purging broker queues

The purge action removes ready messages from a monitored queue. It should be used carefully.

Purge does not normally remove messages already delivered to consumers as unacknowledged. If work is already in progress, the relevant worker or service may still complete or fail it.

Do not purge a queue just because messages are visible. First decide whether the messages are stale, duplicate or intentionally abandoned.

Statistics

The Statistics page shows historical workflow-run records from PushNotifier. It loads the latest workflow run statistics and refreshes after workflow-state updates.

Cards:

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

The model filter narrows the list to one model, such as VaR95, Hybrid95, Valuation or another workflow model.

Statistics table

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

The details panel shows the simulation id, currency, portfolio count, aggregation flag, measure type, finish time and compact/raw statistics JSON.

How to use Statistics

Use Statistics when answering questions such as:

Question	Where to look
Did the latest VaR run finish?	Status and Started columns.
Why was this run slower than usual?	Instruments, Scenarios, Dimensions and Estimated Observations.
Which simulation id should I inspect?	Details panel and copy button.
Was aggregation requested?	Details panel.

Statistics is not the best place to diagnose live stuck work. Use System Overview and Workflow Queue for that.

Workflow Queue

Workflow Queue shows the workflow admission queue managed by PushNotifier. This queue controls which workflow batch is allowed to run.

It is not the RabbitMQ broker queue.

The admission queue exists to avoid uncontrolled overlapping workflow batches. Queued and running batches can block subsequent batches until they become terminal.

Cards:

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

Admission Queue table

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

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

Unblock Queue

Unblock is an operator action for abandoned admission batches.

Current batch state	Unblock 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 use unblock when the batch is known to be abandoned. It changes persisted workflow state.

Active schedules

Active schedules show configured scheduled workflow triggers.

Column	Meaning
Name	Schedule name.
Cron	Cron expression.
Time Zone	Time zone used to evaluate the schedule.
Last Run	Last trigger time.
Last Success	Last successful scheduled run.
Last Failure	Last failed scheduled run and error.

Recent scheduled runs

Recent scheduled runs show the latest schedule-triggered workflow batches. Non-completed runs and completed runs from the recent time window are included.

Column	Meaning
Status	Scheduled run status.
Schedule	Schedule name.
Triggered	Trigger time.
Source	Manual or scheduler source.
COB	Reference date.
Finished	Finish time.
Batch	Batch id that entered admission.

Troubleshooting guide

Symptom	Likely cause	First check
Dashboard shows no new results	Workflow did not finish or aggregation did not run.	Statistics and Workflow Queue.
Workflow Queue has one Running batch for a long time	Batch may still be active or abandoned.	Open child workflows, then check workers and logs.
RabbitMQ queue Ready count grows	Consumers are unavailable or slower than producers.	Broker consumers and worker states.
Unacked stays high	Consumer has received work but has not acknowledged it.	Worker current work and service logs.
Workers disappear or turn stale	Heartbeats stopped.	Container status and PushNotifier connectivity.
Core Load is high but no progress	Worker may be CPU-bound or stuck in calculation.	Current Work, logs and batch progress.

Recommended practice

Use the pages in this order:

• System Overview: confirm workers and broker are alive.
• Workflow Queue: confirm no old batch is blocking admission.
• Statistics: confirm the run completed and inspect run scale.
• Domain dashboard: inspect business results and evidence.

This sequence separates infrastructure health, workflow admission, historical run facts and business interpretation.

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

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

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.

Purpose

Readiness status summarizes whether a model, instrument or validation item can be used for the stated scope.

Status values

Status	Meaning
Green	Checks passed for the documented scope.
Amber	Evidence exists but is partial, restricted or has important limitations.
Red	A critical check failed.
Unknown	No executable evidence exists or the item is inventory-only.

Recommended practice

Always read limitations before using a Green or Amber result. Status does not replace scope, evidence and model-owner review.

Purpose

Evidence records expected values, actual values, tolerances and references used to support a validation status.

Important fields

Field	Meaning
Expected	Benchmark or reference value.
Actual	Value generated by the system.
Tolerance	Maximum accepted difference.
Evidence reference	Link to detailed generated evidence.
Dataset reference	Input data used for the validation check.

Common issues

Issue	Meaning	Possible action
Difference inside tolerance	Result is acceptable for that check.	Review scope and limitation.
Difference outside tolerance	Validation failed or requires investigation.	Compare input data and benchmark assumptions.
Missing evidence	No check was generated.	Treat readiness as Unknown for that scope.

Purpose

Model validation focuses on the method that produced a result: its assumptions, inputs, outputs, benchmarks, evidence and limitations.

Important fields

Field	Meaning
Model ID	Stable identifier for the model or method.
Family	Pricing, VaR, ES, FRTB, Volatility or Data Quality grouping.
Validation method	How the model was checked.
Benchmark source	Reference used to compare actual results.
DQ checks	Data Quality checks that apply to the model pack or its validation inputs.
Limitation	Scope restriction that remains visible even when evidence passes.

Data Quality connection

Model Validation answers whether a method is ready for the documented scope. Data Quality answers whether the inputs used by that method are complete and reliable enough to trust the evidence.

The Model Validation dashboard can therefore show DQ links beside model pack actions such as Shocks, Scenario, Portfolio, Results and Status. These links should be used as part of the validation workflow, not only after a failure.

Examples:

Model pack	DQ evidence can explain
VaR / ES	Missing scenario inputs, incomplete shock vectors, stale reference data or inconsistent portfolio scenario vectors.
DCF / Pricing	Missing cashflow inputs, curve mappings, date conventions or static-data issues.
Sensitivities	Missing base or shifted prices, inconsistent bump setup or unavailable risk factors.
FRTB	Missing sensitivity inputs, bucket mappings, risk-class inputs or incomplete test portfolio data.
Volatility	Missing surface nodes, invalid vol quotes, unsupported interpolation points or convention mismatches.

NMD validation

Non-maturity deposits connect instrument validation, IRRBB methodology, sensitivities and market-data validation. A Green status is meaningful only when behavioural assumptions and market data match the tested scope.

Check area	What to read
Segment and core balance	Segment cap, stable balance ratio and calculated core share must be consistent.
Runoff and WAL	Cashflow profile and weighted average maturity must remain within the cap.
Floor component	With IncludeFloorValue, the normal-volatility surface must exist and match FloorStrike.
Sensitivities	PV01 comes from curve exposure; IrVega comes from the NMD floor and must not be confused with IR Delta.
VaR	Historical scenarios need the same mapped curve and volatility factors used by valuation.

Typical Red or Amber causes include missing surface nodes, missing historical vol quotes, an overly long runoff profile, exceeded core-balance cap or a sensitivity run using a different strike from valuation.

How to use the link

• Select the model pack.
• Open the action column that failed or looks suspicious.
• Open the DQ view or DQ reference.
• Review Critical findings first.
• Compare the affected input with the model evidence.
• Decide whether the issue is data readiness, model readiness or benchmark/tolerance disagreement.

If DQ is incomplete or not applicable for a pack, the dashboard may show a placeholder. In that case, do not infer that data quality passed; it only means that no dedicated DQ evidence is currently attached to that pack.

Accepted DQ exceptions

Some model packs can show DQ results with status Accepted. This means an active Data Quality exception rule matched the finding. The most relevant current case is RfValue, where missing risk-factor values in non-zero sensitivity vector entries can be accepted when the configured rule matches the instrument or risk-factor facts.

Accepted DQ should be read as a documented exception:

Review point	What to check
Rule name	Does the name describe the exact exception?
Priority	Was the intended rule selected when multiple exception rules could match? Lower priority numbers are applied first.
Owner	Is a person or team accountable for the exception?
Reason	Is the business or model-validation reason clear?
Validity	Is ValidTo set where the exception should expire?
Scope	Are the rule conditions narrow enough to avoid masking unrelated DQ issues?

The applied rule is stored in DQ result metadata as AcceptedByExceptionRule. Accepted findings are counted separately from Pass and Fail, so a Green model with Accepted DQ still needs limitation review.

Recommended practice

Use model validation when the question is "which method produced this result and how was it checked". Use instrument validation when the question is "can this instrument be used for this capability".

For review meetings, document both the model status and the DQ status. A Green model with unresolved Critical DQ findings should not be interpreted as ready for unrestricted use.

Purpose

Market data completeness checks whether the required inputs exist for a valuation or risk run.

Required data

Input	Typical use
Discount curve	Present value and cashflow discounting.
Projection curve	Floating coupons and forward rates.
FX rate	Reporting currency conversion.
Volatility surface	Option valuation and vega.
Fixings	Historical index-linked cashflows.

Recommended practice

Check completeness by valuation date and product type. A run can fail even when most market data is present if one required fixing, curve node or volatility point is missing.

Purpose

Instrument static data determines which model is selected and which market data is required.

Important fields

Field	Meaning
Instrument type	Product classification for model selection.
Currency	Determines discounting and reporting behavior.
Index	Floating-rate or inflation index family.
Maturity	End date used for eligibility and cashflow generation.
Quantity	Position amount applied to unit valuation.

Common issues

Issue	Meaning	Possible action
Missing maturity	Cashflows cannot be generated reliably.	Correct instrument static data.
Negative or extreme quantity	Results can look implausibly large.	Confirm position size and sign.
Missing curve mapping	Model cannot resolve required curve.	Update market-data mapping.

Purpose

Data Quality findings explain why a position, instrument or market data item may be unsafe for calculation.

Severity

Severity	Meaning
Info	Useful context; not usually blocking.
Warning	Calculation may proceed but should be reviewed.
Critical	Calculation should not be trusted or may fail.

Links from validation dashboards

Data Quality findings can be opened directly from Instrument Validation and Model Validation. The link is intended to shorten the investigation path when a validation item is Amber, Red, Unknown or unexpectedly empty.

Use linked DQ evidence to answer:

• Did the position have complete static data?
• Were all required market data inputs available?
• Were curve, volatility, FX or scenario references mapped correctly?
• Was the validation portfolio complete for the selected model pack?
• Did a DQ finding affect only one instrument, one model input or the whole validation pack?

Instrument versus model context

Link source	Typical DQ scope
Instrument Matrix cell	Product static data, required quotes, curve mappings and capability-specific checks for the selected instrument/capability.
Model Matrix row	Model pack inputs, benchmark datasets, scenario vectors, validation portfolio and model-specific assumptions.
Validation evidence detail	Dataset or evidence item used by a specific validation check.

The same underlying issue may appear in more than one place. For example, a missing curve quote can affect bond pricing, PV01, scenario generation and VaR. In that situation, fix the data cause once and then regenerate the affected validation packs.

Common DQ-linked situations

Finding	Effect on validation	Possible action
Missing market quote	Pricing, sensitivity or scenario validation may be missing or unreliable.	Add or correct the quote and regenerate evidence.
Missing curve mapping	Instrument can exist but cannot be valued consistently.	Check curve assignment and valuation date.
Stale quote	Validation may run with outdated inputs.	Confirm whether stale data is acceptable for the test scope.
Invalid static data	Instrument-level validation can fail before model evidence is meaningful.	Correct maturity, coupon, notional, index, currency or convention data.
Incomplete scenario vector	VaR, ES or hybrid results may be unavailable or not comparable.	Check scenario input coverage before reviewing quantile results.

DQ exception rules

Data Quality Profiles now include an Exceptions tab for controlled exception rules. Use it for known, documented cases where a DQ finding is understood and temporarily accepted, not for hiding unresolved data problems.

Open the configuration at Analyzer / Config / Data Quality Profiles or /app/analyzer/config/dataqualityprofiles, select the relevant profile, then open Exceptions.

Field	Meaning
Name	Short, unique rule name within the selected Data Quality Profile.
CheckType	DQ check to which the exception applies. Current operational use is focused on RfValue.
Priority	Deterministic match order. Lower numbers are evaluated first; default priority is 100.
IsActive	Enables or disables the rule without deleting it.
Owner	Person or team accountable for the exception.
Reason	Business or model-validation reason why the exception is accepted.
Valid From / Valid To	Date window in which the exception may apply. Open-ended rules should be avoided unless deliberately permanent.
Condition JSON	Match conditions evaluated against DQ facts such as instrument, book, portfolio, currency, risk factor, factor type, tenor and values.

For RfValue, the check inspects sensitivity vectors. If a sensitivity entry has a non-zero Value but an empty or zero RfValue, the result normally fails. If an active exception rule matches all configured conditions, the result is reported as Accepted.

Accepted means the finding is documented and allowed under the rule. It does not mean the original data is clean.

When more than one active rule can match the same finding, the rule with the lowest Priority is applied. If priorities are equal, the system uses rule name and rule id as deterministic tie-breakers. The matched rule is written into the DQ result metadata as AcceptedByExceptionRule, including rule id, name, owner, reason, priority and validity dates.

An Accepted result is not counted as Pass or Fail in the DQ run summary. It is counted separately as accepted evidence so reviewers can distinguish clean data from documented exceptions.

Exception condition operators

Exception conditions support simple field/operator/value matching.

Operator	Typical use
Equals	Match an exact instrument, book, currency, factor type or tenor.
NotEquals	Exclude a known value.
Contains	Match part of a risk-factor name.
StartsWith	Match a risk-factor family, for example a dividend shift prefix.
Regex	Match a controlled naming pattern.
IsZero	Match numeric values close to zero.
IsNullOrEmpty	Match missing text fields.

Example rule intent:

Rule part	Example
CheckType	RfValue
Owner	Model Validation
Reason	Known dividend-shift risk factor does not carry an RF value in the current sensitivity vector format.
Conditions	RiskFactor starts with EQU/QIA_FR/DIV.Shift. and FactorType equals IrDelta.
Expected result	Matching missing RF values are shown as Accepted; non-matching missing RF values still fail.

Governance expectations

Practice	Reason
Keep exception names specific.	Reviewers must understand what was accepted without opening every detail.
Set ValidTo whenever possible.	Exceptions should expire when data, model mapping or vector format is fixed.
Use priority deliberately.	Keep normal exceptions at 100; use lower numbers only for narrower or more authoritative rules.
Keep conditions narrow.	Broad exceptions can mask unrelated DQ issues.
Review accepted findings with validation evidence.	Accepted DQ can still restrict model or instrument readiness.
Do not use exceptions for missing market data that should exist.	Missing quotes, curves, vols or fixings should usually be corrected, not accepted.

Recommended practice

Start with Critical findings, then review repeated Warnings. When a result is missing, compare failed instruments with Data Quality findings before rerunning.

Do not treat the absence of a DQ link as proof that data quality passed. It can also mean that no DQ evidence is currently attached to that pack or workflow.

Highlights

Area	Change
Help	In-portal bilingual help drawer with protected Markdown content.
Validation	Dashboard-oriented evidence and readiness guidance.
Data Quality	Additional user-facing descriptions for common findings.
Instruments	Initial product notes for rates, options and inflation.

Recent changes

Area	Change
Data Quality exceptions	Data Quality Profiles now expose an Exceptions tab. Exception rules can mark matching findings as Accepted, with owner, reason, validity window and condition configuration.
Exception priority	DQ exception rules now have deterministic priority. Lower priority numbers match first; applied rules are recorded in AcceptedByExceptionRule metadata.
Dashboard queries	Analyzer dashboard paging now applies a deterministic default sort when the UI does not send an explicit sort column.
RfValue check	Missing risk-factor values in non-zero sensitivity vector entries are now evaluated against exception rules before failing the DQ check.
Validation dashboards	Help text now distinguishes Accepted DQ from clean Pass status and explains how Accepted findings affect model and instrument readiness interpretation.
Model Validation	Model Validation help now covers DQ links, accepted DQ exceptions and review points for exception governance.
Instrument documentation	Implemented instrument samples are displayed as centered field/value tables instead of raw JSON, including rates, equity, FX, commodity, inflation and exotic option samples.
Help layout	Markdown tables in the help drawer now render as compact centered documentation tables where possible.

Recommended practice

Use the help drawer while staying on the current screen. Content is intentionally concise and will be expanded as workflows mature.

Important limitations

Area	Limitation
Help search	Search is currently client-side over article metadata only.
Methodology	Examples are simplified and do not replace model documentation.
Validation	Status applies only to the generated evidence scope.
Inflation	YoY and zero-coupon conventions must be checked explicitly.

Recommended practice

Treat these notes as operating guidance. For formal model approval, use the model validation evidence and governance process.