Obscura

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.

Category Regulatory Columns 21 Refresh Every 6 hours Entity key subject_cik Point-in-time available_date

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.

ColumnTypeDescription
accessiontext · not nullPK. 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.
filenametext · not nullThe 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_datedatePublic 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_attimestamp with time zoneWhen 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_ofdateSEC'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_cikbigintCentral 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_nametextName of the filing party as EDGAR conforms it, e.g. `S&P Global Inc.`.
filer_sic_codeintegerThe 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_cikbigintCentral 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_nametextSubject company name as EDGAR conforms it.
subject_sic_codeintegerThe 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_incorporationtextSubject'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_numbertextThe 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_numbertextThe `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_filedboolean · not nullTRUE 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_cikbigintCIK 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_cikbigintCIK of the TARGET fund in a fund reorganisation, from the matching `<TARGET-DATA>` block. NULL on every non-fund communication.
document_countintegerNumber 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_typesjsonb · not nullOrdered 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_agreementboolean · not nullTRUE 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_descriptiontextThe 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.

Related datasets

CFTC Commitments of Traders (COT)The CFTC's weekly Commitments of Traders report: how commercial, non-commercial and small traders are positioned in each… EPA Environmental Enforcement ActionsEnvironmental enforcement actions and penalties from the EPA's ECHO database. One row per case, with the facility, the s… EPA Regulated Facilities and ComplianceEPA-regulated facilities and their compliance history, from ECHO: one row per facility, with location, industry, permit … 13F Filing MetadataMetadata for every 13F report, the quarterly filing where large institutional managers list their U.S. equity holdings. … 13F Institutional HoldingsThe line-item positions inside each 13F: which manager held which security, and how much, each quarter. Deep history is … 13F Other Included ManagersWhich other manager reports a fund's 13F holdings, from the 13F-NT notices managers file when their positions appear on … SEC 8-K Item Codes and Material EventsThe item numbers reported on each 8-K (5.02 officer changes, 2.01 acquisitions, 1.01 material agreements, and so on), so… Asset-Backed Securities Distributions (Form 10-D)Form 10-D distribution reports for asset-backed securities: which trust paid out, for which distribution period, its dep…