Merger Communications (Rule 425)
Every communication filed under Rule 425 while a merger, acquisition or de-SPAC is pending - press releases, investor decks, employee memos and executed merger agreements. Each row is a dated pair: who filed it and which company it is about, with a CIK, SIC and file number on each side, plus the 333- registration the deal is being registered on.
edgar_merger_communications - the dataset name to pass to the Obscura API.
What one row means
One communication filed under **Securities Act Rule 425** - a press release, investor deck, employee memo or executed agreement published while a merger, acquisition or de-SPAC is pending. The prose is not the point and is not stored. The SGML header names **who filed it** and **which company it is about**, with a CIK on each, so every row is a *dated, directed communication* between two identified registrants - the only place on EDGAR where a proposed combination is stated as a relation between two CIKs on a specific day, without opening a single document. Roughly 41 % of communications name two different parties (an acquirer → target edge); the rest are a company announcing its own deal, which `is_self_filed` says explicitly rather than leaving a consumer to infer it from two equal CIKs. See `docs/datasets/edgar_merger_communications.md`.
One row per One row per Rule 425 communication, keyed by its ACCESSION. The key is the accession and NOT the archive path because EDGAR indexes one communication under one path PER associated CIK, and a 425 associates BOTH parties: measured over four dissemination days spanning 2015-2024, 124 index rows carry only 88 distinct communications, and every one of the 36 duplicated accessions is duplicated because the filer and the subject are different companies. Keying on the path would store every genuine acquirer -> target edge TWICE - precisely the rows this dataset exists for..
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 edgar_merger_communications: filing_join: available_date is the EDGAR DISSEMINATION day, taken from the bronze object's own day partition, never from the header's FILED AS OF DATE. Rule 425 carries no embargo - a communication is public the day EDGAR disseminates it - but the header's legal filing date is NOT that day: accession 0001144204-19-039613 was accepted 2019-08-15 12:38:55, stamped FILED AS OF DATE 20190813, and appears in the daily index for 2019-08-15 and in neither the 08-13 nor the 08-14 index. Dating that row from the header would be a two-day look-ahead.
Refresh cadence
Obscura refreshes edgar_merger_communications every 6 hours - 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 - 21 columns
The full public column list for edgar_merger_communications, with the meaning of every field. The same
schema is served unauthenticated at https://api.obscura.trade/v1/catalog/edgar_merger_communications.
| Column | Type | Description |
|---|---|---|
| accession | text · not null | PK. SEC accession number of the communication, e.g. `0001140361-24-024039`. The key is the accession, not the archive path: EDGAR lists a two-party 425 under the filer's CIK path AND the subject's. |
| filename | text · not null | The FILING party's SEC EDGAR Archives path for this communication (`edgar/data/{filer_cik}/{accession}.txt`), derived from the payload's own `FILED BY` CIK rather than from whichever index row was walked - so it is the same value on every ingestion path. The join key into `edgar_filings`. |
| available_date | date | Public availability date: the EDGAR DISSEMINATION day, recovered from the bronze object's day partition. A Rule 425 communication IS a publication, so this is both when it happened and when it could be read; it is the point-in-time anchor and the only date a backtest may key on. |
| accepted_at | timestamp with time zone | When SEC ACCEPTED the submission (`<ACCEPTANCE-DATETIME>`), US-Eastern wall clock stored under a UTC type. Deliberately NOT the availability date: an after-hours acceptance is disseminated the next morning (`0001193125-24-127736`, accepted 2024-05-01 18:38:58, public 2024-05-02). NULL on a row ingested from the dissemination feed rather than from Archives - the feed's PDS envelope does not carry this stamp, so a NULL here is a fact about the envelope and not a decoder gap. |
| filed_as_of | date | SEC's LEGAL filing date for the communication (`FILED AS OF DATE`), which is what a Rule 425 deadline means by "filed". Kept for parity with `edgar_filings`; never an availability date - SEC both back-dates it (measured two days on `0001144204-19-039613`) and rolls it forward past an after-hours acceptance. |
| filer_cik | bigint | Central Index Key of the party that FILED the communication - the acquirer, the SPAC, or the company itself. From the header's `FILED BY:` block. |
| filer_name | text | Name of the filing party as EDGAR conforms it, e.g. `S&P Global Inc.`. |
| filer_sic_code | integer | The FILING party's SIC code, read from its own header block - `6770` (BLANK CHECKS) identifies a SPAC filer directly. NULL when the filer's block states none, which really happens on foreign private issuers (`0001104659-24-056517`, Smurfit Kappa). |
| subject_cik | bigint | Central Index Key of the company the communication is ABOUT - the target, or the newly-formed holdco in a de-SPAC. From the header's `SUBJECT COMPANY:` block. |
| subject_name | text | Subject company name as EDGAR conforms it. |
| subject_sic_code | integer | The SUBJECT company's SIC code - the industry of the thing being acquired. Read from the subject's own header block: an unscoped read would return the same code for both parties and silently record the acquirer as being in the target's industry. |
| subject_state_of_incorporation | text | Subject's domicile from its own header block, e.g. `DE`, `E9` (Cayman), `D0` (Bermuda) - the offshore codes are what identify a de-SPAC or an inversion structure. |
| subject_file_number | text | The subject's SEC file number on this communication. Multi-modal, measured: `333-` (a Securities Act registration - the S-4/F-4 the deal registers on), `001-`/`000-` (Exchange Act listing), `811-`/`814-` (Investment Company Act / BDC), `132-`. Only the `333-` case links to a registration statement, which is what `registration_file_number` isolates. |
| registration_file_number | text | The `333-` registration number when `subject_file_number` is one, else NULL - the join to the S-4/F-4 and to `edgar_dilution_events`' registration rows. Derived, and the derivation is enforced by a CHECK rather than trusted. |
| is_self_filed | boolean · not null | TRUE when the filer and the subject are the same company - the row is a company's own deal announcement rather than a counterparty edge. The COMMON case: 52 of 88 communications measured across four dissemination days 2015-2024. |
| acquiring_cik | bigint | CIK of the ACQUIRING fund in a fund reorganisation, from the header's `<SERIES-AND-CLASSES-CONTRACTS-DATA><MERGER><ACQUIRING-DATA>` block. Present only on the fund shape, and it matters precisely there: a fund 425 is filed by the target on its own behalf, so `is_self_filed` is TRUE and the header's party pair carries no edge at all while SEC states the real direction here (`0001104659-15-038173`: 703153 acquires 352667). |
| target_cik | bigint | CIK of the TARGET fund in a fund reorganisation, from the matching `<TARGET-DATA>` block. NULL on every non-fund communication. |
| document_count | integer | Number of documents in the submission (`PUBLIC DOCUMENT COUNT:`) - a size/complexity proxy: 1 for a bare press release, 8 for an investor deck with seven images. |
| exhibit_types | jsonb · not null | Ordered JSON array of the submission's document types, e.g. `["425","EX-2.1"]` or `["425","GRAPHIC","GRAPHIC"]`. The manifest is kept; the bodies are NOT - measured at 3.1 MB/filing of images against 22 KB of text, and one sampled communication is 13.9 MB. |
| has_transaction_agreement | boolean · not null | TRUE when an `EX-2.x` (merger / business-combination / purchase agreement) rides on the submission - the filing publishes the EXECUTED deal document rather than commentary about it, which is a far stronger signal than the press release around it. |
| primary_description | text | The filer's own label for the primary document (`<DESCRIPTION>` on sequence 1), e.g. `425`, `FORM 425`, `CURRENT REPORT`. Free text and NOT a controlled vocabulary - useful as a communication-kind hint only. |
Access edgar_merger_communications
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="edgar_merger_communications",
symbols=["NVDA", "AAPL"],
start="2024-01-01",
)
Create a free account Browse all 122 datasets
Frequently asked questions
What is in the edgar_merger_communications dataset?
Every communication filed under Rule 425 while a merger, acquisition or de-SPAC is pending - press releases, investor decks, employee memos and executed merger agreements. Each row is a dated pair: who filed it and which company it is about, with a CIK, SIC and file number on each side, plus the 333- registration the deal is being registered on. One communication filed under **Securities Act Rule 425** - a press release, investor deck, employee memo or executed agreement published while a merger, acquisition or de-SPAC is pending. The prose is not the point and is not stored. The SGML header names **who filed it** and **which company it is about**, with a CIK on each, so every row is a *dated, directed communication* between two identified registrants - the only place on EDGAR where a proposed combination is stated as a relation between two CIKs on a specific day, without opening a single document. Roughly 41 % of communications name two different parties (an acquirer → target edge); the rest are a company announcing its own deal, which `is_self_filed` says explicitly rather than leaving a consumer to infer it from two equal CIKs. See `docs/datasets/edgar_merger_communications.md`.
How do I avoid look-ahead bias with edgar_merger_communications?
Filter on edgar_merger_communications.available_date, the day the publisher made the row public. For this dataset that date is derived as follows - filing_join: available_date is the EDGAR DISSEMINATION day, taken from the bronze object's own day partition, never from the header's FILED AS OF DATE. Rule 425 carries no embargo - a communication is public the day EDGAR disseminates it - but the header's legal filing date is NOT that day: accession 0001144204-19-039613 was accepted 2019-08-15 12:38:55, stamped FILED AS OF DATE 20190813, and appears in the daily index for 2019-08-15 and in neither the 08-13 nor the 08-14 index. Dating that row from the header would be a two-day look-ahead. A query of the form WHERE available_date <= '<as-of date>' never sees a row before it existed.
In what formats can I get edgar_merger_communications?
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="edgar_merger_communications". The column schema is public at https://api.obscura.trade/v1/catalog/edgar_merger_communications.
Can I filter edgar_merger_communications by company or symbol?
Yes. edgar_merger_communications carries subject_cik, the column the API's symbols filter resolves against.
How often is edgar_merger_communications updated?
Obscura refreshes edgar_merger_communications on a every 6 hours 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.