involving two registered security-based swap dealers must have an
indication to that effect. An observer of a transaction report
without that indicator will be able to infer that the transaction
involved at least one side that does not have a registered security-
based swap dealer.
    \113\ DTCC V at 11.
    \114\ ISDA IV at 16.
---------------------------------------------------------------------------

    The Commission believes that publicly disseminating an indication
of whether both sides of a security-based swap are registered security-
based swap dealers would enhance transparency in the security-based
swap market by helping market participants to assess the reported price
of a security-based swap. Although the Commission understands the
concerns about potential burdens that could result from changes to
existing dissemination practices, the required indicator should not
impose significant burdens. Furthermore, the Commission believes that
any potential burden created by requiring the indicator will be
justified by the transparency benefits of publicly disseminating this
information. The Commission notes that flagging transactions between
two registered security-based swap dealers does indeed provide
information to the public that the transaction involved two dealers,
thus restricting the set of possible counterparties. However, since a
majority of security-based swap transactions presently have a dealer as
one of the counterparties, an interdealer flag is unlikely to enable
market observers to identify counterparties to particular transactions.
Also, although there is a limited group of entities that likely would
be required to register as security-based swap dealers that are
currently active in the security-based swap market, this number is more
than two.\115\ The Commission also notes that in the bond market
interdealer transactions are flagged as part of TRACE's public
dissemination of corporate bond trades. Therefore, the Commission does
not believe that flagging transactions between two registered security-
based swap dealers would ultimately result in ``worse pricing and
reduced liquidity for end-users.'' \116\
---------------------------------------------------------------------------

    \115\ Historical data reviewed by the Commission suggest that,
among an estimated 300 reporting sides, approximately 50 are likely
to be required to register with the Commission as security-based
swap dealers. See infra Section XXI(B)(3).
    \116\ See ISDA IV at 16.
---------------------------------------------------------------------------

    The Commission, therefore, is adopting this requirement as final
Rule 901(c)(5), with one revision. The Commission has added the word
``registered'' before the term ``security-based swap dealer.''
Therefore, the final rule requires an indication only when there is a
registered security-based swap dealer on both sides of the transaction.
As discussed further below, the Commission seeks to avoid imposing
costs on market participants for assessing whether or not they are
security-based swap dealers solely for purposes of Regulation
SBSR.\117\ Therefore, counterparties would have to be identified for
purposes of Rule 901(c)(5), as adopted, only if they are registered
security-based swap dealers.
---------------------------------------------------------------------------

    \117\ See infra notes 284 to 285 and accompanying text.
---------------------------------------------------------------------------

g. Rule 901(c)(6)
    Re-proposed Rule 901(c)(9) would have required the reporting side
to indicate whether or not a security-based swap would be cleared by a
clearing agency. This requirement is being adopted substantially as
proposed but numbered as Rule 901(c)(6), with an additional
clarification, described below. In the Regulation SBSR Proposing
Release, the Commission noted that the use of a clearing agency to
clear a security-based swap could affect the price of the security-
based swap because counterparty credit risk might be diminished
significantly if the security-based swap were centrally cleared.\118\
Thus, the Commission preliminarily believed that information concerning
whether a security-based swap would be cleared would provide market
participants with information that would be useful in assessing the
reported price of the security-based swap, thereby enhancing price
discovery.\119\ One commenter agreed, stating that it ``will likely
also be necessary to identify whether a price is associated with a
bilateral trade or a cleared trade . . . as these distinctions may well
have price impacts.'' \120\
---------------------------------------------------------------------------

    \118\ See 75 FR 75214.
    \119\ See id.
    \120\ Cleary II at 20, note 56.
---------------------------------------------------------------------------

    The Commission continues to believe that information concerning
whether a security-based swap will be cleared is useful in assessing
the price of the security-based swap and will facilitate understanding
of how risk exposures may change after the security-based swap is
executed. Accordingly, final Rule 901(c)(6) requires the reporting side
to indicate ``whether the direct counterparties intend that the
security-based swap will be submitted to clearing.'' Reporting of
whether the direct counterparties intend that the security-based swap
will be submitted to clearing, rather than whether the security-based
swap will be cleared, as originally proposed, more accurately reflects
the process of entering into and clearing a security-based swap
transaction. It may not be known, when the transaction is reported,
whether a registered clearing agency will in fact accept the security-
based swap for clearing. The Commission received no comments on this
issue. The Commission believes, however, that the modified language
enhances the administration of the rule.
    The Commission notes that, in some cases, the identity of the
registered clearing agency that clears a security-based swap could be
included in the product ID of a security-based swap. If the identity of
the registered clearing agency is included in the product ID, no
information would have to be separately reported pursuant to Rule
901(c)(6).
h. Rule 901(c)(7)
    Re-proposed Rule 901(c)(11) would have required a reporting side to
indicate, if applicable, that a security-based swap transaction does
not accurately reflect the market. In the Regulation SBSR Proposing
Release, the Commission noted that, in some instances, a security-based
swap transaction might not reflect the current state of the
market.\121\ This could occur, for example, in the case of a late
transaction report, which by definition would not represent the current
state of the market, or in the case of an inter-affiliate transfer or
assignment, where the new counterparty might not have an opportunity to
negotiate the terms, including the price, of taking on the
position.\122\ The Commission believed that there might not be an arm's
length negotiation of the terms of the security-based swap transaction,
and disseminating a transaction report without noting that fact would
be inimical to price discovery. Accordingly, Rule 901(c)(11), as
proposed and as re-proposed, would have required a reporting side to
note such circumstances in its transaction report to the registered
SDR.
---------------------------------------------------------------------------

    \121\ See 75 FR 75214.
    \122\ See id. at 75214-15.
---------------------------------------------------------------------------

    Rule 907(a)(4), as proposed and as re-proposed, would have required
a registered SDR to establish and maintain written policies and
procedures that describe, among other things, how a reporting side
would report security-based swap transactions that, in the estimation
of the registered SDR, do not accurately reflect the market. The
Commission noted its expectation that these policies and procedures
would require, among other things, different

indicators being applied in different situations.\123\
---------------------------------------------------------------------------

    \123\ See id. at 75215.
---------------------------------------------------------------------------

    One commenter suggested that Rule 901 should require the
counterparties to a security-based swap to disclose specific reasons
why a security-based swap does not accurately reflect the market
because it would not be possible to understand the reported prices
without that information.\124\ The commenter also stated that the
Commission, rather than registered SDRs, should specify the indicators
used for such transaction reports.\125\
---------------------------------------------------------------------------

    \124\ See Better Markets I at 6.
    \125\ See id. at 7 (``Such disclosure should not be left to the
discretion of the SDRs, but should instead be required by the
rules'').
---------------------------------------------------------------------------

    The Commission agrees in general that an effective regime for
public dissemination should provide market observers with appropriate
information to assist them in understanding the disseminated
transaction information. The Commission also agrees with the commenter
that it could be useful to market observers to provide more specific
information about particular characteristics of or circumstances
surrounding a transaction that could affect its price discovery value.
Therefore, after careful consideration, the Commission is adopting the
substance of re-proposed Rule 901(c)(11), but is modifying the rule
text to reflect final Rule 907(a)(4), and is renumbering the
requirement as Rule 901(c)(7). Rule 901(c)(7), as adopted, requires
reporting of any applicable flag(s) pertaining to the transaction that
are specified in the policies and procedures of the registered SDR to
which the transaction will be reported. Rule 907(a)(4)(i) requires a
registered SDR to establish and maintain written policies and
procedures for ``identifying characteristic(s) of a security-based
swap, or circumstances associated with the execution of a security-
based swap, that could, in the fair and reasonable estimation of a
registered security-based swap data repository, cause a person without
knowledge of these characteristic(s) or circumstance(s) to receive a
distorted view of the market.'' A registered SDR also must establish
flags to denote these characteristic(s) or circumstance(s).\126\ As
discussed in Section VI(G), infra, the Commission generally believes
that a registered SDR should consider providing condition flags
identifying the following: Inter-affiliate security-based swaps;
transactions resulting from netting or compression exercises;
transactions resulting from a ``forced trading session'' conducted by a
clearing agency; transactions reported late; transactions resulting
from the default of a clearing member; and package trades. The
Commission believes that these condition flags, and others that
registered SDRs may adopt in the future, should provide additional
information that will help to prevent market observers from receiving a
distorted view of the market. The Commission believes, further, that
these condition flags address the commenter's recommendation that
security-based swap transaction reports identify the specific reasons
why a transaction does not accurately reflect the market.
---------------------------------------------------------------------------

    \126\ See Rule 907(a)(4)(ii).
---------------------------------------------------------------------------

    The Commission disagrees, however, with the commenter's suggestion
that a Commission rule rather than the policies and procedures of a
registered SDR should identify the specific characteristics or
circumstances that must be reported to prevent a transaction report
from presenting a distorted view of the market. The Commission
continues to believe that requiring registered SDRs to develop,
maintain, and require the use of condition flags, and to modify them as
needed, will facilitate the development of a flexible reporting regime
that is better able to respond quickly to changing conditions in the
security-based swap market. This flexibility will help to assure that
reported transaction information remains meaningful as the security-
based swap market evolves over time.

B. Rule 901(d)--Secondary Trade Information

1. Description of Proposed and Re-Proposed Rule
    Rule 901(d)(1), as proposed and as re-proposed, would have required
the reporting of certain secondary trade information concerning a
security-based swap. Information reported pursuant to Rule 901(d)(1)
would be available to regulatory authorities only and would not be
publicly disseminated. Rule 901(d)(1), as re-proposed, would have
required the reporting of the following secondary trade information to
a registered SDR: (1) The participant ID of each counterparty; (2) as
applicable, the broker ID, desk ID, and trader ID of the direct
counterparty on the reporting side; (3) 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; (4) the title of any master agreement, or any other agreement
governing the transaction (including the title of any document
governing the satisfaction of margin obligations), incorporated by
reference and the date of any such agreement; (5) the data elements
necessary for a person to determine the market value of the
transaction; (6) if applicable, and to the extent not provided pursuant
to Rule 901(c), the name of the clearing agency to which the security-
based swap will be submitted for clearing; (7) if the security-based
swap is not cleared, whether the exception in Section 3C(g) of the
Exchange Act \127\ was invoked; (8) if the security-based swap is not
cleared, a description of the settlement terms, including whether the
security-based swap is cash-settled or physically settled, and the
method for determining the settlement value; and (9) the venue where
the security-based swap was executed.\128\
---------------------------------------------------------------------------

    \127\ 15 U.S.C. 78c-3(g).
    \128\ Rule 901(d)(1), as re-proposed, was substantially similar
to Rule 901(d)(1), as proposed, but made several technical changes.
Rule 901(d)(1), as re-proposed, revised the rule to add references
to the reporting side, the direct counterparty on the reporting
side, and secondary trade information.
---------------------------------------------------------------------------

    As discussed in the Regulation SBSR Proposing Release, the
Commission believed that the information required to be reported by
proposed Rule 901(d) would facilitate regulatory oversight and
monitoring of the security-based swap market by providing comprehensive
information regarding security-based swap transactions and trading
activity.\129\ The Commission believed, further, that this information
would assist the Commission in detecting and investigating fraud and
trading abuses in the security-based swap market.\130\
---------------------------------------------------------------------------

    \129\ See 75 FR 75217. Furthermore, to the extent that the
Commission receives information that is reported under Rule 901(d),
the Commission anticipates that it will keep such information
confidential, to the extent permitted by law. See id. at note 59.
    \130\ See id.
---------------------------------------------------------------------------

    Re-proposed Rule 901(d)(2) specified timeframes for reporting the
secondary trade information required to be reported under Rule
901(d)(1). Rule 901(d)(2), as re-proposed, would have required the
reporting of secondary trade information promptly, but in no event
later than: (1) 15 minutes after the time of execution of a security-
based swap that is executed and confirmed electronically; (2) 30
minutes after the time of execution for a security-based swap that is
confirmed electronically but not executed electronically; or (3) 24
hours after the time of execution for a security-based swap that is not
executed or confirmed electronically.
2. Final Rule 901(d)
    As discussed more fully below, the Commission is adopting Rules
901(d)(1)

