Policy Rates
The policy interest rate set by each currency's monetary authority, on every calendar day back to 1946 — twenty currencies including USD, EUR, JPY, GBP, CHF, CNY and SGD. Rates are carried forward across days on which the authority did not change them, with a flag marking which days were carried rather than published, so the series is dense enough to difference across currencies and still reversible to the real decision dates. The policy leg of a carry or rate-differential calculation.
policy_rates — the dataset name to pass to the Obscura API.
What one row means
One central-bank POLICY rate for one currency on one calendar day, in percent per annum — the headline rate the monetary authority has set (a target rate, a target-band midpoint, a discount or base rate, depending on the authority's own convention), carried forward across days on which it did not change. Twenty currencies: nineteen from the Bank for International Settlements' central-bank policy-rate panel (USD, JPY, AUD, EUR, CAD, CHF, NZD, GBP, SEK, NOK, DKK, PLN, CNY, BRL, TRY, RUB, ZAR, HKD, MXN), plus SGD from the Monetary Authority of Singapore, which the BIS daily panel does not carry. This is the policy leg of a carry or rate-differential calculation — the level, not an overnight market print (`nyfed_rates`) and not a spot FX quote (`fx_rates`). The panel is DENSE by construction: the underlying sources publish on a change, or on business days only, so every day between a currency's first observation and the newest day the source covers carries a row. Days whose value was carried forward rather than published are flagged by `is_carried_forward`, so the fill is reversible.
One row per (currency, occurred_on).
Point-in-time availability
Every Obscura dataset carries available_date: the calendar day the publisher made the row
available, day-of, with no session rounding. It is the one column a backtest filters on, and it means the
same thing on every dataset in the catalog.
For policy_rates: UNVERIFIED — deliberately, and this is the honest state rather than a gap nobody looked at. WHY: `available_date` is currently the rate's own day (`occurred_on`), which is a FLOOR on availability, not a proven publication date. Two candidate rules were measured and both were rejected. (1) `available_date = occurred_on`: a policy rate in force on a day was, for the modern era, announced publicly by the authority that set it on or before that day — but that is an argument about KNOWABILITY, not an observation of a publication event, so it is evidence class D and cannot be confirmed. (2) `available_date = occurred_on + a republication lag`: the BIS panel is republished WEEKLY (its own release calendar lists 137 dated releases from 2024-04-04 to 2026-11-26, almost all Thursdays; the release of 2026-07-23 carried daily values through 2026-07-21), so a day first appears in that archive between 2 and 9 calendar days later — but that lag is a property of the ARCHIVE, not of the rate, it is not a constant a generated column can express, and no release calendar exists for the 1946-2024 span at all. The archive is also fully RESTATED on every release: the source's own record of when an observation was last updated stamps the entire history with the current release, including series that permanently ended in 1998, so the day a given row FIRST became available is provably unrecoverable from the source. Evidence class D; see docs/availability/policy_rates.md. A consumer needing strict point-in-time behaviour should apply the documented 2-9 day republication lag themselves.
Refresh cadence
Obscura refreshes policy_rates daily — the most frequent scheduled job that re-collects or re-exports it. This is Obscura's own pipeline cadence, not the upstream publisher's release schedule; when a row became public is recorded per row in available_date.
Schema — 7 columns
The full public column list for policy_rates, with the meaning of every field. The same
schema is served unauthenticated at https://api.obscura.trade/v1/catalog/policy_rates.
| Column | Type | Description |
|---|---|---|
| currency | text · not null | ISO 4217 code of the currency the policy rate governs (`USD`, `EUR`, `JPY`, …). Composite primary key with `occurred_on`. Note the two codes that are routinely got wrong when this panel is mapped by hand: Denmark is `DKK` (not `DDK`) and China is `CNY` (not `CHN`, which is a country code, not a currency). |
| occurred_on | date · not null | The calendar day on which this rate was IN FORCE — the natural event day, not the day it became public. Composite primary key with `currency`. Every day is present, including weekends and holidays: a policy rate is a level that persists until the authority changes it, so a non-publishing day still has a rate (see `is_carried_forward`). |
| country_code | text · not null | ISO 3166-1 alpha-2 code of the jurisdiction whose authority sets the rate (`US`, `JP`, `SG`, …), or `XM` for the euro area, which is a currency union rather than a country. Carried alongside `currency` because the two are not interchangeable — one authority, one currency, many members. |
| rate | double precision · not null | The policy rate itself, in PERCENT PER ANNUM (3.625 means 3.625%, not 0.03625). What the number means in detail is the setting authority's own convention and differs across the panel — for the United States it is the midpoint of the federal funds target range from 1985-12-19 and the effective funds rate before that — so compare levels within a currency and differentials across currencies, rather than reading the panel as one homogeneous instrument. |
| is_carried_forward | boolean · not null | TRUE when this day's value was CARRIED FORWARD from an earlier observation rather than published for this day, FALSE when the source itself carried a value for this exact day. The underlying panels are sparse — an authority publishes on a change, or on business days only — and this dataset presents them on a dense daily calendar, which is what a rate-differential calculation needs. The flag keeps that transformation reversible: filter to `is_carried_forward = false` to recover the source's own observation days, or group by (currency, rate) to recover the dates a rate actually changed. |
| source | text · not null | Which publisher's panel this row came from: `BIS` for the nineteen currencies in the Bank for International Settlements' central-bank policy-rate panel, `MAS` for SGD, which that panel does not carry and which is taken from the Monetary Authority of Singapore's domestic interest rates series instead. A closed set, constrained in the schema. |
| available_date | date | The conformed point-in-time column — DB-generated (STORED) from `occurred_on`, read-only, never written by the collector. **This dataset's availability is UNVERIFIED**: the value is a floor (the rate was in force that day, and for the modern era the authority announced it that day), not a measured publication date, because the archive this data is collected from is republished weekly and fully restated, which destroys any record of when an individual row first became available. See the `availability` note on this dataset and `docs/availability/policy_rates.md` before using it for a point-in-time backtest. |
Access policy_rates
Two delivery paths, one identifier. Both require an Obscura account and an active subscription; the catalog entry and the schema above are public.
import obscura
client = obscura.Client("obs_live_…")
df = client.query(
dataset="policy_rates",
symbols=["NVDA", "AAPL"],
start="2024-01-01",
)Create a free account Browse all 95 datasets
Frequently asked questions
What is in the policy_rates dataset?
The policy interest rate set by each currency's monetary authority, on every calendar day back to 1946 — twenty currencies including USD, EUR, JPY, GBP, CHF, CNY and SGD. Rates are carried forward across days on which the authority did not change them, with a flag marking which days were carried rather than published, so the series is dense enough to difference across currencies and still reversible to the real decision dates. The policy leg of a carry or rate-differential calculation. One central-bank POLICY rate for one currency on one calendar day, in percent per annum — the headline rate the monetary authority has set (a target rate, a target-band midpoint, a discount or base rate, depending on the authority's own convention), carried forward across days on which it did not change. Twenty currencies: nineteen from the Bank for International Settlements' central-bank policy-rate panel (USD, JPY, AUD, EUR, CAD, CHF, NZD, GBP, SEK, NOK, DKK, PLN, CNY, BRL, TRY, RUB, ZAR, HKD, MXN), plus SGD from the Monetary Authority of Singapore, which the BIS daily panel does not carry. This is the policy leg of a carry or rate-differential calculation — the level, not an overnight market print (`nyfed_rates`) and not a spot FX quote (`fx_rates`). The panel is DENSE by construction: the underlying sources publish on a change, or on business days only, so every day between a currency's first observation and the newest day the source covers carries a row. Days whose value was carried forward rather than published are flagged by `is_carried_forward`, so the fill is reversible.
How do I avoid look-ahead bias with policy_rates?
Filter on policy_rates.available_date, the day the publisher made the row public. For this dataset that date is derived as follows — UNVERIFIED — deliberately, and this is the honest state rather than a gap nobody looked at. WHY: `available_date` is currently the rate's own day (`occurred_on`), which is a FLOOR on availability, not a proven publication date. Two candidate rules were measured and both were rejected. (1) `available_date = occurred_on`: a policy rate in force on a day was, for the modern era, announced publicly by the authority that set it on or before that day — but that is an argument about KNOWABILITY, not an observation of a publication event, so it is evidence class D and cannot be confirmed. (2) `available_date = occurred_on + a republication lag`: the BIS panel is republished WEEKLY (its own release calendar lists 137 dated releases from 2024-04-04 to 2026-11-26, almost all Thursdays; the release of 2026-07-23 carried daily values through 2026-07-21), so a day first appears in that archive between 2 and 9 calendar days later — but that lag is a property of the ARCHIVE, not of the rate, it is not a constant a generated column can express, and no release calendar exists for the 1946-2024 span at all. The archive is also fully RESTATED on every release: the source's own record of when an observation was last updated stamps the entire history with the current release, including series that permanently ended in 1998, so the day a given row FIRST became available is provably unrecoverable from the source. Evidence class D; see docs/availability/policy_rates.md. A consumer needing strict point-in-time behaviour should apply the documented 2-9 day republication lag themselves. A query of the form WHERE available_date <= '<as-of date>' never sees a row before it existed.
In what formats can I get policy_rates?
As a Parquet bulk export (POST https://api.obscura.trade/v1/download) or as JSON from the typed query API (POST https://api.obscura.trade/v1/query), both with dataset="policy_rates". The column schema is public at https://api.obscura.trade/v1/catalog/policy_rates.
Can I filter policy_rates by company or symbol?
Yes. policy_rates carries currency, the column the API's symbols filter resolves against.
How often is policy_rates updated?
Obscura refreshes policy_rates on a daily schedule — that is the most frequent scheduled job that re-collects or re-exports the table. It is Obscura's own pipeline cadence, not the upstream publisher's release schedule; when the publisher makes a row available is described by the availability rule above, and is recorded per row in available_date.