Data methodology · version 1.0

How exchangerate.dev builds and labels FX rates

Every rate is indicative. This page defines the public source classes, timestamps, market-session states, derivation rules, historical behavior, and limitations behind the API.

Published and last reviewed: July 16, 2026

1. Source classes

The public source field describes a data class, not a vendor. live is aggregated indicative spot data that can update on short intervals during the interbank trading week. ecb_daily is a European Central Bank reference rate, normally published once per business day. fred_daily is a daily series distributed by the Federal Reserve Bank of St. Louis.

A multi-currency response includes a sources map for each quoted currency. Its top-level source is conservative: it reports the least-fresh class present in that response.

Primary references: ECB euro reference exchange rates and FRED foreign-exchange series.

2. Time and market state

data_updated_at is the time the underlying observation was last written. timestamp is when the API response was built. Use the former to calculate data age and the latter to audit request timing.

market_session is open during the interbank week, weekend after the Friday 17:00 New York close until Sunday 17:00 New York, or interbank_closed for a known non-weekend closure. A weekend response can carry the final observation from the trading week; the label does not imply a fresh weekend quote.

3. Re-basing and derived crosses

Rates are normalized so callers can request any supported base. When a pair is not directly observed, the API triangulates it through available legs. Derived values are identified in derived_symbols; single-pair responses also expose derived and a derivation_bps_max bound when applicable.

A cross inherits the least-fresh source of its component legs. Applications that cannot accept a derived rate should check the derivation fields rather than infer from the currency pair.

4. Historical observations

Historical endpoints return daily reference observations. Coverage starts with the available ECB series in 1999; individual currencies can begin later. On a weekend or holiday with no new fix, a prior observation may be carried and is labeled is_forward_filled: true. The API does not fabricate an unpublished fix.

5. Validation and publication

  • Currency identifiers are normalized to uppercase ISO-style codes before pricing.
  • Source and update-time fields travel with the observation instead of being inferred by the client.
  • Live observations that are absent or too old fall back to an available daily reference class rather than being labeled live.
  • Every tier receives the same observations; quotas and rate limits do not change the data source.
  • Published research must include its measurement window, sample count, method, and limitations.

6. Limitations

These are indicative reference rates, not executable bid/ask quotes. They do not include a bank, card, broker, payment-provider, or cash-dealer spread and fee. They must not be used for settlement, payment execution, regulated trading, or as a source of record. Coverage and freshness can vary by currency, source availability, market closure, and the publication schedule of a reference institution.

7. Freshness benchmark standard

We publish the protocol before publishing a ranking. The reproducible FX API freshness benchmark defines the observation window, timestamp requirements, metrics, exclusions, and minimum sample size. Its machine-readable protocol currently contains no provider results; results will be added only after the stated evidence threshold is met.

Revision log

1.0 · July 16, 2026: Initial public methodology, source semantics, market-session rules, derivation policy, historical behavior, limitations, and benchmark publication standard.

Corrections: hello@exchangerate.dev