IFRS 17 Production Architecture: The 5-Layer Reporting Chain From Data to Financial Statements
Running IFRS 17 in production means more than having the right actuarial models. It means having a full pipeline — from raw data inputs through actuarial calculation to financial statements — where every step is controlled, traceable, and independently testable. The architecture that sits beneath the reported numbers is what determines whether your team can actually rely on them.
This post walks through the five-layer architecture used in live IFRS 17 production environments, from data transformation through to automated reporting.
flowchart TB
subgraph Layer1[Layer 1: Data]
D1[Policy Admin] --> D2[Claims Systems]
D2 --> D3[Investment Data]
end
subgraph Layer2[Layer 2: Calculation]
E1[Actuarial Engine]
end
subgraph Layer3[Layer 3: Adjustment]
F1[Post-Engine Adjustments]
end
subgraph Layer4[Layer 4: Disclosure]
G1[IFRS 17 Templates]
end
subgraph Layer5[Layer 5: Reporting]
H1[Financial Statements]
H2[Management MI]
end
Layer1 --> Layer2
Layer2 --> Layer3
Layer3 --> Layer4
Layer4 --> Layer5
style Layer1 fill:#0A0F1E,stroke:#00C2CB,color:#F0F0F0
style Layer2 fill:#0A0F1E,stroke:#00C2CB,color:#F0F0F0
style Layer3 fill:#0A0F1E,stroke:#00C2CB,color:#F0F0F0
style Layer4 fill:#0A0F1E,stroke:#00C2CB,color:#F0F0F0
style Layer5 fill:#0A0F1E,stroke:#00C2CB,color:#F0F0F0Layer 1 — Data Transformation (DTT)
The first layer handles everything that needs to happen before any actuarial calculation can run. The Data Transformation Tool ingests raw inputs in whatever form they arrive — CSV files, Excel extracts, SAS datasets, actuarial system outputs — and converts them into clean, validated, model-ready data stored in a central database.
This is where validation checks live: completeness tests, referential integrity, range checks, reconciliation to source systems. Any discrepancy between what was received and what should have been received gets flagged here, before it can propagate downstream. The cost of catching an error at Layer 1 is low. The cost of catching it at Layer 4, when it shows up as an unexplained movement in the income statement, is considerably higher.
Most production issues in IFRS 17 environments originate in the data layer. Not because the data is bad, but because the controls around it are insufficient. A robust DTT layer treats data quality as a precondition, not an afterthought.
Layer 2 — LIC Actuarial Models (GART)
The second layer handles the Liability for Incurred Claims. The GART model takes the clean inputs from Layer 1 and produces the actuarial estimates that represent claims already incurred but not yet fully settled.
The methods used are standard reserving methodology: development triangles, chain ladder, Bornhuetter-Ferguson. Where IFRS 17 adds complexity is the additional outputs required — not just IBNR and OCR, but also the risk adjustment for non-financial risk, and the discounting of future cash flows to present value. Each of these outputs is produced within the same model, fully traceable from input triangle to final reserve.
What matters practically is that the GART outputs are deterministic given the inputs. Every number has a clear lineage. When an auditor or reviewer asks why the risk adjustment moved, the answer comes from within the model — not from a separate spreadsheet maintained by someone who may or may not still be on the team.
Layer 3 — LFRC Actuarial Models (Autory DCF)
The third layer handles the Liability for Remaining Coverage — the forward-looking side of the IFRS 17 balance sheet. The Autory DCF component projects fulfilment cash flows across the coverage period, applies discount rates, and produces the building blocks of the LRC: the present value of future cash flows and the risk adjustment.
This layer also handles group classification — the determination of whether each group of contracts is profitable or onerous at initial recognition — and the ongoing profitability testing required each period. The Analysis of Movement from opening to closing balance is produced here, applying IFRS 17’s required disaggregation into changes in estimates, experience variances, and the contractual service margin movements.
The group aggregation logic — annual cohorts, portfolio and group boundaries — is embedded in the model rather than managed externally. This matters because the aggregation rules under IFRS 17 have real economic consequences for the reported CSM, and any manual override of the model’s groupings introduces the kind of uncontrolled variability that makes period-on-period comparison unreliable.
Layer 4 — IFRS 17 Accounting Engine (Autory)
The fourth layer is where actuarial outputs become accounting entries. The Autory accounting engine takes the LIC results from GART and the LRC results from the DCF component, combines them with management accounting inputs — earned premium, claims payments, acquisition costs, investment income — and produces the full set of IFRS 17 journal movements.
Account mappings are maintained within the engine. The opening to closing movement analysis covers all required IFRS 17 disclosure components: insurance revenue, insurance service expenses, insurance finance income and expenses, and the reinsurance equivalent of each. The output is a structured dataset ready for financial reporting rather than a set of numbers that someone needs to manually reformat.
The practical implication is that the accounting engine is the single source of truth for the reported numbers. There are no parallel spreadsheet calculations that produce slightly different results and then need to be reconciled. The journal is what it is, and if something doesn’t tie, the investigation starts in the engine rather than in a series of Excel files.
Layer 5 — Results and Reporting
The fifth layer sits above the calculation stack and is focused entirely on presentation and distribution. The central results database holds all outputs from Layers 2, 3, and 4. Automated dashboards pull directly from this database to produce the income statement, balance sheet, disclosures, and subledger extracts.
No manual interventions sit between the calculated results and the reported outputs. The income statement shown to management is the same income statement produced by the accounting engine, without transcription. Disclosure schedules — roll-forwards, maturity analyses, sensitivity disclosures — are generated from the same source.
Each layer is independently version-controlled. When model updates are applied — changes to discount rate methodology, updates to actuarial assumptions, corrections to account mappings — those changes are tracked at the layer where they were made. The full production run for any period can be reproduced exactly from the archived inputs and the version of each layer that was in production at that time.
Why Architecture Matters More Than Software
A layered architecture is about separation of concerns. When each component — data transformation, actuarial models, accounting engine, reporting — has defined interfaces, three things become possible.
First, each layer can be tested independently. The GART model can be validated against benchmark reserves without running a full close; the accounting engine can be tested with synthetic inputs before live models are finalised.
Second, the architecture is resilient to change. When regulation changes — and IFRS 17 continues to see interpretive guidance — the impact is contained to one layer. A risk adjustment update stays in the actuarial models; a disclosure format update stays in the reporting layer.
Third, and most practically: when something doesn’t tie, trace the chain to find the break. Layer 5 doesn’t tie to Layer 4? Look at the reporting layer or database extract. Layer 4 doesn’t tie to Layer 3? Look at the accounting engine’s treatment of the LRC. This diagnosis is only possible when the architecture enforces clear boundaries.
Traceability is not a compliance feature. It is an operational necessity for teams that close monthly, produce reliable numbers, and defend them when challenged.
If your team is building or refining an IFRS 17 production environment, I’d welcome the conversation. Get in touch.