Robustness & Multiple-Testing Discipline (rfs-robustness)

When to trigger

• The main result holds in one specification but you have not stress-tested it
• A new return predictor / cross-sectional anomaly is the central claim
• You tested many candidate variables and want to report the ones that "worked"
• Reviewers will ask "does this survive [alternative spec / subsample / period]?"
• Results may be sensitive to outliers, windsorization, or a single event

The two robustness mandates at RFS

RFS punishes fragile results and, in cross-sectional asset pricing, undisciplined multiple testing. Build the battery proactively — a result that only the authors can reproduce in one specification is treated as no result.

Two RFS-specific mechanisms raise the bar above JF/JFE:

• Public code release is a condition of publication. Referees and post-publication readers can and do re-run your code. A robustness claim you cannot reproduce from the released code is a liability, not a footnote — design the battery so the released scripts regenerate every check.
• Registered Reports neutralize the multiple-testing critique by construction. Because RFS offers pre-results review (the format it pioneered in finance), pre-specifying the hypothesis and the test before seeing outcomes is the strongest possible answer to "you data-mined this." Even outside the Registered Report track, pre-specification is the RFS-preferred defense. The q-factor spanning logic of Hou, Xue, and Zhang (2015) "Digesting Anomalies" (RFS 28(3)) is a model for confronting the anomaly zoo head-on.