Same Cash Flows, Different Questions — Why Solvency II and IFRS 17 Require Different Pipelines

What building both systems taught me about question-driven design

The Moment I Saw It

I built a Solvency II BEL pipeline. Nine scenarios, four discount curves, two mortality tables — all running in parallel, all recomputed from scratch every time assumptions changed. Stateless. Snapshot-oriented. Designed to answer one question: what is the liability worth right now?

Then I built an IFRS 17 reinsurance pipeline. Quarterly roll-forwards, sequential state transitions, CSM that accumulates and releases over time. Stateful. History-dependent. Designed to answer a different question: how does this liability generate profit as service is delivered?

Both pipelines started from projected cash flows. Both applied discounting. Both produced numbers that would appear on financial statements.

But the systems could not have been more different.

It was not until both were running — tested, validated, producing results — that I understood why. The divergence was not in the formulas. It was in the questions.

Start From the Same Object: Cash Flows

In practice, actuarial teams usually start from a common foundation: shared projection logic, a common data structure, a core set of aligned assumptions.

This foundation produces the same structured expectations: expected cash flows over time, timing and contract grouping, core risk drivers.

At this stage, there is no such thing as “Solvency II cash flows” or “IFRS 17 cash flows.” What exists is better described as a Unified Cash Flow Layer — a layer that deliberately avoids answering any valuation question.

In reality, even these elements may diverge due to governance rules, contract boundaries, or expense allocation. But conceptually, they originate from the same underlying structure. The point is not that cash flows are shared. It is that they are deliberately kept free of interpretation. That conceptual separation is what matters for system design.

Where Systems Diverge: The Question

The real divergence does not start with Risk Margin versus CSM. It starts earlier — when we decide what the numbers are supposed to mean.

Solvency II asks: “What would it cost to transfer this liability today?”

This is a point-in-time, market-consistent question. This difference is easy to describe in theory. It becomes unavoidable when you build the system. BEL, Risk Margin, and SCR are consequences of that question. Everything is designed to answer: how much risk must be absorbed now, how sensitive is the position to market movements, how much capital is required to survive stress.

When I built my BEL pipeline, every design decision reflected this. Nine stress scenarios ran simultaneously because the framework demands instantaneous sensitivity. Four EIOPA curves ran in parallel because the question is about today’s market conditions — not yesterday’s. The pipeline optimised for recomputation: change an assumption, rerun everything, compare.

IFRS 17 asks: “How does this liability generate profit as insurance service is provided?”

This is a performance-over-time question. IFRS 17 does not eliminate uncertainty — it restructures how uncertainty is recognised. Fulfilment Cash Flows and CSM exist because when profit emerges matters more than its instantaneous value.

When I built my reinsurance pipeline, this changed everything. CSM had to accumulate at inception and release over coverage periods. Loss Components had to appear when a group turned onerous and reverse when it recovered. The pipeline could not simply recompute — it had to remember. Every quarter’s closing state became the next quarter’s opening state.

Discounting Is Where Interpretation Begins

This is where many system designs quietly fail.

Discounting is not a neutral technical step applied after cash flows. It is already part of the question being asked.

Solvency II applies market-consistent discounting — EIOPA RFR curves that update monthly — because its question is about transfer value today. In Article #10, I showed how four different EIOPA curves changed BEL by 3.9%. The curve is current. The answer is current.

IFRS 17 mixes locked-in and current rates. The CSM uses rates fixed at initial recognition. Fulfilment Cash Flows use current rates. This duality exists because IFRS 17’s question spans time — it needs to separate the effect of changing market conditions from the underlying insurance performance.

In my BEL pipeline, I had one discount curve dimension (version_id). In an IFRS 17 pipeline, I would need two: a locked-in curve that never changes after inception, and a current curve that updates every reporting period. Same cash flows, same discounting concept — but the implementation diverges because the questions require different temporal perspectives.

Solvency II discounts from the present looking outward. IFRS 17 discounts from the past looking forward.

The moment time value is interpreted, systems must diverge. Discounting is not a shared component. It is the first interpretation layer.

Stateless vs Stateful: The Design Consequence

Once the questions diverge, pipeline architecture diverges with them.

My Solvency II pipeline is stateless.

Every run produces a complete result from scratch. There is no dependency on previous runs. When I added four EIOPA curves, I used a cross join — every cashflow was discounted under every curve simultaneously. When I added a second mortality table, I added another cross join. The pipeline scaled horizontally: more assumptions meant more combinations, but the same logic.

This is recomputation-oriented design. The pipeline does not remember. It recalculates.

