Aug. 22, 2026
I am submitting this public comment on File No. S7-2026-22, the Joint Request for Comment on Swap and Security-Based Swap Data Reporting. This responds primarily to Questions 12, 18, 19, and 25 concerning data consistency, corrections, machine-readable logic, and reference data that change over time. The Commissions should distinguish a stable identifier from the time-varying attributes resolved through that identifier. If an historical transaction contains a UPI, LEI, or other reference-data key but an analyst later resolves that key only against the current state of the reference dataset, the apparent attributes of the historical transaction can change even though the transaction record itself did not. That creates a reproducibility problem for regulatory analysis and public data use. Suggested principle: any reference data used to interpret a transaction should be temporally reproducible. A technology-neutral implementation could require, where a referenced attribute can change over time: effective-from/effective-to timestamps (or equivalent validity intervals) for reference-data states; a publication/release/version identifier for the reference-data set; retention of superseded reference-data states needed to reconstruct historical reports; transaction or repository logic that resolves the reference data applicable at the relevant reporting/effective time, rather than silently substituting the latest state; and documented rules for how retroactive corrections to reference data affect already reported transactions. Corrections should likewise preserve lineage rather than overwrite history. A corrected report should remain traceably related to the prior report/state, with enough information for regulators to distinguish (1) the transaction/lifecycle event changing, (2) a reporting error being corrected, and (3) a reference-data classification changing or being corrected. If the Commissions adopt machine-readable validation/reporting logic, each accepted report should be traceable to the applicable rule/specification version. Otherwise, a historical report can become difficult to reproduce after validation logic changes even if the submitted data are unchanged. Suggested conformance tests: Resolve the same 2025 transaction in 2026 after a referenced entity/product attribute changes; the system should reproduce the attribute state applicable to the historical record rather than silently use the current state. Correct a reference-data value retroactively; both the original interpretation and corrected interpretation should remain auditable, with the correction date and basis distinguishable from the transaction event time. Re-run an archived submission against a newer validation specification; the system should identify the rule version under which it was originally accepted and separately show the result under the newer rule set rather than rewriting acceptance history. Export/publicly disseminate historical data after reference-data updates; downstream users should be able to determine whether displayed attributes are as-reported/as-of-event or current enrichment. This approach does not require duplicating all reference data in every trade report. It requires the reporting ecosystem to preserve the minimum version/time linkage needed to reconstruct what a reference meant when it was used. The goal is to reduce reporting burden through shared reference data without making historical transaction meaning dependent on whatever the reference table happens to contain today.