substantially as re-proposed, although it is making several clarifying
and technical changes to address issues raised by commenters.
    The Commission is not adopting the 15-minute, 30-minute, and 24-
hour timeframes in re-proposed Rule 901(d)(2). Instead, final Rule
901(d) requires a reporting side to report the information required
under Rule 901(d) within the timeframes specified by Rule 901(j).\131\
Because re-proposed Rule 901(d)(2) is not being adopted, re-proposed
Rule 901(d)(1) is renumbered as final Rule 901(d), and re-proposed
Rules 901(d)(1)(i)-(ix), which would identify the categories of
secondary trade information required to be reported, are renumbered as
final Rules 901(d)(1)-(9).
---------------------------------------------------------------------------

    \131\ Rule 901(j), which specifies the timeframe for reporting
of the information enumerated in Rules 901(c) and 901(d), is
discussed in Section VII(B)(1) infra.
---------------------------------------------------------------------------

    Rule 901(d), as adopted, requires the reporting side to report the
following secondary trade information: (1) The counterparty ID or
execution agent ID of each counterparty, as applicable; (2) as
applicable, the branch ID, broker ID, execution agent ID, trader ID,
and trading desk ID of the direct counterparty on the reporting side;
(3) to the extent not provided pursuant to Rule 901(c)(1), the terms of
any fixed or floating rate payments, including the terms and
contingencies of any such payments; (4) for a security-based swap that
is not a clearing transaction, the title and date of any master
agreement, collateral agreement, margin agreement, or any other
agreement incorporated by reference into the security-based swap
contract; (5) to the extent not provided pursuant to Rule 901(c) or
other provisions of Rule 901(d), any additional elements included in
the agreement between the counterparties that are necessary for a
person to determine the market value of the transaction; (6) if
applicable, and to the extent not provided pursuant to Rule 901(c), the
name of the registered clearing agency to which the security-based swap
will be submitted for clearing; (7) if the direct counterparties do not
intend to submit the security-based swap to clearing, whether they have
invoked the exception in Section 3C(g) of the Exchange Act; (8) to the
extent not provided pursuant to other provisions of Rule 901(d), if the
direct counterparties do not submit the security-based swap to
clearing, a description of the settlement terms, including whether the
security-based swap is cash-settled or physically settled, and the
method for determining the settlement value; (9) the platform ID, if
applicable; and (10) if the security-based swap arises from the
allocation, termination, novation, or assignment of one or more
existing security-based swaps, the transaction ID of the allocated,
terminated, assigned, or novated security-based swap(s), except in the
case of a clearing transaction that results from the netting or
compression of other clearing transactions.
3. Discussion of Final Rule 901(d) and Response to Comments
a. Rule 901(d)(1)--Counterparty IDs
    In the Regulation SBSR Proposing Release, the Commission expressed
the view that a registered SDR ``must have a systematic means to
identify and track'' all persons involved in the security-based swap
transactions reported to that registered SDR.\132\ The Commission
intended to accomplish this, in part, through proposed Rule
901(d)(1)(i), which would have required the reporting party to report
the participant ID of each counterparty to a registered SDR.\133\ As
proposed in Rule 900, ``participant ID'' would have been defined as
``the UIC assigned to a participant'' \134\ and ``participant'' would
have encompassed: (1) A U.S. person that is a counterparty to a
security-based swap that is required to be reported to a registered
SDR; or (2) a non-U.S. person that is a counterparty to a security-
based swap that is (i) required to be reported to a registered SDR; and
(ii) executed in the United States or through any means of interstate
commerce, or cleared through a clearing agency that has its principal
place of business in the United States.
---------------------------------------------------------------------------

    \132\ 75 FR 75217.
    \133\ See infra Section X (discussing use of LEIs).
    \134\ The definition of ``participant ID'' was re-proposed,
without change, in re-proposed Rule 900(s). The UIC is the unique
identification code assigned to a person, unit of a person, product,
or transaction. See Rule 900(qq). As discussed more fully in Section
IV, infra, final Rule 907(a)(5) requires a registered SDR to
establish and maintain policies and procedures for assigning UICs in
a manner consistent with adopted Rule 903.
---------------------------------------------------------------------------

    Re-proposed Rule 901(d)(1)(i) would have required the reporting
side to report the participant ID of each counterparty to a security-
based swap. Re-proposed Rule 900(s) would have defined ``participant''
as ``a person that is a counterparty to a security-based swap that
meets the criteria of Sec.  242.908(b).'' Under re-proposed Rule
900(s), the following types of person would have met the criteria of
Rule 908(b): (1) U.S. persons; (2) security-based swap dealers and
major security-based swap participants; and (3) counterparties to a
transaction ``conducted within the United States.'' \135\
---------------------------------------------------------------------------

    \135\ See Cross-Border Proposing Release, 78 FR 31065
(discussing re-proposed Rule 908(b)).
---------------------------------------------------------------------------

    The Commission received no comments on re-proposed Rule
901(d)(1)(i), but has determined to adopt, as final Rule 901(d)(1), a
modified rule that will, in the Commission's estimation, better
accomplish the objective of ensuring that a registered SDR can identify
each counterparty to a security-based swap. As re-proposed, the
reporting side would have been required to report the participant ID of
its counterparty only if the counterparty met the definition of
``participant,'' which would have been limited by Rule 908(b). Under
the re-proposed definition of ``participant,'' some counterparties to
security-based swaps would not have become participants of the
registered SDRs that receive reports of those security-based swaps
under Rule 901(a). For example, if a U.S. person security-based swap
dealer entered into a security-based swap with a non-U.S. person
private fund in a transaction that is not conducted within the United
States, the security-based swap dealer would have been a participant of
the registered SDR to which the security-based swap is reported
pursuant to Rule 901(a), but the private fund would not. In this
circumstance, Rule 901(d)(1)(i), as re-proposed, would not have
provided a mechanism for the reporting of the private fund's identity
to the registered SDR; because the private fund would not have been a
participant of that registered SDR it would not have received a
``participant ID.''
    The Commission believes that it is necessary and appropriate for a
registered SDR to obtain identifying information for all counterparties
to security-based swaps that are subject to Regulation SBSR. Without
this information being reported to a registered SDR, the Commission's
ability to oversee the security-based swap market could be impaired
because the Commission might not be able to determine the identity of
each counterparty to a security-based swap reported to a registered SDR
pursuant to Regulation SBSR.
    Final Rule 901(d)(1) addresses this concern by requiring the
reporting side to report ``the counterparty ID or the execution agent
ID of each counterparty, as applicable.'' The Commission is adopting,
as Rule 900(j), the term ``counterparty ID,'' which means ``the UIC
assigned to a counterparty to a

security-based swap.'' \136\ A ``counterparty'' is a person that is a
direct or indirect counterparty of a security-based swap.\137\ A
``direct counterparty'' is a person that is a primary obligor on a
security-based swap,\138\ and an ``indirect counterparty'' is a
guarantor of a direct counterparty's performance of any obligation
under a security-based swap such that the direct counterparty on the
other side can exercise rights of recourse against the indirect
counterparty in connection with the security-based swap; for these
purposes a direct counterparty has rights of recourse against a
guarantor on the other side if the direct counterparty has a
conditional or unconditional legally enforceable right, in whole or in
part, to receive payments from, or otherwise collect from, the
guarantor in connection with the security-based swap.\139\ Thus, the
definition of ``counterparty ID'' encompasses UICs that identify all
direct and indirect counterparties to a security-based swap, even if a
particular counterparty is not a participant of a registered SDR.\140\
---------------------------------------------------------------------------

    \136\ The Commission is not adopting the re-proposed definition
of ``participant ID'' as this term is not used in Regulation SBSR,
as adopted.
    \137\ See Rule 900(i).
    \138\ See Rule 900(k).
    \139\ See Rule 900(p). Re-proposed Rule 900(o) would have
defined ``indirect counterparty'' to mean ``a guarantor of a direct
counterparty's performance of any obligation under a security-based
swap.'' The Commission is adopting, consistent with the approach it
took in the cross-border context, a modified definition of
``indirect counterparty'' to clarify the type of guarantor
relationship that would cause a person to become an indirect
counterparty for purposes of Regulation SBSR. See Securities
Exchange Act Release No.72472 (June 25, 2014), 79 FR 47278, 47316-17
(August 12, 2014) (``Cross-Border Adopting Release''). Final Rule
900(p) defines ``indirect counterparty'' to mean a guarantor of a
direct counterparty's performance of any obligation under a
security-based swap such that the direct counterparty on the other
side can exercise rights of recourse against the indirect
counterparty in connection with the security-based swap; for these
purposes, a direct counterparty has rights of recourse against a
guarantor on the other side if the direct counterparty has a
conditional or unconditional legally enforceable right, in whole or
in part, to receive payments from, or otherwise collect from, the
guarantor in connection with the security-based swap. Thus, under
final Rule 900(p), a person becomes an indirect counterparty to a
security-based swap if the guarantee offered by the person permits a
direct counterparty on the other side of the transaction to exercise
rights of recourse against the person in connection with the
security-based swap. The Commission believes that, if a recourse
guarantee exists, it is reasonable to assume that the other side of
the transaction would look both to the direct counterparty and its
guarantor(s) for performance on the security-based swap. If the
direct counterparty fails to fulfill its payment obligations on the
security-based swap, its guarantor would be obligated to make the
required payments. As noted in the Cross-Border Adopting Release,
such rights may arise in a variety of contexts. The meaning of the
terms ``guarantee,'' ``recourse,'' and any related terms used in
Regulation SBSR is the same as the meaning of those terms in the
Cross-Border Adopting Release and the rules adopted therein.
    \140\ The process for obtaining UICs, including counterparty
IDs, is described in Section X, infra.
---------------------------------------------------------------------------

    The Commission believes final Rule 901(d)(1) will accomplish the
Commission's objective of obtaining identifying information for all
counterparties to a security-based swap and improve regulatory
oversight and surveillance of the security-based swap market. The
counterparty ID will allow registered SDRs, the Commission, and other
relevant authorities to track activity by a particular market
participant and facilitate the aggregation and monitoring of that
market participant's security-based swap positions.
    The Commission also is adopting a requirement in Rule 901(d)(1)(i)
for the reporting side to report the ``execution agent ID'' as
applicable.\141\ This situation could arise if the identity of a
counterparty is not known at the time of execution.\142\ In this
circumstance, the reporting side would report the execution agent ID
because it would not know the counterparty ID.
---------------------------------------------------------------------------

    \141\ See infra Section II(C)(3)(b)(i) (discussing execution
agent ID).
    \142\ The Commission believes the reporting side may not know
the counterparty ID of the other side if, for example, the security-
based swap will be allocated after execution. Section VIII describes
how Regulation SBSR applies to security-based swaps involving
allocation.
---------------------------------------------------------------------------

    Regulation SBSR requires reporting of the UIC of each counterparty
to a security-based swap.\143\ One commenter stated that ``each series
or portfolio within each trust should be given its own LEI/UCI number
to address possible confusion between series or portfolios within the
same trust. Each portfolio is distinct with its own separate assets and
liabilities.'' \144\ The Commission agrees with this commenter and
notes that Rule 901(d)(1) requires the reporting of the UIC for each
counterparty to a security-based swap, whether not the counterparty is
a legal person.\145\ If a counterparty is an entity other than a legal
person, such as a series or portfolio within a trust, or an account,
Rule 901(d)(1) requires the reporting of the UIC that identifies that
counterparty.
---------------------------------------------------------------------------

    \143\ See Rule 901(d)(1); Rule 907(a)(5) (requiring a registered
SDR to have written policies and procedures for assigning UICs in a
manner consistent with Rule 903).
    \144\ Institutional Investors Letter at 6.
    \145\ Consequently, the word ``person,'' as used in this
release, includes any counterparty to a security-based swap,
including a counterparty that is not a legal person. Cf. Cross-
Border Adopting Release, 79 FR 47312 (providing that an account,
whether discretionary or not, of a U.S. person also is a U.S.
person--even though accounts generally are not considered separate
legal persons--and noting that this prong of the ``U.S. person''
definition focuses on the party that actually bears the risk arising
from a security-based swap transaction).
---------------------------------------------------------------------------

    Finally, the Commission notes that although it is not adopting a
