API Enterprise

Bank balance sheets and fundamentals, for every covered company in a region, as it was known on one date. One request replaces a per-ticker fan-out over the Bank Fundamentals dataset: each row is one company's latest published reading of one series for one entity it is reported under (a marque, a trial, a plant - named in entityRef), with its ORTEX company id beside it. A company reported under several entities has one row per entity.

Built for enterprise consumers: uncharged, and every row joins onto the rest of ORTEX on ortexCid.

Available Data Points:

• Date: The date the snapshot is as of (YYYY-MM-DD): every row is the latest reading published on or before this day, in UTC.
• Company: The name of the company issuing the security.
• Ortex Company ID: Unique id for a company.
• Period Date: The period the value describes — what the number is about (the valid clock).
• Published At: When the value first became knowable — when the publisher released it (the knowledge clock). Filter on this for anything where look-ahead bias would matter.
• Value: The numeric value, where the series has one.
• Value Text: The textual value, for categorical series such as a trial's status or phase.
• Unit: Unit of the value, e.g. vehicles, percent, USD.
• Value Type: number, percent, currency, count or text.
• Frequency: How often the publisher releases the series.
• Market: The market the reading describes — an ISO-3166 alpha-2 code (DE), a sub-national one (US-CA), a supranational aggregate (EA, EU) or GLOBAL.
• Series Slug: Which series the reading belongs to. Unique within a publisher, not globally.
• Series Name: Human-readable name of the series.
• Source Slug: Publisher/feed identifier, e.g. kba_registrations.
• Source Name: Human-readable name of the publisher or feed.
• Publisher: Who publishes the underlying data.
• Entity Ref: The publisher's own identifier for what the reading is about — a manufacturer name, a securitisation trust, a reactor unit, a country code. Kept so any value can be traced back to the row it was parsed from.

Coverage

Three regulators. The FDIC: all roughly 4,300 insured US charters, quarterly, about 30 days after quarter end. APRA: about 120 authorized deposit-taking institutions, monthly from March 2019, published on the last business day of the following month. OSFI: the Big Six plus Equitable Bank and Laurentian Bank alongside OSFI's all-banks total, monthly back to January 1996, about six weeks after the month closes.

The filing entity is not always the listed company. A US holding company may own several charters and most charters belong to no listed company at all; most Australian deposit-takers are mutuals or foreign branches with no ticker. Only a minority of rows carry a listing, by construction rather than through incomplete mapping.

What to look for

Ratios travel across banks; balance-sheet levels do not. return_on_assets and return_on_equity are comparable between institutions of any size; a loan or deposit balance is only meaningful against the same institution's own history, or as a share of the regulator's industry total, which APRA and OSFI publish beside every series.

In Canada the uninsured mortgage book is the line to watch: insured lending carries government-backed credit risk, uninsured is the bank's own, and a housing downturn shows there first. In Australia the owner-occupied against investor split is where the argument usually is.

Currencies differ by regulator (USD, AUD, CAD) and so do period lengths, so never add a US quarter to an Australian month. total_assets is published under that slug by both the FDIC and OSFI; pair it with market or source.

The date is the knowledge date, not the period

Every reading has two dates. periodDate is what the number is about; publishedAt is when it first became knowable. date selects on the second: the response holds, for each company, the most recent reading of each series that had been published by the end of date (UTC) - what ORTEX could have told you that evening.

That makes the snapshot dense and look-ahead-free. Monthly and quarterly series have a period once a month or once a quarter, so selecting on periodDate would return nothing on almost every day, and on the days it did would return readings not yet published - a backtest joined on them reads the future. Here, a July reading filed in mid-August first appears in the snapshot dated that August day, and every snapshot after it until the next period is published.

A publisher's restatement replaces the earlier value, so a restated period is absent from snapshots dated before the restatement was published; those snapshots report the previous period instead. The data errs toward staleness, never foresight. Each row still carries its own periodDate, so a stale reading is visible as one.

