Dates, Windows and Releases

Data Bank distinguishes an observation period, its calculation window, a curve/scenario snapshot date and the release that contains it. Keep these separate in both storage and presentation.

Date Selection

Use YYYY-MM for all market products and monthly mortgage/spread products. Use YYYY-MM-DD for daily rate references, curves and scenario snapshots. Do not send timestamps or time zones in these filters.

GET /v1/markets/series?dataset=price_bands&area=E08000025&price_band=3&from=2026-06&to=2026-06
GET /v1/rates/series?dataset=bank_rate&from=2026-09-01&to=2026-09-14

Valid dates outside retained history produce a successful empty selection with availability metadata. Partially overlapping requests return the available observations and a notice that the requested dates extend beyond history. No values are filled or moved to the nearest date. A Sunday can legitimately have no daily observation.

Rolling Windows

Market dates normally label the end of a rolling window:

Each next observation advances by one month. Adjacent windows overlap heavily. Do not sum 12 rolling sales counts and describe the result as annual sales: that repeatedly counts the same transactions. Nor should the change in a rolling statistic be labelled the change in activity during just the final month.

The customer's query range chooses which observations to return. It never changes a product's calculation window. A January-to-June query yields six monthly endpoints, not a newly calculated six-month aggregate.

Reporting Lag

Core PPD-dependent property products target T-3, where T is the release month. A September release therefore has a June core endpoint. This does not mean June registrations are final; later releases can revise them.

Rent follows the latest accepted rental observation, potentially ahead of core property data. It may be T-1 or T-2 depending on the source release; the API does not invent the missing months. A new rental publication can support a separate rent/yield supplement when approved, without relabelling the older capital series.

Rates do not use the property T-3 policy. Daily and monthly financing inputs retain their actual dates, so a daily scenario snapshot can legitimately use the most recent monthly mortgage evidence. There is no universal lag number for all rates products.

Mixed-Date Rental Yield

Estimated Gross Rental Yield may combine a newer rental estimate with an older capital estimate. For example:

• Rental endpoint: July 2026, with 12-month rental inputs.
• Capital endpoint: June 2026, with 24-month sale evidence.
• Yield endpoint: July 2026, with mixed_vintage: true and input_month_gap: 1.

The accepted contract limits this input gap to two months, with rent no earlier than capital. The response discloses each period. Show both dates rather than claiming the whole result is a July capital valuation.

A grouped latest query can therefore return July rent/yield and June property value. An exact July query can return no July capital observation while still returning July rent. This is not a reason to forward-fill or silently redownload a different metric month.

Curves and Scenario Dates

For curves, from and to select snapshot dates, not maturity dates. For scenarios, they select when the scenario was produced, not the dates it projects into.

horizon_month=24 describes a point 24 months after its snapshot. A five-year fixed interval beginning then ends at month 84. A one-month forward interval beginning at month 120 ends at month 121. Use the returned interval/projection dates rather than labelling every point as a single future day.

With no dates, a curve/path query selects the latest product snapshot before applying node filters. It must not mix different dates to construct a seemingly complete latest curve. A missing node at that snapshot is not silently substituted from an older snapshot.

Specifying a future to does not request forecasting. It filters already available observations. Use a scenario dataset and its horizon selectors for future assumptions.

Release Identity and Revisions

release_id identifies the immutable family package used to answer a request. Market and rates releases are independent. Their IDs need not match and their publication times need not coincide.

Omitting release_id selects the current available family release. Supplying it requests that retained release exactly. If it is unavailable, the request fails rather than substituting current data.

An observation date is not an information vintage. Asking for January 2020 in the current release returns the January 2020 observation as represented in that release, potentially revised since 2020. It does not reconstruct what a customer could have known in January 2020. Reproducible vintage analysis requires a genuinely retained release and its recorded identity.

For durable analysis, retain the family, release ID, dataset, selectors, series ID, observation period, value and units. Fetch later releases as distinct versions rather than silently replacing the provenance of an earlier result.

Refresh Behaviour and Availability

The service follows monthly property releases, business-day rate refreshes and monthly mortgage source updates. Publication depends on validation and source availability. If an update cannot be published, the current release retains its original observation dates. Refresh frequency is not a guaranteed delivery-time SLA.

The current response exposes dates and release state, not a universal is_fresh or stale flag. Evaluate recency for the specific product. Do not label any response "live market data" solely because it was fetched today.