definition of ``participant ID,'' the concept of a ``participant'' is
still utilized in Regulation SBSR. Rule 900(u), as adopted, defines
``participant,'' with respect to a registered SDR, as ``a counterparty,
that meets the criteria of Sec.  242.908(b), of a security-based swap
that is reported to that registered security-based swap data repository
to satisfy an obligation under Sec.  242.901(a).'' \146\ The adopted
definition makes clear that a person becomes a participant of a
particular registered SDR only if the person meets the criteria of Rule
908(b) and is a counterparty to a security-based swap that is reported
to that registered SDR on a mandatory basis. A counterparty would not
become a participant of all registered SDRs as a result of being a
counterparty to a security-based swap that is subject to Regulation
SBSR and reported to a particular registered SDR as required by Rule
901(a). The adopted definition also clarifies that a counterparty would
not become a participant of a registered SDR as a result of any non-
mandatory report \147\ submitted to that registered SDR.\148\
Similarly, a counterparty that meets the criteria of Rule 908(b) would
not become a participant of any registered SDR if the security-based
swap is reported pursuant to a substituted compliance determination
under Rule 908(c), because such a security-based swap would not be
reported to a registered SDR pursuant to Rule 901(a).
---------------------------------------------------------------------------

    \146\ Re-proposed Rule 900(s) would have defined ``participant''
as ``a person that is a counterparty to a security-based swap that
meets the criteria of Sec.  242.908(b).''
    \147\ See infra Section VI(D)(1) (discussing non-mandatory
reports).
    \148\ Assume, for example, that Fund X is a U.S. person and
engages in a single uncleared security-based swap with a registered
security-based swap dealer. Further assume that the registered
security-based swap dealer, who has the duty to report the
transaction under the reporting hierarchy, elects to submit the
required transaction report to SDR P, and also submits a non-
mandatory report of the transaction to SDR Q. Fund X is now a
participant of SDR P but not of SDR Q. Under Rule 900(u), Fund X
would not become a participant of SDR Q unless and until it enters
into a future security-based swap that is reported on a mandatory
basis to SDR Q.
---------------------------------------------------------------------------

    The final definition of ``participant'' is less comprehensive than
the re-proposed definition because Rule 908(b), as adopted, is narrower
than Rule 908(b), as re-proposed. As discussed in Section XV(D), infra,
final Rule 908(b) includes U.S. persons, registered security-based swap
dealers, and registered major security-based

swap participants. The Commission is not at this time taking action on
the prong of re-proposed Rule 908(b) that would have caused a person to
become a participant solely by being a counterparty to a security-based
swap that is a transaction conducted within the United States. As a
result, fewer non-U.S. persons are likely to ``meet the criteria of
Rule 908(b),'' as adopted, because a non-U.S. person that is a
counterparty of a security-based swap would meet the criteria of final
Rule 908(b) only if that counterparty is a registered security-based
swap dealer or a registered major security-based swap participant.
Thus, only a U.S. person, a registered security-based swap dealer, or a
registered major security-based swap participant could be a
``participant'' under Regulation SBSR.
b. Rule 901(d)(2)--Additional UICs
    Rule 901(d)(1)(ii), as re-proposed, would have required reporting
of, as applicable, the broker ID, desk ID, and trader ID of the direct
counterparty on the reporting side. The Commission preliminarily
believed that the reporting of this information would help to promote
effective oversight, enforcement, and surveillance of the security-
based swap market by the Commission and other relevant
authorities.\149\ The Commission noted, for example, that this
information would allow regulators to track activity by a particular
participant, a particular desk, or a particular trader. In addition,
relevant authorities would have greater ability to observe patterns and
connections in trading activity, or examine whether a trader had
engaged in questionable activity across different security-based swap
products. Such identifiers also would facilitate aggregation and
monitoring of the positions of security-based swap counterparties,
which could be of significant benefit for systemic risk
management.\150\
---------------------------------------------------------------------------

    \149\ See Regulation SBSR Proposing Release, 75 FR 75217.
    \150\ See id.
---------------------------------------------------------------------------

    Adopted Rule 901(d)(2) modifies re-proposed Rule 901(d)(1)(ii) in
certain respects. First, final Rule 901(d)(2) replaces the defined term
``desk ID'' with the defined term ``trading desk ID.'' Second, final
Rule 901(d)(2) now includes a requirement to report the branch ID and
the execution agent ID of the direct counterparty on the reporting
side, in addition to the broker ID, trading desk ID, and trader ID. In
conjunction with this requirement, final Rule 900 includes the new
defined terms ``branch ID'' and ``execution agent ID.'' Third, final
Rule 900 includes a revised definition of ``trader ID.'' Thus, final
Rule 901(d)(2) requires reporting of, ``[a]s applicable, the branch ID,
broker ID, execution agent ID, trader ID, and trading desk ID of the
direct counterparty on the reporting side.'' \151\
---------------------------------------------------------------------------

    \151\ As discussed in greater detail in Section XIII(A), infra,
Rule 906(a), as adopted, requires reporting to a registered SDR of
the branch ID, broker ID, execution agent ID, trader ID, and trading
desk ID, as applicable, of a direct counterparty to a security-based
swap that is not the reporting side. Thus, Rules 901(d)(2) and
906(a) together require reporting, as applicable, of the branch ID,
broker ID, execution agent ID, trader ID, and trading desk ID of
each direct counterparty to a security-based swap.
---------------------------------------------------------------------------

i. Branch ID and Execution Agent ID
    Rule 901(d)(2), as adopted, requires the reporting of, as
applicable, the branch ID and execution agent ID of the direct
counterpart on the reporting side, in addition to the broker ID, trader
ID, and trading desk ID of the direct counterparty on the reporting
side. The ``branch ID'' is the ``UIC assigned to a branch or other
unincorporated office of a participant.'' \152\ The Commission did not
include a requirement to report the branch ID in Rule 901(d), as
proposed or as re-proposed. However, the Commission now believes that
it is appropriate to include in Regulation SBSR a new concept of the
branch ID and require reporting of the branch ID, when a transaction is
conducted through a branch, as part of Rule 901(d)(2), as adopted.
Reporting of the branch ID, where applicable, will help identify the
appropriate sub-unit within a large organization that executed a
security-based swap (if a transaction were in fact conducted through
that sub-unit). This information also will facilitate the aggregation
and monitoring of security-based swap transactions by branch, at the
level of the registered SDR and potentially within the firm itself.
---------------------------------------------------------------------------

    \152\ See Rule 900(d).
---------------------------------------------------------------------------

    Final Rule 901(d)(2) also includes another UIC, the ``execution
agent ID,'' that was not included in the proposal or re-proposal. Rule
900(m), as adopted, provides that the execution agent ID is the ``UIC
assigned to any person other than a broker or trader that facilitates
the execution of a security-based swap on behalf of a direct
counterparty.'' The Commission initially proposed to require reporting
of the broker ID in order to obtain a record of an agent that
facilitates a transaction, if there is such an agent. The Commission
now recognizes, however, that entities other than registered brokers
could act as agents in a security-based swap transaction. For example,
an asset manager could be acting as an agent on behalf of a fund
counterparty but likely would not be a broker-dealer. The definition of
``execution agent ID'' is designed to encompass the entities in
addition to brokers that may act as agents for security-based swap
counterparties. The broker ID,\153\ which also must be reported under
final Rule 901(d)(2), will identify a registered broker, if any, that
intermediates a security-based swap transaction between two direct
counterparties and itself is not a counterparty to the transaction.
---------------------------------------------------------------------------

    \153\ ``Broker ID'' is defined as ``the UIC assigned to a person
acting as a broker for a participant.'' See Rule 900(e).
---------------------------------------------------------------------------

    The Commission believes that obtaining information about a broker
or execution agent, if any, involved in the transaction will provide
regulators with a more complete understanding of the transaction and
could provide useful information for market surveillance purposes. The
Commission notes that some security-based swap transactions may involve
multiple agents. For example, an asset manager could use a broker to
facilitate the execution of a security-based swap on behalf of one or
more of the funds that it advises. In that case, final Rule 901(d)
would require reporting of the counterparty ID of the direct
counterparty (the fund), the execution agent ID (for the asset
manager), and the broker ID (of the broker that intermediated the
transaction).
ii. Revised Defined Terms in Rule 901(d)(2)
    Rule 901(d)(1)(ii), as re-proposed, would have required the
reporting of, among other things, the desk ID of the direct
counterparty on the reporting side. Rule 900(i), as re-proposed, would
have defined ``desk ID'' as the UIC assigned to the trading desk of a
participant or of a broker of a participant. Rule 900, as re-proposed,
did not include a definition of ``desk.'' Final Rule 901(d)(2) requires
the reporting of the ``trading desk ID,'' rather than the ``desk ID.''
Accordingly, the defined term ``desk ID'' is being replaced in Rule 900
with the defined term ``trading desk ID,'' which Rule 900(ll) defines
as ``the UIC assigned to the trading desk of a participant.'' Unlike
re-proposed Rule 900, which provided no definition of the term
``desk,'' final Rule 900(kk) provides a definition of the term
``trading desk.'' Specifically, final Rule 900(kk) defines ``trading
desk'' to mean, ``with respect to a counterparty, the smallest discrete
unit of organization of the participant

that purchases or sells financial instruments for the account of the
participant or an affiliate thereof.'' The Commission believes that
adding a definition of ``trading desk'' will help to clarify the rule
by describing the type of structure within an enterprise that must
receive a trading desk ID. The ``trading desk ID'' concept is designed
to identify, within a large organization, the smallest discrete unit
that initiated a security-based swap transaction. Requiring the
reporting of the trading desk ID will assist regulators in monitoring
the activities and exposures of market participants. The trading desk
ID could, among other things, facilitate investigations of suspected
manipulative or abusive trading practices.\154\
---------------------------------------------------------------------------

    \154\ The trading desk ID also might allow relevant authorities
to determine whether a particular trading desk is engaging in
activity that could disrupt the security-based swap markets. For
example, in early 2012, a trading desk of JPMorgan Chase and Company
known as the Chief Investment Office executed transactions in
synthetic credit derivatives that declined in value by at least $6.2
billion later in the year. According to the report of the United
States Senate Permanent Subcommittee on Investigations, these
trades, which were unknown to the bank's regulators, were ``so large
in size that they roiled world credit markets.'' Report of the
United States Senate Permanent Subcommittee on Investigations,
JPMorgan Chase Whale Trades: A Case History of Derivatives Risks and
Abuses (March 15, 2013), available at http://www.hsgac.senate.gov/subcommittees/investigations/hearings/chase-whale-trades-a-case-history-of-derivatives-risks-and-abuses (last visited October 7,
2014). The existence of a trading desk ID could, in the future,
facilitate the ability of relevant authorities to detect this type
of trading activity.
---------------------------------------------------------------------------

    Final Rule 901(d)(2) also requires reporting of, if applicable, the
trader ID of the direct counterparty on the reporting side. Re-proposed
Rule 900(gg) would have defined ``trader ID'' as ``the UIC assigned to
a natural person who executes security-based swaps.'' This definition
would encompass a direct counterparty that executed a security-based
swap, as well as a trader acting as agent that executes a security-
based swap on behalf of a direct counterparty. The Commission did not
intend for the definition of ``trader ID'' to include both direct
counterparties (whose counterparty IDs must be provided pursuant to
Rule 901(d)(1)) and traders acting in an agency capacity that execute
security-based swaps on behalf of a direct counterparty. To narrow the
definition of ``trader ID'' so that it includes only traders that
execute security-based swaps on behalf of direct counterparties, final
Rule 900(jj) defines ``trader ID'' as ``the UIC assigned to a natural
person who executes one or more security-based swaps on behalf of a
direct counterparty.'' The direct counterparty would be the person,
account, or fund that is the direct counterparty to the security-based
swap that employs the trader.
iii. Response to Comments
    One commenter supported the proposed requirement for reporting