In practice, this meant: 8 model points × 9 scenarios × 4 curves × 2 mortality versions = 576 parallel calculation paths. All validated. All independent. If an assumption changes tomorrow, I rerun everything. Yesterday’s results are irrelevant.

My IFRS 17 pipeline is stateful.

Each quarter’s result depends on the previous quarter. CSM at Q2 opening equals CSM at Q1 closing. A Loss Component created in Q2 persists until reversed. The pipeline cannot simply recompute — it must preserve history.

This showed up concretely in the state machine design. GoC B started profitable (CSM = 55,000), turned onerous in Q2 after adverse experience (LC = -40,000), and the transition required consuming CSM first before creating a Loss Component. That sequential logic — where the order of operations determines the outcome — is fundamentally incompatible with stateless recomputation.

The aoc_order column I introduced in Medium-3 exists precisely because of this: AoC steps must execute in a defined sequence. Without it, window functions silently produce wrong results because SQL's string ordering puts CLOSING before CSM_RELEASE.

One pipeline optimises for recomputation. The other optimises for continuity. These are not implementation preferences — they are consequences of the questions being asked.

Why This Becomes a Real Problem

Most organisations do not separate these layers cleanly.

In Article #4, I described what happens when they don’t: duplicated logic across systems, shared tables where meaning has already diverged, and reconciliation that becomes a permanent process rather than a one-time control.

The most concrete example I encountered in practice: a calculation engine produced cashflow data exceeding 7GB per reporting period, delivered as flat files that were compressed, uploaded, downloaded, transformed, and re-uploaded across systems. Each step added latency, failure points, and version inconsistencies. Most of this complexity came not from the actuarial models — but from how data moved between the Solvency II view and the IFRS 17 view without a clean separation point.

The issue is rarely the actuarial model itself. It is the system design around it. When the same number starts to mean different things depending on where it is used, reconciliation is no longer a technical exercise — it becomes a conceptual one.

Reconciliation fails not because numbers differ — but because meanings do.

There is no single source of truth. Only multiple interpretations of the same truth.

What Changes If You Design It This Way

Teams that explicitly separate cash flow foundations from interpretation layers tend to reduce reconciliation effort, simplify validation, and make assumption changes easier to implement.

Looking back at my own projects, the separation was already implicit. Medium-2’s INT layer generates cashflows and applies decrements — that is the unified foundation. The discounting step (int_cashflows_discounted) is where interpretation begins. Medium-3's INT layer similarly separates cashflow generation (int_treaty_quarterly_movement) from balance sheet interpretation (int_goc_bs_state).

If I were to combine them into a single architecture, the design would look like this:

I did not build this unified system. I built the two halves separately. The cost of this separation is duplication. The benefit is clarity — and clarity always wins. But building both made the structure visible — and that visibility is the prerequisite for designing it intentionally.

The Real Insight

The difference between Solvency II and IFRS 17 is not in the cash flows. It is in the question being asked.

Solvency II compresses uncertainty into a single value today. IFRS 17 spreads it into a time-based narrative. One demands recomputation. The other demands continuity. One treats the discount curve as current market truth. The other treats it as a mix of historical commitment and current reality.

Systems designed around formulas break as requirements evolve. Systems designed around questions scale — because answers can change, but questions remain stable.

You are not building two systems. You are building one system that refuses to confuse two different questions.

What Twelve Articles Taught Me

This is the last article in the series. And only after building all of them did the pattern become clear.

Over twelve articles and three pipeline projects, I moved from P&C loss reserving to life insurance BEL to reinsurance IFRS 17 — and then stepped back to examine the assumptions, the curves, and the frameworks that connect them.

The technical lessons were important: cumulative products via log-sum-exp, state machines in SQL, assumption versioning, multi-curve discounting, experience studies. Each one solved a specific problem.

But the deeper lesson was structural. Insurance data systems are not defined by their formulas. They are defined by the constraints those formulas impose on data architecture. Survival must reconcile. States must transition sequentially. Assumptions must be versioned. Cash flows must flow through interpretation layers that are explicit, auditable, and separable.

Every project I built reinforced the same principle: the hardest part is never the calculation. It is the system that carries the calculation.

And the most important decision is never the formula. It is the question you choose to answer.

In the end, systems do not fail because formulas are wrong. They fail because the question was never made explicit.

And once the question is wrong, the system will be wrong in ways that are invisible until it is too late.

About the author

SukHee Lee is an actuarial data analyst working at the intersection of insurance, reserving, and data engineering, with hands-on experience in IFRS 17-related data pipelines.

GitHub: github.com/SHLee5864