From R-Based IFRS 9 ECL Calculation to an AI-Assisted Provisioning Engine

A monthly provision can be computationally automated and operationally manual at the same time.

R can calculate thousands or millions of exposures efficiently, yet analysts may still prepare and validate inputs, run scripts, diagnose failures, export results, compare periods, investigate stage migration, reconcile balances and write commentary by hand. The mathematical kernel is automated; the surrounding analytical workflow is not.

The evolution is therefore not R → LLM. It is deterministic calculation → controlled orchestration → analytical intelligence. This article uses only newly written Entimema code and entirely hypothetical data; it is an engineering pattern, not accounting advice or a complete IFRS 9 methodology.

Start with an explicit computational contract

PD represents probability of default over the relevant interval; LGD the proportion lost conditional on default; EAD the expected exposure at default; and DF the discount factor derived using the applicable effective-interest basis. The time horizon determines which periods enter. With scenarios:

Each scenario weight wₛ expresses the approved weighting of a coherent forward-looking scenario and must satisfy Σₛwₛ = 1. In practice, teams must be precise about marginal versus cumulative PD, survival, recoveries, prepayment and discount timing; the multiplication below is only a transparent kernel.

portfolio$ecl <- with(
  portfolio,
  pd * lgd * ead * discount_factor
)

Separate the stage decision from the loss calculation

A Stage Engine determines Stageᵢ under an approved methodology. A separate ECL Engine calculates ECLᵢ conditional on Stageᵢ. That boundary permits independent unit tests, clearer explanations, separately versioned methodologies, faster troubleshooting and traceable audit evidence—without publishing or embedding institution-specific thresholds.

portfolio <- portfolio %>%
  mutate(ecl_horizon = case_when(
    stage == 1 ~ "12M",
    stage %in% c(2, 3) ~ "Lifetime"
  ))

The label routes an exposure; it does not calculate lifetime ECL. Lifetime treatment needs period-specific risk vectors.

Traditional R automation can stop at export

Source files or databases flow through import, cleansing, stage assignment, parameter joins, scenario expansion, calculation, aggregation and export. The hand-offs after export—reconciliation, movement analysis and reporting—can still consume most of the close.

A small hypothetical portfolio makes the pipeline visible

The eight exposures below are invented for this article. Rates and parameters are illustrative, not benchmarks, policy settings or staging criteria. Only the Base scenario is shown here; the calculation expands every exposure across all scenarios.

library(dplyr)

ecl_results <- portfolio %>%
  mutate(expected_loss = pd * lgd * ead * discount_factor) %>%
  group_by(stage, product) %>%
  summarise(ead = sum(ead), ecl = sum(expected_loss), .groups = "drop")

Vectorised transformations are concise, reviewable and reproducible. A production implementation would additionally control parameter semantics, dates, term structures, default and recovery treatment, currencies, missing values and calculation versions.

Lifetime ECL changes the grain of the calculation

The useful data shape moves from one row per exposure to one row per exposure × period × scenario before aggregation. Long format makes horizon selection, scenario calculations, aggregation and diagnostics explicit.

Base, Upside and Downside are purely illustrative and use weights of 50%, 20% and 30%. Their sum is one. Period PD values are treated as marginal probabilities in this simplified table.

scenarios <- tibble(
  scenario = c("Base", "Upside", "Downside"),
  scenario_weight = c(0.50, 0.20, 0.30)
)
stopifnot(abs(sum(scenarios$scenario_weight) - 1) < 1e-12)

scenario_ecl <- expanded_portfolio %>%
  left_join(scenarios, by = "scenario") %>%
  mutate(ecl_component = pd * lgd * ead * discount_factor * scenario_weight) %>%
  group_by(exposure_id) %>%
  summarise(ecl = sum(ecl_component), .groups = "drop")

A returned number is not a completed calculation

Controls must answer whether every expected exposure entered, balances and stage totals agree, duplicates exist, exclusions are understood and any adjustments are authorised. Critical assumptions should fail loudly rather than produce a plausible-looking total.

stopifnot(
  nrow(portfolio) == n_distinct(portfolio$exposure_id),
  all(portfolio$ead >= 0),
  all(portfolio$stage %in% 1:3)
)

reconciliation <- ecl_results %>%
  group_by(stage) %>%
  summarise(exposure = sum(ead), ecl = sum(ecl), .groups = "drop")

Explain the bridge, not only the closing balance

New business, repayments or exits, stage migration, PD, LGD and EAD change, scenario change, default, write-off and methodology change can all contribute. The taxonomy and ordering must be designed for the portfolio; there is no universal decomposition. A controlled sequential or attribution method must prevent double counting.

Opening ECL + new business + risk-parameter movement + stage migration + scenario effect + exposure movement + other controlled effects = closing ECL. Each exposure-driver assignment should be mutually intelligible and reproducible.

R alone is not the problem

R remains highly appropriate for numerical calculation, transformations, vectorised portfolio operations, statistical models, diagnostics, reconciliation and movement analysis. The operational problem begins when analysts must decide: Which changes matter? Which exposures caused them? Which are expected or anomalous? What should be investigated first? How should the evidence be explained?

AI creates the greatest value around the calculation—validating inputs, investigating movements, reconciling outputs, identifying exceptions and explaining results.

Put the Agent after and around deterministic computation

A future conceptual Entimema Provisioning Agent would orchestrate and analyse this controlled workflow; this is not a claim that it currently exists as a production product. It would receive reconciled results, movement records and exceptions—not an invitation to generate arbitrary ECL values.

Trust begins with an explicit execution boundary

The Agent need not be non-deterministic in every component: its filters, access controls, schemas, thresholds and routing can themselves be bounded and tested. Human accountability remains at the interpretation and approval boundary.

The Agent should call tools—not perform uncontrolled arithmetic

These are conceptual interfaces, not claims about current product functions. Each should have an approved implementation, typed inputs, versioned configuration, authorised access, structured output, error states and execution log.

Redesign the monthly workflow around exceptions and evidence

The target chain is Portfolio Data → Controlled Inputs → Deterministic ECL Engine → Validation → Reconciliation → Movement Analysis → Exception Detection → AI Investigation → Analyst Review → Reporting / Evidence.

Calculate → Control → Investigate → Explain → Approve

The deterministic engine remains the source of mathematical truth. Controlled orchestration makes every input, formula, output and exception traceable. The Agent then reduces the costly work around the number: finding material changes, retrieving evidence, coordinating investigation and drafting an explanation for review.

This is Deterministic Engine + AI Agent, not one replacing the other. Related Entimema work on credit portfolio monitoring architecture shows how risk signals become controlled cases, while the model validation pipeline shows how deterministic tests become reproducible evidence.