# Regulation SBSR-Reporting and Dissemination of Security-Based Swap Information > Briefs, arguments, decisions, and more. URL: https://www.frixlaw.com/law-library/documents/fr%3A2015-03124 ## Record - **Collection:** Federal Register - **Document type:** Rule - **Published:** March 19, 2015 - **Citation:** 80 FR 14564 ## Text SECURITIES AND EXCHANGE COMMISSION 17 CFR Part 242 [Release No. 34-74244; File No. S7-34-10] RIN 3235-AK80 Regulation SBSR—Reporting and Dissemination of Security-Based Swap Information AGENCY: Securities and Exchange Commission. ACTION: Final rule. SUMMARY: In accordance with Section 763 and Section 766 of Title VII (“Title VII”) of the Dodd-Frank Wall Street Reform and Consumer Protection Act (the “Dodd-Frank Act”), the Securities and Exchange Commission (“SEC” or “Commission”) is adopting Regulation SBSR—Reporting and Dissemination of Security-Based Swap Information (“Regulation SBSR”) under the Securities Exchange Act of 1934 (“Exchange Act”). Regulation SBSR provides for the reporting of security-based swap information to registered security-based swap data repositories (“registered SDRs”) or the Commission, and the public dissemination of security-based swap transaction, volume, and pricing information by registered SDRs. Registered SDRs are required to establish and maintain certain policies and procedures regarding how transaction data are reported and disseminated, and participants of registered SDRs that are registered security-based swap dealers or registered major security-based swap participants are required to establish and maintain policies and procedures that are reasonably designed to ensure that they comply with applicable reporting obligations. Regulation SBSR contains provisions that address the application of the regulatory reporting and public dissemination requirements to cross-border security-based swap activity as well as provisions for permitting market participants to satisfy these requirements through substituted compliance. Finally, Regulation SBSR will require a registered SDR to register with the Commission as a securities information processor. DATES: Effective Date: May 18, 2015. Compliance Date: For Rules 900, 907, and 909 of Regulation SBSR, the compliance date is the effective date. For Rules 901, 902, 903, 904, 905, 906, and 908 of Regulation SBSR, compliance dates are being proposed in a separate release, 34-74245 (February 11, 2015). FOR FURTHER INFORMATION CONTACT: Michael Gaw, Assistant Director, at (202) 551-5602; Natasha Cowen, Special Counsel, at (202) 551-5652; Yvonne Fraticelli, Special Counsel, at (202) 551-5654; George Gilbert, Special Counsel, at (202) 551-5677; David Michehl, Special Counsel, at (202) 551-5627; Geoffrey Pemble, Special Counsel, at (202) 551-5628; Mia Zur, Special Counsel, at (202) 551-5638; all of the Division of Trading and Markets, Securities and Exchange Commission, 100 F Street NE., Washington, DC 20549-7010. SUPPLEMENTARY INFORMATION: Table of Contents I. Introduction A. Summary of Final Regulation SBSR B. Role of Registered SDRs C. Unique Identification Codes D. Public Dissemination and Block Trades E. Cross-Border Issues F. Compliance Dates II. Information Required To Be Reported A. Primary Trade Information—Rule 901(c) 1. Description of Re-Proposed Rule 2. Discussion of Final Rule 901(c) and Response to Comments a. General Approach to Required Information b. Rule 901(c)(1) i. Elimination of the Reference to Equity Derivatives ii. Product ID iii. Rule 901(c)(1)(i) iv. Rules 901(c)(1)(ii) and (iii) v. Rule 901(c)(1)(iv) vi. Rule 901(c)(1)(v) c. Rule 901(c)(2) d. Rule 901(c)(3) e. Rule 901(c)(4) f. Rule 901(c)(5) g. Rule 901(c)(6) h. Rule 901(c)(7) B. Rule 901(d)—Secondary Trade Information 1. Description of Proposed and Re-Proposed Rule 2. Final Rule 901(d) 3. Discussion of Final Rule 901(d) and Response to Comments a. Rule 901(d)(1)—Counterparty IDs b. Rule 901(d)(2)—Additional UICs i. Branch ID and Execution Agent ID ii. Revised Defined Terms in Rule 901(d)(2) iii. Response to Comments c. Rule 901(d)(3)—Payment Stream Information d. Rule 901(d)(4)—Titles and Dates of Agreements e. Rule 901(d)(5)—Other Data Elements f. Rule 901(d)(6)—Submission to Clearing g. Rule 901(d)(7)—Indication of Use of End-User Exception h. Rule 901(d)(8)—Description of Settlement Terms i. Rule 901(d)(9)—Platform ID j. Rule 901(d)(10)—Transaction ID of Any Related Transaction k. Information That Is Not Required by Rule 901(d) C. Reporting of Historical Security-Based Swaps 1. Statutory Basis and Proposed Rule 2. Final Rule and Discussion of Comments Received III. Where To Report Data A. All Reports Must Be Submitted to a Registered SDR B. Duties of Registered SDR Upon Receiving Transaction Reports 1. Rule 901(f)—Time Stamps 2. Rule 901(g)—Transaction IDs IV. How To Report Data—Rules 901(h) and 907 A. Introduction B. Rules 907(a)(1), 907(a)(2), and 901(h)—Data Elements and Formats C. Rule 907(a)(6)—Ultimate Parent IDs and Counterparty IDs V. Who Reports—Rule 901(a) A. Proposed and Re-Proposed Rule 901(a) B. Final Rule 901(a) 1. Reporting Hierarchy 2. Other Security-Based Swaps C. Discussion of Comments and Basis for Final Rule 1. Application of the Reporting Hierarchy to Sides 2. Reporting by Agents 3. Reporting Clearing Transactions 4. Reporting by a Platform 5. Reporting of a Security-Based Swap Resulting From a Life Cycle Event VI. Public Dissemination—Rule 902 A. Background B. Registered SDR's Duty To Disseminate—Rule 902(a) 1. Format of Disseminated Data 2. Timing of Public Dissemination 3. Dissemination of Life Cycle Events 4. Correction of Minor Drafting Error 5. Use of Agents by a Registered SDR To Carry out the Public Dissemination Function C. Definition of “Publicly Disseminate” D. Exclusions From Public Dissemination—Rule 902(c) 1. Discussion of Final Rule 2. Other Exclusions From Public Dissemination Sought by Commenters a. Customized Security-Based Swaps b. Inter-Affiliate Transactions c. Security-Based Swaps Entered Into in Connection With a Clearing Member's Default d. Total Return Security-Based Swaps e. Transactions Resulting From Portfolio Compression f. Thinly Traded Products E. Dissemination of Block Transactions—Rule 902(b) F. The Embargo Rule—Rule 902(d) G. Condition Flags—Rule 907(a)(4) VII. Block Trades and the Interim Phase of Regulation SBSR A. Proposed Rules Regarding Block Trades B. Potential Impact on Liquidity 1. T+24 Hour Reporting for All Transactions 2. Reporting Timeframe for Trades Executed Prior to Weekends or U.S. Federal Holidays 3. Other Revisions To Accommodate the Interim Approach 4. Dissemination of Notional Amount 5. Analysis Period VIII. Reporting and Public Dissemination of Security-Based Swaps Involving Allocation A. Discussion of Comments Received and Application of Regulation SBSR B. Example: Reporting and Public Dissemination for an Uncleared Bunched Order Execution 1. Reporting the Executed Bunched Order 2. Reporting the Allocations IX. Inter-Affiliate Security-Based Swaps A. Background and Summary of Final Rule B. Discussion of Comments 1. Regulatory Reporting of Inter-Affiliate Security-Based Swaps 2. Public Dissemination of Inter-Affiliate Security-Based Swaps X. Rule 903—Use of Codes A. Proposed Treatment of Coded Information B. Comments Received and Final Rule 903 1. Relocation of UIC Provisions Into Rule 903 2. Comments Regarding UICs and Final Rule 903(a) 3. Comments on Proposed Rule 903 and Final Rule 903(b) C. Policies and Procedures of Registered SDRs Relating to UICs XI. Operating Hours of Registered SDRs—Rule 904 XII. Subsequent Revisions to Reported Security-Based Swap Information A. Reporting Life Cycle Events—Rule 901(e) 1. Description of Proposal and Re-Proposal 2. Final Rules Relating to Life Cycle Events and Response to Comments a. General Comment and Definition of “Life Cycle Event” b. Final Rule 901(e)(1) c. Final Rule 901(e)(2) d. Reporting Timeframe for Life Cycle Events e. Re-Proposed Rule 901(e)(2) f. Additional Comments Regarding Life Cycle Event Reporting B. Error Corrections—Rule 905 C. Policies and Procedures for Reporting Life Cycle Events and Corrections XIII. Other Duties of Participants A. Duties of Non-Reporting Sides To Report Certain Information—Rule 906(a) B. Duty To Provide Ultimate Parent and Affiliate Information to Registered SDRs—Rule 906(b) C. Policies and Procedures of Registered Security-Based Swap Dealers and Major Security-Based Swap Participants To Support Reporting—Rule 906(c) XIV. Other Aspects of Policies and Procedures of Registered SDRs A. Public Availability of Policies and Procedures B. Updating of Policies and Procedures C. Provision of Certain Reports to the Commission XV. Rule 908—Cross-Border Reach of Regulation SBSR A. General Considerations B. Definition of “U.S. Person” C. Scope of Security-Based Swap Transactions Covered by Requirements of Regulation SBSR—Rule 908(a) 1. Transactions Involving a Direct Counterparty That Is a U.S. Person 2. Transactions Conducted Through a Foreign Branch or Office 3. Transactions Guaranteed by a U.S. Person 4. Transactions Accepted for Clearing by a U.S. Clearing Agency 5. Transactions Involving a Registered Security-Based Swap Dealer or Registered Major Security-Based Swap Participant That Is Not a U.S. Person 6. No Final Rule Regarding Transactions Conducted Within the United States D. Limitations on Counterparty Reporting Obligations—Rule 908(b) E. Substituted Compliance—Rule 908(c) 1. General Considerations 2. Substituted Compliance Procedure—Rule 908(c)(2)(i) 3 Security-Based Swaps Eligible for Substituted Compliance—Rule 908(c)(1) 4. Requests for Substituted Compliance—Rule 908(c)(2)(ii) 5 Findings Necessary for Substituted Compliance—Rule 908(c)(2)(iii) a. Data Element Comparability—Rule 908(c)(2)(iii)(A) b. Timeframe of Reporting and Public Dissemination—Rule 908(c)(2)(iii)(B) c. Direct Electronic Access—Rule 908(c)(2)(iii)(C) d. Trade Repository Capabilities—Rule 908(c)(2)(iii)(D) e. Memoranda of Understanding—Rule 908(c)(2)(iv) f. Modification or Withdrawal of Substituted Compliance Order 6. Consideration of Regulatory Reporting and Public Dissemination in the Commission's Analysis of Substituted Compliance XVI. Other Cross-Border Issues A. Foreign Public Sector Financial Institutions B. Foreign Privacy Laws Versus Duty To Report Counterparty IDs C. Antifraud Authority D. International Coordination Generally XVII. Rule 909—SIP Registration XVIII. Constitutional Questions About Reporting and Public Dissemination XIX. What Happens If There Are Multiple SDRs? XX. Section 31 Fees XXI. Paperwork Reduction Act A. Definitions—Rule 900 B. Reporting Obligations—Rule 901 1. Summary of Collection of Information 2. Use of Information 3. Respondents 4. Total Initial and Annual Reporting and Recordkeeping Burdens a. Baseline Burdens b. Burdens of Final Rule 901 5. Recordkeeping Requirements 6. Collection of Information Is Mandatory 7. Confidentiality of Responses to Collection of Information C. Public Dissemination of Transaction Reports—Rule 902 1. Summary of Collection of Information 2. Use of Information 3. Respondents 4. Total Initial and Annual Reporting and Recordkeeping Burdens 5. Recordkeeping Requirements 6. Collection of Information Is Mandatory 7. Confidentiality of Responses to Collection of Information D. Coded Information—Rule 903 1. Summary of Collection of Information 2. Use of Information 3. Respondents 4. Total Initial and Annual Reporting and Recordkeeping Burdens 5. Recordkeeping Requirements 6. Collection of Information Is Mandatory 7. Confidentiality of Responses to Collection of Information E. Operating Hours of Registered SDRs—Rule 904 1. Summary of Collection of Information 2. Use of Information 3. Respondents 4. Total Initial and Annual Reporting and Recordkeeping Burdens 5. Recordkeeping Requirements 6. Collection of Information Is Mandatory 7. Confidentiality of Responses to Collection of Information F. Correction of Errors in Security-Based Swap Information—Rule 905 1. Summary of Collection of Information 2. Use of Information 3. Respondents 4. Total Initial and Annual Reporting and Recordkeeping Burdens 5. Recordkeeping Requirements 6. Collection of Information Is Mandatory 7. Confidentiality of Responses to Collection of Information G. Other Duties of Participants—Rule 906 1. Summary of Collection of Information 2. Use of Information 3. Respondents 4. Total Initial and Annual Reporting and Recordkeeping Burdens a. For Registered SDRs b. For Participants i. Rule 906(a) ii. Rule 906(b) iii. Rule 906(c) 5. Recordkeeping Requirements 6. Collection of Information Is Mandatory 7. Confidentiality of Responses to Collection of Information H. Policies and Procedures of Registered SDRs—Rule 907 1. Summary of Collection of Information 2. Use of Information 3. Respondents 4. Total Initial and Annual Reporting and Recordkeeping Burdens 5. Recordkeeping Requirements 6. Collection of Information Is Mandatory 7. Confidentiality of Responses to Collection of Information I. Cross-Border Matters—Rule 908 1. Summary of Collection of Information 2. Use of Information 3. Respondents 4. Total Initial and Annual Reporting and Recordkeeping Burdens 5. Recordkeeping Requirements 6. Collection of Information Is Mandatory 7. Confidentiality of Responses to Collection of Information J. Registration of SDRs as Securities Information Processors—Rule 909 XXII. Economic Analysis A. Broad Economic Considerations B. Baseline 1. Current Security-Based Swap Market a. Security-Based Swap Market Participants i. Participant Domiciles ii. Current Estimates of Dealers and Major Participants iii. Security-Based Swap Data Repositories b. Security-Based Swap Transaction Activity c. Counterparty Reporting d. Sources of Security-Based Swap Information 2. Global Regulatory Efforts a. Dealer and Major Swap Participant Definitions for Cross-Border Security-Based Swaps b. International Regulatory Developments 3. Cross-Market Participation C. Programmatic Costs and Benefits of Regulation SBSR 1. Regulatory Reporting a. Programmatic Benefits b. Programmatic Costs i. Reporting Security-Based Swap Transactions to a Registered SDR—Rule 901 ii. Registered SDRs—Receipt and Processing of Security-Based Swap Transactions—Rule 901 2. Public Dissemination a. Programmatic Benefits b. Programmatic Costs c. Alternative Approaches to Public Dissemination 3. Interim Phase for Reporting and Public Dissemination a. Programmatic Benefits b. Programmatic Costs 4. Use of UICs a. Programmatic Benefits b. Programmatic Costs 5. Cross-Border Aspects of Regulation SBSR a. Programmatic Benefits b. Programmatic Costs c. Assessment Costs 6. Other Programmatic Effects of Regulation SBSR a. Operating Hours of Registered SDRs—Rule 904 b. Error Reporting—Rule 905 c. Other Participants' Duties—Rule 906 d. Registered SDR Policies and Procedures—Rule 907 e. SIP Registration by Registered SDRs—Rule 909 7. Definitions—Rule 900 D. Effects on Efficiency, Competition, and Capital Formation 1. Introduction 2. Regulatory Reporting 3. Public Dissemination 4. Implementation of Regulatory Reporting and Public Dissemination a. Role of Registered SDRs b. Interim Phase of Reporting Requirements and Block Rules c. Use of UICs and Rule 903 d. Rules Assigning the Duty To Report e. Embargo Rule 5. Impact of Cross-Border Aspects of Regulation SBSR a. General Considerations b. Regulatory Reporting and Public Dissemination c. Substituted Compliance E. Aggregate Quantifiable Total Costs XXIII. Regulatory Flexibility Act Certification XXIV. Statutory Basis and Text of Final Rules I. Introduction The Commission is adopting Regulation SBSR, which implements the requirements for regulatory reporting and public dissemination of security-based swap transactions set forth in Title VII of the Dodd-Frank Act. 1 The Dodd-Frank Act was enacted, among other reasons, to promote the financial stability of the United States by improving accountability and transparency in the financial system. 2 The 2008 financial crisis highlighted significant issues in the over-the-counter (“OTC”) derivatives markets, which experienced dramatic growth in the years leading up to the financial crisis and are capable of affecting significant sectors of the U.S. economy. Title VII of the Dodd-Frank Act provides for a comprehensive new regulatory framework for swaps and security-based swaps, by, among other things: (1) Providing for the registration and comprehensive regulation of swap dealers, security-based swap dealers, major swap participants, and major security-based swap participants; (2) imposing clearing and trade execution requirements on swaps and security-based swaps, subject to certain exceptions; (3) creating recordkeeping, regulatory reporting, and public dissemination requirements for swaps and security-based swaps; and (4) enhancing the rulemaking and enforcement authorities of the Commission and the Commodity Futures Trading Commission (“CFTC”). 1 Public Law 111-203, 124 Stat. 1376 (2010). 2 See Public Law 111-203, Preamble. The Commission initially proposed Regulation SBSR in November 2010. 3 In May 2013, the Commission re-proposed the entirety of Regulation SBSR as part of the Cross-Border Proposing Release 4 and re-opened the comment period for all of its other outstanding Title VII rulemakings. 5 3 See Securities Exchange Act Release No. 63346 (November 19, 2010), 75 FR 75207 (December 2, 2010) (“Regulation SBSR Proposing Release”). 4 See Securities Exchange Act Release No. 69490 (May 1, 2013), 78 FR 30967 (May 23, 2013) (“Cross-Border Proposing Release”). 5 See Securities Exchange Act Release No. 69491 (May 1, 2013), 78 FR 30799 (May 23, 2013). The Commission received 86 comments that were specifically directed to the comment file (File No. S7-34-10) for the Regulation SBSR Proposing Release, of which 38 were comments submitted in response to the re-opening of the comment period. 6 Of the comments directed to the comment file (File No. S7-02-13) for the Cross-Border Proposing Release, six referenced Regulation SBSR specifically, while many others addressed cross-border issues generally, without specifically referring to Regulation SBSR. The Commission also has considered other comments germane to regulatory reporting and/or public dissemination of security-based swaps that were submitted in other contexts. The comments discussed in this release are listed in the Appendix to the release. 6 However, one comment that was specifically directed to the comment file for the Regulation SBSR Proposing Release exclusively addressed issues related to clearing “debt swaps.” See Hamlet Letter. Because the subject matter of this comment letter is beyond the scope of Regulation SBSR, the Commission is not addressing this comment. The Commission is now adopting Regulation SBSR largely as re-proposed, with certain revisions suggested by commenters or designed to clarify the rules. In addition, in separate releases, as discussed below, the Commission also is adopting rules relating to SDR registration, duties, and core principles (the “SDR Adopting Release”) 7 and is proposing certain rules, amendments, and guidance relating to Regulation SBSR (“Regulation SBSR Proposed Amendments Release”). 8 The principal aspects of Regulation SBSR—which, as adopted, consists of ten rules, Rules 900 to 909 under the Exchange Act 9 —are briefly described immediately below. A detailed discussion of each rule within Regulation SBSR, as well as how these rules interact with the rules in the SDR Adopting Release, follows in the body of this release. 10 7 See Securities Exchange Act Release No. 74246 (February 11, 2015). 8 See Securities Exchange Act Release No. 74245 (February 11, 2015). 9 15 U.S.C. 78a et seq. All references in this release to the Exchange Act refer to the Securities Exchange Act of 1934. 10 If any of the provisions of these rules, or the application thereof to any person or circumstance, is held to be invalid, such invalidity shall not affect other provisions or application of such provisions to other persons or circumstances that can be given effect without the invalid provision or application. A. Summary of Final Regulation SBSR Rule 900, as adopted, sets forth the definitions used throughout Regulation SBSR. The defined terms are discussed in connection with the rules in which they appear. Rule 901(a), as adopted, assigns the reporting obligation for all security-based swaps except for the following: (1) Clearing transactions; 11 (2) security-based swap transactions executed on a platform 12 that will be submitted to clearing; (3) transactions where there is no U.S. person, registered security- based swap dealer, or registered major security-based swap participant on either side; and (4) transactions where there is no registered security-based swap dealer or registered major security-based swap participant on either side and there is a U.S. person on only one side. For purposes of this release, the Commission uses the term “covered transactions” to refer to all security-based swaps other than those listed in the four categories above; all covered transactions shall be reported in the manner set forth in Regulation SBSR, as adopted. For covered transactions, Rule 901(a) assigns the duty to report to one side of the transaction (the “reporting side”). The “reporting hierarchy” established in Rule 901(a) is based, where possible, on the registration status ( e.g., registration as a security-based swap dealer or major security-based swap participant) of the direct and indirect counterparties to the transaction. In the Regulation SBSR Proposed Amendments Release, the Commission is proposing amendments to Rule 901(a) that would impose reporting obligations for security-based swaps in categories one and two above ( i.e., clearing transactions and security-based swap transactions executed on a platform and that will be submitted to clearing). 11 A “clearing transaction” is defined as “a security-based swap that has a registered clearing agency as a direct counterparty.” See Rule 900(g). 12 A “platform” is defined as a “national securities exchange or security-based swap execution facility that is registered or exempt from registration.” See Rule 900(v); infra note 199 and accompanying text (discussing the definition of “platform”). Rule 901(b), as adopted, provides that if there is no registered security-based swap data repository (“SDR”) that will accept the report, the reporting side must report the transaction to the Commission. 13 13 A “registered security-based swap data repository” is defined as “a person that is registered with the Commission as a security-based swap data repository pursuant to Section 13(n) of the Exchange Act (15 U.S.C. 78m(n)) and any rules or regulations thereunder.” See Rule 900(ff). Rule 901(c) sets forth the primary trade information and Rule 901(d) sets forth the secondary trade information that must be reported. For most transactions, the Rule 901(c) information will be publicly disseminated. Information reported pursuant to Rule 901(d) is for regulatory purposes only and will not be publicly disseminated. Rule 901(e) requires the reporting of life cycle events to the entity to which the original transaction was reported. Rule 901(i) requires reporting, to the extent the information is available, of security-based swaps entered into before the date of enactment of the Dodd-Frank Act (“pre-enactment security-based swaps”) and security-based swaps entered into after the date of enactment but before Rule 901 becomes fully operative (“transitional security-based swaps”). B. Role of Registered SDRs Rule 902(a) requires a registered SDR to publicly disseminate a transaction report immediately upon receipt of information about a security-based swap, except in certain limited circumstances. Pursuant to Rule 902(a), the published transaction report must consist of all the information reported pursuant to Rule 901(c), plus any condition flag contemplated by the registered SDR's policies and procedures that are required by Rule 907. Rule 901(f) requires a registered SDR to timestamp any information submitted to it pursuant to Rule 901(c), (d), (e), or (i), and Rule 901(g) requires a registered SDR to assign a transaction ID to each security-based swap. Rule 907(a) requires a registered SDR to establish and maintain written policies and procedures that detail how it will receive and publicly disseminate security-based swap transaction information. For example, Rule 907(a)(1) requires policies and procedures that enumerate the specific data elements of a security-based swap that must be reported to the registered SDR, including the data elements specified in Rules 901(c) and 901(d). Rule 907(a)(2) requires policies and procedures that specify one or more acceptable data formats, connectivity requirements, and other protocols for submitting information. Rules 907(a)(3) and 907(a)(4) require policies and procedures for assigning condition flags to the appropriate transaction reports. In addition, Rule 907(c) requires a registered SDR to make its policies and procedures available on its Web site. Rule 907(e) requires a registered SDR to provide to the Commission, upon request, information or reports related to the timeliness, accuracy, and completeness of data reported to it pursuant to Regulation SBSR and the registered SDR's policies and procedures established thereunder. Finally, Rule 909 requires a registered SDR also to register with the Commission as a securities information processor (“SIP”). C. Unique Identification Codes Rule 903 requires a registered SDR to use “unique identification codes” (“UICs”) to specifically identify a variety of persons and things. The following UICs are specifically required by Regulation SBSR: Counterparty ID, product ID, transaction ID, broker ID, branch ID, trading desk ID, trader ID, platform ID, and ultimate parent ID. Rule 906(b) requires each participant of a registered SDR to provide the registered SDR with information sufficient to identify the participant's ultimate parent(s) and any affiliate(s) of the participant that are also participants of the registered SDR. Rule 903(a) provides that, if an internationally recognized standards-setting system (“IRSS”) meeting certain criteria is recognized by the Commission and has assigned a UIC to a person, unit of a person, or product (or has endorsed a methodology for assigning transaction IDs), that UIC must be used by all registered SDRs and their participants in carrying out duties under Regulation SBSR. If the Commission has not recognized an IRSS—or if the Commission-recognized IRSS has not assigned a UIC to a particular person or thing—the registered SDR is required to assign a UIC using its own methodology. Additionally, Rule 903(a) provides that, if the Commission has recognized such a system that assigns UICs to persons, each participant of a registered SDR shall obtain a UIC from or through that system for identifying itself, and each participant that acts as a guarantor of a direct counterparty's performance of any obligation under a security-based swap that is subject to Rule 908(a) shall, if the direct counterparty has not already done so, obtain a UIC for identifying the direct counterparty from or through that system, if that system permits third-party registration without a requirement to obtain prior permission of the direct counterparty. As discussed further in Section X(B)(2), infra, the Commission recognizes the Global LEI System (“GLEIS”), administered by the Regulatory Oversight Committee (“ROC”), as meeting the criteria specified in Rule 903. The Commission may, on its own initiative or upon request, evaluate other IRSSs and decide whether to recognize such other systems. D. Public Dissemination and Block Trades Section 13(m)(1)(B) of the Exchange Act 14 authorizes the Commission “to make security-based swap transaction and pricing data available to the public in such form and at such times as the Commission determines appropriate to enhance price discovery.” Section 13(m)(1)(C) of the Exchange Act 15 identifies four categories of security-based swaps and authorizes the Commission “to provide by rule for the public availability of security-based swap transaction, volume, and pricing data.” Section 13(m)(1)(C) further provides that, with respect to each of these four categories of security-based swaps, “the Commission shall require real-time public reporting for such transactions.” Section 13(m)(1)(D) of the Exchange Act 16 provides that the Commission may require registered entities (such as registered SDRs) to publicly disseminate the security-based swap transaction and pricing data required to be reported under Section 13(m) of the Exchange Act. Finally, Section 13(n)(5)(D)(ii) of the Exchange Act 17 requires SDRs to provide security-based swap information “in such form and at such frequency as the Commission may require to comply with public reporting requirements.” 14 15 U.S.C. 78m(m)(1)(B). 15 15 U.S.C. 78m(m)(1)(C). 16 15 U.S.C. 78m(m)(1)(D). 17 15 U.S.C. 78m(n)(5)(D)(ii). Under Rule 902, as adopted, a registered SDR must, immediately upon receiving a transaction report of a security-based swap, publicly disseminate the primary trade information of that transaction, along with any condition flags. In addition, Section 13(m)(1)(E) of the Exchange Act 18 requires the Commission rule for real-time public dissemination of cleared security-based swaps to: (1) “specify the criteria for determining what constitutes a large notional security-based swap transaction (block trade) for particular markets and contracts”; and (2) “specify the appropriate time delay for reporting large notional security-based swap transactions (block trades) to the public.” Section 13m(1)(E)(iv) of the Exchange Act 19 requires the Commission rule for real-time public dissemination of security-based swaps that are not cleared at a registered clearing agency but reported to a registered SDR to contain provisions that “take into account whether the public disclosure [of transaction and pricing data for security-based swaps] will materially reduce market liquidity.” 18 15 U.S.C. 13m(m)(1)(E). 19 15 U.S.C. 13m(m)(1)(E)(iv). As discussed in detail below, in response to the comments received and in light of the fact that the Commission has not yet proposed block thresholds, the Commission is adopting final rules that require all security-based swaps—regardless of their notional amount—to be reported to a registered SDR at any point up to 24 hours after the time of execution. 20 The registered SDR will be required, as with all other dissemination-eligible transactions, to publicly disseminate a report of the transaction immediately and automatically upon receipt of the information from the reporting side. 20 As discussed in more detail in Section VII(B), infra, if reporting would take place on a non-business day ( i.e., a Saturday, Sunday or U.S. federal holiday), reporting would instead be required by the same time on the next business day. Although the Commission is adopting final rules relating to regulatory reporting and public dissemination of security-based swaps, it intends for the rules relating to public dissemination to apply only on an interim basis. This interim approach is designed to address the concerns of commenters who believed that a public dissemination regime with inappropriately small block trade thresholds could harm market liquidity, and who argued that market participants would need an extended phase-in period to achieve real-time reporting. In connection with its future rulemaking about block thresholds, the Commission anticipates seeking public comment on issues related to block trades. Given the establishment of this interim phase, the Commission is not adopting any other proposed rules relating to block trades. E. Cross-Border Issues Regulation SBSR, as initially proposed, included Rule 908, which addressed when Regulation SBSR would apply to cross-border security-based swaps and counterparties of security-based swaps. The Commission re-proposed Rule 908 with substantial revisions as part of the Cross-Border Proposing Release. The Commission is now adopting Rule 908 substantially as re-proposed with some modifications, as discussed in Section XV, infra. 21 21 The Commission anticipates seeking further public comment on the application of Regulation SBSR to: (1) Security-based swaps where there is no U.S. person, registered security-based swap dealer, or registered major security-based swap participant on either side; and (2) transactions where there is no registered security-based swap dealer or registered major security-based swap participant on either side and there is a U.S. person on only one side. Under Rule 908, as adopted, any security-based swap involving a U.S. person, whether as a direct counterparty or as a guarantor, must be reported to a registered SDR, regardless of where the transaction is executed. 22 Furthermore, any security-based swap involving a registered security-based swap dealer or registered major security-based swap participant, whether as a direct counterparty or as a guarantor, also must be reported to a registered SDR, regardless of where the transaction is executed. In addition, any security-based swap that is accepted for clearing by a registered clearing agency having its principal place of business in the United States must be reported to a registered SDR, regardless of the registration status or U.S. person status of the counterparties and regardless of where the transaction is executed. 22 See also Section II(B)(3) and note 139, infra (describing the type of guarantees that could cause a transaction to be subject to Regulation SBSR). In the Cross-Border Proposing Release, the Commission proposed a new paragraph (c) to Rule 908, which contemplated a regime for allowing “substituted compliance” for regulatory reporting and public dissemination with respect to individual foreign jurisdictions. Under this approach, compliance with the foreign jurisdiction's rules could be substituted for compliance with the Commission's Title VII rules, in this case Regulation SBSR. Final Rule 908(c) allows interested parties to request a substituted compliance determination with respect to a foreign jurisdiction's regulatory reporting and public dissemination requirements, and sets forth the standards that the Commission would use in determining whether the foreign requirements were comparable. F. Compliance Dates For Rules 900, 907, and 909 of Regulation SBSR, the compliance date is the effective date of this release. For Rules 901, 902, 903, 904, 905, 906, and 908 of Regulation SBSR, a new compliance schedule is being proposed in the Regulation SBSR Proposed Amendments Release. Accordingly, compliance with Rules 901, 902, 903, 904, 905, 906, and 908 is not required until the Commission establishes compliance dates for those rules. Rules 910 and 911, as proposed and re-proposed, would have established compliance dates and imposed certain restrictions, respectively, during Regulation SBSR's phase-in period. For reasons discussed in the Regulation SBSR Proposed Amendments Release, the Commission has determined not to adopt Rule 910 or 911. 23 23 Thus, Regulation SBSR, as adopted, consists of Rules 900 through 909 under the Exchange Act. Conforming changes have been made throughout Regulation SBSR to replace references to “§§ 242.900 through 242.911” to “§§ 242.900 through 242.909.” In addition, the defined terms “registration date” and “phase-in period” which appeared in re-proposed Rules 910 and 911, respectively, are not being defined in final Rule 900. II. Information Required To Be Reported A. Primary Trade Information—Rule 901(c) 1. Description of Re-Proposed Rule Rule 901(c), as re-proposed, would have required the reporting of the following primary trade information in real time, which information would then be publicly disseminated: (1) The asset class of the security-based swap and, if the security-based swap is an equity derivative, whether it is a total return swap or is otherwise designed to offer risks and returns proportional to a position in the equity security or securities on which the security-based swap is based; (2) information that identifies the security-based swap instrument and the specific asset(s) or issuer(s) of any security on which the security-based swap is based; (3) the notional amount(s), and the currenc(ies) in which the notional amount(s) is (are) expressed; (4) the date and time, to the second, of execution, expressed using Coordinated Universal Time (UTC); (5) the effective date; (6) the scheduled termination date; (7) the price; (8) the terms of any fixed or floating rate payments, and the frequency of any payments; (9) whether or not the security-based swap will be cleared by a clearing agency; (10) if both counterparties to a security-based swap are registered security-based swap dealers, an indication to that effect; (11) if applicable, an indication that the transaction does not accurately reflect the market; and (12) if the security-based swap is customized to the extent that the information in items (1) through (11) above does not provide all of the material information necessary to identify such customized security-based swap or does not contain the data elements necessary to calculate the price, an indication to that effect. 2. Discussion of Final Rule 901(c) and Response to Comments a. General Approach to Required Information Rules 901(c) and 901(d), as adopted, require the reporting of general categories of information, without enumerating specific data elements that must be reported, except in limited cases. The Commission has made minor revisions to the introductory language of Rule 901(c). 24 24 The first sentence of re-proposed Rule 901(c), which would have required real-time public dissemination of certain data elements, would have stated, in relevant part, “For any security-based swap that must be publicly disseminated pursuant to §§ 242.902 and 242.908 and for which it is the reporting side, the reporting side shall report the following information . . .” The information required to be reported pursuant to Rule 901(c) must be reported for all covered transactions, even though Rule 902(c) provides that certain security-based swap transactions are not subject to public dissemination. Accordingly, the Commission is not including in final Rule 901(c) the phrase “For any security-based swap that must be publicly disseminated pursuant to §§ 242.902 and 242.908 and for which it is the reporting side . . .” In addition, as discussed in Section VII(B)(1), infra , Rule 901(c), as adopted, provides that the reporting side shall report the information specified in Rule 901(c) within the timeframe specified by Rule 901(j). In addition, Rule 907(a)(1), as adopted, requires each registered SDR to establish, maintain, and make publicly available policies and procedures that, among other things, specify the data elements that must be reported. 25 Commenters expressed mixed views regarding this approach. One commenter expressed the view that “any required data should be clearly established by the Commission in its rules and not decided in part by [SDRs].” 26 This commenter further asked the Commission to clarify that any additional fields provided by registered SDRs for reporting would be optional. 27 Two commenters, however, supported the Commission's approach of providing registered SDRs with the authority to define relevant fields on the basis of general guidelines as set by the SEC. 28 One of these commenters noted that it would be difficult for the Commission to specify the security-based swap data fields because security-based swaps are complex products that may require a large number of data fields to be electronically confirmed. 29 In addition, the commenter stated that electronic methods for processing existing and new security-based swaps continue to be developed; accordingly, the commenter stated that establishing a detailed list of reportable fields for each category of security-based swap would be impracticable because such a system “will be outdated with every new product launch or change in market practice,” and would result in a “regulatory scheme that is continuously lagging behind the market.” 30 The commenter cautioned, however, that the Commission must assure that there is consistency among the data fields collected and reported by registered SDRs in the same asset class so that it would be possible to consolidate the data. 31 25 See infra Section V. 26 ISDA IV at 8. 27 See id. at 9. 28 See MarkitSERV I at 10; Barnard I at 2 (also supporting the proposed categories of information that would be required to be reported for public dissemination). 29 See MarkitSERV I at 9-10. The commenter stated, for example, that the confirmation for a new “standard” credit default swap (“CDS”) would contain 35 to 50 data fields, depending on the structure of the CDS, and the confirmation for other CDS products and life cycle events combined would require a total of 160 data fields. See id. at note 37. 30 MarkitSERV I at 10. 31 See MarkitSERV I at 10. The Commission shares the commenter's concerns about the potential difficulties of consolidating data if there are multiple registered SDRs in the same asset class and each establishes different data elements for information that must be reported. Enumerating specific data elements required to be reported could help to promote consistency among the data fields if there are multiple registered SDRs in the same asset class. In addition, as discussed more fully below, such an approach would be more consistent with the approach taken by the CFTC's swap reporting rules. The Commission also acknowledges the comment that the Commission's rules, rather than the policies and procedures of a registered SDR, should specify the information required to be reported. However, the Commission believes on balance that establishing broad categories of required information will more easily accommodate new types of security-based swaps and new conventions for capturing and reporting transaction data. The Commission agrees with the commenter who expressed the view that a rule that attempted to enumerate the required data elements for each category of security-based swap could become outdated with each new product, resulting in a regulatory framework that constantly lagged the market and would need to be updated. 32 The Commission believes that a standards-based approach will more easily accommodate new security-based swap reporting protocols or languages, as well as new market conventions, including new conventions for describing the data elements that must be reported. 32 See id. One group of commenters noted that the CFTC provided greater specificity regarding the information to be reported. 33 Several commenters generally urged the Commission and the CFTC to establish consistent reporting obligations to reduce the cost of implementing both agencies' reporting rules. 34 33 See ISDA/SIFMA I at 6. 34 See Better Markets I at 2; Cleary II at 3, 21 note 61 (noting that a consistent approach between the two agencies would address the reporting of mixed swaps); ISDA/SIFMA I at 6; J.P. Morgan Letter at 14; ISDA IV at 1-2 (generally urging that the Commission align, wherever possible and practical, with the CFTC reporting rules). The last commenter also noted that reporting of mixed swaps will be difficult if Regulation SBSR requires a different reporting counterparty from the CFTC's swap data reporting rules or if transaction identifiers are not conformed to the CFTC approach, see ISDA IV at 4, 11, and urged the Commission to coordinate with the CFTC on a uniform approach to the time of execution for mixed swaps, see id. at 14. A mixed swap is a swap that is subject to both the jurisdiction of the CFTC and SEC, and, absent a joint order of the CFTC and SEC with respect to the mixed swap, as described in Rule 3a67-4(c) under the Exchange Act, is subject to the applicable reporting and dissemination rules adopted by the CFTC and SEC. The Commission agrees that it would be beneficial to harmonize, to the extent practicable, the information required to be reported under Regulation SBSR and under the CFTC's swap reporting rules. However, the Commission believes that it is possible to achieve a significant degree of consistency without including in final Rule 901 a detailed list of required data elements for each security-based swap. Rather than enumerating a comprehensive list of required data elements in the rule itself, Rule 901 identifies broad categories of information in the rule, and a registered SDR's policies and procedures are required to identify specific data elements that must be reported. The Commission believes that the flexibility afforded by Rule 901 will facilitate harmonization of reporting protocols and elements between the CFTC and SEC reporting regimes. In identifying the specific data elements that must be reported, a registered SDR could, in some instances, require reporting of the same data elements that are required to be reported pursuant to the CFTC's swap reporting rules, provided that those data elements include the information required under Rules 901(c) and 901(d). In some cases, however, the differences between the asset classes under the Commission's jurisdiction and those under the CFTC's jurisdiction will require a registered SDR's policies and procedures to specify the reporting of data elements different from those required under the CFTC's rules. The Commission recognizes that enumerating the specific data elements required to be reported would be more consistent with the approach taken by the CFTC's swap reporting rules. Nevertheless, the Commission believes that the flexibility afforded by the category-based approach in adopted Rule 901(c) could facilitate harmonization. Accordingly, Rule 901(c), as adopted, continues to require the reporting of broad categories of security-based swap information to registered SDRs, without enumerating each data element required to be reported (with a few exceptions, described below). b. Rule 901(c)(1) Rule 901(c)(1), as re-proposed, would have required reporting of the asset class of a security-based swap and, if the security-based swap is an equity derivative, whether it is a total return swap or is otherwise designed to offer risks and returns proportional to a position in the equity security or securities on which the security-based swap is based. As described in detail below, the Commission is making several revisions to Rule 901(c)(1) in response to comments. Among other things, these revisions clarify the final rules and eliminate certain unnecessary elements and redundancies. Final Rule 901(c)(1), however, does not expand on the types of data elements that must be reported. i. Elimination of the Reference to Equity Derivatives The Commission is eliminating the reference to equity derivatives in final Rule 901(c)(1). Under Regulation SBSR, as proposed and re-proposed, it would have been necessary to identify total return swaps and other security-based swaps designed to offer risks and returns proportional to a position in an equity security or securities, because those security-based swaps would not have been eligible for a block trade exception. 35 However, because the Commission is not adopting block thresholds or other rules relating to the block trade exception at this time, it is not necessary to identify security-based swaps that are not eligible for a block trade exception during the first, interim phase of Regulation SBSR. 36 Accordingly, the Commission is not including in final Rule 901(c)(1) any requirement to identify a security-based swap as a total return swap or a security-based swap otherwise designed to offer risks and returns proportional to a position in the equity security or securities on which the security-based swap is based. 35 Rule 907(b)(2)(i), as proposed and re-proposed, would have prohibited a registered SDR from designating as a block trade any security-based swap that is an equity total return swap or is otherwise designed to offer risks and returns proportional to a position in the equity security or securities on which the security-based swap is based. As noted in the Regulation SBSR Proposing Release, there is no delay in the reporting of block transactions for equity securities in the United States. Re-proposed Rule 907(b)(2)(i) was designed to discourage market participants from evading post-trade transparency in the equity securities markets by using synthetic substitutes in the security-based swap market. See Regulation SBSR Proposing Release, 75 FR 75232. 36 See infra Section VII. ii. Product ID Final Rule 901(c)(1) requires the reporting of the product ID 37 of a security-based swap, if one is available. If the security-based swap has no product ID, or if the product ID does not include the information enumerated in Rule 901(c)(1)(i)-(v), then the information specified in subparagraphs (i)-(v) of Rule 901(c)(1) (discussed below) must be reported. Rule 901(c)(1) is designed to simplify the reporting process for security-based swaps that have a product ID by utilizing the product ID in lieu of each of the categories of data enumerated in Rule 901(c)(1)(i)-(v). 37 See Rule 900(bb) (defining “product ID” as “the UIC assigned to a product”). The Commission believes that the product ID will provide a standardized, abbreviated, and accurate means for identifying security-based swaps that share certain material economic terms. In addition, the reporting and public dissemination of the product ID could enhance transparency because a transaction report that used a single identifier for the product traded could be easier to read than a transaction report that identified the product traded through information provided in numerous individual data fields. For example, market observers would be able to discern quickly that transaction reports including the same product ID related to trades of the same product. Product IDs also could facilitate risk management and assist relevant authorities in analyzing systemic risk and conducting market surveillance. Furthermore, the Commission believes that the development of security-based swaps with standardized terms could facilitate the development of product IDs that would readily identify the terms of these transactions. Re-proposed Rule 901(c)(2) would have required reporting of information that identifies the security-based swap instrument and the specific asset(s) or issuer(s) of any security on which the security-based swap is based. Proposed Rule 900 defined “security-based swap instrument” to mean “each security-based swap in the same asset class, with the same underlying reference asset, reference issuer, or reference index.” 38 In the context of final Rule 901(c), the requirement to report the product ID, if one is available, replaces, among other things, the requirement in re-proposed Rule 901(c)(2) to report information that identifies the security-based swap instrument and the specific asset(s) or issuer(s) of any security on which the security-based swap is based. For a security-based swap that has no product ID, Rule 901(c)(1)(i), as adopted, requires reporting of information that identifies the security-based swap, including the asset class of the security-based swap and the specific underlying reference asset(s), reference issuer(s), or reference index. Because the information that was included in the definition of security-based swap instrument— i.e. , the asset class and the underlying reference asset, issuer, or index—will be reported pursuant to adopted Rule 901(c)(1)(i) or included in the product ID, it is no longer necessary to separately define “security-based swap instrument.” Thus, final Rule 900 no longer contains a definition of security-based swap instrument. 38 This definition was re-proposed in the Cross-Border Proposing Release without change as Rule 900(dd). Although Rule 900, as proposed, defined the term “product ID,” it did not separately propose to define the term “product.” 39 Moreover, the original definition of the term “unique identification code” included the term “product,” again without defining it. 40 The Commission is now adopting a specific definition of the term “product.” Final Rule 900(aa) defines “product” as “a group of security-based swap contracts each having the same material economic terms except those relating to price and size.” Accordingly, the definition of “product ID” in adopted Rule 900(bb) is revised to mean “the UIC assigned to a product.” 39 Rule 900, as proposed, defined “product ID” to mean “the UIC assigned to a security-based swap instrument.” As discussed above, Rule 900, as proposed, defined “security-based swap instrument” to mean “each security-based swap in the same asset class, with the same underlying reference asset, reference issuer, or reference index.” Both of these definitions were re-proposed in the Cross-Border Proposing Release without change as Rules 900(x) and 900(dd), respectively. 40 Rule 900, as proposed, defined UIC as “the unique identification code assigned to a person, unit of a person, or product . . .” (emphasis added). This definition was re-proposed in the Cross-Border Proposing Release without change as Rule 900(nn). The key aspect of the term “product” is the classifying together of a group of security-based swap contracts that have the same material economic terms, other than those relating to price and size. The assignment of product IDs to groups of security-based swaps with the same material economic terms, other than those relating to price and size, is designed to facilitate more efficient and accurate transaction reporting by allowing reporting of a single product ID in place of the separate data categories contemplated by Rule 901(c)(1)(i)-(v). Product IDs also will make disseminated transaction reports easier to read, and will assist the Commission and other relevant authorities in monitoring for systemic risk and conducting market surveillance. Although the price and size of a security-based swap are material terms of the transaction—and thus must be reported, along with many other material terms, to a registered SDR pursuant to Rules 901(c) and 901(d)—they do not help distinguish one product from another. The same product can be traded with different prices and with different notional amounts. Thus, by way of example and not of limitation, if otherwise materially similar security-based swaps have different currencies of denomination, underlying assets, or settlement terms, they are different products for purposes of Regulation SBSR and should have different product IDs. An indicium of whether two or more security-based swaps between the same direct counterparties are the same product is whether they could be compressed or netted together to establish a new position ( e.g. , by a clearing agency or portfolio compression service). 41 If they cannot be compressed or netted, this suggests that there are material differences between the terms of the security-based swaps that do not permit the risks to be fully offset. 41 See TriOptima Letter at 2, 5-6 (explaining the portfolio compression process for uncleared swaps). The fact that the Commission is requiring products to be distinguished for purposes of regulatory reporting and public dissemination even if a single material economic term differentiates one from another would not prevent the Commission and market participants from analyzing closely related products on a more aggregate basis. For example, products that were otherwise identical but for different currencies of denomination could still be grouped together to understand the gross amount of exposure created by these related products (factoring in exchange rates). However, a product ID system that was not granular enough to separate products based on individual material differences would make it difficult or impossible to analyze positions based solely on those individual differences. For example, if a product ID system permitted otherwise similar security-based swaps with different currencies of denomination to be considered as the same product, it would not be possible to observe risk aggregations according to their particular currencies. 42 42 See ISDA/SIFMA at 10 (recommending that the definition of “security-based swap instrument” provide for more granular distinctions between different types of transactions within a single asset class). Similarly, the Commission believes that otherwise materially identical security-based swaps with different dates of expiration are different products and therefore must have different product IDs. Delineating products by, among other things, date of expiration will assist the Commission and other relevant authorities in developing a more precise analysis of risk exposure over time. This feature of the “product” definition is different from the approach taken in the originally proposed definition of “security-based swap instrument,” which specifically rejected distinctions based on tenor. 43 43 The Commission is not expressing a view as to whether products with different tenors might or might not be considered together to constitute a class of securities required to be registered under Section 12 of the Exchange Act. See Section 12(a) of the Exchange Act, 15 U.S.C. 78l(a); Section 12(g)(1) of the Exchange Act, 15 U.S.C. 78l(g); Rule 12g-1 under the Exchange Act, 17 CFR 240.12g-1. In connection with these requirements, the Commission notes the part of the “product” definition referring to a product as “a group of security-based swap contracts ” (plural). If a group of security-based swap contracts is sufficiently standardized such that they all share the same material economic terms (other than price and size), a registered SDR should treat them as the same product and assign them the same product ID. A product could be evidenced, for example, by the fact that a clearing agency makes the group of security-based swap contracts eligible for clearing and will net multiple transactions in that group of contracts into a single open position. In contrast, a security-based swap that has a combination of material economic terms unlike any other security-based swap would not be part of a product group, and the Commission believes that it would be impractical to require registered SDRs to assign a product ID to each of these unique security-based swaps. For such a security-based swap, the transaction ID would be sufficient to identify the security-based swap in the registered SDR's records and would serve the same purpose as a product ID. The product ID is one type of UIC. As discussed more fully in Section X, infra , Rule 903(a), as adopted, requires a registered SDR to use a UIC, including a product ID, assigned by an IRSS, if an IRSS has been recognized by the Commission and issues that type of UIC. If an IRSS that can issue product IDs has not been recognized by the Commission, Rule 903(a) requires a registered SDR to assign a product ID to that product using its own methodology. Similarly, final Rule 907(a)(5) requires a registered SDR to establish and maintain written policies and procedures for assigning UICs in a manner consistent with Rule 903, which establishes standards for the use of UICs. 44 44 See infra Section X(C) (discussing a registered SDR's policies and procedures relating to UICs). One commenter noted that, although there likely will be global standards for identification codes for certain data fields, such as the LEI, some global identifiers will not exist. 45 The commenter believed that requiring registered SDRs to create identifiers would “result in bespoke implementation among” registered SDRs that would be of limited value absent an industry standard. 46 The commenter recommended that the Commission consider postponing a requirement to establish identifiers “until an international taxonomy exists that can be applied consistently.” 47 45 See DTCC V at 14. 46 Id. 47 Id. The use of identifiers is discussed more fully in connection with Rule 903. See infra Section X. The Commission agrees that a system of internationally recognized product IDs would be preferable to a process under which registered SDRs assign their own product IDs to the same product. Nonetheless, the Commission believes that the use of product IDs, even product IDs created by registered SDRs rather than by an IRSS, could simplify security-based swap transaction reporting and facilitate regulatory oversight of the security-based swap market. In addition, the Commission believes that the requirement for registered SDRs to assign product IDs could provide additional incentive for security-based swap market participants to develop industry-wide product IDs. 48 48 In this regard, the Commission notes that one commenter stated that a “newly formed ISDA cross-product data working group, with representatives from sell side and buy side institutions, will look at proposed solutions and the practical implications of unique identifiers for the derivatives industry.” The commenters stated, further, that “ISDA is committed to provide product identifiers for OTC derivatives products that reflect the FpML standard. . . . In the first instance, this work will focus on product identifiers for cleared products. ISDA/FpML is currently working on a pilot project with certain derivative clearing houses to provide a normalized electronic data representation through a FpML document for each OTC product listed and/or cleared. This work will include the assignment of unique product identifiers.” ISDA/SIFMA I at 8-9. In addition, the Commission notes that ISDA has issued a white paper that discusses ways of creating unique identifiers for individual products. See ISDA, “Product Representation for Standardized Derivatives” (April 14, 2011), available at http://www2.isda.org/functional-areas/technology-infrastructure/data-and-reporting/identifiers/upi-and-taxonomies/ (last visited September 22, 2014), at 4 (stating that one goal of the white paper is to “[s]implif[y] . . . the trade processing and reporting architecture across the marketplace for the standardized products, as market participants will be able to abstract the trade economics through reference data instead of having to specify them as part of each transaction”). One commenter stated that “[i]ndustry utilities should be considered for assigning unique IDs for transactions, products, and legal entities/market participants.” 49 As discussed in Section X(B)(2), infra, the Commission is recognizing the Global LEI System (“GLEIS”), an industry utility administered by the Regulatory Oversight Committee (“ROC”), as meeting the criteria specified in Rule 903, as adopted. The GLEIS and this comment are discussed in Section X(B)(2), infra. 49 ISDA/SIFMA I at 8. iii. Rule 901(c)(1)(i) Rule 901(c)(1) requires that, if a security-based swap has no product ID, or if the product ID does not include the information identified in Rule 901(c)(1)(i)-(v), the information specified in Rule 901(c)(1)(i)-(v) must be reported. Final Rule 901(c)(1)(i)-(v) incorporates, with some modifications, information that would have been required under paragraphs (c)(1), (2), (5), (6), (8), and (12) of re-proposed Rule 901, and re-proposed Rule 901(d)(1)(iii). Rule 901(c)(1)(i), as adopted, generally requires the reporting of information that would have been required to be reported under re-proposed Rules 901(c)(1) and 901(c)(2). Re-proposed Rule 901(c)(1) would have required, in part, reporting of the asset class of a security-based swap. 50 Re-proposed Rule 901(c)(2) would have required the reporting of information identifying the security-based swap instrument and the specific asset(s) or issuer(s) on which the security-based swap is based. Re-proposed Rule 900(dd) would have defined “security-based swap instrument” as “each security-based swap in the same asset class, with the same underlying reference asset, reference issuer, or reference index.” Rule 901(c)(1)(i), as adopted, requires the reporting of information that identifies the security-based swap, including the asset class of the security-based swap and the specific underlying reference asset(s), reference issuer(s), or reference index. Although the defined term “security-based swap instrument” is being deleted from Regulation SBSR for the reasons discussed in Section VII(B)(3), infra, final Rule 901(c)(1)(i) retains the requirement to report the underlying reference asset(s), reference issuer(s), or reference index for the security-based swap, as well as the asset class of the security-based swap. 50 “Asset class” is defined as “those security-based swaps in a particular broad category, including, but not limited to, credit derivatives and equity derivatives.” See Rule 900(b), as adopted. As proposed and re-proposed, the definition of “asset class” also would have included loan-based derivatives. However, because loan-based derivatives can be viewed as a form of credit derivative, the Commission has removed the reference to loan-based derivatives as a separate asset class and adopted the definition noted above. This revision aligns the definition of “asset class” used in Regulation SBSR with the definition used in the SDR Adopting Release. The Commission received no comments regarding the information required to be reported in Rule 901(c)(1)(i). As stated in the Regulation SBSR Proposing Release, the Commission believes that the reporting and public dissemination of information relating to the asset class of the security-based swap would provide market participants with basic information about the type of security-based swap ( e.g., credit derivative or equity derivative) being traded. 51 Similarly, the Commission believes that information identifying the specific reference asset(s), reference issuer(s), or reference index of any security on which the security-based swap is based is fundamental to understanding the transaction being reported, and that a transaction report that lacked such information would not be meaningful. 52 Accordingly, Rule 901(c)(1)(i), as adopted, includes the requirement to report this information. 51 See 75 FR 75213. 52 See id. at 75214. iv. Rules 901(c)(1)(ii) and (iii) Re-proposed Rules 901(c)(5) and 901(c)(6) would have required the reporting of, respectively, the effective date of the security-based swap and the scheduled termination date of the security-based swap. These requirements are incorporated into adopted Rules 901(c)(1)(ii) and (iii), which require the reporting of, respectively, the effective date of the security-based swap and the scheduled termination date of the security-based swap. The Commission received no comments regarding the reporting of this information. As stated in the Regulation SBSR Proposing Release, the Commission believes that information specifying the effective date and the scheduled termination date of the security-based swap is fundamental to understanding the transaction being reported, and that a transaction report that lacked such information would not be meaningful. 53 Accordingly, final Rules 901(c)(1)(ii) and (iii) include the requirement to report the effective date and the scheduled termination date, respectively, of the security-based swap. 53 See id. v. Rule 901(c)(1)(iv) Re-proposed Rule 901(c)(8) would have required the reporting of any fixed or floating rate payments of a security-based swap, and the frequency of any payments. Re-proposed Rule 901(d)(1)(iii) would have required the reporting of the amount(s) and currenc(ies) of any up-front payment(s) and a description of the terms and contingencies of the payment streams of each direct counterparty to the other. In the Regulation SBSR Proposing Release, the Commission noted that the terms of any fixed or floating rate payments and the frequency of any payments are among the terms that would be fundamental to understanding a security-based swap transaction. 54 One commenter echoed the importance of information concerning the payment streams of security-based swaps. 55 54 See id. 55 See Benchmark Letter at 1 (stating that “[t]he reference data set [for a security-based swap] must include standard attributes necessary to derive cash flows and any contingent claims that can alter or terminate payments of these contracts. . . . Without these critical pieces of information, users of the trade price dissemination service will be unable to accurately assess reported values”). Another commenter stated that proposed Rule 901(d)(1)(iii) was unclear about the proposed form of the description of the terms and contingencies of the payment streams, and that the requirements of proposed Rule 901(d)(1)(iii) appeared to be duplicative of proposed Rule 901(d)(1)(v), which would have required reporting of the data elements necessary for a person to determine the market value of the transaction. 56 The commenter also suggested that the Commission consider the utility of requiring reporting of the terms of fixed or floating rate payments, as required by re-proposed Rule 901(c)(8). 57 56 See DTCC II at 10. See also DTCC V at 12 (requesting additional clarity with respect to the requirement to report the contingencies of the payments streams of each direct counterparty to the other). 57 See DTCC V at 11. The Commission continues to believe that, for a security-based swap that provides for periodic exchange of cash flows, information concerning those payment streams is fundamental to understanding the terms of the transaction. The Commission acknowledges, however, that re-proposed Rules 901(c)(8), 901(d)(1)(iii), and 901(d)(v) contained overlapping requirements concerning the payment streams of a security-based swap. Accordingly, the Commission is revising Rules 901(c) and 901(d) to streamline and clarify the information required to be reported with respect to the payment streams of a security-based swap. Specifically, final Rule 901(c)(1)(iv) requires the reporting of any standardized fixed or floating rate payments, and the frequency of any such payments. As discussed more fully in Section II(C)(3)(d), infra , final Rule 901(d)(3) requires the reporting of information concerning the terms of any fixed or floating rate payments, or otherwise customized or non-standardized payment streams, including the frequency and contingencies of any such payments, to the extent that this information has not been reported pursuant to Rule 901(c)(1). Thus, Rule 901(c)(1)(iv) requires the reporting of information concerning standardized payment streams, while Rule 901(d)(3) requires the reporting of information concerning customized payment streams. In addition, as discussed more fully below, final Rule 901(d)(5) requires reporting of any additional data elements included in the agreement between the counterparties that are necessary for a person to determine the market value of the transaction, to the extent that such information has not already been reported pursuant to Rule 901(c) or other provisions of Rule 901(d). The Commission believes that these changes to Rules 901(c) and 901(d) will avoid potential redundancies in the reporting requirements and will clarify the information required to be reported with respect to the payment streams of a security-based swap. Like other primary trade information reported pursuant to Rule 901(c), information about standardized payment streams reported pursuant to Rule 901(c)(1)(iv) will be publicly disseminated. The Commission envisions that, rather than disseminating such information as discrete elements, this information could be inherent in the product ID of a security-based swap that has a product ID. Information concerning non-standard payment streams that is reported pursuant to Rule 901(d)(3), like other secondary trade information, will be available for regulatory purposes but will not be publicly disseminated. Re-proposed Rule 901(c)(8) would have required reporting of the terms of any fixed or floating rate payments, standardized or non-standardized, and the frequency of such payments, and re-proposed Rule 902(a) would have required the public dissemination of that information. In addition, as noted above, one commenter discussed the importance of the availability of information concerning payment streams. 58 Nonetheless, the Commission believes that public dissemination of the non-standard payment terms of a customized security-based swap would be impractical, because a bespoke transaction by definition could have such unique terms that it would be difficult to reflect the full material terms using any standard dissemination protocol. In addition, it is not clear that the benefits of publicly disseminating information concerning these non-standard payment streams would justify the costs of disseminating the information. However, the Commission will have access to regulatory reports of such transactions, which should facilitate regulatory oversight and assist relevant authorities in monitoring the exposures of security-based swap market participants. Accordingly, Rule 901(d)(3), as adopted, requires the reporting of information concerning the terms of any non-standard fixed or floating rate payments, or otherwise customized or non-standardized payment streams, including the frequency and contingencies of any such payments. 58 See supra note 55. One commenter expressed the view that, without further clarification, market participants could adopt different interpretations of the requirement in re-proposed Rule 901(c)(8) to report the terms of fixed or floating rate payments, resulting in inconsistent reporting to registered SDRs; the commenter recommended, therefore, limiting the reportable fields to tenor and frequency, where applicable. 59 59 See DTCC V at 11. The Commission shares the commenter's concerns that, without guidance, market participants could adopt different interpretations of the requirement to report the terms of fixed or floating rate payments. The Commission notes, however, that final Rules 907(a)(1) and 907(a)(2) require a registered SDR to establish and maintain written policies and procedures that enumerate the specific data elements that must be reported and that specify the protocols for submitting information, respectively. The Commission believes that, read together, Rules 907(a)(1) and 907(a)(2) provide registered SDRs with flexibility to determine the appropriate conventions for reporting these data elements, including the terms of a security-based swap's fixed or floating rate payments. Thus, although Rule 901(c) itself does not specify the precise manner for reporting a security-based swap's fixed or floating rate payments, the policies and procedures of registered SDRs must do so. The Commission notes, further, that final Rule 906(c), among other things, requires SDR participants that are registered security-based swap dealers and registered major security-based swap participants to establish, maintain, and enforce written policies and procedures that are reasonably designed to ensure that they comply with any obligations to report information to a registered SDR in a manner consistent with Regulation SBSR. vi. Rule 901(c)(1)(v) Re-proposed Rule 901(c)(12) would have required a reporting side to indicate, if applicable, that the information reported under subparagraphs (1)-(11) of re-proposed Rule 901(c) for a customized security-based swap does not provide all of the material information necessary to identify the customized security-based swap or does not contain the data elements necessary to calculate its price. The Commission is adopting the substance of re-proposed Rule 901(c)(12) and locating it in final Rule 901(c)(1)(v). Rule 901(c)(1)(v), as adopted, provides that, if a security-based swap is customized to the extent that the information provided in paragraphs (c)(1)(i) through (iv) of Rule 901 does not provide all of the material information necessary to identify such customized security-based swap or does not contain the data elements necessary to calculate the price, the reporting side must include a flag to that effect. As discussed more fully in Section VI(G), infra , the registered SDRs should develop a condition flag to identify bespoke transactions because absent such a flag, users of public reports of bespoke transactions might receive a distorted impression of the market. One commenter argued that “publicly disseminated data for trades with a non-standard feature flag activated will be of limited usefulness and could be misleading.” 60 The commenter expressed the view that dissemination of information regarding highly structured transactions should not occur until an analysis regarding the impact and potential for misleading the investing public has been conducted. 61 A second commenter, however, endorsed the approach being adopted by the Commission. 62 The Commission acknowledges the concerns that the dissemination of transaction reports for highly customized trades could be misleading or of limited usefulness. However, as discussed more fully in Section VI(D)(2)(a), infra, the Commission believes that public dissemination of the key terms of a customized security-based swap, even without all of the details of the transaction, could provide useful information to market observers, including information concerning the pricing of similar products and information relating to the relative number and aggregate notional amounts of transactions in bespoke products versus standardized products. In addition, the Commission believes that the condition flag signaling that the transaction is a customized trade, and therefore that the reported information does not provide all of the details of the transaction, will minimize the potential for confusion and help to assure that the publicly disseminated reports of these transactions are not misleading. For these reasons, the Commission is declining, at this time, to undertake the study recommended by the commenter. 60 DTCC II at 9. 61 See id. 62 See Cleary II at 16 (recommending “public reporting of a few key terms of a customizedswap . . . [with] some indication that the transaction is customized”). A third commenter indicated that Rule 901 should go further and require reporting of additional information necessary to calculate the price of a security-based swap that is so customized that the price cannot be calculated from the reported information. 63 The Commission generally agrees that transaction reports of customized security-based swaps should be as informative and useful as possible. However, it is not clear that the benefits of publicly disseminating all of the detailed and potentially complex information that would be necessary to calculate the price of a highly customized security-based swap would justify the costs of disseminating that information. Accordingly, Rule 901(c)(1)(v), as adopted, does not require reporting of this information, and it will not be publicly disseminated. 64 63 See Better Markets I at 7. 64 The Commission notes that Rule 901(d)(5) requires the reporting of any additional data elements included in the agreement between the counterparties that is necessary to determine the market value of a transaction. Although this information will not be publicly disseminated, it will be available to the Commission and other relevant authorities. Such relevant authorities are enumerated in Section 13(n)(5)(G) of the Exchange Act, 15 U.S.C. 78m(n)(5)(G), which requires an SDR, upon request, to make available all data obtained by the SDR, including individual counterparty trade and position data, to each appropriate prudential regulator, the Financial Stability Oversight Council, the CFTC, the Department of Justice, and any other person that the Commission determines to be appropriate, including foreign financial supervisors, foreign central banks, and foreign ministries. This commenter also expressed concern that a “composite” security-based swap composed of two swaps grafted together could be used to avoid reporting requirements; the commenter recommended that, if at least one of the transactions could be disaggregated and reported in a format so that its price could be calculated, Regulation SBSR should require that the security-based swap be disaggregated and the component parts be reported separately. 65 In considering the commenter's concern the Commission notes the following: 65 See Better Markets I at 7 (“This enhancement to the Proposed Rules is particularly important with respect to SBS comprised of two swaps grafted together. Such composite SBS can be used to avoid reporting requirements. Even worse they can be used to obfuscate the real financial implications of a transaction. Accordingly, if an SBS can be disaggregated into two or more transactions, and at least one of those disaggregated transactions can be reported in a format so that price can be calculated, then the rules should require that the SBS be disaggregated and reported in that form”); Better Markets II at 3 (stating that complex transactions must be broken down into meaningful components); Better Markets III at 4-5 (stating that the Commission should require reporting of data on disaggregated customized security-based swaps). To begin, the Commission understands that market participants may execute so-called “package trades” that are composed of multiple components, or “legs,” some of which may be security-based swaps. Though such package trades are executed at a single price, each leg is separately booked and processed. In these cases, Regulation SBSR does in fact require a reporting side to separately report (and for the SDR to separately disseminate) each security-based swap component of the package trade. 66 66 In addition, as discussed more fully in Section VI(G), infra, in developing its policies and procedures, a registered SDR should consider requiring participants to identify the individual component security-based swaps of such a trade as part of a package transaction, and should consider disseminating reports of the individual security-based swap components of the package trade with a condition flag that identifies them as part of a package trade. Absent such a flag, observers of public reports of package transactions might obtain a distorted view of the market. However, if a market participant combines the economic elements of multiple instruments into one security-based swap contract, Regulation SBSR requires a single report of the transaction. The Commission understands the commenter's concerns regarding potential attempts to evade the post-trade transparency requirements. Such efforts could undermine Regulation SBSR's goals of promoting transparency and efficiency in the security-based swap markets and impede the Commission's ability to oversee those markets. The Commission does not believe, however, that either a registered SDR or a reporting side should be required to disaggregate a customized security-based swap if it consists of a single contract incorporating elements of what otherwise might have been two or more security-based swaps. In the absence of evidence of a significant amount of such “composite” security-based swap transactions and structuring other than through package trades, the Commission does not at this time believe that devising protocols for disseminating them in a disaggregated fashion would be practical. Importantly, however, and as discussed more fully in Section VI(D)(2)(a), infra , the primary trade information of any complex or bespoke security-based swap, including “composite” security-based swaps as described by the commenter, will be publicly disseminated, as required by Rule 902(a), including the specific underlying reference asset(s), reference issuer(s), or reference index for the transaction, as required by Rule 901(c)(1). 67 The Commission believes that the public dissemination of the primary trade information, even without all of the material economic terms of the transaction that could affect its pricing, could provide market observers with useful information, including information concerning the pricing of similar products and the relative number and aggregate notional amounts of transactions in complex and other bespoke transactions versus transactions in standardized products. The Commission further notes that since all of the material economic terms of a “composite” security-based swap must be reported to a registered SDR, including the data elements required by Rule 901(d), 68 the Commission itself will have complete access to these details. 69 67 One commenter stated its view that “proprietary baskets” should qualify as non-disseminated information, and requested that Regulation SBSR specifically recognize this as an example of non-disseminated information. See ISDA IV at 17 (stating that reportable security-based swaps may include customized narrow-based baskets that a counterparty deems proprietary to its business and for which public disclosure would compromise its anonymity and negatively impact its trading activity). Rule 902(a), as adopted, requires a registered SDR to publicly disseminate, for each transaction, the primary trade information required to be reported by Rule 901(c), as adopted, which includes the specific underlying reference asset(s), reference issuer(s), or reference index. The Commission continues to believe that the primary trading terms of a security-based swap should be disseminated to help facilitate price discovery. See infra Section VI(A). 68 See infra Section II(B)(3)(e) (discussing requirement in Rule 901(d)(5) that, to the extent not provided pursuant to other provisions of Rules 901(c) and 901(d), all data elements included in the agreement between the counterparties that are necessary for a person to determine the market value of the transaction must be reported). 69 See infra Section V(B)(1) (noting that the Commission anticipates proposing for public comment detailed specifications of acceptable formats and taxonomies that would facilitate an accurate interpretation, aggregation, and analysis by the Commission of security-based swap data submitted to it by an SDR); supra Section II(A)(2)(b)(v) (explaining that the Commission will have access to regulatory reports of bespoke security-based swap transactions, which should facilitate regulatory oversight and assist relevant authorities in monitoring the exposures of security-based swap market participants). The commenter also expressed the view that Regulation SBSR should clearly define the meaning of a security-based swap that is so customized that its price is not ascertainable. 70 The Commission does not believe that it is necessary to further define the term “customized security-based swap” for purposes of Rule 901(c)(1)(v). The condition flag required under adopted Rule 901(c)(1)(v) will notify market participants that the security-based swap being reported does not have a product ID and is customized to the extent that the information provided in Rules 901(c)(1)(i)-(iv) does not provide all of the material information necessary to identify the security-based swap or does not contain the data elements necessary to calculate the price. Thus, market participants will know that a customized security-based swap transaction was executed, and that the information reported pursuant to Rules 901(c)(1)(i)-(iv) provides basic but limited information about the transaction. The Commission believes, further, that Rule 901(c)(1)(v) provides clear guidance with respect to when a transaction is customized to the extent that the reporting side must attach a condition flag that identifies the transaction as a bespoke transaction, i.e. , when the information reported pursuant to Rules 901(c)(1)(i)-(iv) does not provide all of the material information necessary to identify the security-based swap or does not contain the data elements necessary to calculate the price. Accordingly, the Commission does not believe that it is necessary, at this time, to further define what constitutes a customized security-based swap for purposes of Regulation SBSR. 70 See Better Markets I at 7 (“The Proposed Rules also represent a critically important opportunity to shed light on the nature of `customized' swaps. Since the inception of the debate over disclosure and clearing in connection with financial regulation, the concept of the `customized' or `bespoke' transactions has figured prominently, yet these terms remain poorly understood in real world terms. The Proposed Rules should clearly define the meaning of SBS that are so customized that price is not ascertainable”). c. Rule 901(c)(2) Re-proposed Rule 901(c)(4) would have required reporting of the date and time, to the second, of the execution of a security-based swap, expressed using Coordinated Universal Time (“UTC”). 71 In the Regulation SBSR Proposing Release, the Commission stated that information concerning the time of execution would allow security-based swap transactions to be ordered properly, and would provide the Commission with a detailed record of when a security-based swap was executed. 72 The Commission further noted that, without the time of execution, market participants and relevant authorities would not know whether the transaction reports that they are seeing reflect the current state of the market. 73 In both the proposal and the re-proposal, the Commission defined “time of execution” to mean “the point at which the counterparties to a security-based swap become irrevocably bound under applicable law.” 74 71 UTC is defined by the International Telecommunication Union (ITU-R) and is maintained by the International Bureau of Weights and Measures (BIPM). See http://www.itu.int/net/newsroom/wrc/2012/reports/atomic_time.aspx (last visited September 22, 2014). 72 See 75 FR 75213. 73 See id. 74 See re-proposed Rule 900(ff). One commenter expressed the view that time of execution should be reported at least to the second, and by finer increments where practicable. 75 A second commenter raised timestamp issues in connection with proposed Rule 901(f), which would have required a registered SDR to timestamp transaction information submitted to it under Rule 901. The commenter stated that especially for markets for which there are multiple security-based swap execution facilities and markets where automated, algorithmic trading occurs, “the sequencing of trade data for transparency and price discovery, as well as surveillance and enforcement purposes, will require much smaller increments of time-stamping.” 76 The commenter urged the Commission to revise proposed Rule 901(f) to require a registered SDR to time stamp information that it receives in increments shorter than one second, stating that time stamps shorter than one second are technologically feasible, affordable, and in use. 77 75 See Barnard I at 2. 76 Better Markets I at 9. 77 See id. The Commission understands that trading in the security-based swap market does not yet occur as fast or as frequently as in the equities market, which makes recording the time of security-based swap executions in subsecond increments less necessary for surveillance purposes. While some market participants may have the capacity to record trades in subsecond intervals, others may not. Given the potential costs of requiring all market participants to utilize subsecond timestamps, the Commission believes that it is not necessary or appropriate at this time to require reporting of the time of execution in subsecond increments. 78 Accordingly, the Commission is adopting Rule 901(c)(4) as proposed and re-proposed, but renumbering it as final Rule 901(c)(2). The Commission will continue to monitor developments in the security-based swap market and could in the future reconsider whether reporting time of execution in subseconds would be appropriate. 78 However, a registered SDR could, in its policies and procedures, allow its participants to report using subsecond timestamps. One commenter discussed the time of execution for a voice trade in the context of proposed Rule 910(a), which addressed the reporting of pre-enactment security-based swaps. 79 The commenter noted that in the Regulation SBSR Proposing Release, the Commission stated that “proposed Rule 910(a) would not require reporting parties to report any data elements (such as the time of execution) that were not readily available. Therefore, proposed Rule 910(a) would not require reporting parties to search for or reconstruct any missing data elements.” 80 The commenter disagreed with this assertion in the context of voice trades, stating that the time of entry of the voice trade into the system is typically provided, but not the actual execution time of the trade. The commenter stated that “[p]roviding the actual execution time in the case of voice trades would then prove extremely challenging and invasive for the marketplace.” 81 Similarly, one commenter requested that the “Commission clarify that participants are not required to provide trade execution time information for pre-enactment security-based swap transactions and that going-forward, such information need only be provided when industry-wide time stamping practices are implemented.” 82 79 As discussed in Section I(F), supra, the Commission is not adopting Rule 910. 80 See 75 FR 75278-79. 81 ISDA/SIFMA I at 11. 82 ISDA I at 5. With respect to these concerns, the Commission notes, first, that it is not adopting Rule 910, but is proposing a new compliance schedule for Rules 901, 902, 903, 904, 905, 906, and 908 of Regulation SBSR in the Regulation SBSR Proposed Amendments Release. The Commission emphasizes, however, that proposed Rule 910(a) would not have required market participants to report information for a pre-enactment security-based swap that was not readily available, or to reconstruct that information. Thus, Rule 910(a), as proposed, would not have required market participants to provide the time of execution for an orally negotiated pre-enactment security-based swap, unless such information was readily available. Likewise, final Rule 901(i) does not require reporting of the date and time of execution for an orally negotiated pre-enactment or transitional security-based swap, unless such information is readily available. 83 However, for all other security-based swaps, including voice trades, final Rule 901(c)(2) requires reporting of the date and time of execution, to the second, of the security-based swap. The Commission noted in the Regulation SBSR Proposing Release that trades agreed to over the phone would need to be systematized by being entered in an electronic system that assigns a time stamp to report the date and time of execution of a security-based swap. 84 The Commission continues to believe that it is consistent with Congress' intent for orally negotiated security-based swap transactions to be systematized as quickly as possible. 85 The Commission notes, further, that market participants also must report the time of execution for voice-executed trades in other securities markets ( e.g. , equities and corporate bonds). 86 Knowing the date and time of execution of a security-based swap is important for reconstructing trading activity and for market surveillance purposes. Accordingly, the Commission continues to believe that the regulatory interest in having information regarding the date and time of execution for all security-based swaps, including orally negotiated security-based swaps, justifies the burden on market participants of recording and reporting this information. 83 For pre-enactment and transitional security-based swaps, final Rule 901(i) requires reporting of the information required under Rules 901(c) and 901(d), including the date and time of execution, only to the extent that such information is available. 84 See 75 FR 75213. 85 See id. 86 See, e.g., FINRA Rule 6230(c)(8) (requiring transactions reported to TRACE to include the time of execution); FINRA Rule 6622(c)(5) (requiring last-sale reports for transactions in OTC Equity Securities and Restricted Securities to include the time of execution expressed in hours, minutes, and seconds). In addition, the Commission is adopting, as proposed and re-proposed, the requirement for all times of execution reported to and recorded by registered SDRs to be in UTC. In the Regulation SBSR Proposing Release, the Commission explained its reasons for proposing to require that the date and time of execution be expressed in UTC. 87 The Commission noted that security-based swaps are traded globally, and expected that many security-based swaps subject to the Commission's reporting and dissemination rules would be executed between counterparties in different time zones. In the absence of a uniform time standard, it might not be clear whether the date and time of execution were being expressed from the standpoint of the time zone of the first counterparty, the second counterparty, or the registered SDR. Mandating a common standard for expressing date and time would alleviate any potential confusion as to when the security-based swap was executed. The Commission believed that UTC was an appropriate and well known standard suitable for purposes of reporting the time of execution of security-based swaps. The Commission received no comments regarding the use of UTC for reporting the time of execution. For the reasons set out in the Regulation SBSR Proposing Release, the Commission continues to believe that UTC is appropriate for security-based swap transaction reporting. Accordingly, the Commission is adopting this requirement as proposed and re-proposed. 87 See 75 FR 75213. Finally, the Commission is adopting the definition of “time of execution” as proposed and re-proposed, and renumbering it as final Rule 900(ii). One commenter stated that the time at which a transaction becomes legally binding may not be the same for all products. 88 The commenter further noted that, in some cases primary terms are not formed until the security-based swap is confirmed, and that the full terms of a total return swap might not be formed until the end of the day “and therefore the [total return swap] is not executed and confirmed until the end of the day.” 89 A second commenter stated that “the obligation to report should not be triggered until price, size, and other transaction terms required to be reported are available.” 90 The Commission understands the concerns of these commenters and believes that the definition of “time of execution” provides sufficient flexibility to address these commenters' concerns. For example, if the key terms of a security-based swap, such as price or size, are so indefinite that they cannot be reported to a registered SDR until some time after the counterparties agree to preliminary terms, the counterparties may not have executed the security-based swap under applicable law. Alternatively, even if the counterparties determine that their preliminary agreement constitutes an execution, the reporting timeframe adopted herein, which will allow a security-based swap to be reported at any point up to 24 hours after the time of execution, should address the concerns raised by the commenters. 88 See ISDA/SIFMA I at 7. 89 Id. 90 Cleary II at 6. See also ISDA/SIFMA I at 15 (“for some transaction types . . . the price or size of the transaction cannot be determined at the time the swap is negotiated”); ISDA IV at 10. A third commenter urged the Commission to revise the definition to equate time of execution with “the time of execution of the confirmation.” 91 The Commission declines to do so. While confirmation is an important aspect of post-trade processing, performance of the actions necessary to confirm a transaction is within the discretion of the counterparties and their agents. Defining the “time of execution” to mean the time that a confirmation is issued could create incentives for counterparties to delay confirmation and thus the reporting of the transaction. The Commission notes that Section 13(m)(1)(A) of the Exchange Act 92 defines “real-time public reporting” as reporting certain security-based swap data “as soon as technologically practicable after the time at which the security-based swap transaction has been executed.” The Commission believes this provision is most appropriately implemented by linking obligations to the time at which the counterparties become bound to the terms of the transaction— i.e., the time of execution—rather than some indefinite point in the future, such as the time when the confirmation is issued. 91 MFA I at 5. 92 15 U.S.C. 78m(m)(1)(A). d. Rule 901(c)(3) Re-proposed Rule 901(c)(7) would have required the reporting of the price of a security-based swap. Re-proposed Rule 901(d)(1)(iii) would have required the reporting of the “amount(s) and curren(cies) of any up-front payment(s) and a description of the terms and contingencies of the payment streams of each direct counterparty to the other.” Final Rule 901(c)(3) combines these elements and requires the reporting of “[t]he price, including the currency in which the price is expressed and the amount(s) and currenc(ies) of any up-front payments.” 93 The Commission believes that including in final Rule 901(c)(3) the explicit requirement to report the currency in which the price is expressed will help to clarify the information required to be reported. 94 Re-proposed Rule 901(c)(3) is being re-numbered as final Rule 901(c)(4). 95 93 Cf. Section II(B)(3)(c), infra (describing Rule 901(d), which enumerates data elements that will not be subject to public dissemination). 94 The addition of the reference to currency also is consistent with re-proposed Rule 901(c)(3), which would have required reporting of the notional amount(s) of the security-based swap and the currenc(ies) in which the notional amount(s) is expressed. 95 See infra Section II(B)(2)(b)(vi)(e). Rule 901(c)(3), as adopted, requires the reporting of the amount(s) and currenc(ies) of any up-front payments, a requirement that was included in re-proposed Rule 901(d)(1)(iii). The Commission believes that information concerning the amount(s) and currenc(ies) of any up-front payment(s) will help regulators and market observers understand the reported price of a security-based swap, and that the public dissemination of this information will further the transparency goals of Title VII. The Commission also believes that Rule 901(c) will be simpler if all considerations relating to the price are consolidated into a single provision. Accordingly, Rule 901(c)(3), as adopted, requires the reporting and public dissemination of the amount(s) and currenc(ies) of any up-front payment(s) along with other pricing information for the security-based swap. As discussed in the Regulation SBSR Proposing Release, the price of a security-based swap could be expressed in terms of the commercial conventions used in that asset class. 96 The Commission recognized that the price of a security-based swap generally might not be a simple number, as with stocks, but would likely be expressed in terms of the quoting conventions of the security-based swap. For example, a credit default swap could be quoted in terms of the economic spread—which is variously referred to as the “traded spread,” “quote spread,” or “composite spread”—expressed as a number of basis points per annum. Alternately, a credit default swap might be quoted in terms of prices representing a discount or premium over par. 97 In contrast, an equity or loan total return swap might be quoted in terms of a LIBOR-based floating rate payment, expressed as a floating rate plus a fixed number of basis points. 98 As discussed further in Section IV, infra, final Rule 907(a)(1) requires a registered SDR to establish, maintain, and make publicly available policies and procedures that specify the data elements of a security-based swap that must be reported, including elements that constitute the price. The Commission believes that, because of the many different conventions that exist to express the price in various security-based swap markets and new conventions that might arise in the future, registered SDRs should have flexibility to select appropriate conventions for denoting the price of different security-based swap products. 96 See 75 FR 75214. Final Rule 900(z) defines “price” to mean “the price of a security-based swap transaction, expressed in terms of the commercial conventions used in the asset class.” 97 See id. 98 See id. One commenter expressed concern that disseminating prices of margined and unmargined transactions together could mislead the market about the intrinsic prices of the underlying contracts. 99 Noting that the CFTC proposed a field for “additional price notation” that would be used to provide information, including margin, that would help market participants evaluate the price of a swap, the commenter recommended that the Commission and the CFTC harmonize their approaches to assure that the market has an accurate picture of prices. 100 The Commission agrees that publicly disseminated transaction reports should be as informative as possible. However, the Commission believes, at this time, that it could be impractical to devise additional data fields for describing the potentially complex margin requirements governing a security-based swap. Furthermore, it could be difficult if not impossible to attribute a portion of the price to a particular margin arrangement when the overall price represents the aggregation of a number of different factors into a single variable. The Commission notes that the bespoke flag required by Rule 901(c)(1)(v) is designed to inform market observers when a security-based swap is customized to the extent that the other data elements required by Rule 901(c)(1) do not provide all of the material information necessary to identify the security-based swap or provide sufficient information to calculate the price. 99 See CCMR I at 4. 100 See id. Another commenter expressed concern that disseminating the terms of the floating rate payment for an equity swap, which is often comprised of a benchmark rate plus or minus a spread and thus contains information about the direction of a customer transaction (positive spreads indicate a customer long swap and negative spreads indicate a customer short swap) may harm customers by offering other market participants the opportunity to anticipate their execution strategy. 101 The commenter believes that the spread value should thus be masked for equity security-based swaps when disclosing the price or terms of the floating rate payment. 102 As noted above, the Commission believes that publicly disseminated transaction reports should be as informative as possible. The floating rate payment of an equity security-based swap, including the spread, is an important part of the price of an equity security-based swap, and as such the Commission continues to believe that it should be disseminated. Not disseminating this information would undermine one of the key aspects of public dissemination, namely price discovery. The Commission further understands that in other markets—such as the cash equity market and the bond market—similar information is publically disclosed or can be inferred from public market data, which informs on the direction of the customer transaction. 103 101 See ISDA IV at 17. 102 See id. 103 In the bond markets, the side of the customer is reported on TRACE. See http://www.finra.org/Industry/Compliance/MarketTransparency/TRACE/Announcements/P039007 . In the cash equity markets, the side of the initiator of a transaction is, for many exchanges, provided as a data element on direct data feeds. It can also be inferred according to whether the trade was executed at the bid or offer. e. Rule 901(c)(4) Re-proposed Rule 901(c)(3) would have required reporting of the notional amount(s) and the currenc(ies) in which the notional amount(s) is expressed. The Commission is adopting this rule as re-proposed, but re-numbering it as Rule 901(c)(4). The Commission received two comments regarding the reporting and public dissemination of the notional amount of a security-based swap. One commenter believed that, “in the case of some asset classes, there is not a universal definition of the notional amount of the trade. This is particularly the case where the notional amount is not confirmable information.” 104 To address this issue, the commenter recommended that the Commission provide guidelines, such as those developed by the Federal Reserve Bank of New York, for reporting the notional amount of a security-based swap. 105 104 ISDA/SIFMA I at 12. 105 See id. The commenter refers to the guidelines included under “Line Item Instructions for Derivatives and Off-Balance-Sheet Item Schedule HC-L” in the Board of Governors of the Federal Reserve System's “Instructions for Preparation of Consolidated Financial Statements for Bank Holding Companies Reporting Form FR Y-9C.” See ISDA/SIFMA I at 12, note 13. As discussed below, final Rules 907(a)(1) and 907(a)(2) require a registered SDR to establish and maintain written policies and procedures that enumerate the specific data elements that must be reported and that specify the protocols for submitting information, respectively. The Commission believes that, read together, Rules 907(a)(1) and 907(a)(2) provide registered SDRs with flexibility to determine the appropriate conventions for reporting all required data elements, including the notional amount. Thus, although Rule 901(c) itself does not specify the precise manner for reporting a security-based swap's notional amount, the policies and procedures of registered SDRs must do so. The Commission believes that a registered SDR could choose to incorporate the guidance noted by the commenter, or other appropriate guidance, into its policies and procedures for reporting notional amounts. Another commenter suggested that the Commission, to mitigate adverse impacts on market liquidity, should—like the CFTC—adopt masking thresholds, rather than requiring public dissemination of the precise notional amount of a security-based swap transaction. 106 The commenter noted that FINRA's Trade Reporting and Compliance Engine (“TRACE”) system 107 uses masking conventions, and suggested applying that approach to the swap and security-based swap markets by “computing how much market risk is represented by the TRACE masking thresholds and using those numbers to map the masking thresholds into other asset classes.” 108 106 See J.P. Morgan Letter at 12. See also ISDA IV at 16 (recommending the use of a notional cap in each asset class). 107 TRACE is a FINRA facility to which FINRA member firms must report over-the-counter transactions in eligible fixed income securities. See generally http://www.finra.org/Industry/Compliance/MarketTransparency/TRACE/ (last visited September 22, 2014). 108 Id. at 13. The Commission appreciates the commenter's concerns regarding the uncertainty of the potential effects of public dissemination of security-based swap transaction reports on liquidity in the security-based swap market. As discussed further in Section VII, infra, the rules adopted in this release will allow the reporting, on an interim basis, of a security-based swap transaction at any time up to 24 hours after the time of execution (or, if 24 hours after the time of execution would fall on a day that is not a business day, by the same time on the next day that is a business day). This timeframe is designed in part to minimize potential adverse impacts of public dissemination on liquidity during the interim phase of Regulation SBSR's implementation, as market participants grow accustomed to operating in a more transparent environment. Accordingly, the Commission does not believe that it is necessary at this time to adopt a masking convention for purposes of reporting and publicly disseminating the notional amount of security-based swap transactions. 109 109 The Commission anticipates soliciting comment on issues relating to block trades, including the possibility of utilizing masking thresholds, at a later date. See infra Section VII. f. Rule 901(c)(5) Rule 901(c)(10), as proposed and re-proposed, would have required the reporting side to indicate whether both counterparties to a security-based swap are security-based swap dealers. In the Regulation SBSR Proposing Release, the Commission stated its preliminary belief that such an indication would enhance transparency and provide more accurate information about the pricing of security-based swap transactions. 110 The Commission noted, further, that prices of security-based swap transactions involving a dealer and non-dealer are typically “all-in” prices that include a mark-up or mark-down, while interdealer transactions typically do not. Thus, the Commission believed that requiring an indication of whether a security-based swap was an interdealer transaction or a transaction between a dealer and a non-dealer counterparty would enhance transparency by allowing market participants to more accurately assess the reported price of a security-based swap. 111 110 See 75 FR 75214. 111 See id. Commenters expressed mixed views regarding this proposed requirement. One commenter supported a requirement to include the counterparty type in security-based swap transaction reports. 112 Another commenter, however, recommended that the Commission eliminate the interdealer indication because “[e]xcluding this field from the information required to be reported to [a registered SDR] in real time will bring the scope of required data in line with existing dissemination functionality.” 113 A third commenter expressed concern that disseminating information that both counterparties are security-based swap dealers would reduce the anonymity of participants, ultimately resulting in “worse pricing and reduced liquidity for end-users.” 114 112 See Benchmark Letter at 2. The commenter also suggested that it would be useful to include an entry for “end user,” similar to the “Producer/Merchant/Producer/User” designation used in agricultural futures reports. See id. The Commission does not believe, at this time, that it is necessary to require a specific end-user indication. Under final Rule 901(c)(5), a transaction involving two registered security-based swap dealers must have an indication to that effect. An observer of a transaction report without that indicator will be able to infer that the transaction involved at least one side that does not have a registered security-based swap dealer. 113 DTCC V at 11. 114 ISDA IV at 16. The Commission believes that publicly disseminating an indication of whether both sides of a security-based swap are registered security-based swap dealers would enhance transparency in the security-based swap market by helping market participants to assess the reported price of a security-based swap. Although the Commission understands the concerns about potential burdens that could result from changes to existing dissemination practices, the required indicator should not impose significant burdens. Furthermore, the Commission believes that any potential burden created by requiring the indicator will be justified by the transparency benefits of publicly disseminating this information. The Commission notes that flagging transactions between two registered security-based swap dealers does indeed provide information to the public that the transaction involved two dealers, thus restricting the set of possible counterparties. However, since a majority of security-based swap transactions presently have a dealer as one of the counterparties, an interdealer flag is unlikely to enable market observers to identify counterparties to particular transactions. Also, although there is a limited group of entities that likely would be required to register as security-based swap dealers that are currently active in the security-based swap market, this number is more than two. 115 The Commission also notes that in the bond market interdealer transactions are flagged as part of TRACE's public dissemination of corporate bond trades. Therefore, the Commission does not believe that flagging transactions between two registered security-based swap dealers would ultimately result in “worse pricing and reduced liquidity for end-users.” 116 115 Historical data reviewed by the Commission suggest that, among an estimated 300 reporting sides, approximately 50 are likely to be required to register with the Commission as security-based swap dealers. See infra Section XXI(B)(3). 116 See ISDA IV at 16. The Commission, therefore, is adopting this requirement as final Rule 901(c)(5), with one revision. The Commission has added the word “registered” before the term “security-based swap dealer.” Therefore, the final rule requires an indication only when there is a registered security-based swap dealer on both sides of the transaction. As discussed further below, the Commission seeks to avoid imposing costs on market participants for assessing whether or not they are security-based swap dealers solely for purposes of Regulation SBSR. 117 Therefore, counterparties would have to be identified for purposes of Rule 901(c)(5), as adopted, only if they are registered security-based swap dealers. 117 See infra notes 284 to 285 and accompanying text. g. Rule 901(c)(6) Re-proposed Rule 901(c)(9) would have required the reporting side to indicate whether or not a security-based swap would be cleared by a clearing agency. This requirement is being adopted substantially as proposed but numbered as Rule 901(c)(6), with an additional clarification, described below. In the Regulation SBSR Proposing Release, the Commission noted that the use of a clearing agency to clear a security-based swap could affect the price of the security-based swap because counterparty credit risk might be diminished significantly if the security-based swap were centrally cleared. 118 Thus, the Commission preliminarily believed that information concerning whether a security-based swap would be cleared would provide market participants with information that would be useful in assessing the reported price of the security-based swap, thereby enhancing price discovery. 119 One commenter agreed, stating that it “will likely also be necessary to identify whether a price is associated with a bilateral trade or a cleared trade . . . as these distinctions may well have price impacts.” 120 118 See 75 FR 75214. 119 See id. 120 Cleary II at 20, note 56. The Commission continues to believe that information concerning whether a security-based swap will be cleared is useful in assessing the price of the security-based swap and will facilitate understanding of how risk exposures may change after the security-based swap is executed. Accordingly, final Rule 901(c)(6) requires the reporting side to indicate “whether the direct counterparties intend that the security-based swap will be submitted to clearing.” Reporting of whether the direct counterparties intend that the security-based swap will be submit [Text truncated at 120,000 characters. The full text is on the page linked above.] --- Source: Frix Law Library, https://www.frixlaw.com/law-library/documents/fr%3A2015-03124. Public record. Not legal advice.