broker ID, desk ID, and trader ID, stating that these UICs would ``give
regulators a capability to aggregate position and trade data in
multiple ways including by individual trader to spot concentration risk
and insider trading.'' \155\ A second commenter argued that desk
structures change relatively frequently and personnel often rotate or
transfer to other firms; therefore, the effort to maintain trader ID
and desk ID information in a registered SDR could exceed its
usefulness.\156\ The commenter also indicated that information
regarding the desk ID and trader ID would be available from a firm's
audit trail.\157\
---------------------------------------------------------------------------

    \155\ GS1 Letter at 39 (also stating that these elements ``would
be most critical for performing trading oversight and compliance
functions such as trading ahead analysis, assessing trader price
collusion, analyzing audit trail data from multiple derivatives
markets as well as underlying cash markets . . . Also, lack of
unique, unambiguous and universal identification of broker, desks
and traders was one of the significant deterrents to analyzing the
May 6, 2010 flash crash''). Another commenter generally supported
the information required to be reported pursuant to Rule 901(d). See
Barnard I at 2.
    \156\ See DTCC II at 11.
    \157\ See id.
---------------------------------------------------------------------------

    The Commission questions whether consistent and robust information
about a firm's desk and trader activity is available from firms' audit
trails. Even if it were, the Commission believes that reporting of the
trader ID and the trading desk ID--as well as the branch ID, broker ID,
and execution agent ID--will help to assure that information concerning
the persons involved in the intermediation and execution of a security-
based swap is readily available to the Commission and other relevant
authorities. This information could assist in monitoring and overseeing
the security-based swap market and facilitate investigations of
suspected manipulative or abusive trading practices.
    Two other commenters raised issues with requiring reporting of
broker, trader, and trading desk IDs.\158\ One of these commenters
believed that reporting these UICs would require ``great cost and
effort'' from firms, including the costs associated with establishing
and maintaining UICs in the absence of a global standard.\159\ The
commenter also noted that not all of these identifiers are required to
be reported in other jurisdictions.\160\ In a joint comment letter with
another trade association, this commenter also stated that, because
these UICs are not currently reported by any participants in the OTC
derivatives markets, ``[t]he industry will need to develop standards
and appropriate methodology to effectively report this information.''
\161\ This comment expressed concern that the proposed requirement
``will create significant `noise' as a result of booking restructuring
events (due to either technical or desk reorganization considerations).
We therefore recommend that such information be either excluded, or
that participants report the Desk ID and Trader ID associated with the
actual trade or lifecycle events, but not those resulting from internal
reorganization events.'' \162\
---------------------------------------------------------------------------

    \158\ See ISDA III at 2; ISDA IV at 8; ISDA/SIFMA at 11.
    \159\ ISDA III at 2; ISDA IV at 8.
    \160\ See ISDA IV at 8 (stating that ``[u]nder EMIR rules,
broker ID is required, but not desk ID or trader ID. In Canada, only
broker ID is required, but we note that reporting entities are
struggling with the availability of an LEI to identify brokers that
have not been subject to a mandate to obtain one''). See also ISDA
III at 2.
    \161\ ISDA/SIFMA at 11.
    \162\ Id. See also ISDA IV at 8 (``We suggest that the
Commission eliminate broker ID, desk ID and trader ID from the list
of reportable secondary trade information. If the Commission wants
to retain these fields we strongly believe a cost-benefit analysis
should be conducted'').
---------------------------------------------------------------------------

    The Commission recognizes that, currently, UICs for branches,
execution agents, trading desks, and individual traders are generally
not in use. While the Commission agrees with the commenters that there
could be a certain degree of cost and effort associated with
establishing and maintaining UICs, the Commission believes that such
costs have already been taken into account when determining the costs
of Regulation SBSR.\163\ The costs of developing such UICs are included
in the costs for Rule 901 (detailing the data elements that must be
reported) and Rule 907 (detailing the requirement that SDRs develop
policies and procedures for the reporting of the required data
elements).
---------------------------------------------------------------------------

    \163\ See infra Section XXII(C)(1) (providing the economic
analysis of these requirements).
---------------------------------------------------------------------------

    The Commission confirms that these UICs must be reported pursuant
to Rule 901(d)(2) only in connection with the original
transaction.\164\
---------------------------------------------------------------------------

    \164\ Thus, a participant would not be required to ``re-report''
a transaction to the registered SDR if, for example, the trader who
executed the transaction leaves the firm some time afterwards.
However, the participant will be subject to the policies and
procedures of the registered SDR for, among other things, assigning
UICs in a manner consistent with Rule 903. See infra Section IV.
Those policies and procedures could include a requirement for the
participant to regularly notify the registered SDR about changes in
persons or business units requiring a UIC.

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

c. Rule 901(d)(3)--Payment Stream Information
    Rule 901(d)(1)(iii), as proposed and re-proposed, would have
required the reporting side to report 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. The Commission stated that this requirement would include, for a
credit default swap, an indication of the counterparty purchasing
protection, the counterparty selling protection, and the terms and
contingencies of their payments to each other; and, for other security-
based swaps, an indication of which counterparty is long and which is
short.\165\ The Commission noted that this information could be useful
to regulators in investigating suspicious trading activity.\166\
---------------------------------------------------------------------------

    \165\ See Regulation SBSR Proposing Release, 75 FR 75218, note
62.
    \166\ See id.
---------------------------------------------------------------------------

    One commenter stated the view that proposed Rule 901(d)(1)(iii) was
duplicative of proposed Rule 901(d)(1)(v), which would require
reporting of the data elements necessary to determine the market value
of a transaction.\167\ The commenter stated, further, that proposed
Rule 901(d)(1)(iii) was unclear about the required form of the
description of the terms and contingencies of the payment streams, and
requested further clarification of this proposed requirement.\168\
---------------------------------------------------------------------------

    \167\ See DTCC II at 10.
    \168\ See DTCC II at 10; DTCC V at 12.
---------------------------------------------------------------------------

    The Commission agrees with the commenter's concerns regarding the
need to clarify the information required to be reported under these
provisions of Rule 901. Accordingly, the Commission is revising adopted
Rule 901(d)(3) to require the reporting, to the extent not provided
pursuant to Rule 901(c)(1), of 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.\169\ As
discussed above, adopted Rule 901(c)(1)(iv) requires the reporting side
to report the terms of any standardized fixed or floating rate
payments, and the frequency of any such payments.\170\ To the extent
that a security-based swap includes fixed or floating rate payments
that do not occur on a regular schedule or are otherwise customized or
non-standardized, final Rule 901(d)(3) requires the reporting of the
terms of those payments, including the frequency and contingencies of
the payments. The Commission believes that the changes to final Rule
901(d)(3) make clear that Rule 901(d)(3) requires reporting of
customized or non-standardized payment streams, in contrast to the
standardized payment streams required to be reported pursuant to Rule
901(c)(1)(iv). The terms required to be reported could include, for
example, the frequency of any resets of the interest rates of the
payment streams. The terms also could include, for a credit default
swap, an indication of the counterparty purchasing protection and the
counterparty selling protection, and, for other security-based swaps,
an indication of which counterparty is long and which counterparty is
short. The Commission believes that information concerning the non-
standard payment streams of a security-based swap could be useful to
the Commission or other relevant authorities in assessing the nature
and extent of counterparty obligations and risk exposures. The
Commission believes that the changes made to Rule 901(d)(3) will help
clarify the information required to be reported under the rule and will
eliminate any redundancy between the information required to be
reported under Rules 901(c)(1)(iv) and 901(d)(3).
---------------------------------------------------------------------------

    \169\ As discussed above, the requirement to report the
amount(s) and currenc(ies) of any up-front payments now appears in
Rule 901(c)(3), rather than in Rule 901(d). Rule 901(c)(3), as
adopted, requires reporting of the price of a security-based swap,
including the currency in which the price is expressed and the
amount(s) and currenc(ies) of any up-front payments.
    \170\ If information concerning the terms and frequency of any
regular fixed or floating rate payments is included in the product
ID for the security-based swap, the reporting side is required to
report only the product ID, and would not be required to separately
report the terms and frequency of any regular fixed or floating rate
payments in addition to the product ID. See Rule 901(c)(1); Section
III(B)(2)(b)(ii), supra.
---------------------------------------------------------------------------

    In addition, as discussed more fully below, the Commission is
revising re-proposed Rule 901(d)(1)(v), which is renumbered as final
Rule 901(d)(5), to indicate that Rule 901(d)(5) requires the reporting
of additional data elements necessary to determine the market value of
a transaction only to the extent that the information has not been
reported pursuant to Rule 901(c) or other provisions of Rule 901(d).
The Commission believes that these changes address the concern that
Rule 901(d)(i)(iii) was duplicative of Rule 901(d)(1)(v).
d. Rule 901(d)(4)--Titles and Dates of Agreements
    Rule 901(d)(1)(iv), as proposed, would have required reporting of
the title of any master agreement, or any other agreement governing the
transaction (including the title of any document governing the
satisfaction of margin obligations), incorporated by reference and the
date of any such agreement. Rule 901(d)(1)(v), as proposed, would have
required reporting of the data elements necessary for a person to
determine the market value of the transaction. The Commission noted
that proposed Rule 901(d)(1)(v) would require, for a security-based
swap that is not cleared, information related to the provision of
collateral, such as the title and date of the relevant collateral
agreement. The Commission preliminarily believed that these
requirements, together with other information required to be reported
under Rule 901(d), would facilitate regulatory oversight of
counterparties by providing information concerning counterparty
obligations.\171\ The Commission re-proposed Rules 901(d)(1)(iv) and
901(d)(1)(v) without revision in the Cross-Border Proposing Release.
---------------------------------------------------------------------------

    \171\ See Regulation SBSR Proposing Release, 75 FR 75218.
---------------------------------------------------------------------------

    In proposing Rules 901(d)(1)(iv) and 901(d)(1)(v), the Commission
balanced the burdens associated with reporting entire agreements
against the benefits of having information about these agreements, and
proposed to require reporting only of the title and date of such master
agreements and any other agreement governing the transaction.
Similarly, the Commission indicated that proposed Rule 901(d)(1)(v)
would require the reporting of the title and date of any collateral
agreements governing the transaction.\172\
---------------------------------------------------------------------------

    \172\ See id. at 75218, note 63.
---------------------------------------------------------------------------

    One commenter disagreed with the Commission's proposed approach.
This commenter expressed the view that Regulation SBSR should be more
explicit in requiring reports of information concerning collateral and
margin for use by regulators because this information would be
important for risk assessment and other purposes.\173\
---------------------------------------------------------------------------

    \173\ See Better Markets I at 7-8 (arguing that, to facilitate
oversight, security-based swap counterparties should be required to
report the core data elements of their collateral arrangements,
including, at a minimum: (1) The parties to the agreement; (2) the
thresholds for forbearance of posted collateral applicable to each
party; (3) the triggers applicable to each party that would require
immediate funding (termination of forbearance); and (4) the
methodology for measuring counterparty credit risk); Better Markets
III at 4-5.
---------------------------------------------------------------------------

    The Commission agrees that it is important for regulatory
authorities to have access to information concerning the collateral and
margin associated with security-based swap transactions. The Commission
also is mindful,

however, that requiring the reporting of detailed information
concerning the master agreement and other documents governing security-
based swaps could impose significant burdens on market participants. In
addition, the Commission notes that one commenter on proposed
Regulation SBSR stated that it would not be possible, in all cases, to
identify the collateral associated with a particular security-based
swap transaction because collateral is calculated, managed, and
processed at the portfolio level rather than at the level of individual
transactions.\174\
---------------------------------------------------------------------------

    \174\ See ISDA/SIFMA I at 14-15. Specifically, the commenter
stated that the calculation of exposure collateral ``is performed at
a netted portfolio level and cannot be broken down to the
transaction level--it is simply not possible to identify the
specific exposure collateral or the `exposure' associated with any
particular transaction.'' See id. at 14. The commenter noted,
further, that the independent amount, an optional additional amount
of collateral that two counterparties may negotiate, ``may be
specified at transaction level, at portfolio level, at some
intermediate level (a combination of product type, currency and
maturity, for instance), and possible a hybrid of all three.
Therefore it may or may not be possible to identify the [independent
amount] associated with a particular transaction, but as a general
matter this association cannot be reliably made.'' See id. at 15.
---------------------------------------------------------------------------

    In light of these considerations, the Commission believes that, for
