rof-replication-and-data-policy

Review of Finance Replication And Data Policy

Use this before submission and after acceptance. Reopen the current RoF code-sharing and

data-availability policy before final packaging.

Package checklist

• Prepare replication programs with comments, software names, versions, package dependencies,

and execution order.

• Provide actual data when non-proprietary. If data are proprietary, prepare a pseudo-dataset

plus log files or other evidence required by current policy.

• Draft a Data Availability Statement and formatted dataset citations.
• Request any exception in the cover letter at initial submission when policy requires early

disclosure.

• Expect publication to wait until code is received when the policy applies.
• Package materials for OUP supplementary hosting rather than inventing a separate archive.

RoF replication packet

Build the packet around editorial risk:

• README states execution order, software, package versions, expected runtime, and output locations.
• data_manifest names every raw, intermediate, pseudo, and restricted dataset, with access status.
• run_all recreates each table, figure, and appendix exhibit or clearly marks non-runnable restricted

steps.

• logs prove that the submitted outputs were generated from the submitted programs.
• DAS and dataset citations match the manuscript, cover letter, and supplementary files.

For proprietary data, the pseudo-dataset is not decoration. It should let the editor see variable names,

file structure, merge keys, and code flow, while logs or other evidence document the confidential run.

Request exceptions at the earliest required stage; late exceptions create publication risk.

OUP supplementary package blueprint

rof_replication/
  README.md            run order, software + versions, runtime, output map
  data/raw/            non-proprietary inputs only, with dataset citations
  data/pseudo/         simulated rows mirroring restricted files (schema-true)
  code/01_build        cleaning: return screens, merges, winsorizing
  code/02_main         every body table and figure, numbered as in the paper
  code/03_appendix     internet-appendix exhibits
  logs/                full execution logs from the confidential run
  output/              regenerated exhibits, traceable to the submitted PDF

Finance-data shipping reality

| Source | Ships in the package? | What ships instead |

|---|---|---|

| CRSP / Compustat (WRDS) | No — licensed | exact query, extraction date, variable list, pseudo-rows |

| Datastream / Refinitiv | No | request scripts, screen list incl. dead-stock handling, pseudo-data |

| Bankscope / Orbis (BvD) | No; vintages also vanish | vintage date, consolidation filters, ID list if the license allows |

| ECB SDW / Eurostat | Usually yes | series codes plus download date, or the snapshot itself |

| Hand-collected (filings, prospectuses) | Yes — expected | the dataset plus the collection protocol |

| Proprietary (exchange, supervisor, bank) | No | pseudo-dataset, logs, access procedure, exception named in the cover letter |

Confirm the current shipping rules for each source against the journal's current author

guidelines and your own license terms before promising anything in the DAS.

Vintage and version control

• BvD products overwrite history: pin the Orbis/Bankscope vintage in the README and store

per-table row counts so the editor's office can audit drift in any re-pull.

• WRDS tables are backfilled; record extraction dates next to every query.
• Pin software environments (Stata version plus ado dates, renv or requirements files);

the expectation behind RoF's policy is that the editorial side can execute the package,

not reverse-engineer it.

Pre-acceptance dry run

• Clone the package to a clean machine or container and run only what the README says —

no tribal knowledge allowed.

• Trace every number in the submitted PDF to a line in output/; anything untraceable is

either a stale exhibit or a missing script.

• Run the pseudo-data through the full code path: identical merge keys, variable types,

and column order, so structure errors surface before the editor finds them.

• Reconcile four documents — manuscript DAS, cover letter, README, dataset citations

(Chicago style, matching the manuscript's reference format) — into one consistent story.

Worked exception case

Illustrative. A microstructure paper combines proprietary order-book data from a European

exchange with public Datastream prices. The packet ships: complete code; a pseudo

order-book with the true schema and fabricated quantities; logs from the confidential run;

Datastream request scripts; a cover-letter paragraph requesting the exception at initial

submission — the stage RoF requires — citing the exchange's redistribution restriction;

and a DAS routing readers to the exchange's access procedure. Publication then waits only

on packet verification, not a post-acceptance scramble. Verify the exact exception

mechanics against the journal's current author guidelines.

Output format

[Replication status] ready / needs fixes / exception needed
[Data status] public / proprietary / restricted / simulated
[Code status] complete / missing pieces / undocumented
[DAS] <draft or missing>
[Publication risk] <low/medium/high>