SCHEMA-DRIVEN TESTING FRAMEWORKS FOR IFRS9 REGULATORY WAREHOUSES

Volume-05 Issue 06, June-2021 ISSN: 2456-9348 Impact Factor:5.004 International Journal of Engineering Technology Research & Management (IJETRM) https://ijetrm.com/ IJETRM (http://ijetrm.com/) [246] SCHEMA-DRIVEN TESTING FRAMEWORKS FOR IFRS9 REGULATORY WAREHOUSES Narasimha Chaitanya Samineni Vice President, Quality Assurance Supervisor ABSTRACT International Financial Reporting Standard 9 (IFRS9) fundamentally transformed credit risk reporting by introducing forward-looking Expected Credit Loss (ECL) models for financial institutions. The regulatory implementation of IFRS9 requires large-scale data warehouses capable of integrating heterogeneous financial, risk, and macroeconomic datasets while ensuring extreme levels of data quality, consistency, and auditability. Even minor schema mismatches, referential breaks, or temporal inconsistencies in IFRS9 data pipelines can lead to material misstatement of ECL, regulatory objections, and audit qualifications [2], [3]. Traditional testing and validation of IFRS9 warehouses rely heavily on manual rule execution, sample-based verification, and post-aggregation reconciliations, which are operationally expensive, error-prone, and poorly scalable for modern regulatory environments [4], [5]. This research introduces a schema-driven testing framework for IFRS9 regulatory warehouses that automates structural, referential, temporal, and cross-table validation using metadata-bound schema controls. The framework integrates a centralized schema registry, automated test orchestration, exception governance, and audit-ready lineage tracking across the full IFRS9 reporting lifecycle. Performance analysis demonstrates that schema-driven testing significantly improves defect detection coverage, reduces test execution cycle time, strengthens audit defensibility, and enhances regulatory confidence in ECL computations. By systematically enforcing schema integrity at every layer of the regulatory warehouse, the proposed framework establishes a scalable and regulator-defensible foundation for IFRS9 data assurance in large banking environments. Keywords: IFRS9, Expected Credit Loss (ECL), Schema-Driven Testing, Regulatory Data Warehouses, Data Quality Assurance, Financial Data Validation, Risk Reporting, RegTech. I. INTRODUCTION The adoption of International Financial Reporting Standard 9 (IFRS9) marked a paradigm shift in how financial institutions recognize, measure, and report credit risk. Unlike prior incurred-loss accounting frameworks, IFRS9 mandates a forward-looking Expected Credit Loss (ECL) model that requires continuous estimation of lifetime credit losses using granular exposure data, borrower behavior, macroeconomic forecasts, and probability-weighted scenarios [2], [3]. This transformation has dramatically increased the data volume, model complexity, and governance requirements of regulatory reporting infrastructures. To support IFRS9 compliance, banks have established large-scale regulatory data warehouses that consolidate information from core banking systems, loan origination platforms, collateral management systems, risk engines, treasury systems, customer information files, and macroeconomic data providers [4]. These warehouses serve as the authoritative platforms for ECL staging classification, PD/LGD/EAD computation, scenario weighting, and journallevel financial disclosures. The correctness of IFRS9 financial statements is therefore directly dependent on the structural and semantic integrity of warehouse schemas. Despite extensive investment in IFRS9 infrastructure, many institutions continue to experience persistent data quality and testing challenges. Common issues include schema drift across source systems, inconsistent data types between mart layers, broken referential links between exposure and borrower dimensions, misaligned effective dates, and silent data truncation during transformation [5], [6]. These defects frequently remain undetected until late in the reporting cycle, at which point remediation becomes operationally disruptive and regulatorily risky. Volume-05 Issue 06, June-2021 ISSN: 2456-9348 Impact Factor:5.004 International Journal of Engineering Technology Research & Management (IJETRM) https://ijetrm.com/ IJETRM (http://ijetrm.com/) [247] Current IFRS9 testing practices remain heavily manual and sampling-driven, relying on spreadsheets, ad hoc SQL checks, and fragmented business-unit-level validation rules [7]. Such approaches introduce variability in test coverage, suffer from inconsistent rule interpretation, and provide limited end-to-end audit traceability. As IFRS9 models grow in sophistication and data refresh cycles accelerate, manual testing frameworks have become structurally unsustainable for large banking environments [8]. Schema-driven testing has emerged as a powerful paradigm in data engineering for enforcing structural, semantic, and temporal data correctness through metadata-bound rules [9]. In a schema-driven model, the schema itself becomes the primary source of validation truth, enabling automated detection of missing attributes, domain violations, referential breaks, and effective-date inconsistencies before data propagates into downstream risk models. Recent advances in metadata registries and automated orchestration platforms demonstrate that schema-enforced validation significantly strengthens data reliability and control scalability in regulated data pipelines [1], [10]. However, existing academic and industry literature offers limited end-to-end frameworks tailored specifically to IFRS9 regulatory warehouses. Most available work focuses either on generic data quality management, financial data governance, or isolated ECL model validation without a unifying schema-driven testing architecture [11], [12]. There remains a critical gap in operationalizing continuous, automated, and audit-ready schema testing across the full IFRS9 reporting lifecycle. This research addresses that gap by proposing a comprehensive schema-driven testing framework for IFRS9 regulatory warehouses. The framework integrates: • Centralized schema registry and version governance • Automated structural, domain, referential, and temporal schema testing • Cross-table and cross-layer reconciliation testing • Exception lifecycle orchestration and remediation tracking • Audit-ready lineage, certification, and regulatory evidence capture The primary contributions of this paper are: 1. A scalable system architecture for schema-driven IFRS9 warehouse testing. 2. A taxonomy of automated schema validation techniques tailored to IFRS9 ECL data. 3. A governance and audit framework aligned with IFRS9, SOX, and supervisory expectations. 4. Performance evaluation comparing manual testing with schema-driven automation. 5. A Tier-1 bank case study demonstrating real-world regulatory impact. The remainder of this paper is organized as follows. Section II reviews related work in IFRS9 reporting, regulatory data quality, and schema-based validation. Section III defines the research objectives. Section IV presents the system architecture. Section V details schema-driven testing techniques. Section VI discusses governance and auditability. Section VII describes the implementation methodology. Section VIII presents performance results. Section IX provides a bank-scale case study. Sections X, XI, and XII discuss implications, limitations, and future scope, followed by the conclusion in Section XIII. Volume-05 Issue 06, June-2021 ISSN: 2456-9348 Impact Factor:5.004 International Journal of Engineering Technology Research & Management (IJETRM) https://ijetrm.com/ IJETRM (http://ijetrm.com/) [248] Fig 1: High-Level Architecture of IFRS9 Regulatory Data Warehouse and Testing Workflow II. LITERATURE REVIEW The implementation of IFRS9 introduced significant regulatory, data engineering, and governance challenges for financial institutions due to its reliance on forward-looking Expected Credit Loss (ECL) modeling. As a result, research related to IFRS9 spans multiple domains including regulatory accounting, risk modeling, data warehousing, data quality management, metadata governance, and automated testing. This section reviews the most relevant literature across five key dimensions: IFRS9 and ECL frameworks, regulatory data warehousing, data quality and schema validation, automated testing in financial systems, and existing gaps in IFRS9 testing research. 2.1 IFRS9 and Expected Credit Loss (ECL) Frameworks IFRS9 replaced the incurred loss model with a forward-looking ECL framework requiring continuous estimation of 12-month and lifetime credit losses using PD, LGD, and EAD measures under multiple macroeconomic scenarios [2], [3]. Academic and regulatory studies emphasize that ECL computation is extremely sensitive to data completeness, staging classification, scenario calibration, and temporal alignment of exposures [4]. Research further highlights that ECL engines depend on large volumes of historical, behavioral, and forward-looking data aggregated across disparate banking systems [5]. Any inconsistency in structural schema, effective dates, or attribute domains can materially distort credit loss projections and financial disclosures. Volume-05 Issue 06, June-2021 ISSN: 2456-9348 Impact Factor:5.004 International Journal of Engineering Technology Research & Management (IJETRM) https://ijetrm.com/ IJETRM (http://ijetrm.com/) [249] 2.2 Regulatory Data Warehousing for IFRS9 Regulatory data warehouses for IFRS9 integrate core banking data, collateral systems, credit risk engines, treasury feeds, and macroeconomic data providers into a unified analytical platform [6]. Prior studies identify schema uniformity, dimensional conformance, and historical versioning as critical requirements for reliable regulatory warehousing [7]. Financial data warehouse design patterns proposed by Inmon and Kimball continue to influence IFRS9 warehouse architectures through star-schema modeling, slowly changing dimensions, and audit trail preservation [8], [9]. However, IFRS9 introduces higher schema volatility due to frequent regulatory interpretation updates, new staging rules, and evolving disclosure requirements. 2.3 Data Quality and Schema Validation in Financial Systems Data quality research consistently identifies structural correctness, domain validity, referential integrity, and temporal consistency as the primary pillars of regulatory data integrity [10], [11]. Traditional validation approaches apply rule-based profiling and reconciliation at batch boundaries, often after transformation and aggregation. Schema validation techniques enforce data type integrity, mandatory attribute presence, constraint satisfaction, and referential coherence across relational and distributed data platforms [12]. However, most reported implementations treat schema validation as a preprocessing activity rather than as a continuous regulatory testing layer embedded within warehouse operations. 2.4 Automated Testing in Regulatory and Financial Data Pipelines Automated data testing has gained prominence with the growth of DevOps and DataOps practices in financial services [13]. Frameworks for metadata-driven validation, rule orchestration, and automated reconciliation have demonstrated measurable improvements in test coverage and defect detection speed [14]. Recent advances in scalable cloud-based data integration and schema-driven automation further enable enterprisewide testing at regulatory scale. The work by Maddali [1] demonstrates how metadata-driven integration and quality enforcement substantially improve fault tolerance and validation scalability in regulated cloud data platforms, directly supporting schema-driven regulatory testing paradigms. Nevertheless, most available studies focus on generic financial data pipelines and do not explicitly tailor automated testing architectures for IFRS9-specific warehouse constraints such as staging logic, scenario alignment, and ECL traceability. 2.5 Governance, Auditability, and Regulatory Testing Controls Regulators increasingly require demonstrable data lineage, rule reproducibility, audit evidence, and exception traceability across regulatory reporting pipelines [15]. BCBS 239 principles further mandate strong metadata governance, accuracy, adaptability, and supervisory transparency for risk data aggregation [16]. Prior research highlights that manual IFRS9 validation frameworks suffer from weak audit defensibility, fragmented rule ownership, and poor historical reproducibility due to spreadsheet-driven workflows and undocumented overrides [17]. 2.6 Limitations of Existing IFRS9 Testing Research Although extensive work exists in ECL modeling and regulatory data quality, the literature reveals several critical gaps: • Lack of end-to-end schema-driven testing architectures for IFRS9 warehouses • Limited treatment of temporal and versioned schema validation under evolving regulatory interpretations • Absence of unified frameworks integrating schema validation, reconciliation, exception governance, and audit lineage • Sparse performance benchmarking of manual vs automated IFRS9 testing models Most current studies address ECL modeling, data quality, or governance in isolation, without integrating them through a continuous schema-enforced testing layer. III. RESEARCH OBJECTIVES The primary objective of this research is to design, implement, and evaluate a schema-driven automated testing framework for IFRS9 regulatory data warehouses that strengthens data integrity, testing scalability, and audit readiness across the full Expected Credit Loss (ECL) reporting lifecycle. Given the complexity, heterogeneity, and Volume-05 Issue 06, June-2021 ISSN: 2456-9348 Impact Factor:5.004 International Journal of Engineering Technology Research & Management (IJETRM) https://ijetrm.com/ IJETRM (http://ijetrm.com/) [250] regulatory sensitivity of IFRS9 data pipelines, the framework aims to replace fragmented manual testing practices with continuous, metadata-bound, and governance-aligned validation mechanisms [2], [4], [10]. A key objective of this study is to automate structural and domain-level schema conformance testing across all layers of the IFRS9 warehouse. This includes enforcing mandatory attribute population, data-type consistency, range constraints, and regulatory code-set validation for exposure, borrower, collateral, and scenario dimensions [11], [12]. By binding validation rules directly to schema definitions, the framework seeks to eliminate silent schema drift and late-stage structural defects. Another central objective is to implement robust referential and cross-table integrity testing between fact and dimension tables supporting IFRS9 staging (Stage 1, Stage 2, Stage 3), EAD computation, and scenario-based aggregations [3], [7]. This ensures that all exposures are consistently and correctly linked to governing borrower, product, and collateral hierarchies required for regulatory traceability. The research further aims to enable automated temporal and effective-date validation for IFRS9 datasets. Since ECL computation is highly sensitive to reporting cutoffs, default aging, cure periods, and scenario effective dates, the framework enforces temporal consistency rules across snapshot, history, and projection tables [5], [6]. These objectives addresses one of the most common root causes of ECL misstatement in large regulatory warehouses. A critical objective is to strengthen governance, auditability, and regulatory defensibility through schema version control, rule versioning, exception lifecycle management, and audit-evidence capture [15], [16]. The framework is designed to ensure that all test executions are reproducible and regulator-defensible under internal audit, external audit, and supervisory review. Another objective is to reduce operational testing cost and reporting cycle time by shifting IFRS9 testing from batch-bound, manual execution to continuous automated enforcement embedded within warehouse operations [13], [14]. This objective is evaluated through comparative benchmarking of manual versus schema-driven testing models. Finally, this study aims to validate the practical effectiveness of schema-driven testing using a bank-scale IFRS9 warehouse case study, measuring improvements in defect detection coverage, testing cycle time, audit readiness, and overall regulatory confidence in ECL reporting [8], [9]. IV. SYSTEM ARCHITECTURE FOR SCHEMA-DRIVEN IFRS9 TESTING The proposed schema-driven testing framework for IFRS9 regulatory warehouses is designed to provide continuous, automated, and audit-defensible validation across the complete Expected Credit Loss (ECL) reporting lifecycle. The architecture adopts a layered, metadata-centric design in which all testing logic is bound directly to governed schema definitions rather than hard-coded procedural rules. This ensures scalability, regulatory consistency, and resilience to schema evolution under changing IFRS9 interpretations [2], [4], [10]. The architecture consists of six tightly integrated layers: (1) Source Financial Systems Layer, (2) IFRS9 Data Ingestion and Standardization Layer, (3) Schema Registry and Metadata Repository, (4) Automated Schema Testing Engine, (5) Exception Management and Reporting Layer, and (6) Governance and Audit Layer. 4.1 Source Financial Systems Layer The source layer comprises all upstream systems that supply data required for IFRS9 ECL computation. These include core banking platforms, loan origination and servicing systems, collateral management systems, customer master databases, treasury platforms, risk engines generating PD, LGD, and EAD metrics, and external macroeconomic data providers [4], [6]. These systems operate with heterogeneous schemas, update frequencies, and control environments. Retail portfolios refresh daily; treasury and market data may refresh intraday, while behavioral and macroeconomic data often follow monthly or quarterly cycles. The framework therefore assumes asynchronous, multi-frequency data ingestion with inherent schema variability and latency. Volume-05 Issue 06, June-2021 ISSN: 2456-9348 Impact Factor:5.004 International Journal of Engineering Technology Research & Management (IJETRM) https://ijetrm.com/ IJETRM (http://ijetrm.com/) [251] 4.2 IFRS9 Data Ingestion and Standardization Layer The ingestion and standardization layer extracts raw source feeds and transforms them into a canonical IFRS9 warehouse model aligned with regulatory disclosure and ECL computation requirements [7], [8]. This layer performs schema normalization, reference-data alignment, code-set standardization, currency normalization, and effective-date standardization. Incremental ingestion strategies are used to process deltas rather than full reloads to support high-frequency warehouse refresh cycles [9]. At this stage, pre-schema validation is executed to detect malformed records, illegal data types, and missing mandatory attributes before data enters downstream testing and ECL processing layers [10], [12]. 4.3 Schema Registry and Metadata Repository The schema registry is the authoritative control plane for all structural, semantic, and temporal definitions governing the IFRS9 warehouse. It stores versioned definitions for: • Table and column structures • Data types and mandatory attributes • Domain constraints and reference code sets • Primary and foreign key relationships • Effective-date and temporal validity rules • Cross-table dependency rules for ECL staging and aggregation Schema versions are fully governed through formal lifecycle management, including version tagging, effective dating, regulatory change impact analysis, and deployment approvals [15], [16]. This registry serves as the single source of truth for automated testing execution across the warehouse. 4.4 Automated Schema Testing Engine The automated testing engine dynamically consumes governed schema definitions from the registry and executes structural, domain, referential, and temporal validations on incoming warehouse data [11], [12]. Unlike traditional rule engines, all test logic is schema-bound and metadata-driven, eliminating the need for manual rule re-coding during schema evolution. Testing is executed continuously across: • Staging layer (pre-ECL) • Intermediate transformation marts • Final ECL aggregation and disclosure layers Test execution supports parallel processing across portfolios, reporting dates, and scenario dimensions to maintain performance at bank scale. Violations are classified by severity using regulatory materiality thresholds derived from IFRS9 disclosure rules and financial reporting tolerances [5], [14]. 4.5 Exception Management and Reporting Layer All schema validation failures are centrally captured within the exception management layer. Each exception is enriched with: • Schema rule identifier and version • Impacted table, attribute, and exposure scope • Reporting date and scenario context • Regulatory materiality classification Automated workflow orchestration routes exceptions to accountable data owners across risk, finance, and data engineering domains [13], [15]. Controlled reprocessing is supported at the partition level (portfolio, reporting date, or scenario) rather than full-warehouse re-execution, preserving reporting timelines. The exception layer also generates regulatory test coverage metrics, defect density trends, and remediation performance dashboards for operational and governance oversight. 4.6 Governance and Audit Layer The governance layer provides end-to-end auditability and regulatory defensibility for schema-driven testing. Every test execution is captured with: • Schema and rule version references • Data snapshot identifiers Volume-05 Issue 06, June-2021 ISSN: 2456-9348 Impact Factor:5.004 International Journal of Engineering Technology Research & Management (IJETRM) https://ijetrm.com/ IJETRM (http://ijetrm.com/) [252] • Execution timestamps • Exception results and remediation status • Management certification artifacts Historical re-execution of tests under the exact schema version applied at the time of regulatory submission is fully supported, satisfying audit reproducibility expectations under IFRS9, SOX, and BCBS 239 [15], [16]. Immutable evidence repositories retain all test logs, exception outcomes, and approvals for regulatory examination. 4.7 Cross-Layer Reliability and Control Enforcement Reliability is enforced through checkpointing, idempotent test execution, and fault-isolation boundaries across warehouse layers [9], [13]. Upstream ingestion failures generate schema availability alerts rather than false ECL testing errors. Downstream ECL computation is automatically gated when material schema defects remain unresolved, preventing contaminated financial disclosures. This architecture ensures that schema conformance becomes a continuous regulatory control rather than a onetime pre-submission activity. V. SCHEMA-DRIVEN TESTING TECHNIQUES FOR IFRS9 WAREHOUSES Schema-driven testing enforces IFRS9 data correctness by binding validation logic directly to governed metadata definitions rather than ad-hoc procedural rules. This approach enables continuous structural, semantic, and temporal assurance across the Expected Credit Loss (ECL) data lifecycle [9], [10], [12]. The proposed framework operationalizes five primary categories of schema-driven testing tailored to IFRS9 regulatory warehouses. 5.1 Structural Schema Conformance Testing Structural testing verifies that all IFRS9 tables adhere strictly to approved schema definitions, including column presence, data types, nullability constraints, and primary key uniqueness [11]. Mandatory regulatory attributes such as staging flags, default indicators, exposure balances, and scenario identifiers are enforced at ingestion to prevent silent structural drift that can invalidate downstream ECL computations [2], [4]. 5.2 Domain and Regulatory Constraint Validation Domain validation ensures that all attributes conform to IFRS9-approved value ranges and code sets. Examples include valid credit stage values (Stage 1–3), product classifications, impairment status flags, and risk rating bands [3], [7]. Range constraints for PD, LGD, and discount factors enforce mathematically defensible ECL boundaries and prevent corrupted financial disclosures [5]. 5.3 Referential Integrity and Cross-Table Dependency Testing Referential testing enforces foreign-key integrity between exposure facts and governing borrower, account, collateral, and product dimensions [8], [9]. Cross-table dependency rules further ensure that ECL fact tables remain synchronized with staging, scenario, and macroeconomic projection tables. Orphaned exposures or broken borrower links are flagged as high-severity regulatory defects due to their impact on traceability and audit defensibility [6], [15]. 5.4 Temporal and Effective-Date Consistency Validation IFRS9 ECL reporting is highly sensitive to reporting cutoff dates, default aging, cure periods, and scenario effective dates [2], [5]. Temporal schema validation enforces monotonic reporting timelines, correct historical versioning, and alignment between snapshot, history, and projection tables. This prevents misclassification of staging transitions and inaccurate lifetime loss estimation [4], [11]. 5.5 Cross-Layer and Cross-Scenario Reconciliation Testing Schema-driven reconciliation validates the structural and quantitative alignment between pre-ECL warehouse layers, ECL computation outputs, and financial disclosure tables [7], [14]. Cross-scenario reconciliation ensures that probability-weighted scenario aggregations reconcile precisely to base exposure data. Structural mismatches across layers are treated as material regulatory control failures. Volume-05 Issue 06, June-2021 ISSN: 2456-9348 Impact Factor:5.004 International Journal of Engineering Technology Research & Management (IJETRM) https://ijetrm.com/ IJETRM (http://ijetrm.com/) [253] TABLE 1: IFRS9 SCHEMA-DRIVEN TESTING TECHNIQUES AND REGULATORY IMPACT Testing Category Example Rule Defect Type Detected Regulatory Impact Reference Structural Conformance Mandatory IFRS9 column missing Schema drift ECL misstatement risk [2], [11] Domain Validation PD outside [0,1] range Invalid risk metric Financial disclosure distortion [5], [12] Referential Integrity Exposure without borrower key Orphaned records Traceability violation [8], [15] Cross-Table Dependency EAD not aligned with staging Staging inconsistency Incorrect lifetime ECL [3], [7] Temporal Validation Scenario date misalignment Projection timing error Scenario weighting defect [4], [5] Historical Versioning Incorrect effective dating Data restatement risk Audit qualification [6], [16] Cross-Layer Reconciliation ECL output not reconciling to exposure Aggregation break Regulatory objection [7], [14] Code-Set Validation Invalid product classification Misclassification Disclosure noncompliance [2], [13] VI. DATA GOVERNANCE, CONTROLS, AND REGULATORY AUDITABILITY Strong data governance and auditability are mandatory for IFRS9 regulatory warehouses because Expected Credit Loss (ECL) figures directly impact financial statements, capital adequacy, and supervisory assessments [2], [3], [15]. Schema-driven testing without formally governed controls exposes institutions to regulatory qualification, model risk escalation, and audit deficiencies. The proposed framework embeds governance across schema definition, test execution, exception remediation, and regulatory certification to ensure continuous compliance and reproducible assurance. 6.1 Data Lineage and Traceability End-to-end lineage is enforced across source systems, ingestion pipelines, canonical warehouse layers, ECL computation marts, and regulatory disclosure outputs [16]. Each data element is persistently linked to its originating source, transformation logic, schema version, and test execution outcome. This enables rapid root-cause analysis during regulatory examinations and supports IFRS9 audit traceability requirements. 6.2 Schema and Rule Version Governance All schema definitions and testing rules are subject to controlled lifecycle governance, including version tagging, effective dating, impact assessment, and regulatory change approvals [11], [15]. This ensures historical IFRS9 submissions can be exactly reproduced under the schema and test logic applicable at the time of filing. 6.3 Exception Lifecycle Governance All schema-driven testing violations are captured in a centralized exception repository and governed through a formal lifecycle comprising detection, triage, ownership assignment, remediation, retesting, and regulatory closure [13], [17]. Each exception is classified by materiality, portfolio scope, and reporting impact to guide prioritization and regulatory disclosure. 6.4 Audit Evidence Management and Certification Automated evidence management captures immutable records of schema versions, test executions, exception remediation actions, and management certifications required for internal audit, external audit, and supervisory review [15], [16]. Evidence artifacts are retained in accordance with statutory record retention and SOX requirements. Volume-05 Issue 06, June-2021 ISSN: 2456-9348 Impact Factor:5.004 International Journal of Engineering Technology Research & Management (IJETRM) https://ijetrm.com/ IJETRM (http://ijetrm.com/) [254] 6.5 SOX, IFRS9, and BCBS 239 Control Alignment The governance layer aligns schema-driven testing with enterprise SOX financial reporting controls and BCBS 239 principles for accuracy, completeness, adaptability, and supervisory transparency [16], [18]. This alignment ensures that IFRS9 testing operates as a regulated internal control rather than a purely technical validation step. 6.6 Regulatory Defensibility and Supervisory Readiness By integrating governance directly into schema-driven testing execution, the framework ensures that all IFRS9 submissions are technically validated, operationally certified, and regulator-defensible. This reduces exposure to audit qualifications, restatements, and supervisory remediation programs [3], [17]. TABLE 2: IFRS9 DATA GOVERNANCE AND AUDIT CONTROLS WITH REGULATORY OBJECTIVES Governance Control Description Applied Layer Regulatory Objective Reference End-to-End Data Lineage Traceability from source to regulatory disclosure All Layers Audit transparency and reproducibility [16], [18] Schema Version Control Controlled lifecycle of schema definitions Schema Registry Reproducible filings [11], [15] Test Rule Versioning Governed evolution of schema tests Testing Engine Regulatory consistency [12], [15] Exception Ownership Assignment Accountable remediation authority Exception Management Timely regulatory compliance [13], [17] Immutable Evidence Repository Storage of test logs and certifications Governance Layer Audit defensibility [15], [16] Management Certification Approval prior to IFRS9 disclosure Reporting Layer Financial statement assurance [3], [17] SOX Control Integration Alignment with financial controls Enterprise Controls Financial reporting reliability [15], [18] Regulatory Change Governance Controlled adoption of new IFRS9 rules Rule Governance Continuous regulatory alignment [2], [11] VII. IMPLEMENTATION METHODOLOGY The schema-driven testing framework was implemented using a bank-scale IFRS9 regulatory data warehouse simulation designed to replicate realistic ECL production environments. The methodology integrates heterogeneous financial source systems, a governed schema registry, automated test orchestration, centralized exception workflows, and audit-ready evidence capture to evaluate both technical performance and regulatory defensibility [2], [4], [8]. 7.1 IFRS9 Dataset Modeling The implementation environment modeled core IFRS9 entities including exposures, borrowers, accounts, collateral, staging classifications, PD/LGD/EAD metrics, macroeconomic scenarios, and probability-weighted projections [3], [5]. Datasets spanned multiple reporting dates and scenario dimensions to reflect 12-month and lifetime ECL computation requirements. Synthetic data defects such as schema drift, referential breaks, invalid domain values, and effective-date misalignment were intentionally injected to evaluate detection sensitivity [10], [11]. 7.2 Schema Registry Configuration All warehouse schemas were registered in a centralized schema registry containing versioned definitions for table structures, column constraints, foreign-key relationships, and temporal validity rules [12], [15]. Each schema version was governed through approval workflows and effective dating to ensure regulatory reproducibility. The schema registry served as the authoritative metadata source consumed dynamically by the automated testing engine. 7.3 Automated Test Rule Parameterization Schema-driven test rules were externalized as metadata rather than hard-coded logic. Structural, domain, referential, and temporal validation rules were auto-generated from schema constraints and enhanced with IFRS9-specific regulatory tolerances for staging logic, risk parameters, and scenario aggregation [5], [7]. Rule execution parameters were calibrated using historical reporting baselines and regulatory materiality thresholds [14].