security-based swaps that are not clearing transactions, requiring
reporting of the title and date of any master agreement, collateral
agreement, margin agreement, or any other agreement incorporated by
reference into the security-based swap contract--but not the agreements
themselves or detailed information concerning the agreements--will
facilitate regulatory oversight of the security-based swap market by
providing regulators with a more complete understanding of a security-
based swap counterparty's obligations while not imposing significant
burdens on market participants. The Commission anticipates that, if a
situation arose where the Commission or another relevant authority
needed to consult information about a transaction contained in one of
the related agreements, the Commission could request the agreement from
one of the security-based swap counterparties. Knowing the title and
date of the agreement will assist relevant authorities in identifying
the agreement and thereby expedite the process of obtaining the
necessary information.
    One commenter argued that the ``level of change'' necessary to
incorporate the titles and dates of master agreements into individual
trade messages was excessive and recommended that the trade level
reference continue to follow the current process of referencing the
lowest level governing document, which would permit the identification
of all of the other relevant documents.\175\ Another commenter
questioned the value of requiring reporting of the title and date of
party level agreements.\176\ This commenter stated that, because other
jurisdictions do not require reporting of the ``title and date of a
Credit Support Agreement or other similar document (``CSA'') governing
the collateral arrangement between the parties . . . global trade
repositories do not currently have fields to support separate reporting
of data pertaining to the CSA from those which define the master
agreement. Equally challenging is firms' ability to report data
pertaining to the CSA as the terms of these agreements are not readily
reportable in electronic format nor could this be easily or accurately
achieved.'' \177\ Noting that other global regulators have limited
their trade reporting requirements to the relevant date and type of the
master agreement, the commenter believed that the information required
to be reported should be limited to the identification of party level
master agreements that govern all of the derivatives transactions
between the parties, and should not include master confirmations or
other documentation that is used to facilitate confirmation of the
security-based swap.\178\
---------------------------------------------------------------------------

    \175\ See DTCC II at 11.
    \176\ See ISDA IV at 8.
    \177\ Id.
    \178\ See id.
---------------------------------------------------------------------------

    The Commission understands that reporting the titles and dates of
agreements for individual security-based swap transactions may require
some modification of current practices. However, the Commission
believes that it is important for regulators to know such titles and
dates so that the Commission and other relevant authorities would know
where to obtain further information about the obligations and exposures
of security-based swap counterparties, as necessary. The Commission
believes that requiring reporting of the titles and dates of master
agreements and other agreements governing a transaction--but not the
agreements themselves or detailed information concerning the
agreements--would provide regulators with access to necessary
information without creating an unduly burdensome reporting obligation.
Therefore, the Commission is adopting Rule 901(d)(1)(iv) substantially
as proposed and re-proposed, while renumbering it final Rule 901(d)(4).
With respect to the commenter's concern regarding the difficulty of
reporting the terms of the documentation governing a security-based
swap, the Commission emphasizes that final Rule 901(d)(4) requires
reporting only of the titles and dates of the documents specified in
Rule 901(d)(4), but not the terms of these agreements.
    The commenter also requested additional clarity regarding the
proposed requirement generally.\179\ As discussed above, Rule
901(d)(1)(iv), as proposed and re-proposed, would have required
reporting of ``the title of any master agreement, or any other
agreement governing the transaction (including the title of any
document governing the satisfaction of margin obligations),
incorporated by reference and the date of any such agreement.'' The
proposed rule also would have required reporting of the title and date
of any collateral agreements governing the transaction.\180\ Although
the rule, as proposed and re-proposed, would have required reporting of
the title and date of any master agreement, margin agreement,
collateral agreement, and any other document governing the transaction
that is incorporated by reference, the Commission agrees that it would
be useful to state more precisely the information required to be
reported and to clarify the scope of the rule. Rule 901(d)(4), as
adopted, requires reporting of, ``[f]or a security-based swap that is
not a clearing transaction, the title and date of any master agreement,
collateral agreement, margin agreement, or any other agreement
incorporated by reference into the security-based swap contract.'' The
new language makes clear that Rule 901(d)(4) applies only to security-
based swaps that are not clearing transactions (i.e., security-based
swaps that do not have a registered clearing agency as a direct
counterparty). Any such agreements relating to a clearing transaction
would exist by operation of the rules of the registered clearing
agency, and therefore do not need to be reported pursuant to Regulation
SBSR because the Commission could obtain information from the
registered clearing agency as necessary.
---------------------------------------------------------------------------

    \179\ See DTCC V at 12.
    \180\ See Regulation SBSR Proposing Release, 75 FR 75218, note
63.
---------------------------------------------------------------------------

e. Rule 901(d)(5)--Other Data Elements
    Rule 901(d)(1)(v), as re-proposed, would have required reporting of
the data elements necessary for a person to determine the market value
of a transaction. The Commission is adopting Rule 901(d)(1)(v)
substantially

as re-proposed, but renumbering it as Rule 901(d)(5) and making certain
technical and clarifying changes in response to comments.
    As discussed above, re-proposed Rule 901(d)(1)(iii) would have
required reporting of the amount(s) and currenc(ies) of any up-front
payments and the terms and contingencies of the payment streams of each
direct counterparty to the other. One commenter believed that re-
proposed Rule 901(d)(1)(iii) was duplicative of re-proposed Rule
901(d)(1)(v),\181\ and asked the Commission to provide additional
clarity on what re-proposed Rule 901(d)(1)(v) requires.\182\ To address
these comments, the Commission is revising adopted Rule 901(d)(5) to
require the reporting, to the extent not required pursuant to Rule
901(c) or other provisions of Rule 901(d), 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.
---------------------------------------------------------------------------

    \181\ See DTCC II at 10.
    \182\ See DTCC V at 12.
---------------------------------------------------------------------------

    Another commenter expressed concern that the requirements of re-
proposed Rule 901(d)(1)(v) were vague, ``leaving reporting parties and
trade repositories with the task of establishing the reportable data
with potentially different result.'' \183\ This commenter recommended
that Commission revise the rule to clarify the requirement to report
``(i) the mark-to-market value and currency code and (ii) the date and
time of the valuation in Coordinated Universal Time . . .'' \184\
Further, because information necessary to determine the market value of
a transaction ``is determined as part of end of day processes,'' the
commenter requested that the timeframe for reporting data pertaining to
market value be based on the end of the day on which the relevant data
was determined.\185\
---------------------------------------------------------------------------

    \183\ ISDA IV at 9.
    \184\ Id.
    \185\ See id.
---------------------------------------------------------------------------

    In response to these concerns, the Commission emphasizes that
neither Regulation SBSR, as proposed and re-proposed, nor Regulation
SBSR, as adopted, requires the reporting of the market value of a
security-based swap (although the negotiated price of the actual
transaction is required to be reported), either on a one-time or
ongoing basis.\186\ As noted above, final Rule 901(d)(5) requires
reporting, to the extent not required pursuant to Rule 901(c) or other
provisions of Rule 901(d), of any additional data elements included in
the agreement between the counterparties that are necessary to
determine the market value of the transaction. This refers to all of
the contractual terms and conditions of a security-based swap that a
party would need to perform its own calculation of the market value of
the security-based swap using its own market data. Although the
reporting side must include, as part of the initial transaction report,
the information necessary to determine the market value of the
transaction, Regulation SBSR does not require the reporting side to
take the additional step of calculating and reporting the market value
of the transaction, nor does it require the reporting side to provide
any market data that would be needed to calculate the market value of
the transaction.
---------------------------------------------------------------------------

    \186\ In contrast, the CFTC's swap data reporting rules require
reporting parties to report the market value of swap transactions to
a CFTC-registered swap data repository on a daily basis. See 17 CFR
45.4(a)(2).
---------------------------------------------------------------------------

    Rule 901(d)(5) is designed to help to ensure that all of the
material terms of the agreement between the counterparties that is
necessary to determine the market value of a security-based swap are
available to the Commission and other relevant authorities.\187\ The
Commission continues to believe that this requirement will facilitate
regulatory oversight by giving relevant authorities the information
necessary to value an entity's security-based swap positions and
calculate the exposure resulting from those positions. However, the
final language of Rule 901(d)(5) is designed to eliminate any overlap
with other provisions of Rule 901(c) or 901(d). For example, if a
security-based swap has a product ID, the Commission presumes that all
information necessary to identify the security-based swap and determine
the market value of the transaction could be derived from the product
ID (or the identification information behind that particular product
ID). Therefore, it would not be necessary to report any additional
information pursuant to Rule 901(d)(5) for a security-based swap for
which a product ID is reported.
---------------------------------------------------------------------------

    \187\ This could include--by way of example and not of
limitation--information about interest rate features, commodities,
or currencies that are part of the security-based swap contract.
---------------------------------------------------------------------------

    In addition, the Commission is further clarifying the rule by
making a technical change to indicate that final Rule 901(d)(5)
requires the reporting only of data elements ``included in the
agreement between the counterparties.'' The Commission believes that
the rule as proposed and re-proposed--which did not include this
phrase--could have been interpreted to require the reporting of
information external to the agreement between the counterparties that
could have helped determine the market value of the security-based swap
(e.g., the levels of supply and demand in the market for the security-
based swap). The Commission intended, however, to require reporting
only of information included in the agreement between the
counterparties, not of general market information. Accordingly, final
Rule 901(d)(5) requires the reporting only of data elements ``included
in the agreement between the counterparties'' that are necessary for a
person to determine the market value of the transaction.
    Finally, one commenter believed that proposed Rule 901(d)(1)(v)
should require reporting only of the full terms of a security-based
swap as laid out in the trade confirmation.\188\ Although the
Commission agrees that the full terms of a trade confirmation could, in
some cases, provide the data elements included in the agreement between
the counterparties that are necessary to determine the market value of
a transaction, the Commission notes that the information required to be
reported pursuant Rule 901(d)(5) would not necessarily be limited to
information included in the trade confirmation. Not all market
participants observe the same conventions for confirming their trades.
The Commission understands that confirmations for some types of trades
are significantly more standardized than others. Some trades may have
critical terms included in other documentation, such as master
confirmation agreements or credit support annexes. Moreover,
confirmation practices in the future may differ from current
confirmation practices. The Commission believes, therefore, that
restricting information reported in accordance with Rule 901(d)(5) to
the information included in the confirmation would not provide the
Commission and other relevant authorities with sufficient information
regarding the market value of a security-based swap.
---------------------------------------------------------------------------

    \188\ See DTCC II at 10.
---------------------------------------------------------------------------

f. Rule 901(d)(6)--Submission to Clearing
    Rule 901(d)(1)(vi), as re-proposed, would have required reporting
of the following data element: ``If the security-based swap will be
cleared, the name of the clearing agency.'' This information would
allow the Commission to verify, if necessary, that a security-based
swap was cleared, and to identify the clearing agency that cleared the
transaction. The

Commission received no comments on this provision and is adopting it
substantially as re-proposed, with minor clarifying changes and
renumbered as Rule 901(d)(6). Rule 901(d)(6), as adopted, requires
reporting of the following: ``If applicable, and to the extent not
provided pursuant to paragraph (c) of this section, the name of the
clearing agency to which the security-based swap will be submitted for
clearing.''
    For some security-based swaps, the name of the clearing agency that
clears the security-based swap could be inherent in the product ID.
Rule 901(d)(6), as adopted, clarifies that the name of the clearing
agency to which the security-based swap will be submitted for clearing
need not be reported if that information is inherent in the product ID.
In addition, the new language regarding whether the security-based swap
will be submitted for clearing reflects the possibility that a clearing
agency could reject the security-based swap for clearing after it has
been submitted. The Commission believes that it would be useful to know
the name of the clearing agency to which the transaction is submitted,
even if the clearing agency rejects the transaction.
g. Rule 901(d)(7)--Indication of Use of End-User Exception
    Rule 901(d)(1)(vii), as re-proposed, would have required reporting
of whether a party to the transaction invoked the so-called ``end user
exception'' from clearing, which is contemplated in Section 3C(g) of
the Exchange Act.\189\ Section 3C(g)(6) of the Exchange Act \190\
provides for the Commission to request information from persons that
invoke the exception. The Commission preliminarily believed that
requiring reporting of whether the exception was invoked in the case of
a particular security-based swap would assist the Commission in
monitoring use of the exception.\191\
---------------------------------------------------------------------------

    \189\ 15 U.S.C. 78c-3(g). Section 3C(g)(1) of the Exchange Act