A reading stops being carried forward once its period is older than a bound set by the series' frequency - 45 days for daily and realtime series, 120 for weekly, 400 for monthly, 550 for quarterly, 1,100 for annual and 730 for event series (a series of any other frequency is not bounded) - so a company that has stopped reporting drops out rather than appearing with its last reading forever. Each bound allows several periods plus the slowest publisher's lag, so a release that is merely late is never dropped.

Filtering: one market or all of them

Called with no filters, the endpoint returns every series in the dataset, for every market ORTEX covers it in. Each row names its own market, seriesSlug and sourceSlug, so a single request is enough to chart the whole dataset.

Narrow it with any combination of market (one market), series (one measure) and source (one publisher). Filter values that are each valid but select nothing together return 400 invalidSelection rather than a misleading empty result.

Raw readings here; comparable ones next door

This endpoint serves the publisher's numbers. Raw values are frequently not comparable — receivables of $10.9bn against $4.9bn say nothing without each book's size, and a 5.3% charge-off rate means something different on a subprime book than a prime one. The Alt Data signals endpoint serves the same series as percentiles and z-scores against a stated comparison set, which is the form a screen or a backtest wants.

Why a company you expect may be missing

Three reasons, and none of them is a bug:

• The dataset is a window, not a census: Several of these publishers release a rolling window rather than a complete history.
• The filer is not the listed company: Registers name a marque, a charter or a trust. ORTEX maps those to the listed parent where the link is defensible and leaves them unmapped where it is not — a wrong mapping silently attributes another company's data to your ticker.
• The population is genuinely narrow: Not every listed company appears in every register, and no amount of mapping changes that.

A series slug identifies a series within a publisher, not globally

unemployment_rate is published under that exact slug by the US Bureau of Labor Statistics, the UK Office for National Statistics and Statistics Canada. Where a slug names more than one series in a dataset, passing it alone returns 400 invalidSeries listing the alternatives — pair it with market or source. ORTEX would rather refuse than hand you one country's print labelled as another's.

How much history there is

Several of these publishers overwrite their own pages and keep no archive. Where that is so, the series begins on the day ORTEX started capturing it and lengthens from there — nobody, including the publisher, can supply the days before that. Everything ORTEX has ever fetched is archived on capture, so the series only ever grows.

Company and region

Each row is about a company, so it carries the company's name (as it stood on the date the response is about) and ortexCid, the ORTEX company id - the key to join onto every other ORTEX dataset. Listing and security identifiers are deliberately absent: the reading describes the company, not one of its listings.

region selects the companies: a region name, an ISO-2 country code, or ALL (defaults to US). A company is placed by the country of the exchange of the listing ORTEX files each reading against, as it stood on the date the response is about - not by where it trades today, and not by its domicile. For a company listed in several countries the region follows that listing, so a reading ORTEX files against the company's listing in another region appears under that region instead.

Only readings ORTEX has attributed to a listed company are returned. A publisher entity ORTEX could not map to a listed parent has no exchange to place in a region, and is left out rather than guessed; the per-instrument endpoint documents the same mapping rules.

Every release, not only the latest

A snapshot keeps the latest reading per series, company and entity, so a series that published two periods since your last call shows only the newer one. To keep a complete copy of the dataset, use the published/ sibling of this endpoint, which returns every reading published in a date window.

Date-restricted keys

A key whose access is limited to a date range is held to it on the knowledge clock these endpoints select on: a snapshot date outside the range is refused, and a publication window is clipped to it (reported in meta.restriction). A reading published inside the range can describe a period before it, so periodDate values earlier than the range are expected.

Try it out! You can test the API with the trial key TEST. Simply include it in your request headers; either here, or add the header "Ortex-Api-Key": "TEST" to your http request.

Trial key restrictions: Trial keys may be limited to a specific date range and set of regions. Requests outside the allowed regions or entirely outside the allowed date range are rejected; a date window that partially overlaps the allowed range is trimmed to it, reported in meta.restriction.

Get full access! Contact [email protected]