Navigating Common Data Collection Challenges in 2023

1) Why this topic matters for IFRS 9 practitioners

IFRS 9 requires that provisioning under Expected Credit Losses be forward-looking, data-driven and auditable. In practice, the largest friction points for finance, risk and credit teams are data gaps, inconsistent definitions across silos, and slow reconciliation between source systems and the model environment. Understanding and fixing data collection challenges reduces volatility in provisions, strengthens audit trails for IFRS 7 disclosures, and makes Risk Committee Reports more reliable.

For a strategic view on the central role of inputs and assumptions, readers should consider the companion article that explains why data is central to ECL and how it affects model outputs and governance.

2) Core concept: what are the data collection challenges?

Definition and components

“Data collection challenges” describe the operational, technical and governance issues that prevent accurate, timely and auditable ECL model inputs. They typically involve:

• Source system inconsistencies (product codes, counterparty identifiers).
• Incomplete historical performance data (default flags, cure events, charge-offs).
• Insufficient macroeconomic linkage (mismatch between macro scenarios and exposure granularity).
• Latency — monthly vs daily feeds affecting staging and flows.
• Poor lineage and provenance for disclosures and audit queries.

Concrete example

Consider a retail portfolio of 120,000 accounts where PD models require 36 months of payment history. If 20% of accounts lack a continuous payment status due to a legacy ingestion error, staging (three-stage classification) and historical default rate calculations will be biased. You may observe an unexpected 50–75 bps swing in lifetime ECL simply because cure and missed payment flags are inconsistent.

Link to adjacent challenges

Some of these issues overlap with broader data quality challenges, such as duplicate records and mismatched keys, which compound during aggregation for Risk Committee Reports and IFRS 7 disclosures.

3) Practical use cases and scenarios

Scenario A — Retail portfolio model recalibration

Situation: The model team plans a Historical Data and Calibration exercise using 60,000 accounts and 24 months of history. Problem: a third-party servicer changed product codes mid-period, splitting the history into two separate records per borrower.

Fix: Implement a reconciliation script to match Ssn/CustomerID across product code changes, rebuild the continuous time series, and document the transformation. Re-run calibrations and document the delta: if lifetime PDs increase by 10% after correction, capture the drivers and include an addendum in the Risk Committee Reports.

Scenario B — Corporate lending with sparse defaults

Situation: Large corporate exposures (500 obligors) show limited default observations, so probability of default models are unstable. This is a classic problem of data scarcity and quality for low-default portfolios.

Fix: Use conservative overlays, benchmarking to external datasets, and create a documented calibration approach aligned with governance. For more on managing limited observations, review discussion on data scarcity and quality.

Scenario C — Rapid macro shock and scenario mapping

Situation: Macroeconomic variables used in forward-looking scenarios are at an unusual frequency (quarterly), while internal exposures update monthly. Mapping errors can create misaligned point-in-time adjustments.

Fix: Define clear mapping rules (e.g., carry-forward, interpolation), store transformation code in version control, and include example calculations in the model validation pack.

4) Impact on decisions, performance and compliance

Poor data collection and processing reverberate across the organisation:

• Profitability: inaccurate lifetime loss estimates may lead to over- or under-provisioning, which affects reported earnings and capital metrics.
• Operational efficiency: manual reconciliations slow reporting cycles and inflate operational costs.
• Governance and audit: weak lineage undermines model validation and increases the audit burden for IFRS 7 disclosures and model governance committees.
• Risk transparency: Risk Committee Reports lose credibility when model inputs or historical series are questioned.

Improving inputs through automation and standardisation — and documenting decisions — makes it easier to present robust evidence during model validation and defend assumptions against regulators and auditors. For pragmatic steps to standardise input processes, consider the best practices for ECL data that teams deploy across the sector.

5) Common mistakes and how to avoid them

Mistake 1 — Treating data ingestion as a one-off project

Cause: Projects deliver a snapshot, but maintenance is neglected. Consequence: repeated regressions and ad-hoc fixes.

Avoidance: Treat ingestion as a live product with SLAs, monitoring and a small sustained team responsible for uptime and lineage tracking.

Mistake 2 — Overreliance on manual spreadsheets

Cause: Quick fixes are implemented in Excel. Consequence: Errors, lack of version control and auditability.

Avoidance: Migrate transformations into scripted pipelines, include unit tests, and use PRs for changes. Document the migration in model governance artifacts to pass model validation review.

Mistake 3 — Poor alignment with model assumptions

Cause: Data definitions don’t match what the model expects (e.g., reporting default vs regulatory default). Consequence: invalid inputs and failed back-tests.

Avoidance: Maintain a data dictionary aligned with model documentation and confirm alignment during validation. Many of the common ECL modeling challenges trace back to mis-specified inputs rather than model form.

6) Practical, actionable tips and checklist

Below is a prioritized, pragmatic checklist you can apply immediately. These items focus on reducing friction in data collection, improving traceability and strengthening governance.

1. Source mapping & reconciliation
   • Map identifiers across systems and maintain a canonical key table. Example: map legacy product_code -> canonical_product_id with timestamps.
   • Automate daily reconciliation reports: rows ingested vs expected, null rate by field, drift alerts.
2. Historical completeness
   • Define minimum history per segment: e.g., retail secured = 36 months, corporate = 60 months where available.
   • Where history is insufficient, document rationale for proxying or external supplement sources.
3. Data collection and cleaning
   • Adopt scripted pipelines with unit tests and version control; include data profiling at each stage. For practical upskilling and tooling guidance, see resources on data collection and cleaning.
   • Implement constraint checks (e.g., exposure > 0, date <= today) and fail-fast alerts.
4. Scenario linkage and transformation
   • Store the mapping logic between macro scenarios and granular exposures as code; include worked examples in validation packs.
   • Sample test: change a single macro input by +/-10% and verify the expected directional change in ECL.
5. Documentation and governance
   • Maintain a data dictionary, lineage diagrams and a change log for every transformation. Include a short executive summary for Risk Committee Reports.
   • Include data owners in the risk model governance forums to speed sign-off cycles.
6. Scale and technology
   • Assess whether current infrastructure can support scaling to millions of exposures and streaming updates — a common requirement described in handling big data in ECL discussions.
   • Evaluate ETL vs ELT trade-offs and use columnar stores for large aggregations; see research on big data’s role in ECL.

KPIs / success metrics

Track these measurable metrics to verify improvements in your data collection and processing lifecycle:

• Data completeness rate — percentage of exposures with required historical fields (target: > 99% for critical fields).
• Null rate by field — trend monitoring for sudden spikes.
• Reconciliation pass rate — percent of daily/weekly feeds reconciled without exceptions (target: > 98%).
• Time-to-close for ECL run — from data availability to final report (target: reduce by 30% year-over-year).
• Number of manual adjustments per close — track and aim to reduce by automation (target: 50% reduction in 12 months).
• Model validation exceptions caused by data — percent of validation findings attributable to data issues (target: single-digit percent).

FAQ

Reference pillar article

This article is part of a broader cluster exploring data’s role in ECL. For foundational concepts, frameworks and governance models, read the pillar piece: The Ultimate Guide: The importance of data in calculating expected credit losses – why data is central to ECL models and its role in forecasting risk and complying with IFRS 9.