Issue verifying default rate tables in SAS IFRS 9

[Musheer1]

Hello everyone,

I am currently working on default rate analysis within the SAS IFRS 9 framework and I am facing an issue reconciling the calculated default rates with the values available in the IFRS 9 data tables.

Specifically, I would like to understand which standard SAS IFRS 9 tables should be checked to validate historical and cohort‑based default rates (e.g., performing population vs. new defaults). At the moment, the default rates I am deriving do not fully align with what is stored or reported in the model outputs.

Could anyone advise on:

• The key IFRS 9 tables used for default rate / PD monitoring
• How default events are typically captured and aggregated in these tables
• Any common pitfalls when validating default rates in SAS IFRS 9

Any guidance or best practices would be highly appreciated.

Thank you in advance.

[cyezer]

Hi Musheer1, thank you for your question and for working with SAS—great to see this level of analysis being discussed in the community!

From your comments, it sounds like you may be performing a historical transition / default rate analysis (e.g., building a transition matrix across reporting periods), rather than reconciling PD model outputs directly.

Within the SAS Allowance for Credit Loss solution (which supports IFRS 9), it’s important to note that default rates are typically not stored as pre-calculated fields in standard tables. Instead, they are derived from changes in credit status across reporting dates (e.g., performing [Stage 1/2] → Stage 3).

To compute these correctly, you generally need to:

• Track the same instruments or counterparties across consecutive reporting dates
• Compare their credit status (e.g., ECL_Stage or default flag) at t‑1 and t

This allows you to derive:

• New defaults: performing → Stage 3
• Survivors: performing → performing
• Cures: Stage 3 → performing

If your calculated rates don’t align with reported values, common pitfalls include:

• Stage vs. default definition mismatch
  Stage 3 is often used as a proxy for default, but this depends on configuration. IFRS 9 staging is driven by Stage Allocation rules, which may vary by entity and internal risk policies.  You can see the applied Stage Allocation rule in the audit report and view the underlying rules in the rules repository.

• Snapshot vs. cohort misalignment
  IFRS 9 outputs are snapshot-based. Transition analysis requires consistent cohort tracking across periods. While period-over-period movements are reflected in Credit Risk Details outputs (see the calculation_config configuration table for more), broader historical analysis is typically performed by querying snapshots (e.g., via SAS Enterprise Guide or SAS Studio).

• Aggregation differences
  Calculations at instrument vs. counterparty level can produce different results.

• Run/cycle inconsistencies
  Mixing data from different runs or combining pre- and post-adjustment results can lead to discrepancies.

The above approach focuses on deriving observed default rates from stage transitions over time.

If instead you are trying to reconcile observed default rates with PD model outputs, it’s important to note that these are fundamentally different measures and are not expected to match directly:

• PDs are forward-looking, model-based, and often scenario-weighted
• Observed default rates are backward-looking and based on realized events (e.g., Stage 3 or a default flag)

To compare them meaningfully, you need alignment on:

• Time horizon (e.g., 12-month PD vs. observed 12-month default rate)
• Definition of default (Stage 3 vs. regulatory default flag)
• Segmentation / population

Otherwise, discrepancies are expected and not necessarily a data issue. In practice, what often appears to be a table reconciliation problem is actually a difference in definitions (transition-based vs. model-based measures).