Project Record

Calendar of Earnings

Summarize the Ionitsa project record titled "Calendar of Earnings" for a technical reader.
Cover the problem or research question, implementation or method, evidence or results, and limitations.
Separate facts stated on the page from your own assessment, note anything unclear or unverified, and avoid promotional language.

Primary source: https://ionitsa.com/projects/calendar-of-earnings.md
Canonical page: https://ionitsa.com/projects/calendar-of-earnings/

Latency-sensitive earnings-release intelligence for ~2,000 bond issuers—forecasting disclosure windows, monitoring issuer pages, and capturing PDFs before standard feeds.

Executive Summary

A hedge fund credit book covered roughly 2,000 issuers that were not publicly listed but had outstanding bonds. Earnings and financial disclosures often landed on issuer websites as PDFs—not through Bloomberg or a clean vendor calendar. Being early on those releases mattered: credit analysts and traders needed the numbers before the rest of the market had fully digested them.

I built an earnings-release intelligence system, not a passive calendar. It stored historical release dates and times per issuer, interpolated expected disclosure windows from that history, and spun up tight monitoring on the day of release. Lightweight page-change listeners polled issuer IR pages; when a PDF appeared, the pipeline downloaded it immediately and handed it to the document extraction stack. Operators worked from a Google Calendar view of the day’s expected events, but the real work was speed—forecast, watch, capture, parse.

This demonstrates event-risk forecasting from sparse historical data, low-latency change detection, and end-to-end research operations pipelines for less-covered credit names.

Problem

Standard event calendars do not cover private or thinly followed bond issuers reliably. Disclosure timing is irregular: the same company may release at 07:12 one quarter and 18:45 the next. Without a model of when to watch, teams either poll constantly (expensive, noisy) or miss the first minutes after publication.

We need a system that (1) maintains a historical record of release timestamps per issuer, (2) estimates the next expected release window from that history, (3) escalates monitoring intensity inside that window, (4) detects page or document changes with minimal latency, and (5) triggers immediate PDF download and extraction when a release lands.

Release-Time Model

For issuer $i$, let $\{t_{i,1}, \ldots, t_{i,n}\}$ be past release timestamps and $E_i$ the expected reporting date for the upcoming quarter (from fiscal calendar or prior pattern). Define day-offset residuals:

The forecast release time is the historical centre plus the next expected reporting anchor:

When sample size is small, fall back to sector or peer-group medians. The active watch window is a band around the forecast:

where $w_\pm$ widen for volatile issuers (high $\operatorname{IQR}(\Delta_{i,\cdot})$) and narrow as release day approaches. Polling frequency $f(t)$ increases inside $W_i$—sparse outside the window, aggressive near $\hat{t}_i$.

A simple readiness score for operator prioritisation:

Higher $s_i$ names surface first in the day’s calendar and receive dedicated listener capacity.

Detection Pipeline

Once $t \in W_i$, a change listener issues lightweight HTTP requests to the issuer’s disclosure URL and compares a content fingerprint $H_t$ to the previous state $H_{t-1}$. On $H_t \neq H_{t-1}$, the pipeline:

1. Resolves the new PDF link from the changed page.
2. Downloads the document immediately (parallel fetch, no batch queue).
3. Hands the file to the PDF extraction system for structured field parsing.
4. Records actual release time $t_{i,n+1}$ back into the historical store for the next forecast.

The listener layer favoured early, frequent probes over heavy parsing—speed on detection, depth on extraction downstream.

Implementation

• Historical store: per-issuer release timestamps, fiscal anchors, and residual statistics ($\Delta$, IQR, sample count).
• Forecast job: nightly refresh of $\hat{t}_i$ and $W_i$ for the coverage universe (~2,000 names).
• Calendar surface: Google Calendar integration for the operations view—each expected release as an event with watch-window bounds, so the team knew which names to expect on a given day.
• Monitoring: page-change listeners with escalating poll rates inside $W_i$; fingerprint diff rather than full DOM parse.
• Capture handoff: on PDF detection, direct download → extraction pipeline (see Financial Segment & Geography Parser); structured data points returned to research and risk systems.

Trade-offs

Historical interpolation works until an issuer changes disclosure practice—new IR site, different quarter timing, or a switch from PDF to HTML tables. Polling cost scales with coverage; widening $W_i$ reduces miss risk but burns requests on quiet names. Fingerprint diffs can false-positive on unrelated page edits (cookie banners, analytics scripts). The Google Calendar layer was operator-friendly but not the technical core; the value was in forecast accuracy and capture latency, not the calendar UI itself. For names with fewer than three historical releases, forecasts were noisy and windows stayed deliberately wide.

Related Work