General analytics
AuraScore 81/100

Market Risk Model Validation Data Readiness Checklist

Audit data integrity, market feeds, and pipeline completeness prior to regulatory quantitative risk model validation.

Use this prompt when preparing financial market risk engines for regulatory audits, backtesting cycles, or internal model approvals. It ensures all underlying market feeds, asset classes, and pipeline transformations pass rigorous scrutiny.

Template

Role: Principal Quantitative Data Architect with 15+ years of experience in Basel regulatory compliance and market risk stress-testing architectures.

Context

  • Regulatory Framework: {{regulatory_mandate}}
  • Target Risk Methodology: {{risk_framework_type}}
  • Scope of Financial Instruments: {{financial_asset_classes}}
  • Ingestion Source Platforms: {{data_source_systems}}
  • Historical Time Horizon: {{historical_lookback_period}}
  • Cadence of Model Validation: {{validation_frequency}}

Task

Produce an exhaustive, pre-validation data readiness checklist designed to audit, verify, and document data pipelines feeding market risk models ahead of formal regulatory review, ensuring zero unmitigated pipeline failures or unverified data transformations.

Method

  1. Inspect upstream ingestion feeds from {{data_source_systems}} for missing trade dates, price holidays, and stale timestamps across {{historical_lookback_period}}.
  2. Detail reconciliation checkpoints comparing front-office trade capture pricing against middle-office risk database valuations for {{financial_asset_classes}}.
  3. Formulate sanity checks on curve construction, volatility surface interpolation, and corporate action adjustments tailored to {{risk_framework_type}}.
  4. Define schema enforcement and type validation rules for trade lifecycle state changes, including amendments, novations, and cancellations.
  5. Design stress data coverage checks ensuring past extreme market shock windows are fully populated without interpolation bias.
  6. Establish lineage documentation gates linking raw ticks to calculated factor sensitivities according to {{regulatory_mandate}}.
  7. Structure sign-off criteria for anomaly resolution, out-of-bounds tolerance thresholds, and rerun procedures on a {{validation_frequency}} basis.

Constraints

  • MUST format every deliverable item as a testable, actionable checklist item with an explicit acceptance condition.
  • MUST NOT include subjective criteria such as "check if data looks reasonable"; specify exact statistical or boundary thresholds.
  • All items must directly evaluate data feed integrity for {{financial_asset_classes}}.
  • Prioritize audit defensibility required under {{regulatory_mandate}}.

Output format

Provide a structured checklist organized into the following four markdown sections:

  1. Ingestion & Time-Series Completeness Checks (5-6 items)
  2. Valuation & Curve Integrity Verification (5-6 items)
  3. Lineage & Regulatory Traceability Gates (4-5 items)
  4. Failover, Reconciliation & Sign-Off Criteria (4-5 items) Each item must include: [ ] Item Description | Verification Procedure | Pass/Fail Metric | Responsible Owner.

Self-review

  • Did I incorporate all asset classes specified in {{financial_asset_classes}}?
  • Are the validation rules aligned directly with {{regulatory_mandate}} expectations?
  • Is every checklist row accompanied by a clear, numeric or binary Pass/Fail metric?
AuraScore breakdown
81/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering12/12 · Strong

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

data-analytics
data-general
financial-services
risk-analytics
market-risk
model-validation