provides that the general clearing mandate set forth in Section
3C(a)(1) of the Exchange Act will not apply to a security-based swap
if one of the counterparties to the security-based swap: (1) Is not
a financial entity; (2) is using security-based swaps to hedge or
mitigate commercial risk; and (3) notifies the Commission, in a
manner set forth by the Commission, how it generally meets if
financial obligations associated with entering into non-cleared
security-based swaps. The application of Section 3C(g)(1) is solely
at the discretion of the security-based swap counterparty that
satisfies these conditions. See Securities Exchange Act Release No.
63556 (December 15, 2010), 75 FR 79992 (December 21, 2010).
    \190\ 15 U.S.C. 78c-3(g)(6).
    \191\ See Regulation SBSR Proposing Release, 75 FR 75218.
---------------------------------------------------------------------------

    One commenter argued that the Commission should not use the trade
reporting mechanism ``to police the end-user exception.'' \192\ The
commenter expressed concern with an end user having to certify
eligibility with each transaction and stated that ``it is illogical
that filings by swap dealers should determine the eligibility of the
end user.'' \193\ The Commission acknowledges the commenter's concerns
but believes that they are misplaced. Re-proposed Rule 901(d)(1)(vii)
would not require reporting of any information as to the end user's
eligibility to invoke the exception for a specific transaction;
instead, it would require reporting only of the fact of the exception
being invoked. The Commission could then obtain information from a
registered SDR regarding instances of the exception being invoked and
could determine, as necessary, whether to further evaluate whether the
exception had been invoked properly. The Commission does not believe
that it is necessary or appropriate to require information about the
end user's eligibility to invoke the exception to be reported under
Rule 901(d). Therefore, the Commission has determined to adopt Rule
901(d)(1)(vii) as re-proposed, but is renumbering it as Rule 901(d)(7).
---------------------------------------------------------------------------

    \192\ Cravath Letter at 3.
    \193\ Id. at 4.
---------------------------------------------------------------------------

h. Rule 901(d)(8)--Description of Settlement Terms
    Rule 901(d)(1)(viii), as re-proposed, would have required, for a
security-based swap that is not cleared, a description of the
settlement terms, including whether the security-based swap is cash-
settled or physically settled, and the method for determining the
settlement value. In the Regulation SBSR Proposing Release, the
Commission stated its preliminary belief that this information would
assist relevant authorities in monitoring the exposures and obligations
of security-based swap market participants.\194\ One commenter
expressed the view that the settlement terms could be derived from
other data fields and thus recommended deletion of this data element,
or in the alternative, requested additional clarity on what would be
required pursuant to this provision.\195\
---------------------------------------------------------------------------

    \194\ See 75 FR 75218.
    \195\ See DTCC V at 12.
---------------------------------------------------------------------------

    Re-proposed Rule 901(d)(1)(viii) is being adopted substantially as
re-proposed but renumbered as final Rule 901(d)(8) and now includes
certain revisions that respond to the commenter and clarify the
operation of the rule. Rule 901(d)(8), as adopted, requires: ``[t]o the
extent not provide pursuant to other provisions of this paragraph (d),
if the direct counterparties do not submit the security-based swap to
clearing, a description of the settlement terms, including whether the
security-based swap is cash-settled or physically settled, and the
method for determining the settlement value.'' The Commission believes
that the final rule makes clear that there is no requirement to report
information concerning the settlement terms of an uncleared security-
based swap if the information was reported pursuant to another
provision of Rule 901(d). Similarly, there is no requirement to report
the settlement terms pursuant to Rule 901(d)(8) if the settlement terms
are inherent in the product ID. Final Rule 901(d)(8) is designed to
facilitate regulatory oversight by providing the Commission and other
relevant authorities with information necessary to understand the
exposures of security-based swap counterparties.
i. Rule 901(d)(9)--Platform ID
    Rule 901(d)(1)(ix), as re-proposed, would have required reporting
of the venue where a security-based swap was executed. This would
include, if applicable, an indication that a security-based swap was
executed bilaterally in the OTC market.\196\ This information could be
useful for a variety of purposes, including studying the development of
security-based swap execution facilities (``SB SEFs'') or conducting
more detailed surveillance of particular security-based swap
transactions. In the latter case, the Commission or another relevant
authority would find it helpful to know the execution venue, from which
it could obtain additional information as appropriate.
---------------------------------------------------------------------------

    \196\ See Regulation SBSR Proposing Release, 75 FR 75218.
---------------------------------------------------------------------------

    One commenter, in discussing the entity that should assign
transaction IDs, suggested that linking a trade to a particular
platform potentially could result in the unintentional disclosure of
the identities of the counterparties.\197\ The Commission notes that
information concerning the venue where a security-based swap was
executed, like all secondary trade information reported under Rule
901(d), is not required to be, and thus may not be, publicly
disseminated. Because the platform ID may not be publicly disseminated,
there is no potential for it to unintentionally

identify the counterparties to the transaction.
---------------------------------------------------------------------------

    \197\ See DTCC II at 15-16.
---------------------------------------------------------------------------

    The Commission continues to believe that information identifying
the venue where a security-based swap was executed, whether on a
trading platform or in the OTC market, is necessary information for
relevant authorities to conduct surveillance in the security-based swap
market and understand developments in the security-based swap market
generally. Therefore, the Commission is adopting the rule substantially
as re-proposed and renumbering it as final Rule 901(d)(9).
    One commenter asked the Commission to clarify that re-proposed Rule
901(d)(1)(ix) would require reporting only of execution platforms
required to register with the Commission or the CFTC.\198\ The
Commission believes that final Rule 901(d)(9) largely accomplishes this
result. Specifically, the Commission has revised Rule 901(d)(9) to
require reporting, if applicable, of the ``platform ID,'' rather than
the ``execution venue'' more broadly. To implement this requirement,
the Commission also is adopting a definition of ``platform.'' Final
Rule 900(v) defines a ``platform'' as ``a national securities exchange
or a security-based swap execution facility that is registered or
exempt from registration.'' \199\ Rule 900(w) defines ``platform ID''
as the UIC assigned to the platform on which a security-based swap is
executed. The platform ID, like other UICs, must be assigned as
provided in Rule 903. The Commission believes that this approach makes
clear that other entities that may be involved in executing
transactions, such as inter-dealer brokers, are not considered
platforms for purposes of this reporting requirement.\200\
---------------------------------------------------------------------------

    \198\ See ISDA IV at 9.
    \199\ The Commission believes that transactions occurring on a
registered SB SEF as well as an exempt SB SEF should be reported to
a registered SDR. Certain entities that currently meet the
definition of ``security-based swap execution facility'' are not yet
registered with the Commission and will not have a mechanism for
registering until the Commission adopts final rules governing the
registration and core principles of SB SEFs. These entities
currently operate pursuant to an exemption from certain otherwise
applicable provisions of the Exchange Act. See Securities Exchange
Act Release No. 34-64678 (June 15, 2011), 76 FR 36287, 36292-93
(June 22, 2011) (Temporary Exemptions and Other Temporary Relief,
Together With Information on Compliance Dates for New Provisions of
the Securities Exchange Act of 1934 Applicable to Security-Based
Swaps). In addition, the Commission has raised the possibility of
granting exemptions to certain foreign security-based swap markets
that otherwise would meet the definition of ``security-based swap
execution facility.'' See Cross-Border Proposing Release, 78 FR
31056 (``The Commission preliminarily believes that it may be
appropriate to consider an exemption as an alternative approach to
SB SEF registration depending on the nature or scope of the foreign
security-based swap market's activities in, or the nature or scope
of the contacts the foreign security-based swap market has with, the
United States''). The adopted definition of ``platform'' requires
such entities to be identified in SDR transaction reports and thus
will enable the Commission and other relevant authorities to observe
transactions that occur on such exempt SB SEFs.
    \200\ Consistent with Rule 901(d)(9), a registered SDR could
create a single identifier for transactions that are not executed on
a national securities exchange or a SB SEF that is registered or
exempt from registration.
---------------------------------------------------------------------------

j. Rule 901(d)(10)--Transaction ID of Any Related Transaction
    Regulation SBSR, as proposed and re-proposed, was designed to
obtain complete and accurate reporting of information regarding a
security-based swap from its execution through its termination or
expiration. In the Regulation SBSR Proposing Release, the Commission
noted that maintaining an accurate record of the terms of a security-
based swap would require reporting of life cycle event information to a
registered SDR.\201\ The term ``life cycle event'' includes
terminations, novations, and assignments of existing security-based
swaps.\202\ As discussed in greater detail in Sections V(C)(5) and
VIII(A), infra, a new security-based swap may arise following the
allocation, termination, novation, or assignment of an existing
security-based swap, and that the reporting side for the new security-
based swap must report the transaction to a registered SDR.\203\ The
Commission believes that it should be able to link any new security-
based swaps that arise from the termination, novation, or assignment of
an existing security-based swap to the original transaction. For
example, when a single security-based swap is executed as a bunched
order and then allocated among multiple counterparties, the Commission
and other relevant authorities should be able to link the allocations
to the executed bunched order.\204\ The ability to link a security-
based swap that arises from an allocation, termination, novation, or
assignment back to the original security-based swap(s) will help to
assure that the Commission and relevant authorities have an accurate
and current representation of counterparty exposures.
---------------------------------------------------------------------------

    \201\ See 75 FR 75220. The Commission re-affirmed the importance
of life cycle event reporting for security-based swaps in the Cross-
Border Proposing Release. See 75 FR 31068.
    \202\ See infra Section XXI(A) (discussing the definition of
``life cycle events'').
    \203\ Certain terminations, such as the termination of an alpha
upon acceptance for clearing, result in the creation of new
security-based swaps (e.g., the beta and gamma). Similarly,
security-based swaps that are terminated during netting or
compression exercises result in the creation of new security-based
swaps. Regardless of the circumstances, if a security-based swap
arises from the termination of an existing security-based swap, the
reporting side for the new security-based swap must report the
transaction to a registered SDR as required by Rule 901(a).
    \204\ See infra Section VIII (explaining the application of
Regulation SBSR to security-based swaps involving allocations).
---------------------------------------------------------------------------

    To facilitate the Commission's ability to map a resulting security-
based swap back to the original transaction--particularly if the
original transaction and the resulting transaction(s) are reported to
different registered SDRs--the Commission is adopting Rule 901(d)(10),
which requires the reporting side for a security-based swap that arises
from an allocation, termination, novation, or assignment of one or more
existing security-based swaps, to report ``the transaction ID of the
allocated, terminated, assigned, or novated security-based swap(s),
except in the case of a clearing transaction that results from the
netting or compression of other clearing transactions.'' \205\ The
Commission does not believe that it is necessary to require reporting
of the transaction ID for clearing transactions that result from other
clearing transactions because clearing transactions occur solely within
the registered clearing agency and are used by the registered clearing
agency to manage the positions of clearing members and, possibly their
clients. Thus, it would not be necessary for regulatory authorities to
have the ability to link together clearing transactions that result
from other clearing transactions.
---------------------------------------------------------------------------

    \205\ See infra Section V(B) (discussing the definition of
``clearing transaction'').
---------------------------------------------------------------------------

k. Information That Is Not Required by Rule 901(d)
    One commenter, responding to a question in the Regulation SBSR
Proposing Release,\206\ stated that the Commission should not require
reporting of the purpose of a security-based swap because it could
reveal proprietary information, and because the parties to a security-
based swap often will have several reasons for executing the
transaction.\207\ The Commission agrees that counterparties could have
multiple reasons for entering into a security-based swap, and that
requiring reporting of a particular reason could be impractical.
Furthermore, different sides to the same transactions would likely have
different reasons for entering into it. The

Commission notes, further, that it did not propose to require reporting
of the purpose of the security-based swap and Rule 901, as adopted,
does not include a requirement to report this information.
---------------------------------------------------------------------------

    \206\ See 75 FR 75218 (question 39).
    \207\ See ISDA/SIFMA I at 12. See also Barnard I at 2 (stating
that the commenter was ``not convinced'' that the Commission should
require reporting of the purpose of a security-based swap
transaction).
---------------------------------------------------------------------------

    Two commenters recommended that the Commission require reporting of
