Event Study Course Project: Build and Defend a Market Hypothesis

A strong event-study project begins before the first return is calculated. The student has to state why an event could move price, who is constrained, when the information became tradable, and what pattern would reject the idea.

This is deliberately different from our list of event-study project ideas for MFE students. That page helps you choose a topic. This high-risk companion is the grading rubric for taking one topic from hypothesis to a result you can defend.

Write the research contract

Choose one recurring, dated, disclosed event class. A filing, earnings release, index change, merger completion, default notice, or lockup expiration can work. Write the economic mechanism in plain language and identify the participant expected to create pressure.

Then pin the sample before looking at forward returns. Define eligible securities, event types, date range, exclusions, benchmark, event window, and treatment of announcements outside market hours. Save that document with a timestamp because it is the contract your later analysis must honor.

• Hypothesis: the event creates a measurable return pattern through a named mechanism.
• Population: every eligible event under rules knowable at the time.
• Clock: the first tradable timestamp and day-zero convention.
• Outcome: raw and abnormal returns over fixed windows.
• Rejection: the evidence that would make you drop or narrow the claim.

Build point-in-time data

Create one event table with a stable identifier, source timestamp, event type, security identifier, and any classification fields used in the hypothesis. Preserve the raw source or accession reference so another researcher can trace every row.

Join market data without using today's universe to describe the past. Include delisted securities, symbol changes, corporate actions, and missing outcomes. If an event is amended or withdrawn, preserve the history and define which version was knowable at each decision time.

Make a data-quality report before the return study. Count duplicate events, missing prices, events outside trading hours, securities with short histories, and rows lost at every join. A polished final sample means little if half the original population disappeared silently.

Store exclusions as data rather than deleting them. Each dropped row should carry a reason code such as missing benchmark, ambiguous timestamp, insufficient price history, or duplicate disclosure. This makes the sample-selection process reproducible and lets the reviewer test how sensitive the conclusion is to each exclusion. A final count with no rejected-event ledger is difficult to audit.

Measure the distribution

Calculate raw and benchmark-adjusted returns for the predefined windows. Report count, mean, median, hit rate, quantiles, and cumulative path. Show the full distribution because a few extreme events can create an attractive average while most observations do little.

Split the sample only along dimensions justified before the test, such as event subtype, liquidity, sector, or signal strength. Label exploratory splits as exploratory. They can generate the next hypothesis and should not be presented as clean confirmation of the first one.

Include time. A result concentrated in one year or one market regime deserves a narrower interpretation. Rolling estimates, calendar subperiods, and a held-out final period help distinguish a repeated pattern from one historical episode.

Uncertainty belongs in the result table. Use standard errors or bootstrap intervals appropriate to the design, while accounting for repeated issuers and clustered event dates where possible. The point is not to decorate the mean with statistical notation. It is to show how much the estimate can move under reasonable resampling and how much evidence the sample truly contains.

1. Freeze the research contract and hash or date it.
2. Build the auditable event ledger.
3. Generate the data-quality report.
4. Calculate raw and abnormal return panels.
5. Inspect tails, subperiods, and justified cohorts.
6. Run the attacks before writing the conclusion.

Attack the favorite result

Shift the event clock by one defensible convention, change the benchmark, remove the largest winners, widen cost assumptions, and require stricter data quality. If the conclusion depends on one exact choice, say so. Fragility is a result, not an embarrassment.

Check overlapping events, clustering by security, multiple tests, and the possibility that the event merely proxies for size, distress, sector, or volatility. The project does not need to solve every causal question. It needs to state clearly what the evidence supports and what remains unresolved.

The Alphanume lesson on Event Windows and Study Design establishes the clock, day zero, and measurement choices used by later projects. Those decisions belong at the front because every attractive chart inherits them.

Defend the project

Submit the research contract, event ledger schema, quality report, reproducible code, result tables, attack memo, and a two-page defense. The defense should explain one choice you would change, one observation that surprised you, and one live condition that would invalidate the study.

Grade reproducibility with a clean-room rerun. A reviewer should be able to start from the documented raw inputs, execute the project in a fresh environment, and regenerate the tables without manual edits. Record the software versions and random seeds used by any resampling. If licensing prevents sharing raw data, provide the retrieval script, schema, checksums where allowed, and a small permitted fixture that exercises the full pipeline.

The quant course projects hub contains adjacent rubrics. A good event study earns credit for an honest negative result when the student can show that the mechanism, data, measurement, and attack were handled correctly. The process is the graded outcome.