P&C Reserving vs Life BEL — Two Inverse Worlds

What building both pipelines taught me about the hidden symmetry between past and future.

The Day “Best Estimate” Broke in Half

When I built my P&C loss development pipeline, I thought I understood what a best estimate was. When I later built a Life BEL projection engine, I assumed I was solving the same problem in a different domain.

I wasn’t even close.

It wasn’t until both pipelines were running — both tested, both producing numbers that would eventually feed financial statements — that I realized something fundamental: P&C reserving and Life BEL are not siblings. They are mirror images facing opposite directions.

One reconstructs the past. The other manufactures the future. One extracts uncertainty from data. The other injects uncertainty through assumptions. One validates reasonableness. The other validates identities.

This article is not a comparison. It is the story of what I discovered while building both worlds from scratch — and how those discoveries reshaped my understanding of insurance analytics.

The Arrow of Time — The First Fracture

The first time the symmetry hit me was when I drew the time axis for both pipelines.

P&C reserving moves left to right: accidents happened, claims developed, we estimate the ultimate.

Life BEL moves right to left: cashflows will happen, they will be discounted, we estimate their present value.

Both anchor themselves at the valuation date, but one looks backward while the other looks forward.

This is not a conceptual curiosity. It is the root cause of every structural difference that follows.

In P&C, the data exists. In Life, the data does not exist yet.

That single fact reshaped every design decision I made — from how the INT layer works, to what “validation” means, to how uncertainty is measured.

Discovery #1 — The INT Layer: Two Different Machines

When I built the P&C INT layer, I thought I was doing something generalizable: reshape messy history into a clean triangle. But when I built the Life INT layer, I realized I had stepped into a different universe.

The difference is best shown in code — not words.

P&C INT — Unfolding the past

-- Date spine: claim × month
SELECT
  c.claim_id,
  m.valuation_month,
  COALESCE(p.paid_in_month, 0) AS paid_in_month,
  SUM(COALESCE(p.paid_in_month, 0))
    OVER (PARTITION BY c.claim_id
          ORDER BY m.valuation_month) AS cumulative_paid
FROM claim_base c
LEFT JOIN month_spine m
  ON m.valuation_month
     BETWEEN c.accident_month AND current_month
LEFT JOIN payments p
  ON p.claim_id = c.claim_id
 AND p.payment_month = m.valuation_month;

This is data engineering: fill gaps, align dates, accumulate history. The core pattern is LEFT JOIN + COALESCE(0) — everything revolves around reshaping data that already exists.

Life INT — Generating the future

-- State rollforward: recursive projection
SELECT
  cohort_id,
  scenario_id,
  projection_month,
  inforce_open,
  inforce_open * q_monthly                        AS deaths,
  inforce_open - (inforce_open * q_monthly)        AS post_death,
  (post_death) * lapse_monthly                     AS lapses,
  (post_death) - ((post_death) * lapse_monthly)    AS inforce_close
FROM projection_frame;

This is not reshaping data. This is simulating a world that does not exist yet. The core pattern is recursive state transitions — each row depends on the row before it. There is no history to align. There are only assumptions to project.

The discovery:

P&C INT = unfold the past.

Life INT = generate the future.

Same dbt layer name. Completely different computational responsibility. I wasn’t building two pipelines — I was building two philosophies.

Discovery #2 — Validation: When “Test” Stopped Meaning the Same Thing

In P&C, validation is almost optional. If the triangle looks reasonable and the LDFs behave, you’re fine. Why? Because P&C starts from observed reality. The data is assumed correct; the model is the approximation.

Life BEL is the opposite. It starts from assumptions, not data. Nothing is observed. Everything is generated. So the pipeline must prove that the calculations are internally consistent.

That’s why my Life pipeline includes seven validation models:

• Inforce rollforward identity
• Mortality and lapse consistency
• Premium and benefit sign conventions
• Discounting identity
• Projection frame completeness
• Cashflow reconciliation
• BEL decomposition checks

These aren’t “sanity checks.” They are mathematical identities that must hold exactly — to the decimal.

My P&C pipeline has zero validation models. Not because I was lazy, but because the computational responsibility is different. P&C validates by checking whether results look reasonable. Life validates by proving that equations balance.

The discovery:

P&C validation = empirical reasonableness.

Life validation = mathematical proof.

Same word. Opposite meaning. Once you’ve built both, you stop using the word “validation” casually.

Discovery #3 — Premium: The Word That Betrayed Me

Premium was the concept that forced me to confront how deeply the two worlds diverge. Here is the simplest way to show it:

This isn’t a modeling detail. It’s a philosophical difference.

P&C uses premium to measure performance: loss_ratio = ultimate_loss / earned_premium. Premium is the denominator — an external benchmark that appears at the end of the pipeline.

Life uses premium to construct economics: BEL = PV(benefits) + PV(expenses) − PV(premiums). Premium is a cashflow component — an inflow that reduces the liability, appearing at the very start of the projection with a negative sign.

I didn’t understand this until I had to encode it — and then debug it. The sign convention alone caused more confusion than any actuarial formula.

Discovery #4 — Uncertainty: Two Worlds Fear Different Things

Both domains ask the same question: “How much can we trust this number?”

But the source of uncertainty is inverted.

P&C fears instability in the past. The question is: are past patterns stable enough to predict the future? The tools are statistical — link ratio scatter, σ², MSEP, Mack variance. Uncertainty is extracted from the data itself. No external assumptions are needed. If the triangle has enough history, the variance estimate follows.

Life fears being wrong about the future. The question is: what if our assumptions are wrong? The tools are scenario-based — mortality +10%, lapse −50%, discount −50bps. Uncertainty is injected through perturbation. The data contains no information about the future; only the assumptions do.

The discovery:

P&C extracts uncertainty from history.

Life perturbs uncertainty into the future.

This is not just a methodological difference. It reflects a deeper truth: P&C has data but needs to trust its stability. Life has assumptions but needs to test their sensitivity. The same goal — quantifying confidence — requires opposite approaches because the information flows in opposite directions.

Discovery #5 — Model Count: Responsibility, Not Complexity

When I finished both pipelines, I counted the models. P&C: 18. Life: 26. At first I thought Life was simply more complex. But the total hides the real insight.

The difference doesn’t come from INT being “harder.” It comes from an entire layer — VALIDATION — that exists in Life but has no equivalent in P&C.

Life isn’t more complex. It simply carries more computational responsibility. It must generate future states, produce cashflows, validate identities, discount, validate again, aggregate, and reconcile. P&C does none of this — its responsibility is to summarize the past, not simulate the future.

The discovery:

Model count is not a measure of complexity. It is a measure of responsibility.

This changed how I think about pipeline design entirely.

Two Worlds, One Question — and Why IFRS 17 Lives Between Them

After building both pipelines, I stopped seeing P&C and Life as separate domains. I started seeing them as mirror images:

• One backward, one forward
• One data-driven, one assumption-driven
• One validated empirically, one validated mathematically
• One extracts uncertainty, one perturbs it
• One reshapes history, one generates the future

And this is exactly why IFRS 17 sits between them.

The CSM mechanism is literally the intersection: it updates a future liability (Life thinking) using past experience adjustments (P&C thinking). IFRS 17 is where the two worlds meet — where backward-looking experience and forward-looking projection collapse into a single measurement model.

To understand IFRS 17, you must understand both worlds — not as isolated techniques, but as two halves of the same question:

“What is our best estimate, and how does new information reshape it?”

Building both pipelines made this symmetry impossible to ignore. And once you see it, you can’t unsee it.

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