valuation data on an ongoing basis.\208\ The Commission emphasizes that
it did not propose to require the reporting of valuation data in either
the Regulation SBSR Proposing Release or the Cross-Border Proposing
Release, and that it is not adopting such a requirement at this
time.\209\ However, the Commission will continue to assess the
reporting and public dissemination regime under Regulation SBSR and
could determine to propose additional requirements, such as the
reporting of valuations, as necessary or appropriate. In addition, the
Commission notes that the data elements required under Rules 901(c) and
901(d) are designed to allow the public, the Commission, other relevant
authorities, or a data analytics firm engaged by a relevant authority,
to calculate the market value of a security-based swap at the time of
execution of the trade.\210\
---------------------------------------------------------------------------

    \208\ See DTCC II at 10; Markit I at 3. A third commenter,
discussing the Commission's proposed rules governing recordkeeping
and reporting requirements for security-based swap dealers, major
security-based swap participants, and broker-dealers (Securities
Exchange Act Release No. 34-71958 (April 17, 2014), 79 FR 25194 (May
2, 2014)), urged the Commission to provide guidance regarding the
methods these entities should use to produce valuation information).
See Levin Letter at 3-4. A fourth commenter asked the Commission to
confirm that there is no requirement to report valuation data on a
daily basis, provided that there has been no change in the data. See
ISDA IV at 11.
    \209\ See also Section II(B)(3)(e), supra.
    \210\ See Rule 901(d)(5) (requiring reporting of any additional
data elements included in the agreement between the counterparties,
to the extent not already provided under another provision of Rule
901(c) or 901(d), that are necessary for a person to determine the
market value of the transaction); Regulation SBSR Proposing Release,
75 FR 75218 (``the reporting of data elements necessary to calculate
the market value of a transaction would allow regulators to value an
entity's [security-based swap] positions and calculate the exposure
resulting from those provisions'').
---------------------------------------------------------------------------

C. Reporting of Historical Security-Based Swaps

1. Statutory Basis and Proposed Rule
    Section 3C(e)(1) of the Exchange Act \211\ requires the Commission
to adopt rules providing for the reporting to a registered SDR or to
the Commission of security-based swaps entered into before the date of
enactment of Section 3C (i.e., July 21, 2010). By its terms, this
provision is not limited to security-based swaps that were still open
as of the date of enactment of the Dodd-Frank Act. In the Regulation
SBSR Proposing Release, the Commission took the preliminary view that
an attempt to collect many years' worth of transaction-level security-
based swap data (including data on terminated or expired security-based
swaps) would not enhance the goal of price discovery, nor would it be
particularly useful to relevant authorities or market participants in
implementing a forward-looking security-based swap reporting and
dissemination regime.\212\ The Commission also took the preliminary
view that collecting, reporting, and processing all such data would
involve substantial costs to market participants with little potential
benefit. Accordingly, the Commission proposed to limit the reporting of
security-based swaps entered into prior to the date of enactment to
only those security-based swaps that had not expired as of the date of
enactment of the Dodd-Frank Act (``pre-enactment security-based
swaps'').
---------------------------------------------------------------------------

    \211\ 15 U.S.C. 78c-3(e)(1).
    \212\ See 75 FR 75223-24.
---------------------------------------------------------------------------

    In addition, Section 3C(e)(2) of the Exchange Act \213\ requires
the Commission to adopt rules that provide for the reporting of
security-based swaps entered into on or after the date of enactment of
Section 3C (``transitional security-based swaps'').\214\
---------------------------------------------------------------------------

    \213\ 15 U.S.C. 78c 3(e)(2).
    \214\ See Regulation SBSR Proposing Release, 75 FR 75224. See
also re-proposed Rule 900(kk) (defining ``transitional security-
based swap'' to mean ``any security-based swap executed on or after
July 21, 2010, and before the effective reporting date'').
---------------------------------------------------------------------------

    The Commission proposed Rule 901(i) to implement both of these
statutory requirements. Rule 901(i), as proposed, would have required a
reporting party to report all of the information required by Rules
901(c) and 901(d) for any pre-enactment security-based swap or
transitional security-based swap (collectively, ``historical security-
based swaps''), to the extent such information was available. Thus,
Rule 901(i), as proposed and re-proposed, would have required the
reporting only of security-based swaps that were open on or executed
after the date of enactment (July 21, 2010). The Commission further
proposed that historical security-based swaps would not be subject to
public dissemination. In the Cross-Border Proposing Release, the
Commission re-proposed Rule 901(i) in its entirety with only one
technical revision, to replace the term ``reporting party'' with
``reporting side.''
2. Final Rule and Discussion of Comments Received
    As adopted, Rule 901(i) states: ``With respect to any pre-enactment
security-based swap or transitional security-based swap in a particular
asset class, and to the extent that information about such transaction
is available, the reporting side shall report all of the information
required by [Rules 901(c) and 901(d)] to a registered security-based
swap data repository that accepts security-based swaps in that asset
class and indicate whether the security-based swap was open as of the
date of such report.'' In adopting Rule 901(i), the Commission is
making minor changes to the rule as re-proposed in the Cross-Border
Proposing Release. The Commission has added the clause ``in a
particular asset class'' following ``transitional security-based swap''
and the clause ``to a registered security-based swap data repository
that accepts security-based swaps in that asset class.'' The security-
based swap market is segregated into different asset classes, and an
SDR might choose to collect and maintain data for only a single asset
class. These new clauses clarify that a reporting side is not obligated
to report historical security-based swaps in a particular asset class
to a registered SDR that does not accept security-based swaps in that
asset class. A reporting side's duty to report a historical security-
based swap in a particular asset class arises only when there exists a
registered SDR that accepts security-based swaps in that asset class.
    The Commission also is adopting the definition of ``pre-enactment
security-based swap'' as proposed and re-proposed.\215\ Further, the
Commission is adopting the definition of ``transitional security-based
swap'' substantially as proposed and re-proposed, with one clarifying
change and a technical revision to eliminate the obsolete term
``effective reporting date.'' \216\ Rule

900(nn), as adopted, defines ``transitional security-based swap'' to
mean ``a security-based swap executed on or after July 21, 2010, and
before the first date on which trade-by-trade reporting of security-
based swaps in that asset class to a registered security-based swap
data repository is required pursuant to Sec. Sec.  242.900 through
242.909.'' Thus, only those security-based swaps that were open as of
the date of enactment (July 21, 2010) or opened thereafter must be
reported. The Commission continues to believe that the costs of
reporting security-based swaps that terminated or expired before July
21, 2010, would not justify any potential benefits, particularly given
the difficulty of assembling records concerning these transactions
after many years. One commenter specifically agreed with the
Commission's proposal to limit reporting of security-based swaps
entered into prior to the date of enactment only to those that had not
expired as of that date.\217\
---------------------------------------------------------------------------

    \215\ See Rule 900(y).
    \216\ The term ``effective reporting date'' was used in the
compliance schedule set out in re-proposed Rule 910, which the
Commission is not adopting. The ``effective reporting date,'' would
have been defined to mean, with respect to a registered [SDR], the
date six months after the registration date. The ``registration
date'' would have been defined to mean, with respect to a registered
SDR, ``the date on which the Commission registers the security-based
swap data repository, or, if the Commission registers the security-
based swap data repository before the effective date of Sec. Sec.
242.900 through 242.911, the effective date of Sec. Sec.  242.900
through 242.911.'' See re-proposed Rules 900(l) and 900(bb),
respectively. The Commission is making a conforming change to delete
the defined terms ``effective reporting date'' and ``registration
date'' from final Rule 900. As noted in Section I(F) above, the
Commission 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.
    \217\ See ISDA I at 2, note 1.
---------------------------------------------------------------------------

    However, this commenter also expressed concern that a blanket
requirement to report all pre-enactment security-based swaps ``risks
double-counting and presenting a distorted view of certain markets.''
\218\ In particular, the commenter indicated that compression exercises
and tri-party novations raised concerns regarding the potential for
double-counting. The Commission shares the commenter's concern that
double-counting could create a distorted view of the security-based
swap market. Therefore, the Commission is adding new language at the
end of the Rule 901(i) which provides that the reporting side of a pre-
enactment or transitional security-based swap must ``indicate whether
the security-based swap was open as of the date of such report.'' This
information is necessary to allow a registered SDR to calculate a
participant's open positions established before the time trade-by-trade
reporting becomes mandatory for a particular asset class.
---------------------------------------------------------------------------

    \218\ Id. at 4.
---------------------------------------------------------------------------

    The commenter also stated that ``inter-affiliate security-based
swaps should not be subject to reporting.'' \219\ The Commission
disagrees with this suggestion. As described in Section IX, infra, the
Commission believes generally that inter-affiliate security-based swaps
should be subject to regulatory reporting and public dissemination. The
Commission thus believes that pre-enactment inter-affiliate security-
based swaps also should be subject to regulatory reporting, assuming
that such security-based swaps were opened after the date of enactment
or still open as of the date of enactment. The Commission notes,
however, that no information reported pursuant to Rule 901(i) will be
publicly disseminated.
---------------------------------------------------------------------------

    \219\ ISDA I at 5.
---------------------------------------------------------------------------

    Having access to information regarding historical security-based
swaps will help the Commission and other relevant authorities continue
to develop a baseline understanding of positions and risk in the
security-based swap market, starting on the date of enactment of the
Dodd-Frank Act, which contemplates the regime for regulatory reporting
of all security-based swaps. These transaction reports will provide a
benchmark against which to assess the development of the security-based
swap market over time, and help the Commission to prepare reports that
it is required to provide to Congress.
    One commenter, while generally supporting the Commission's proposal
to require reporting of historical security-based swaps to a registered
SDR, argued that only open contracts should be reported.\220\ The
Commission partially agrees with this comment and thus, as noted above,
is requiring reporting of only pre-enactment security-based swaps that
were open as of the date of enactment. However, the Commission believes
that all security-based swaps entered into on or after the date of
enactment should be reported--even if they expired or were terminated
before trade-by-trade reporting becomes mandatory--and that the
reporting side should indicate whether the security-based swap was open
as of the date of such report. While reporting of terminated or expired
transitional security-based swaps is not necessary for the calculation
of market participants' open positions, this information will assist
the Commission and other relevant authorities to create, for
surveillance purposes, at least a partial audit trail \221\ of
transactions executed after the date of enactment and, more generally,
to analyze market developments since the date of enactment.
---------------------------------------------------------------------------

    \220\ See DTCC II at 17.
    \221\ The Commission notes that Rule 901(i) by its terms
requires the reporting of historical security-based swaps only ``to
the extent such information is available.'' Thus, if information
about terminated or expired transitional security-based swaps no
longer exists, it would not be required to be reported under Rule
901(i).
---------------------------------------------------------------------------

    This commenter also argued that security-based swaps ``only [in]
their current state should need to be reported, without additional
information like execution time.'' \222\ A second commenter expressed
concern that the reporting requirements for historical security-based
swaps could require parties to modify existing trades that occurred in
a heretofore unregulated market in order to comply with Rule
901(i).\223\ A third commenter expressed concern that ``[t]he
submission of non-electronic transaction confirmations [for pre-
enactment security-based swaps] will be extremely burdensome for
reporting entities,'' \224\ and recommended instead that the Commission
``permit the reporting in a common electronic format of the principal
electronic terms'' of each such pre-enactment security-based swap.\225\
---------------------------------------------------------------------------

    \222\ DTCC II at 17. See also ISDA I at 5 (requesting that the
Commission clarify that market participants are not required to
provide trade execution time information for pre-enactment security-
based swap transactions).
    \223\ See Roundtable Letter at 11 (stating that ``any effort to
alter the terms or documentation of existing swaps would be resource
intensive with potentially significant negative consequences'').
    \224\ Deutsche Bank Letter at 2.
    \225\ Id. at 3.
---------------------------------------------------------------------------

    For several reasons, the Commission believes that Rule 901(i)
