Review of Financial Studies

Data Editor Website

This website provides key information about the Code and Data Sharing Policy (CDSP) and the pre-acceptance reproducibility checks implemented at the Review of Financial Studies (RFS).

Process

The diagram below illustrates how authors interact with the CDSP and the RFS Data Editors (DE) throughout the editorial process.

%%{init: {"themeVariables": { "fontSize": "24px"}}}%%
flowchart LR
    subgraph Editors["**Editors**"]
        A[Submission]
        B[Revisions]
        C["Conditional Accept"]
        D[Accept]
    end

    subgraph DataEditors["**Data Editors**"]
        E[Onboarding]
        F[Review]
        G[Certification]
    end

    A --> B --> C
    C -.-> D

    C --> E --> F --> G --> D

    style A fill:#2a6197,stroke:#1b3f66,stroke-width:2px,color:white
    style E fill:#2a6197,stroke:#1b3f66,stroke-width:2px,color:white
    style F fill:#2a6197,stroke:#1b3f66,stroke-width:2px,color:white
    style G fill:#2a6197,stroke:#1b3f66,stroke-width:2px,color:white
    style D fill:#2a6197,stroke:#1b3f66,stroke-width:2px,color:white

  • Submission: Please read the Guidelines for Submission. Any requests for exemption from the CDSP must be made at the time of initial submission.
  • Onboarding: All conditionally accepted manuscripts enter the data editing process. At this point, a DE will assess whether a CDSP review is required. If a review is needed, the DE will contact the corresponding author with further instructions. Otherwise, the handling editor will be notified. For common issues that arise during onboarding, please consult the FAQs.
  • Review: Authors must prepare a replication package that complies with the CDSP and submit it via the RFS Dataverse. The package should be prepared for eventual public release and therefore must include pseudo or synthetic data in place of any non-public data. During the review phase, however, the package will remain private. Any issues encountered (e.g., execution errors or output discrepancies) will be resolved directly between the DE and the authors. The review process typically involves the following steps:
    1. The DE configures a secure, dedicated virtual environment for the authors, based on the instructions in the README.
    2. The DE verifies that the code executes successfully in this environment using the provided materials and may request revisions from the authors.
    3. Once the code runs successfully, the DE invites the authors to the environment to upload all required raw data that cannot be shared publicly.
    4. The DE verifies that the results reproduced in the authors’ environment match those reported in the submission.
    5. Upon successful verification, the DE releases the replication package on the RFS Dataverse and permanently and irrevocably deletes the virtual environment and along with any non-public data it contained.
  • Certification: If the replication package successfully reproduces the key tables and figures from the submission, the DE will notify the handling editor of successful certification. If, however, the package yields results that differ from those reported in the paper, the handling editor will decide whether to proceed with or reverse the original decision.
  • Accept: Upon final acceptance, authors must update and publish their replication package in the RFS Dataverse. The DE will then host the verified code and accompanying report in a public GitHub repository under the RFS organization.

Common Issues

Experience from prior reviews indicates that a limited set of recurring issues accounts for most delays during the data editor process. Many of these delays can be avoided by ensuring that the replication package includes a README that follows the Social Science Data Editors template (version 1.1) for standardized documentation, as well as a LICENSE file that clearly specifies the terms governing the use of the code and data.

Beyond these general requirements, the topics summarized below frequently arise during review and should ideally be addressed prior to submission:

Topic Stata Python R
Project execution Do not use cd to change directories within scripts. Launch Stata from the project root (e.g., open main.do in the root or use a Stata project file). Do not use os.chdir(). Run code from the project root (e.g., uv run python main.py or runpy.run_path()), with all paths relative to the root. Do not use setwd(). Run R from the project root (e.g., open the folder directly in RStudio, Positron, or VS Code).
File paths & portability Use relative paths with forward slashes (/). Avoid backslashes (\), which are Windows-specific. Use relative paths with forward slashes (/) or pathlib.Path. Avoid hard-coded absolute paths. Use relative paths with forward slashes (/). Do not rely on escaped backslashes (\\).
Dependency management Document the Stata environment and required packages in setup.do (ado-path included). Use reproducible, cross-platform lockfiles (e.g., uv) rather than pip freeze-based requirements.txt. Use renv.lock to document and restore the R environment.
Examples Stata project template Python project template R project template

Further Information

Contact

If you have any questions about the CDSP of the RFS and the above review process, please reach out to dataeditor@sfs.org. If you have submitted your paper, please add the assigned manuscript ID to your communication.

Currently, Christoph Scheuch and Patrick Weiss act as data editors for the RFS.