Supplementary guidance on benefit illustrations

Where values are unavailable, an appropriate ‘unavailable’ code (data standards 2.301/401) should be returned to explain the absence

ERI/accrued unavailable codes explain the absence of the values. An unavailable code (such as ‘DBC’/’DCC’ where values are being calculated) should always be returned where values cannot be returned. This should be done instead of simply not returning a benefit illustration, or not returning an ERI or accrued component within an illustration. See data standards paragraph 47:

Pension providers and schemes determine which unavailable code to return.

ERI or accrued value unavailable codes are returned within a benefit illustration object in the view JSON schema. The illustration object contains the ERI and accrued components, each of which allows the unavailable codes to be returned instead of values. Therefore, if either the ERI or accrued values are not available to return, an ERI/accrued component should still be returned as part of the benefit illustration object, containing one of the ‘unavailable’ codes.

For example, for a deferred defined benefit pension, for which only accrued values are to be returned, the benefit illustration should contain 2 components:

• 1 accrued component (containing the payable details)
• an ERI component (containing the ERI unavailable field 2.301 populated with the code ‘DB’).

The only exceptions are where ‘contact scheme’ (data standard 2.004) or ‘temporary system error’ (2.006) are populated ‘true’. In these cases, there may be no benefit illustration objects (because 2.004/6 are returned outside of benefit illustration objects, as objects themselves in the definite match arrangement). These codes enable pension providers and schemes to explain absence of information to users, but their use does not absolve the pension provider/scheme of its legal duties in respect of provision of information.

Where 2.004 and 2.006 do not apply, even where values are not available, a benefit illustration with ERI and accrued components, containing the appropriate unavailable code to explain the absence of the values, should be populated.

Returning a value unavailable code does not prevent values being returned in another illustration component. For example, if the ERI component contains the unavailable code, the accrued component can still contain values, or values could be provided in a separate benefit illustration (for example, values are returned for a separately-accrued lump sum but not for a recurring income).

Unavailable code for delayed calculations

If a calculation exceeds the timeframe permitted by the legislation, there is currently no code for data standards 2.301/401 to indicate that the time has expired but the calculation is still being worked on and will be provided late. In this scenario, pension providers and schemes should continue to apply ‘DCC’/’DBC’, unless another code is more appropriate.

We may introduce a new code in the next data standards update that explains that there has been a delay. Calculation times are reported under reporting standard 3.2, so regulators will have visibility where prescribed calculation times are exceeded.

The value data illustration date (data standard 2.501) is returned for the benefit illustration, not an ERI/accrued sub-component

The legislation requires the illustration date to be provided alongside the value data. The view JSON schema is structured such that this is returned at the level of the benefit illustration object, not the level of the ERI/accrued component within an illustration. Hence, the illustration date applies across both the ERI and accrued components within that benefit illustration (even where values are returned in one component but not another).

See data standards paragraphs:

This is illustrated in the view data model, where 3 items are grouped underneath a benefit illustration:

Each benefit illustration should therefore include an illustration date applying to both the ERI and accrued components. For example, in the case of a deferred defined benefit (DB) pension for which only accrued values are returned, the benefit illustration should still contain the illustration date. This applies even though the ERI component is only populated with the ERI unavailable code ‘DB’ for data standard 2.301, because the illustration date applies to the benefit illustration. The only exception where illustration date need not be returned for a benefit illustration would be where both the ERI and accrued components are populated with unavailable codes only – where, given the absence of any values, no illustration date applies.

Although in practical terms an illustration date is returned for each benefit illustration, the legislation nonetheless requires that all value data for a given scheme have the same illustration date. For occupational schemes, TPR’s guidance examines this and illustrates how different illustration dates could be a ‘green’ rated breach.

Multiple benefit illustrations should be used to return distinct benefits, not to return ERI and accrued components relating to the same benefit separately

The data standards support multiple benefit illustrations. The view JSON schema structures these as an array of benefit illustrations, each with an ERI and an accrued component, plus the illustration date – see diagram above. Multiple benefit illustration objects may be used to facilitate return of value data where the user has distinct benefits under the scheme. ‘Distinct benefits’ refers to there being distinct payment terms, for example, relating to type of benefit or period of payment, or distinct periods of accrual. See also PASA’s value data guidance, which covers benefits payable at different dates, step-ups and step-downs, multiple separate benefits in the same scheme, and additional voluntary contributions (AVCs).

A difference in benefit type (data standards 2.302/402), amount type (2.303/403) and payable dates (2.305/405) would all distinguish different benefits under the scheme, as might periods of membership. Scheme rules and existing communications to members may determine when benefits are to be split into distinct benefit illustrations.

Examples of separate benefits under the scheme to be returned as distinct benefit illustration objects include:

• a separately-accrued lump sum, and a recurring income
• different tranches of income, paid at different levels, paying and possibly ceasing on different dates
• a defined benefit pension and an AVC (where the AVC data is supplied by the main scheme rather than a separately connecting AVC provider)

For each of the member’s benefits under the scheme, the accrued value and the projected value form a twin pair, illustrating its current value and projected value. Each should therefore be returned within a distinct benefit illustration object, which groups together the ERI values, accrued values and illustration date, for each benefit.

See data standards paragraph 41:

For example, in a case where there is a separately-accrued lump sum and recurring income, 2 benefit illustration objects would be returned:

• one for the separately-accrued lump sum, with an accrued value, a projected value for this lump sum, and illustration date
• one for the recurring income, with the accrued value, ERI, and illustration date

Since distinct benefits should be returned as distinct benefit illustration objects, each benefit illustration object should usually only contain one ERI and one accrued component, not multiples of both. As per data standards paragraph 41:

For example, when returning ERI and accrued values for the same benefit, you should not send 2 benefit illustrations with the first containing only an ERI component and the second containing only an accrued component).

Where values are returned for a single benefit, such as a single recurring income for life only, a single benefit illustration object should be provided, containing both the ERI component, accrued component, and illustration date relating to that benefit.

Clarification to data standards paragraph 42

The data standards paragraph 42 states:

At the next available point when we update the data standards, we intend to change this paragraph as follows:

Support

Changelog

Last updated:05/06/2026