[Federal Register Volume 80, Number 53 (Thursday, March 19, 2015)]
[Rules and Regulations]
[Pages 14563-14737]
[FR Doc No: 2015-03124]

Vol. 80

Thursday,

No. 53

March 19, 2015

Part III

Securities and Exchange Commission

-----------------------------------------------------------------------

17 CFR Part 242

Regulation SBSR--Reporting and Dissemination of Security-Based Swap
Information; Final Rule

Federal Register / Vol. 80 , No. 53 / Thursday, March 19, 2015 /
Rules and Regulations

-----------------------------------------------------------------------

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<PHONE_NUMBER>;
Yvonne Fraticelli, Special Counsel, at<PHONE_NUMBER>; George Gilbert,
Special Counsel, at<PHONE_NUMBER>; David Michehl, Special Counsel, at
(202) 551-5627; Geoffrey Pemble, Special Counsel, at<PHONE_NUMBER>;
Mia Zur, Special Counsel, at<PHONE_NUMBER>; 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
``Sec. Sec.  242.900 through 242.911'' to ``Sec. Sec.  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 Sec. Sec.
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 Sec. Sec.
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 customized swap . . . [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