strikes a reasonable balance between the burdens placed on security-
based swap counterparties and the policy goal of enabling the
Commission and other relevant authorities to develop a baseline
understanding of counterparties' security-based swap positions. First,
the Commission notes that Rule 901(i) requires reporting of the data
elements set forth in Rules 901(c) and 901(d) only to the extent such
information is available. The Commission does not expect, nor is it
requiring, reporting sides to create or re-create data related to
historical security-based swaps. Thus, if the time of execution of a
historical security-based swap was not recorded by the counterparties,
it is not required to be reported under Rule 901(i). Similarly, Rule
901(i) does not require counterparties to modify existing transactions
in any way to ensure that all data fields are complete. By limiting the
reporting requirement to only that information that is available, the
Commission is acknowledging that, for historical security-based swaps,
certain information contemplated by Rules 901(c) and 901(d) may not be
available. The Commission generally believes that the benefits of
requiring security-based swap counterparties to reconstruct the missing
data elements--including, for example, the time of execution--
potentially several years after the time of execution--would not
justify the costs.

    The Commission agrees with the commenter who argued that providing
large volumes of non-electronic confirmations to registered SDRs is not
desirable, and that the Commission instead should require reporting in
a ``common electronic format.'' \226\ As discussed in Section IV,
infra, Rules 907(a)(1) and 907(a)(2) require registered SDRs to
establish and maintain policies and procedures that enumerate the
specific data elements and the acceptable data formats for transaction
reporting, including of historical security-based swaps. The Commission
expects that registered SDRs and their participants will consult
regarding the most efficient and cost effective ways to report the
transaction information required by Rule 901(i). Furthermore, to the
extent that information regarding a historical security-based swap
already has been reported to a person that will register with the
Commission as an SDR--or to a person that itself will not seek
registration as an SDR but will transfer the historical security-based
swap information to an affiliate that registers as an SDR--Rule 901(i)
would be satisfied, and would not require resubmission of that
information to the registered SDR.\227\
---------------------------------------------------------------------------

    \226\ Deutsche Bank Letter at 2-3.
    \227\ One commenter, DTCC, noted that the Trade Information
Warehouse could provide an affiliate that will seek registration as
an SDR with information related to security-based swaps that were
previously reported to the Trade Information Warehouse. See DTCC II
at 17.
---------------------------------------------------------------------------

    Finally, the Commission notes an issue relating to the reporting of
the counterparty ID of historical security-based swaps. As commenters
have discussed,\228\ certain foreign jurisdictions have privacy laws or
blocking statutes that may prohibit the disclosure of the identity of a
counterparty to a financial transaction, such as a security-based swap
transaction. Thus, the reporting side of a cross-border security-based
swap could face a dilemma: Comply with Regulation SBSR and report the
identity of the counterparty and thereby violate the foreign law, or
comply with the foreign law by withholding the identity of the
counterparty and thereby violate Regulation SBSR. As discussed in
Section XVI(B), infra, the Commission will consider requests for
exemptions from the requirement under Rule 901(i) to report the
identity of a counterparty with respect to historical security-based
swaps.
---------------------------------------------------------------------------

    \228\ See infra note 956.
---------------------------------------------------------------------------

III. Where To Report Data

A. All Reports Must Be Submitted to a Registered SDR

    Section 13A(a)(1) of the Exchange Act \229\ provides that ``[e]ach
security-based swap that is not accepted for clearing by any clearing
agency or derivatives clearing organization shall be reported to--(A) a
registered security-based swap data repository described in Section
13(n); or (B) in the case in which there is no security-based swap data
repository that would accept the security-based swap, to the
Commission.'' Section 13(m)(1)(G) of the Exchange Act \230\ provides
that ``[e]ach security-based swap (whether cleared or uncleared) shall
be reported to a registered security-based swap data repository.'' Rule
901(b) implements these statutory requirements.
---------------------------------------------------------------------------

    \229\ 15 U.S.C. 78m-1(a)(1).
    \230\ 15 U.S.C. 78m(m)(1)(G).
---------------------------------------------------------------------------

    Rule 901(b), as re-proposed, would have required reporting of the
security-based swap transaction information required under Regulation
SBSR ``to a registered security-based swap data repository or, if there
is no registered security-based swap data repository that would accept
the information, to the Commission.'' In addition, Rule 13n-5(b)(1)(ii)
under the Exchange Act, adopted as part of the SDR Adopting Release,
requires an SDR that accepts reports for any security-based swap in a
particular asset class to accept reports for all security-based swaps
in that asset class that are reported to the SDR in accordance with
certain SDR policies and procedures. In view of this requirement under
Rule 13n-5(b)(1)(ii) and the statutory requirement in Section
13(m)(1)(G) that all security-based swaps, whether cleared or
uncleared, must be reported to a registered SDR, the Commission does
not anticipate that any security-based swaps will be reported directly
to the Commission.
    Some commenters noted the potential advantages of designating a
single registered SDR for each asset class.\231\ Another commenter,
however, believed that a diverse range of options for reporting
security-based swap data would benefit the market and market
participants.\232\ These comments concerning the development of
multiple registered SDRs are discussed in Section XIX, infra. No
commenters opposed Rule 901(b), and the Commission is adopting Rule
901(b) with technical modifications to clarify the rule.\233\
---------------------------------------------------------------------------

    \231\ See DTCC II at 14-15 (noting the potential for
fragmentation of data and overstatement of net open interest and net
exposure if security-based swaps in the same asset class are
reported to multiple registered SDRs); ISDA/SIFMA I at note 12
(stating that the designation of a single registered SDR per asset
would provide valuable efficiencies because there would be no
redundancy of platforms or need for additional data aggregation,
which would reduce the risk of errors associated with transmitting,
aggregating, and analyzing data from multiple sources).
    \232\ See MFA I at 6.
    \233\ Rule 901(b), as re-proposed, would have required reporting
of the security-based swap transaction information required under
Regulation SBSR ``to a registered security-based swap data
repository or, if there is no registered security-based swap data
repository that would accept the information, to the Commission.''
Final Rule 901(b) provides: ``If there is no registered security-
based swap data repository that will accept the report required by
Sec.  242.901(a), the person required to make such report shall
instead provide the required information to the Commission.''
---------------------------------------------------------------------------

B. Duties of Registered SDR Upon Receiving Transaction Reports

1. Rule 901(f)--Time Stamps
    Rule 901(f), as re-proposed, provided that ``[a] registered
security-based swap data repository shall time stamp, to the second,
its receipt of any information submitted to it pursuant to paragraph
(c), (d), (e), or (i) of this section.'' The Commission preliminarily
believed that this requirement would help regulators to evaluate
certain trading activity.\234\ For example, a reporting side's pattern
of submitting late transaction reports could be an indicator of
weaknesses in the reporting side's internal compliance processes.
Accordingly, the Commission preliminarily believed that the ability to
compare the time of execution with the time of receipt of the report by
the registered SDR could be an important component of surveillance
activity conducted by relevant authorities.
---------------------------------------------------------------------------

    \234\ See Regulation SBSR Proposing Release, 75 FR 75221.
---------------------------------------------------------------------------

    One commenter, noting that proposed Rule 901(f) would require time-
stamping to the nearest second, argued that ``[t]ime-stamping increment
should be as small as technologically practicable, but in any event no
longer than fractions of milliseconds.'' \235\ The commenter expressed
the view that, especially in markets with multiple SB SEFs or where
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.'' \236\ The Commission notes, however, that Rule 901(f) is
designed to allow the Commission to learn when a transaction has been
reported to a registered SDR, not when the transaction was executed.
The interim phase of applying Regulation SBSR allows transactions to

be reported up to 24 hours after time of execution. The Commission
believes that no purpose would be served by knowing the moment of
reporting to the subsecond. Instead, the Commission believes that this
comment is germane instead to the reporting of time of execution.
Therefore, the Commission has considered this comment in connection
with Rule 901(c)(2) rather than with Rule 901(f).\237\
---------------------------------------------------------------------------

    \235\ Better Markets I at 9.
    \236\ Id.
    \237\ See supra notes 76 and 77 and accompanying text.
---------------------------------------------------------------------------

    The Commission continues to believe that requiring a registered SDR
to timestamp, to the second, its receipt of any information pursuant to
paragraphs (c), (d), (e), or (i) of Rule 901 is appropriate, and is
adopting Rule 901(f) as re-proposed. Rule 901(f) will allow the
Commission to compare the time of execution against the time of receipt
by the registered SDR to ascertain if a transaction report has been
submitted late.
2. Rule 901(g)--Transaction IDs
    Rule 901(g), as proposed and re-proposed, would have provided that
``[a] registered security-based swap data repository shall assign a
transaction ID to each security-based swap.'' The transaction ID was
defined in both the proposal and re-proposal as ``the unique
identification code assigned by a registered security-based swap data
repository to a specific security-based swap.'' The Commission
preliminarily believed that a unique transaction ID would allow
registered SDRs, regulators, and counterparties to more easily track a
security-based swap over its duration and would facilitate the
reporting of life cycle events and the correction of errors in
previously reported security-based swap information.\238\ The
transaction ID of the original security-based swap would allow for the
linking of the original report to a report of a life cycle event.
Similarly, the transaction ID would be required to be included on an
error report to identify the transaction to which the error report
pertained.
---------------------------------------------------------------------------

    \238\ See Regulation SBSR Proposing Release, 75 FR 75221.
---------------------------------------------------------------------------

    In proposing Rule 901(g), the Commission preliminarily believed
that, because each transaction is unique, it would not be necessary or
appropriate to look to an internationally recognized standards setting
body for assigning such identifiers.\239\ Instead, proposed Rule 901(g)
would have required a registered SDR to use its own methodology for
assigning transaction IDs.\240\
---------------------------------------------------------------------------

    \239\ See id.
    \240\ See id.
---------------------------------------------------------------------------

    Two commenters generally supported use of the transaction ID.\241\
One commenter stated that transaction IDs would allow for a complete
audit trail, permit the observation of concentrations of trading and
risk exposure at the transaction level, and facilitate more timely
analysis of market events.\242\ The second commenter agreed that a
transaction ID would be essential for reporting life cycle event and
secondary trade information, as well as corrections to reported
information.\243\
---------------------------------------------------------------------------

    \241\ See GS1 Proposal at 42; DTCC II at 15.
    \242\ See GS1 Proposal at 42 (also stating that transaction IDs
would benefit internal compliance departments and self-regulatory
organizations).
    \243\ See DTCC II at 15. Another commenter believed that
proposed Regulation SBSR would require public dissemination of the
transaction ID, and argued that the transaction ID should not be
publicly disseminated, as it could compromise the identity of the
counterparties to the security-based swap. The commenter suggested
instead that an SDR could create a separate identifier solely for
purposes of public dissemination. See ISDA IV at 17. Under
Regulation SBSR, as adopted, the transaction ID is not a data
element of security-based swap transaction that is required to be
publicly disseminated. Thus, registered SDRs must identify
transactions in public reports without using the transaction ID. See
infra Section XII(C) (discussing requirement for registered SDRs to
establish and maintain policies and procedures for disseminating
life cycle events).
---------------------------------------------------------------------------

    Commenters expressed mixed views regarding the entity that should
assign the transaction ID. One commenter stated that a platform should
assign the transaction ID to assure that the identifier is assigned at
the earliest point in the life of a transaction.\244\ A second
commenter suggested that registered SDRs should assign transaction
IDs,\245\ or have the flexibility to accept transaction IDs already
generated by the reporting side or to assign transaction IDs when
requested to do so.\246\ A third commenter expressed concern that
registered SDRs would assign transaction IDs in a non-standard manner,
which could hinder regulators' ability to gather transaction data
across registered SDRs to reconstruct an audit trail.\247\ A fourth
commenter, a trade association, recommended that security-based swaps
be identified by a Unique Trade Identifier (``UTI'') created either by
the reporting side or by a platform (including an execution venue or an
affirmation or middleware or electronic confirmation platform) on
behalf of the parties.\248\ This commenter noted that it has worked
with market participants to develop a standard for creating and
exchanging a single unique transaction identifier suitable for global
reporting.\249\
---------------------------------------------------------------------------

    \244\ See Tradeweb Letter at 5.
    \245\ DTCC II at 16 (arguing that this approach would
``eliminate any unintentional disclosure issues which stem from
linking a trade to a specific SEF, potentially increasing the
instances of unintended identification of the trade parties'').
    \246\ See DTCC V at 14.
    \247\ See GS1 Proposal at 42-43 (recommending an identification