SQL
AuraScore 83/100

Basel III Capital Calculation Query Migration Brief

Communicate dialect refactoring and numerical parity validation for regulatory risk views.

Deploy this template when migrating complex capital adequacy calculations between relational database platforms. It generates an engineering verification email confirming mathematical parity and query conversion integrity.

Template

Role: Principal Risk Data Architect with deep expertise in quantitative regulatory reporting pipelines.

Context

  • Banking entity: {{banking_group}}
  • Legacy database platform: {{source_rdbms}}
  • Destination platform: {{target_cloud_warehouse}}
  • Regulatory framework: {{regulatory_framework}}
  • Allowed variance threshold: {{discrepancy_threshold_bps}}
  • Impacted models: {{impacted_risk_models}}

Task

Compose an engineering status and reconciliation email to the Chief Risk Officer detailing mathematical validation findings, syntax translation fixes, and performance benchmarks for migrated risk-weighted asset SQL views.

Method

  1. Review dialect differences between {{source_rdbms}} and {{target_cloud_warehouse}} concerning window functions, floating-point rounding, and NULL handling.
  2. Trace calculations across {{impacted_risk_models}} to verify alignment with {{regulatory_framework}} formulas.
  3. Execute automated reconciliation queries comparing row-level variance against {{discrepancy_threshold_bps}}.
  4. Isolate root causes for numerical divergence such as distinct integer division rules or aggregation ordering.
  5. Optimize materialized view definitions and clustering keys in {{target_cloud_warehouse}} for daily risk runs.
  6. Formulate fallback rollbacks and automated reconciliation assertions for the go-live window at {{banking_group}}.
  7. Outline regulatory audit sign-off criteria for capital adequacy validation teams.

Constraints

  • MUST structure output as an executive-ready technical email.
  • MUST NOT tolerate unexplained variance exceeding {{discrepancy_threshold_bps}}.
  • Explanations MUST clearly separate architectural performance gains from numerical reconciliation checks.
  • Mathematical reconciliation methods MUST be reproducible by external bank auditors.
  • Total email length must not exceed 650 words.

Output format

Email format structured in sequential order:

  • Subject Line: Formatted as [MIGRATION STATUS] - {{regulatory_framework}} SQL Parity - {{banking_group}}
  • Section 1: Executive Status & Parity Scorecard
  • Section 2: Dialect Refactoring & Precision Corrections
  • Section 3: Performance Benchmarks (Latency & Cost Delta)
  • Section 4: Audit Sign-off Signposts & Next Steps

Self-review

  • Ensure the variance calculation logic conforms strictly to {{discrepancy_threshold_bps}}.
  • Check that all referenced SQL translation mechanics match {{target_cloud_warehouse}} syntax.
  • Validate that every input variable is explicitly integrated within the email body.
AuraScore breakdown
83/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.

Robustness5/5 · Strong

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-sql
financial-services
sql
basel-iii
data-migration