Much of retirement design still treats decumulation as a secondary problem.

Accumulation receives architecture, products, tax incentives, operational systems, default pathways, and policy attention. Payout often receives something looser: a withdrawal rule, a product shelf, or a late-stage advice conversation. That imbalance matters. A retirement system that is structurally clear in accumulation but vague in payout is only half-designed.

A decumulation framework is not simply a withdrawal rate.

It is the institutional architecture that governs what happens once capital is no longer being built primarily for accumulation, but begins to support income. It defines how income is determined, how capital risk is treated, how volatility is transmitted or moderated, what happens under stress, what role discretion plays, how costs are constrained, and what exactly the system is trying to achieve.

That last point is often underappreciated. Before asking how much can be withdrawn, a serious framework must ask — withdrawn toward what objective?

These are not small technical variations around the same design. They are different design goals. A decumulation framework exists to make those goals explicit and then govern the payout phase accordingly. Without that clarity, the payout phase defaults to improvisation.

Sometimes that improvisation takes the form of simple heuristics: fixed percentage withdrawals, inflation-adjusted rules, or guardrail methods. Sometimes it takes the form of product substitution: buy an annuity, stay in drawdown, or mix both. Sometimes it is handed over to adviser judgment. None of these approaches is necessarily wrong. But absent a governing framework, they remain partial answers to a deeper structural question.

Tactic versus architecture

A decumulation framework should therefore be understood at a higher level than any one payout rule. A payout rule may tell a participant how much can be withdrawn in a given period. A decumulation framework explains why that rule exists, what it is designed to protect, how it behaves under strain, what boundaries it operates within, and how it fits into a broader institutional structure.

That is the difference between tactic and architecture.

This is also why the decumulation question cannot be reduced to whether a given withdrawal rate "works." A rule may survive many historical periods and still embody a design objective that is too narrow, too implicit, or too consumption-oriented for the purpose at hand. Conversely, a framework may deliberately accept lower short-term payout in exchange for greater long-term continuity, lower discretion, better cost discipline, or stronger compatibility with inheritance and capital preservation objectives.

Five structural questions

A serious decumulation framework must address at least five structural questions.

Income logic
How is payout determined? Is income fixed, discretionary, proportional to capital, smoothed, capped, or state-dependent?
Risk transmission
How much market volatility reaches the participant directly? Is volatility absorbed, pooled, delayed, smoothed, or simply passed through?
Capital treatment
Is capital assumed to be consumed, preserved, partially protected, or carried forward as an ongoing base?
Institutional form
Who implements the framework, and under what operational and governance conditions?
Governance
What keeps the framework stable over time? Is there certification, version control, or a discipline around structural recalibration?

Without answers to those questions, "decumulation strategy" often means little more than a payout suggestion. This is one reason the retirement field can appear crowded and incomplete at the same time: many products, many withdrawal ideas, many optimisation debates — but fewer clearly articulated frameworks that define what the payout phase is structurally for.

Where OLTIP Protocol sits

Seen in that light, decumulation is not only a portfolio problem. It is a design problem. It asks what kind of later-life financial experience an institution is trying to produce, under what constraints, and with what relationship between income, capital, flexibility, and continuity.

This is the sense in which OLTIP Protocol should be understood as a decumulation framework. OLTIP Protocol is not simply a withdrawal rule. It is a rule-based institutional architecture that defines payout logic, capital-preservation discipline, cost limits, governance conditions, and implementation boundaries. Its purpose is not only to support income, but to do so within a structure that does not begin from one-generation capital exhaustion as the default endpoint.

That does not make it universal. Not every retirement objective is the same. Some families will prefer certainty over continuity. Some will prioritise maximum current income. Others will want explicit longevity pooling or guaranteed floors. A good framework does not deny those differences. It makes them legible.

A decumulation framework does not eliminate trade-offs. It makes them explicit.

It does not eliminate risk. It defines how risk is handled.

And it does not answer only the question of how to withdraw. It answers the more important question of what the payout phase is designed to do.