Intermediate Schemas¶

This page documents the schemas for intermediate data structures produced during pipeline execution. Each schema represents the state of exposure data after a specific pipeline stage.

Why these schemas matter: Column names accumulate through the pipeline — each stage adds columns to the exposure records rather than replacing them. Understanding what each stage contributes is essential for debugging calculation results and writing correct joins.

Source of truth: All schemas are defined in src/rwa_calc/data/schemas.py. Column names throughout the codebase use _reference suffixes (never _id).

Raw Exposure Schema¶

After the loader unifies facilities, loans, and contingents into a single exposure stream. Each record gets an exposure_reference synthesised from the original entity key:

• Loans: loan_reference → exposure_reference
• Contingents: contingent_reference → exposure_reference
• Facility undrawn: facility_reference + "_UNDRAWN" → exposure_reference

Source: RAW_EXPOSURE_SCHEMA in data/schemas.py, HierarchyResolver._unify_exposures() in engine/hierarchy.py

Resolved Hierarchy Schema¶

After hierarchy resolution, exposures gain counterparty hierarchy, facility hierarchy, rating inheritance, and lending group columns. This is the most column-rich intermediate stage, adding 14+ columns to each exposure record.

Source: RESOLVED_HIERARCHY_SCHEMA in data/schemas.py, HierarchyResolver.resolve() in engine/hierarchy.py

Counterparty hierarchy columns¶

Rating inheritance columns¶

Per-type rating columns¶

The hierarchy resolver resolves internal and external ratings independently via _build_rating_inheritance_lazy(). Each rating type is inherited separately (own → parent → ultimate parent), producing per-type columns:

Derived convenience columns:

Facility hierarchy columns¶

Lending group columns¶

Classified Exposure Schema¶

After classification, each exposure has a regulatory exposure class, approach assignment, and entity flags. The classifier joins counterparty attributes (prefixed cp_*) and derives classification in five phases.

Source: CLASSIFIED_EXPOSURE_SCHEMA in data/schemas.py, ExposureClassifier.classify() in engine/classifier.py

Valid exposure_class values:

• central_govt_central_bank
• institution
• corporate
• corporate_sme
• retail_mortgage
• retail_qrre
• retail_other
• specialised_lending
• equity
• defaulted
• pse
• mdb
• rgla
• other

Valid approach_applied values:

• standardised — Standardised Approach
• foundation_irb — Foundation IRB
• advanced_irb — Advanced IRB
• slotting — Slotting Approach

CRM Adjusted Schema¶

After CRM processing, exposures include the full EAD waterfall: provisions → CCF → collateral → guarantees → final EAD. The CRM processor also determines LGD values (supervisory for F-IRB, modelled for A-IRB with optional floors).

Source: CRM_ADJUSTED_SCHEMA in data/schemas.py, CRMProcessor.apply_crm() in engine/crm/processor.py

EAD calculation columns¶

Collateral impact columns¶

Guarantee impact columns¶

Final EAD and LGD columns¶

Pre/Post CRM columns (regulatory reporting)¶

These columns support COREP dual-view reporting — pre-CRM shows the original borrower exposure, post-CRM shows the split between borrower (unguaranteed) and guarantor (guaranteed).

Source: CRM_PRE_POST_COLUMNS in data/schemas.py

Specialised Lending Schema¶

For slotting approach exposures. The slotting category and type are determined during classification based on counterparty and product attributes.

Source: SLOTTING_RESULT_SCHEMA in data/schemas.py, SlottingCalculator in engine/slotting/

Valid sl_type values:

• project_finance
• object_finance
• commodities_finance
• ipre — Income-producing real estate
• hvcre — High volatility CRE

Valid slotting_category values:

• strong
• good
• satisfactory
• weak
• default

Transformation Examples¶

Hierarchy Resolution¶

import polars as pl

# Input: counterparties with parent relationships
counterparties = pl.DataFrame({
    "counterparty_reference": ["C001", "C002"],
    "entity_type": ["corporate", "corporate"],
})

# Org mappings define the hierarchy
org_mappings = pl.DataFrame({
    "parent_counterparty_reference": ["C001"],
    "child_counterparty_reference": ["C002"],
})

# After resolution, hierarchy columns are added to exposures
resolved_exposure = {
    "exposure_reference": "L001",
    "counterparty_reference": "C002",
    "counterparty_has_parent": True,
    "parent_counterparty_reference": "C001",
    "ultimate_parent_reference": "C001",
    "counterparty_hierarchy_depth": 1,
    "rating_inherited": True,
    "rating_source_counterparty": "C001",
    "rating_inheritance_reason": "parent_rating",
}

Classification¶

# After classification, exposures get regulatory class and approach
classified = {
    "exposure_reference": "L001",
    "counterparty_reference": "C002",
    "exposure_class": "CORPORATE_SME",  # Turnover < EUR 50m
    "exposure_class_reason": "corporate with turnover < 50m EUR",
    "approach_applied": "SA",
    "approach_permitted": "SA",
    "is_sme": True,
}

CRM Application¶

# After CRM, exposures have the full EAD waterfall
crm_adjusted = {
    "exposure_reference": "L001",
    "drawn_amount": 10_000_000,
    "ccf_applied": 0.5,
    "converted_undrawn": 2_500_000,
    "gross_ead": 12_500_000,
    "collateral_gross_value": 8_000_000,
    "collateral_haircut_applied": 0.02,  # 2% for 1-5yr govt bond
    "collateral_adjusted_value": 7_840_000,
    "ead_after_collateral": 4_660_000,
    "final_ead": 4_660_000,
}

Next Steps¶

• Output Schemas
• Regulatory Tables
• Pipeline Architecture