registered SDRs. The Commission further believes that Rule 900(qq),
which defines ``UIC,'' and Rule 903, which establishes standards for
the use of UICs provide adequate parameters for the development of a
UIC system. The Commission believes that allowing the industry to
develop conventions for assigning UICs will likely result in a more
efficient and flexible UIC regime than if the Commission were to adopt
such conventions itself.
---------------------------------------------------------------------------

    \660\ See supra Section X(B)(1).
---------------------------------------------------------------------------

XI. Operating Hours of Registered SDRs--Rule 904

    Title VII of the Dodd-Frank Act does not explicitly address or
prescribe the hours of operation of the reporting and public
dissemination regime that it requires. The security-based swap market
is global in nature, and security-based swaps are executed throughout
the world and at any time of the day. In light of the global nature of
the security-based swap market, the Commission believes that the public
interest is served by requiring near-continuous reporting and public
dissemination of security-based swap transactions, no matter where or
when they are executed (subject to the cross-border rules discussed in
Section XV, infra). Furthermore, having a near-continuous reporting and
public dissemination regime would reduce the incentive for market
participants to defer execution of security-based swap transactions
until after regular business hours to avoid post-trade transparency.
Accordingly, the Commission proposed Rule 904, which would have
required a registered SDR to design its systems to allow for near-
continuous receipt and dissemination of security-based swap data. A
registered SDR would have been permitted to establish ``normal closing
hours'' and to declare, on an ad hoc basis, ``special closing hours,''
subject to certain requirements. Rule 904 was not revised as part of
the Cross-Border Proposing Release, and was re-proposed in exactly the
same form as initially proposed.
    As discussed below, three commenters addressed proposed Rule 904.
The Commission has carefully reviewed the comments received and has
determined to adopt Rule 904, as proposed and re-proposed, subject to
one conforming change, as discussed below.\661\
---------------------------------------------------------------------------

    \661\ In addition, the Commission is making a technical
conforming change to revise the title of the rule to refer to
``registered'' SDRs.
---------------------------------------------------------------------------

    Rule 904, as adopted, requires a registered SDR to have systems in
place to receive and disseminate information regarding security-based
swap data on a near-continuous basis, with certain exceptions. First,
under final Rule 904(a), a ``registered SDR may establish normal
closing hours when, in its estimation, the U.S. market and major
foreign markets are inactive.'' Second, under final Rule 904(b), a
registered SDR ``may declare, on an ad hoc basis, special closing hours
to perform system maintenance that cannot wait until normal closing
hours.'' Rule 904(b) further provides that a registered SDR shall, ``to
the extent reasonably possible under the circumstances, avoid
scheduling special closing hours during [periods] when, in its
estimation, the U.S. market and major foreign markets are most
active.'' Rules 904(a) and 904(b) each require the registered SDR to
provide participants and the public with reasonable advance notice of
its normal closing hours and special closing hours, respectively.
    Rule 904(c) specifies requirements for handling and disseminating
reported data during a registered SDR's normal and special closing
hours. During normal closing hours and, to the extent reasonably
practicable during special closing hours, a registered SDR is required
to ``have the capability to receive and hold in queue'' the transaction
data that it receives. Pursuant to Rule 904(d), immediately upon system
re-opening following normal closing hours or special closing hours
(assuming it was able to hold incoming data in queue), the registered
SDR is required to publicly disseminate any transaction data required
to be reported under Rule 901(c) that it received and held in queue.
Finally, pursuant to Rule 904(e), if the registered SDR could not,
while it was closed, receive and hold in queue reported information, it
would be required, immediately upon resuming normal operations, to send
a notice to all participants that it had resumed normal operations but
could not, while closed, receive and hold in queue such transaction
information. Therefore, any participant that had an obligation to
report information--but was unable to do so because of the registered
SDR's inability to receive and hold data in queue--would be required
upon notification by the registered SDR to promptly report the
information to the registered SDR.
    As proposed and re-proposed, Rule 904(e) would have provided that
if a participant could not fulfil a reporting obligation due to a
registered SDR's inability to receive and hold data in queue, the
participant would be required to report the information ``immediately''
upon receiving a notification that the registered SDR has resumed
normal operations. The Commission has decided to replace the word
``immediately'' with the word ``promptly'' in the final rule because
``promptly'' emphasizes the need for information to be submitted
without unreasonable delay while affording participants a practical
degree of flexibility. In general, the Commission believes that
submitting a required report ``promptly'' implies ``as soon as
practicable.''
    The three commenters that addressed Rule 904 were generally
supportive of the goal of promoting transparency and price discovery
though a regime of continuous reporting and public dissemination,\662\
although one of these commenters pointed out the need for registered
SDRs to close periodically to perform necessary system
maintenance.\663\ Two of these commenters also suggested alternative
operating hours and procedures for registered SDRs.\664\ One commenter
stated that the requirements that a registered SDR have normal closing
hours only when neither U.S. nor international markets are active, and
should continue to receive the relevant transaction data and hold them
in queue even when the registered SDR is closed for normal or ad hoc
special closing hours, exceeded the capabilities of currently existing
reporting infrastructures. The commenter argued that such requirements
would increase the risk of infrastructure failure because SDRs would
not have adequate time to maintain and update their systems.\665\ This
commenter suggested that, if systems are required to be available on a
24-hour basis, the Commission should define operating hours to be 24
hours from Monday to Friday, and consider allowing additional closing
hours either ``when markets are less active'' or ``when only less
active markets are open.'' \666\
---------------------------------------------------------------------------

    \662\ See Barnard I at 3; Markit I at 1; DTCC II at 1.
    \663\ See Markit I at 4.
    \664\ See Markit I at 4-5; DTCC II at 19-20; DTCC IV at 4
(recommending that SDRs operate on a 24/6.5 basis to reflect the
global nature of the financial markets and process transactions in
real time, while also maintaining multiple levels of operational
redundancy and data security).
    \665\ See Markit I at 4.
    \666\ Markit I at 4-5.
---------------------------------------------------------------------------

    The Commission believes there are compelling reasons to implement a
system of reporting and public dissemination that, in general, operates
near-continuously. As discussed above,

the Commission believes that requiring near-continuous reporting and
public dissemination of security-based swaps--except for when, in the
estimation of a registered SDR, the U.S. market and major foreign
markets are inactive--will serve the public interest and reduce
incentives for market participants to trade outside of regular business
hours. The Commission, however, recognizes the need for a registered
SDR to have closing hours to maintain and update its systems, and Rules
904(a) and 904(b), as adopted, specifically allow registered SDRs to
have normal and special closing hours. Further, while Rule 904(b)
states that a registered SDR should avoid scheduling special closing
hours during a time when, in its estimation, the U.S. and major foreign
markets are most active, the Commission notes that a registered SDR is
required to do so only ``to the extent reasonably possible under the
circumstances.'' As such, the Commission believes that Rules 904(a) and
904(b) provide sufficient flexibility to registered SDRs in determining
their closing times to perform the necessary maintenance procedures.
The Commission does not believe it would be appropriate to require
registered SDRs to operate 24 hours only from Monday to Friday, as the
commenter suggests, as certain major foreign markets may be active
during hours that fall within the weekend in the United States.
    The Commission recognizes the commenter who asserted that the
proposed requirement for a registered SDR to receive and hold in the
queue the data required to be reported during its closing hours
``exceeds the capabilities of currently-existing reporting
infrastructures.'' \667\ The Commission notes that this comment was
submitted in January 2011. Since that time, however, provisionally
registered CFTC SDRs that are likely also to register as SDRs with the
Commission appear to have developed the capability of receiving and
holding data in queue during their closing hours.\668\ Accordingly, the
Commission believes that it is appropriate to require registered SDRs
to hold data in queue during their closing hours should help to prevent
market disruptions by enabling reporting sides for security-based swaps
to report transactions at all times.
---------------------------------------------------------------------------

    \667\ Markit I at 4.
    \668\ See, e.g., DDR Rulebook, Section 7.1 (DDR System
Accessibility) (``Data submitted during DDR System down time is
stored and processed once the service has resumed''), available at
http://www.dtcc.com/~/media/Files/Downloads/legal/rules/
DDR_Rulebook.pdf (last visited October 7, 2014).
---------------------------------------------------------------------------

XII. Subsequent Revisions to Reported Security-Based Swap Information

 A. Reporting Life Cycle Events--Rule 901(e)

 1. Description of Proposal and Re-Proposal
    Rule 901(e), as proposed and re-proposed, would have required the
reporting of certain life cycle event information. ``Life cycle event''
was defined in the proposal and re-proposal to mean ``with respect to a
security-based swap, any event that would result in a change in the
information reported to a registered security-based swap data
repository under Sec.  242.901, including a counterparty change
resulting from an assignment or novation; a partial or full termination
of the security-based swap; a change in the cash flows originally
reported; for a security-based swap that is not cleared, any change to
the collateral agreement; or a corporate action affecting a security or
securities on which the security-based swap is based (e.g., merger,
dividend, stock split, or bankruptcy). Notwithstanding the above, a
life cycle event shall not include the scheduled expiration of the
security-based swap, a previously described and anticipated interest
rate adjustment (such as a quarterly rate adjustment), or other event
that does not result in any change to the contractual terms of the
security-based swap.''
    Re-proposed Rule 901(e) would have provided that ``For any life
cycle event, and any adjustment due to a life cycle event, that results
in a change to information previously reported pursuant to Rule 901(c),
901(d), or 901(i), the reporting side shall promptly provide updated
information reflecting such change to the entity to which it reported
the original transaction, using the transaction ID,'' subject to two
exceptions. Under Rule 901(e)(1), as re-proposed, if the reporting side
ceased to be a counterparty to the security-based swap due to any
assignment or novation and if the new side included a U.S. person, a
security-based swap dealer, or a major security-based swap participant,
the new side would be the reporting side following the assignment or
novation. Under re-proposed Rule 901(e)(2), if the new side did not
include a U.S. person, a security-based swap dealer, or a major
security-based swap participant, the other side would be the reporting
side following the assignment or novation.
    In proposing Rule 901(e), the Commission preliminarily believed
that the reporting of life cycle event information would provide
regulators with access to information about significant changes that
occur over the duration of a security-based swap.\669\ The Commission
also stated that the reporting of life cycle event information would
help to assure that regulators have accurate and up-to-date information
concerning outstanding security-based swaps and the current obligations
and exposures of security-based swap counterparties.\670\
---------------------------------------------------------------------------

    \669\ See Regulation SBSR Proposing Release, 75 FR 75220.
    \670\ See id. In a separate rulemaking, the Commission is
adopting a rule that will require a registered SDR to establish,
maintain, and enforce written policies and procedures reasonably
designed to calculate positions for all persons with open security-
based swaps for which the SDR maintains records. See SDR Adopting
Release (adopting Rule 13n-5(b)(2) under the Exchange Act).
---------------------------------------------------------------------------

    In determining the entity that would be required to report life
cycle event information, the Commission's approach in proposing and re-
proposing Rule 901(e) was that, generally, the person who originally
reported the initial transaction would have the responsibility to
report any subsequent life cycle event.\671\ However, if the life cycle
event were an assignment or novation that removed the original
reporting party, either the new counterparty or the remaining original
counterparty would have to be the reporting party.\672\
---------------------------------------------------------------------------

    \671\ See Cross-Border Proposing Release, 78 FR 31068.
    \672\ Rule 901(e), as initially proposed, would have provided
that the new counterparty would be the reporting party if it is a
U.S. person; the other original counterparty would become the
reporting party if the new counterparty is not a U.S. person.
---------------------------------------------------------------------------

    In re-proposing Regulation SBSR, the Commission included the new
concept of a ``reporting side,'' which would have included the direct
counterparty and any indirect counterparty. The Cross-Border Proposing
Release also proposed to impose greater duties to report transactions
on non-U.S. person security-based swap dealers or major security-based
swap participants. Accordingly, the Commission re-proposed Rule 901(e)
to provide that the duty to report would switch to the other side only
if the new side did not include a U.S. person (as in the originally
proposed rule) or a security-based swap dealer or major security-based
swap participant. The Commission preliminarily believed that, if the
new side included a security-based swap dealer or major security-based
swap participant, the new side should retain the duty to report. This
approach was designed to align reporting duties with the market
participants that the Commission believed would be better

suited to carrying them out, because non-U.S. person security-based
swap dealers and major security-based swap participants likely would
have taken significant steps to establish and maintain the systems,
processes and procedures, and staff resources necessary to report
security-based swaps.\673\
---------------------------------------------------------------------------

    \673\ See Cross-Border Proposing Release, 78 FR 31068.
---------------------------------------------------------------------------

2. Final Rules Relating to Life Cycle Events and Response to Comments
a. General Comment and Definition of ``Life Cycle Event''
    One commenter expressed support for the requirement to report life
cycle event information, stating that the reporting of life cycle event
information was necessary for detailed market regulation and for
prudential and central bank regulation.\674\ The commenter noted that
``[m]any life cycle events are price-forming or significantly change
the exposures under a trade. . . .'' \675\ In subsequent comment
letters, this commenter stated that the definition of ``life cycle
event'' was overly broad, and that life cycle events should be limited
to those that impact the counterparties to or the pricing of the
security-based swap.\676\ Specifically, the commenter suggested that
the Commission define ``life cycle event'' to mean ``an event that
would result in a change in the counterparty or price of a security-
based swap reported to the registered [SDR].'' \677\ However, another
commenter believed that the proposed definition was ``clear,
sufficient, and complete.'' \678\
---------------------------------------------------------------------------

    \674\ See DTCC II at 13.
    \675\ See id.
    \676\ See DTCC V at 11; DTCC VI at 9.
    \677\ DTCC VI at 9.
    \678\ Barnard I at 3.
---------------------------------------------------------------------------

    After careful consideration, the Commission is adopting the
definition of ``life cycle event'' in Rule 900(q) substantially as re-
proposed, but with certain minor modifications to respond to comments
and to clarify the original intent of the rule.\679\ First, the
Commission is making a technical change to the definition to indicate
that a life cycle event refers to any event that would result in a
change in the information reported ``under Sec.  242.901(c), (d), or
(i),'' rather than any event that would result in a change in the
information reported ``under Sec.  242.901'' (as re-proposed). This
technical change will conform the definition of ``life cycle event'' to
the requirements of Rule 901(e), as re-proposed and as adopted, which
requires the reporting of a change to information previously reported
pursuant to paragraph (c), (d), or (i) of Rule 901. By defining ``life
cycle event'' in this manner, the Commission aims to ensure that
information reported pursuant to Rules 901(c), (d), and (i) is updated
as needed, so that the data maintained by registered SDRs remains
current for the duration of a security-based swap. This requirement
should help to ensure that the data accessible to the Commission
through registered SDRs accurately reflects the current state of the
market. Therefore, the Commission does not believe that it is
appropriate to limit the definition of ``life cycle event'' to post-
execution events that impact the counterparties to or the pricing of a
security-based swap, as suggested by the commenter.\680\ Although the
final definition of ``life cycle event'' encompasses these types of
events, it also encompasses other information reported pursuant to
Rules 901(c), 901(d), or 901(i).
---------------------------------------------------------------------------

    \679\ Rule 900(q), as adopted, defines ``life cycle event'' to
mean ``with respect to a security-based swap, any event that would
result in a change in the information reported to a registered
security-based swap data repository under Sec.  242.901(c), (d) or
(i), including: An assignment or novation of the security-based
swap; a partial or full termination of the security-based swap; a
change in the cash flows originally reported; for a security-based
swap that is not a clearing transaction, any change to the title or
date of any master agreement, collateral agreement, margin
agreement, or any other agreement incorporated by reference into the
security-based swap contract; or a corporate action affecting a
security or securities on which the security-based swap is based
(e.g., a merger, dividend, stock split, or bankruptcy).
Notwithstanding the above, a life cycle event shall not include the
scheduled expiration of the security-based swap, a previously
described and anticipated interest rate adjustment (such as a
quarterly interest rate adjustment), or other event that does not
result in any change to the contractual terms of the security-based
swap.''
    \680\ See DTCC VI at 9. See also DTCC II at 13 (stating that
``[m]any life cycle events are price-forming or significantly change
the exposures under a trade. . . . The current definition supports
reporting of these events'').
---------------------------------------------------------------------------

    One commenter asked that the Commission remove the reference to
``dividends'' in the definition of ``life cycle event'' because
dividends ``are contract intrinsic events that do not result in a
change to the contractual terms of the SBS and therefore, should not be
defined as reportable life cycle events.'' \681\ The Commission does
not believe that it is necessary to revise the definition of ``life
cycle event'' as the commenter suggests. As indicated above, the
definition of ``life cycle event'' provides, in relevant part, that a
life cycle event includes ``any event that would result in a change in
the information reported to a registered [SDR] . . . including . . . a
corporate action affecting a security or securities on which the
security-based swap is based (e.g., a merger, dividend, stock split, or
bankruptcy)'' (emphasis added). Thus, a regular payment of a dividend
that does not require a restatement of the terms of the security-based
swap would not constitute a life cycle event. However, other actions
involving dividends could be life cycle events. For example, the
distribution of a stock dividend that required an adjustment to the
notional terms of an equity security-based swap--or any other corporate
action related to dividends that resulted in a modification of one or
more terms of the security-based swap--would be a life cycle event and
therefore would have to be reported pursuant to Rule 901(e).
---------------------------------------------------------------------------

    \681\ ISDA IV at 11.
---------------------------------------------------------------------------

    Second, the Commission is clarifying that a life cycle event
includes ``an assignment or novation of the security-based swap,''
instead of ``a counterparty change resulting from an assignment or
novation.'' The Commission notes that, while assignments and novations
necessarily include a counterparty change, assignments and novations
also may involve modifications to other terms of the security-based
swap reported pursuant to paragraphs (c), (d), or (i) of Rule 901.
These modifications are the type of changes that the Commission
believes should be reported to a registered SDR; therefore, the
Commission is modifying the definition of ``life cycle event'' to
clarify this view.
    Third, the Commission is making a technical change to the
definition to indicate that a life cycle event includes, for a
security-based swap that is not a clearing transaction, ``any change to
the title or date of any master agreement, collateral agreement, margin
agreement, or any other agreement incorporated by reference into the
security-based swap contract.'' As re-proposed, the definition of
``life cycle event'' would have included, ``for a security-based swap
that is not cleared, any change to the collateral agreement.'' One
commenter questioned the need to include a reference to a change in the
collateral agreement in the definition of ``life cycle event'' because
``collateral agreement terms are not among the data required to be
reported upon execution.'' \682\ The Commission agrees with the
commenter that collateral agreement terms are not

required to be reported, and the definition of ``life cycle event'' in
final Rule 900(q) no longer refers to changes in the collateral
agreement. To assure that Rule 901(e) operates as intended, the
Commission has modified the definition of ``life cycle event'' in final
Rule 900(q) to reference, with respect to a security-based swap that is
not a clearing transaction, the same terms that must be reported
pursuant to Rule 901(d)(4).\683\ Thus, if there were a change in the
title or date of a master agreement, collateral agreement, margin
agreement, or other agreement incorporated by reference into a
security-based swap contract, such a change would be a ``life cycle
event'' as defined in final Rule 900(q), and final Rule 901(e) would
require reporting of that change.
---------------------------------------------------------------------------

    \682\ DTCC VI at 9. Another commenter stated that the parties to
a collateral agreement rarely modify their agreement over its life,
and that any change to a collateral agreement would require
extensive negotiation between the counterparties. Accordingly, the
commenter believed that the cost of establishing reporting processes
to detect and report changes to a collateral agreement would
outweigh the usefulness of reporting them. See ISDA/SIFMA I at 16.
    \683\ Final Rule 901(d)(4) requires, for a security-based swap
that is not a clearing transaction, reporting of the title and date
of any master agreement, collateral agreement, margin agreement, or
other agreement incorporated by reference in the security-based swap
contract.
---------------------------------------------------------------------------

    Finally, two commenters argued that the ``Commission's
classification of a swap being accepted for clearing as a life cycle
event is inconsistent with the operations of a Clearing Agency''
because clearing may require the ``termination of the pre-existing
alpha swap in order to create two new, unique swaps.'' \684\ The
Commission agrees that any security-based swap that results from
clearing an alpha should not be considered a life cycle event of the
alpha, although the termination of the alpha would be such a life cycle
event.\685\ The Commission believes that the new term ``clearing
transaction'' makes clear that security-based swaps that result from
clearing (e.g., betas and gammas in the agency model) are independent
security-based swaps, not life cycle events of the security-based swap
that is submitted to clearing (e.g., alpha security-based swaps).
---------------------------------------------------------------------------

    \684\ CME/ICE Letter at 3. As discussed in Section V, supra, in
the agency model of clearing, and sometimes in the principal model
as well, acceptance of an alpha for clearing terminates the alpha.
    \685\ See Securities Exchange Act Release No. 66703 (March 30,
2012), 77 FR 20536-37 (April 5, 2012) (noting that ``when a
security-based swap between two counterparties . . . is executed and
submitted for clearing, the original contract is extinguished and
replaced by two new contracts where the [clearing agency] is the
buyer to the seller and the seller to the buyer''). This treatment
also would be consistent with CFTC regulations. See 17 CFR
39.12(b)(6) (CFTC rule providing that derivatives clearing
organizations that clear swaps must have rules providing that, among
other things, ``upon acceptance of a swap by the derivatives
clearing organization for clearing: (i) The original swap is
extinguished; [and] (ii) The original swap is replaced by an equal
and opposite swap between the derivatives clearing organization and
each clearing member acting as principal for a house trade or acting
as agent for a customer trade'').
---------------------------------------------------------------------------

b. Final Rule 901(e)(1)
    As described above, re-proposed Rule 901(e) would have required the
reporting side to promptly report any life cycle event, or any
adjustment due to a life cycle event, that resulted in a change to
information previously reported pursuant to Rule 901(c), (d), or (i) to
the entity to which it reported the original transaction, using the
transaction ID. Rule 901(e), as proposed and re-proposed, also included
provisions for determining which counterparty would report the life
cycle event. The Commission is adopting a modified version of Rule
901(e) to address comments received and to implement certain technical
changes. The Commission also has changed the title of the rule from
``Duty to report any life cycle event of a security-based swap'' in the
re-proposal to ``Reporting of life cycle events'' in the final rule. In
addition, final Rule 901(e) provides that a life cycle event or
adjustment due to a life cycle event must be reported within the
timeframe specified in Rule 901(j).
    Although the definition of ``life cycle event'' would encompass the
disposition of a security-based swap that has been submitted to
clearing (e.g., whether, under the agency model of clearing, the alpha
security-based swap has been accepted for clearing or rejected by the
clearing agency), the Commission believes that it is appropriate to
address the reporting of this specific type of life cycle event in the
context of the Regulation SBSR Proposed Amendments Release, which
address a number of topics regarding the reporting of security-based
swaps that will be submitted to clearing or that have been cleared.
Accordingly, final Rule 901(e)(1)(i) indicates that the reporting side
shall not have a duty to report whether or not a security-based swap
has been accepted for clearing or terminated by a clearing agency, and
instead provides that ``A life cycle event, and any adjustment due to a
life cycle event, that results in a change to information previously
reported pursuant to paragraph (c), (d), or (i) of this section shall
be reported by the reporting side, except that the reporting side shall
not report whether or not a security-based swap has been accepted for
clearing.''
c. Final Rule 901(e)(2)
    Re-proposed Rule 901(e) would have required the reporting side to
include the transaction ID in a life cycle event report, and to report
life cycle event information to the entity to which it reported the
original transaction. Final Rule 901(e)(2) retains both of these
requirements.\686\ The Commission believes that including the
transaction ID in a life cycle event report will help to ensure that it
is possible to link the report of a life cycle event to the report of
the initial security-based swap of which it is a life cycle event. One
commenter supported the requirement to report life cycle events to the
same entity that received the original transaction report.\687\ The
commenter stated that requiring a single registered SDR to receive,
store, and report, where appropriate, all relevant information related
to a given security-based swap throughout its life cycle would help to
prevent fragmentation and ensure that corrections to previously
reported data could be easily identified by the public.\688\ The
Commission generally agrees with these views, and final Rule 901(e)(2)
retains the requirement to report life cycle events to the same entity
to which the original transaction was reported.
---------------------------------------------------------------------------

    \686\ Final Rule 901(e)(2) provides that ``All reports of life
cycle events and adjustments due to life cycle events shall be
reported within 24 hours of the time of occurrence of the life cycle
event to the entity to which the original security-based swap
transaction was reported and shall include the transaction ID of the
original transaction.''
    \687\ See MarkitSERV I at 8.
    \688\ See id. See also DTCC IX at 2.
---------------------------------------------------------------------------

d. Reporting Timeframe for Life Cycle Events
    Rule 901(e), as proposed and re-proposed, would have required life
cycle events to be reported by the reporting side ``promptly.'' Two
commenters believed that it was appropriate to require that life cycle
events be reported ``promptly.'' \689\ One of these commenters also
stated that life cycle events could require different processing times
based on the nature of the event, and asked the Commission to clarify
the meaning of ``promptly'' with respect to life cycle event
reporting.\690\ In particular, the commenter stated that ``the term
`promptly,' . . . without further explanation, may be interpreted by
reporting parties differently for similar events and processes,
particularly in a market where certain processes have historically
taken a

number of days to effect.'' \691\ This commenter also suggested that
the Commission revise Rule 901(e) to allow for the flexibility of
reporting life cycle events either event-by-event or through one daily
submission that would include multiple events.\692\ Another commenter
stated that the required time for reporting both life cycle events and
corrections should be stronger and more specific than the proposed
requirement that they be reported ``promptly.'' \693\
---------------------------------------------------------------------------

    \689\ See Barnard I at 3; DTCC II at 13.
    \690\ See DTCC II at 13. The commenter stated that life cycle
events that are price-forming events subject to confirmation could
be reported within the same timeframes as initial reports of these
events. However, the commenter indicated that life cycle events
resulting from other processes, such as corporate actions or credit
events, ``where many trades will be impacted simultaneously and
processing may be manual or automated,'' would require different
amounts of time to report. See id.
    \691\ DTCC II at 13.
    \692\ See DTCC V at 11. See also ISDA III (requesting that
``reporting parties be allowed to report lifecycle events either
intra-day or as an end-of day [sic] update to the terms of the
[security-based swap]''). Further, one commenter noted that the CFTC
rules allow a life cycle event to be reported either as event data
on the same day as the event occurs or daily as ``state data,'' and
that non-swap dealers or non-major swap participants may report
these events either as life cycle event data or as state data no
later than the end of the first business day following the event.
See ISDA IV at 11. This commenter requested that the Commission
confirm in its rules that the same approach and timelines may be
applied to meet the requirements of Regulation SBSR. The Commission
notes that Rules 901(e) and 901(j), as adopted, provide for
reporting of a life cycle event or an adjustment due to a life cycle
event within 24 hours after the occurrence of the life cycle event
or the adjustment due to the life cycle event. The Commission notes,
further, that Rule 901(e)(1) requires the reporting of a life cycle
event, and any adjustment due to a life cycle event, that results in
a change to information previously reported pursuant to Rule 901(c),
901(d), or 901(i). Thus, Rule 901(e)(1) contemplates the reporting
of the specific changes to previously reported information. Reports
of life cycle events, therefore, must clearly identify the nature of
the life cycle event for each security-based swap. It is not
sufficient merely to re-report all of the terms of the security-
based swap each day without identifying which data elements have
changed. However, Regulation SBSR would not prevent a registered SDR
from developing for its members a mechanism or other service that
automates or facilitates the production of life cycle events from
state data.
    \693\ See Better Markets I at 9.
---------------------------------------------------------------------------

    After careful consideration, the Commission does not believe that
it would be appropriate to require life cycle events or adjustments due
to life cycle events to be reported more quickly than the time within
which information relating to the original transaction must be
reported. As noted in Section VII(B)(3), supra, final Rule 901(j)
provides that the transaction information required by Rules 901(c) and
901(d) generally must be reported within 24 hours of the time of
execution. Similarly, Rule 901(j) provides that the reporting timeframe
for Rule 901(e) shall be 24 hours after the occurrence of the life
cycle event or the adjustment due to the life cycle event. The
Commission believes that 24 hours should provide sufficient time to
report life cycle events even if the processing of some of these events
is not yet fully automated.\694\ The Commission believes, further, that
specifying a time within which life cycle event information must be
reported will address the commenter's concern that reporting sides
could adopt different interpretations of the reporting timeframe. The
Commission notes that it anticipates soliciting comment on the
timeframe for reporting life cycle events, adjustments, and clearing
transactions in the future, when it considers block thresholds and time
delays.
---------------------------------------------------------------------------

    \694\ See DTCC II at 13. The Commission also believes that the
24-hour timeframe for reporting life cycle events will allow
reporting sides to determine whether to report life cycle events on
an intra-day or end-of-day basis. See DTCC V at 11; ISDA III.
Reports of life cycle events, however, must clearly identify the
nature of the life cycle event for each security-based swap. It is
not sufficient merely to re-report all of the terms of the security-
based swap each day without identifying which data elements have
changed. See also note 692 supra.
---------------------------------------------------------------------------

e. Re-Proposed Rule 901(e)(2)
    The Commission has determined not to adopt re-proposed Rule
901(e)(2), which would have specified the reporting side following an
assignment or novation of the security-based swap.\695\ One commenter
noted that, under the current market practice for reporting novations,
the reporting party is re-determined based on the current status of the
parties.\696\ This commenter noted that the current practice allows the
reporting party logic to be consistent for new as well as novated
trades, and recommended that the Commission use a consistent
methodology for reporting of new trades and novations. The Commission
agrees that using a single methodology for assigning reporting
obligations would be administratively easier than using one methodology
when a security-based swap is first executed and a different
methodology when the counterparties change as a result of an assignment
or novation. As the Commission explained above,\697\ it has determined
that the reporting side following an assignment or novation will be
determined using the procedures in Rule 901(a).
---------------------------------------------------------------------------

    \695\ Re-proposed Rule 901(e)(2) would have provided that the
duty to report life cycle event information following an assignment
or novation would switch to the other side only if the new side did
not include a U.S. person (as in the originally proposed rule) or a
security-based swap dealer or major security-based swap participant.
As the Commission explained in the Cross-Border Proposing Release,
if the new side included a security-based swap dealer or major
security-based swap participant, the new side should retain the duty
to report. See 78 FR 31068.
    \696\ See ISDA III.
    \697\ See supra Section V(C)(5).
---------------------------------------------------------------------------

f. Additional Comments Regarding Life Cycle Event Reporting
    One commenter believed that life cycle events should be reported
using standard market forms, such as the trade confirmation for
novations and early terminations, and the exercise notice for an
exercise.\698\ Contrary to the commenter's suggestion, the Commission
believes that registered SDRs should be responsible for specifying the
precise manner and format for reporting data. Moreover, the Commission
understands that standard market forms may exist for some, but not all,
of the life cycle events that must be reported under Regulation SBSR.
Therefore, the Commission has determined not to prescribe a format for
reporting sides to report life cycle event information. Instead, Rule
907(a)(3), as adopted, requires a registered SDR to establish and
maintain written policies and procedures that specify how reporting
sides are to report life cycle events and corrections to previously
submitted information, for making corresponding updates or corrections
to transaction records, and for applying an appropriate flag to these
transaction reports.\699\
---------------------------------------------------------------------------

    \698\ See DTCC II at 13.
    \699\ See infra Section XII(C).
---------------------------------------------------------------------------

    One commenter stated that it was critical for the SEC and the CFTC
to adopt consistent regulatory approaches ``[i]n the life cycle event
model across asset classes.'' \700\ The Commission agrees that would be
useful for the Commissions to adopt consistent approaches to the
reporting of life cycle event information to the extent possible. The
Commission believes that Regulation SBSR's approach to life cycle event
reporting is broadly consistent with the approach taken by the CFTC.
For example, because the agencies have adopted similar definitions, the
life cycle event information required to be reported under the rules of
both agencies is substantially similar.\701\ In addition, both
agencies' rules require that life cycle events be reported to the same
entity that received the report of the original transaction, and both
agencies' rules require the entity that reports the initial transaction
to also report life cycle events for the transaction. The Commission
notes that a registered SDR that accepts transaction reports for both
swaps and security-based swaps could establish policies and procedures
for reporting life cycle events of security-based swaps that are
comparable to its policies and

procedures for reporting life cycle events of swaps, provided that its
policies and procedures for reporting life cycle events of security-
based swaps comply with the requirements of Regulation SBSR.
---------------------------------------------------------------------------

    \700\ ISDA/SIFMA I at 6.
    \701\ See CFTC Rule 45.1, 17 CFR 45.1. The Commissions' ongoing
reporting requirements differ, however, with respect to the
reporting of valuation information. The CFTC's rules require
reporting of valuation data as well as life cycle event data. As
discussed in above in Section II(B)(3)(k), the Commission is not
requiring reporting of valuation data for security-based swaps.
---------------------------------------------------------------------------

    Another commenter expressed the view that Regulation SBSR ``should
clarify what shall be reported as the time of execution for a life
cycle event for purposes of public dissemination.'' \702\ The commenter
stated that the CFTC requires market participants to report the
execution time of the original trade as the execution time for a life
cycle event for the trade. The commenter suggested that, under this
approach, ``the data that is publicly disseminated for lifecycle events
may not be that meaningful to the public as it does not include any
indication of the point in time the reported price has been traded.''
\703\ The commenter stated, further, that the time of execution for a
life cycle event for purposes of public dissemination ``should be the
date and time such price-forming event is agreed.'' \704\
---------------------------------------------------------------------------

    \702\ ISDA IV at 13 (emphasis in original).
    \703\ Id.
    \704\ Id. at 13-14.
---------------------------------------------------------------------------

    As discussed in Section VII(B)(3), supra, final Rule 901(j)
provides that the reporting timeframe for a life cycle event shall be
24 hours after the occurrence of the life cycle event or the adjustment
due to the life cycle event. Final Rule 902(a) requires a registered
SDR to publicly disseminate a transaction report of a life cycle event,
or adjustment due to a life cycle event, immediately upon receipt of
the information. Thus, under Regulation SBSR, a life cycle event, or an
adjustment due to a life cycle event, must be reported and publicly
disseminated within 24 hours after the occurrence of the life cycle
event or adjustment due to the life cycle event. The Commission
believes that together these requirements will provide market observers
with certain information concerning the time when the life cycle event
occurred. However, the Commission notes that Regulation SBSR, as
proposed and re-proposed, did not require the reporting or public
dissemination of the time of execution of a life cycle event, and
Regulation SBSR, as adopted, likewise includes no such requirements.

B. Error Corrections--Rule 905

    As the Commission noted in the Regulation SBSR Proposing Release,
any system for transaction reporting must accommodate the possibility
that certain data elements may be incorrectly reported.\705\ Therefore,
the Commission proposed Rule 905 to establish procedures for correcting
errors in reported and disseminated security-based swap information.
---------------------------------------------------------------------------

    \705\ See 75 FR 75236.
---------------------------------------------------------------------------

    In the Cross-Border Proposing Release, the Commission modified
proposed Rule 905 slightly to correspond with certain new provisions in
re-proposed Rule 908, which contemplated that certain types of cross-
border security-based swaps would be required to be reported but not
publicly disseminated. Rule 905 was re-proposed to clarify that, if a
registered SDR receives corrected information relating to a previously
submitted transaction report, it would be required to publicly
disseminate a corrected transaction report only if the initial
security-based swap were subject to the public dissemination
requirement.\706\ The Commission also made certain other technical and
conforming changes,\707\ but otherwise re-proposed Rule 905 was
substantially similar to proposed Rule 905.
---------------------------------------------------------------------------

    \706\ As discussed above in Section VI, Rule 902 requires a
registered SDR to immediately publicly disseminate a transaction
report of a security-based swap, or a life cycle event or adjustment
due to a life cycle event. If a security-based swap falls into the
category of regulatory reporting but not public dissemination, there
would be no need to publicly disseminate the correction because the
initial security-based swap was not publicly disseminated.
    \707\ The Commission modified the language from ``counterparty''
or ``party'' to ``side'' in the re-proposal of Rule 905. Additional
minor changes were made for clarification such as inserting
``transaction'' in Rule 905(a)(1) and changing an ``a'' to ``the''
in Rule 905(b)(1). Re-proposed Rule 905 also substitutes the word
``counterparties''--which is a defined term in Regulation SBSR--for
the word ``parties,'' which was used in the initial proposal but was
not a defined term.
---------------------------------------------------------------------------

    As discussed below, the Commission received several comments on
proposed Rule 905. After consideration of the comments, the Commission
has determined to adopt Rule 905 with certain minor editorial
revisions.\708\
---------------------------------------------------------------------------

    \708\ For example, the title of final Rule 905(a) is ``Duty to
correct,'' rather than ``Duty of counterparties to correct.'' In
addition, the Commission is deleting a reference to ``security-based
swap transaction'' from Rule 905(a)(2), as well as a reference to
``reporting side'' in Rule 905(b)(1).''
---------------------------------------------------------------------------

    Rule 905(a) applies to any counterparty to a security-based swap
that discovers an error in the information reported with respect to
that security-based swap. If a non-reporting side discovers the error,
the non-reporting side shall promptly notify the reporting side of the
error. Once the reporting side receives notification of the error from
the non-reporting side, or if the reporting side discovers the error on
its own, the reporting side must promptly submit an amended report--
containing corrected data--to the registered SDR that received the
erroneous transaction report. The reporting side must submit the report
required by Rule 905(a) in a manner consistent with the policies and
procedures of the registered SDR that are contemplated by Rule
907(a)(3).\709\
---------------------------------------------------------------------------

    \709\ See infra Section XII(C).
---------------------------------------------------------------------------

    Rule 905(b) details the responsibilities of a registered SDR to
correct information and re-disseminate corrected information, where
appropriate. If a registered SDR either discovers an error in the
security-based swap information or receives notification of an error
from a reporting side, the registered SDR is required to verify the
accuracy of the terms of the security-based swap and, following such
verification, promptly correct the information in its system. If the
erroneous information contains any primary trade information enumerated
in Rule 901(c) (and the transaction is dissemination-eligible \710\),
the registered SDR must publicly disseminate a corrected transaction
report of the security-based swap promptly following verification of
the trade by the counterparties to the security-based swap, with an
indication that the report relates to a previously disseminated
transaction.\711\
---------------------------------------------------------------------------

    \710\ See Rule 902(c) (listing certain transactions that a
registered SDR may not publicly disseminate).
    \711\ See Rule 905(b)(2). When verifying information pursuant to
Rule 905(b), a registered SDR must comply with the standards of Rule
13n-5. In particular, Rule 13n-5(b)(1)(iii) provides that an SDR
``shall establish, maintain, and enforce written policies and
procedures reasonably designed to satisfy itself that the
transaction data that has been submitted to the security-based swap
data repository is complete and accurate, and clearly identifies the
source for each trade side and the pairing method (if any) for each
transaction in order to identify the level of quality of the
transaction data.''
---------------------------------------------------------------------------

    Three commenters were generally supportive of the proposed error
reporting procedures. One commenter believed that publicly
disseminating error reports would ``increase confidence in the
integrity of the markets.'' \712\ Another commenter stated that it
supported ``the objective of prompt correction of errors by the
reporting party.'' \713\ A third commenter expressed support for
requiring a reporting party to correct previously reported erroneous
data, and agreed that it was appropriate for a non-reporting
counterparty to have the obligation to notify the reporting party of an
error of which it is aware.\714\
---------------------------------------------------------------------------

    \712\ Barnard I at 3.
    \713\ ISDA/SIFMA I at 9.
    \714\ See MFA I at 5.

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

    The third commenter also sought guidance regarding the application
of Rule 905 if a dispute arose between a reporting side and non-
reporting side concerning whether a report was, in fact,
erroneous.\715\ The commenter urged the Commission to provide in its
final rule that, if corrected information is not promptly reported to
the registered SDR because of a dispute over whether an error exists,
the non-reporting party side may itself report the disputed data to the
registered SDR; the commenter believed that, in such cases, the
Commission should oblige the registered SDR to review promptly the
disputed data with the counterparties.\716\
---------------------------------------------------------------------------

    \715\ See id.
    \716\ See id.
---------------------------------------------------------------------------

    The Commission notes that, in a separate release, it is adopting
Rule 13n-5(b)(6) under the Exchange Act, which requires an SDR to
establish procedures and provide facilities reasonably designed to
effectively resolve disputes over the accuracy of the transaction data
and positions that are recorded in the SDR.\717\ As the Commission
notes in adopting that rule, only the parties to a dispute can resolve
it. Thus, the SDR itself is not required to resolve the dispute,
although the Commission believes that SDRs must provide processes to
facilitate resolution, which would improve the quality and accuracy of
the security-based swap data that the SDR holds. The Commission is
interpreting the term ``error'' in final Rule 905 as one which both
sides to the transaction would reasonably regard as such. If the
counterparties dispute whether an error exists, then the counterparties
can use an SDR's procedures and facilities established under Rule 13n-
5(b)(6) to attempt to resolve the dispute. If the dispute-resolution
process under Rule 13n-5(b)(6) yielded agreement that an error exists,
then Rule 905 would require the counterparties to correct the
error.\718\
---------------------------------------------------------------------------

    \717\ See SDR Adopting Release.
    \718\ In the context of trade reporting, one commenter stated:
``Confirmation processes are designed to identify when economic
terms to trades have changed, distinguishing between expected events
under an existing confirmation and amendments of economic terms due
to the modification in terms . . . The trade confirmation is a
bilateral process in which both parties agree to the confirmation,
thereby ensuring any errors in the original data are corrected.''
DTCC II at 5. The Commission believes that this comment supports the
approach taken above, that counterparties to a transaction do not
incur duties under Rule 905 unless an error is detected that both
sides would regard as such.
---------------------------------------------------------------------------

    The third commenter also asked the Commission, in the context of
Rule 905, to clarify that the reporting is for informational purposes
and does not affect the terms of the trade; otherwise, ``[a]bsent some
mechanism to make the report nonbinding pending a dispute, the
correction mechanics in the Proposed Rule will result in the reporting
party (typically the SBS dealer) prevailing in any dispute.'' \719\ The
Commission does not believe that reporting of an error in previously
submitted security-based swap transaction information can change the
terms of the trade. Reporting is designed to capture the terms of the
trade, not to establish such terms. The Commission's expectation,
however, is that the report of a security-based swap provided to and
held by a registered SDR will reflect, fully and accurately, the terms
of the trade agreed to by the counterparties. If a counterparty becomes
aware that the record held by the registered SDR does not accurately
reflect the terms of the trade, that counterparty incurs a duty under
Rule 905 to take action to have that record corrected.
---------------------------------------------------------------------------

    \719\ Id. at 5-6.
---------------------------------------------------------------------------

    A fourth commenter argued that the specific root cause of such
amendments (for example a booking error or a trade amendment between
parties) could be omitted.\720\ The Commission notes that Rule 905 does
not require the reporting side to include the root cause of the error.
This commenter also urged the Commission to clarify that reporting
parties are not responsible for data that are inaccurately transcribed
or corrupted after submission to the registered SDR. The Commission
notes that the obligations under Rule 905 attach to a counterparty to a
security-based swap only after that counterparty ``discovers'' the
error or, if the counterparty is the reporting side, after it
``receives notification'' of the error from the non-reporting
side.\721\ Thus, a security-based swap counterparty incurs no duty
under Rule 905 if its transaction data are inaccurately transcribed or
corrupted after submission to the registered SDR unless the
counterparty discovers the inaccurate transcription or corruption.
Thus, under Rule 905, a counterparty would incur no duty to correct
data errors of which it is unaware.\722\
---------------------------------------------------------------------------

    \720\ See ISDA/SIFMA I at 9.
    \721\ Rule 905(a).
    \722\ The registered SDR, however, must comply with Rule 13n-
5(b)(1)(iii) under the Exchange Act, which provides, in relevant
part: ``Every security-based swap data repository shall establish,
maintain, and enforce written policies and procedures reasonably
designed to satisfy itself that the transaction data that has been
submitted to the security-based swap data repository is complete and
accurate.''
---------------------------------------------------------------------------

    Finally, a fifth commenter believed that Rule 905 should provide an
error reporting timeframe that is stronger and more specific than the
proposed requirement that such reports be submitted ``promptly.'' \723\
The Commission continues to believe that ``promptly'' is an appropriate
standard because it emphasizes the need for corrections to be submitted
without unreasonable delay while affording reporting sides a practical
degree of flexibility
---------------------------------------------------------------------------

    \723\ See Better Markets I at 9.
---------------------------------------------------------------------------

C. Policies and Procedures for Reporting Life Cycle Events and
Corrections

    Rule 907(a)(3), as originally proposed, would have required a
registered SDR to establish and maintain written policies and
procedures for ``specifying how reporting parties are to report
corrections to previously submitted information in its records that is
subsequently discovered to be erroneous, and applying an appropriate
indicator to any transaction report required to be disseminated by
[Rule 905(b)(2)] that the report relates to a previously disseminated
transaction.'' Rule 907(a)(3), as re-proposed, would have required a
registered SDR to establish and maintain written policies and
procedures for ``specifying how reporting sides are to report
corrections to previously submitted information, making corrections to
information in its records that is subsequently discovered to be
erroneous, and applying an appropriate indicator to any report required
to be disseminated by [Rule 905(b)(2)] that the report relates to a
previously disseminated transaction.''
    The Commission received no adverse comment on Rule 907(a)(3) and is
adopting it as re-proposed with a slight modification. Rule 907(a)(3),
as adopted, requires a registered SDR to establish and maintain
policies and procedures for ``specifying procedures for reporting life
cycle events and corrections to previously submitted information,
making corresponding updates or corrections to transaction records, and
applying an appropriate flag to the transaction report to indicate that
the report is an error correction required to be disseminated by [Rule
905(b)(2)] or is a life cycle event, or any adjustment due to a life
cycle event, required to be disseminated by [Rule 902(a)]'' (emphasis
added). The Commission is adding to final Rule 907(a)(3) the explicit
requirement that a registered SDR establish and maintain policies and
procedures regarding the reporting and flagging of life cycle events.
The Commission believes that these

additions will improve the ability of the Commission and other relevant
authorities to identify and analyze life cycle events of security-based
swaps.
    In the case of a life cycle event or error correction, the initial
transaction has already been reported to the registered SDR, and the
subsequent report involves some type of revision to the previously
submitted report. The Commission seeks to have the ability to observe a
security-based swap transaction throughout its life, which requires the
ability to connect subsequently reported events to the original
transaction. The Commission also seeks to avoid mistaking life cycle
events or corrections of previously submitted reports for new
transactions, which could result in overcounting the gross notional
amount of the security-based swap market or subsets thereof. Therefore,
the Commission believes that registered SDRs must have appropriate
policies and procedures that stipulate how reporting sides must report
such follow-on events, and how the registered SDR itself can
distinguish them and record them properly.
    Just as the Commission believes that a registered SDR should be
given reasonable flexibility to enumerate specific data elements to be
reported and the method for reporting them, the Commission also
believes that a registered SDR should be given reasonable flexibility
regarding the handling of corrections to previously submitted
information. As discussed above, final Rule 905 does not require the
reporting side to report the cause of an error.\724\ Nor does Rule 905
set forth a specific procedure for how a registered SDR must accept a
report of a life cycle event or error correction. Accordingly, a
registered SDR's policies and procedures under Rule 907(a)(3) could
require resubmission of the entire record with or without an indication
of which elements in that record had been revised. Alternatively, a
registered SDR's policies and procedures could require a submission of
only the data element or elements that had been revised. The Commission
notes, however, that Rule 905(b)(2) requires a registered SDR to
publicly disseminate a corrected transaction report of a security-based
swap, if erroneously reported information relates to a security-based
swap that had been publicly disseminated and falls into any of the
categories of information enumerated in Rule 901(c). Therefore, a
registered SDR will need to have a means of identifying changes in
reported data so that it can identify the changed element or elements
in the publicly disseminated correction report.
---------------------------------------------------------------------------

    \724\ See supra note 721 and accompanying text.
---------------------------------------------------------------------------

    The Commission notes that Rule 907(a)(3) requires a registered
SDR's policies and procedures also to address how the registered SDR
will apply an appropriate condition flag to any corrected transaction
report that must be re-disseminated. Market observers should be able to
understand that a transaction report triggered by Rule 905(b)(2) or
Rule 902(a) does not represent a new transaction, but merely a revision
to a previous transaction. Without an indication to that effect, market
observers could misunderstand the true state of the market.\725\ To
provide observers with a clear view of the market, public reports of
life cycle events should allow observers to identify the security-based
swap subject to the life cycle event. The Commission notes, however,
that registered SDRs may not use the transaction ID for this function
because the transaction ID is not a piece of ``information reported
pursuant to [Rule 901(c)]'' or a condition flag.\726\ Moreover, the
Commission believes that knowledge of the transaction ID should remain
limited to counterparties, infrastructure providers, and their agents,
and should not be widely known. Knowledge of the transaction ID by
additional parties could raise data integrity issues, as such
additional parties could accidentally or even intentionally submit
``false corrections'' to the registered SDR regarding transactions to
which they were never a counterparty. This could damage the otherwise
accurate record of the original transaction. Screening out improperly
submitted ``corrections''--or repairing damage to the registered SDR's
records that a false correction might cause--could become a significant
and unwanted burden on registered SDRs. Therefore, registered SDRs, in
their policies and procedures under Rule 907(a)(3), will need to use
some means other than the transaction ID to indicate that a publicly
disseminated report triggered by Rule 905(b)(2) or Rule 902(a) pertains
to a previously disseminated transaction.\727\
---------------------------------------------------------------------------

    \725\ One such condition flag could be for voided trades. There
may be scenarios in which a security-based swap is executed (or
thought to be executed), subsequently reported to a registered SDR,
and publicly disseminated by that SDR--but later voided or canceled
for some reason. For example, a transaction might be submitted to
clearing but rejected by the clearing agency, and the counterparties
could deem their agreement to be void ab initio. In this situation,
the Commission believes the registered SDR could satisfy its
obligation to publicly disseminate under Regulation SBSR by
including a condition flag that the previously disseminated
transaction report had been voided or canceled.
    \726\ See Rule 902(a).
    \727\ For example, DTCC Data Repository, LLC (``DDR'') utilizes
an Event Identifier (``EID'') to maintain the integrity of a
transaction throughout its lifecycle and enable public
identification of events, including corrections, which occur with
respect to the transaction. See DDR Rulebook, Section 4.1 at http://
dtcc.com/~/media/Files/Downloads/legal/rules/DDR_Rulebook.ashx, last
visited September 22, 2014. The EID is separate from the Unique Swap
Identifiers (``USI''), which is the CFTC-equivalent of the
transaction ID. See also ISDA/SIFMA I at 10 (recommending that
initial trades should carry a ``primary reference number'' when
disseminated, ``and all amendments of that trade would then produce
iterations of the original reference number'').
---------------------------------------------------------------------------

XIII. Other Duties of Participants

A. Duties of Non-Reporting Sides To Report Certain Information--Rule
906(a)

    The Commission believes that a registered SDR generally should
maintain complete information for each security-based swap reported to
the registered SDR, including UICs for both sides of a transaction.
Although Regulation SBSR generally takes the approach of requiring only
one side to report the majority of the transaction information,\728\
the Commission recognizes that it might not be feasible or desirable
for the reporting side to report to a registered SDR all of the UICs of
the non-reporting side. To address this issue, the Commission proposed
Rule 906(a), which would provide a means for a registered SDR to obtain
UICs from the non-reporting side.
---------------------------------------------------------------------------

    \728\ Section 13A(a)(3) of the Exchange Act, 15 U.S.C. 78m-
1(a)(1), stipulates which counterparty must report a security-based
swap that is not accepted by any clearing agency or derivatives
clearing organization. That provision does not contemplate reporting
by the other direct counterparty. Title VII does not stipulate who
should report cleared security-based swaps. However, Section
13(m)(1)(F) of the Exchange Act, 15 U.S.C. 78m(m)(1)(F), provides
that ``[p]arties to a security-based swap (including agents of the
parties to a security-based swap) shall be responsible for reporting
security-based swap transaction information to the appropriate
registered entity in a timely manner as may be prescribed by the
Commission.''
---------------------------------------------------------------------------

    Rule 906(a), as initially proposed, would have established
procedures designed to ensure that a registered SDR obtains UICs for
both direct counterparties to a security-based swap. As initially
proposed, Rule 906(a) would have required a registered SDR to identify
any security-based swap reported to it for which the registered SDR
does not have the participant ID and (if applicable) the broker ID,
desk ID, and trader ID of each counterparty. The registered SDR would
have been required to send a report once a day to each of its
participants identifying, for each security-based swap to which that

participant is a counterparty, the security-based swap(s) for which the
registered SDR lacks participant IDs and (if applicable) a broker ID,
desk ID, or trader ID. The participant would have been required to
provide the missing information within 24 hours of receiving this
report from the registered SDR.
    When the Commission re-proposed Regulation SBSR as part of the
Cross-Border Proposing Release, it made conforming changes to Rule
906(a) to reflect the introduction of the ``reporting side'' concept
and to clarify that the participant ID, broker ID, desk ID, and trader
ID must be reported only for direct counterparties.\729\
---------------------------------------------------------------------------

    \729\ See 78 FR 31214.
---------------------------------------------------------------------------

    The Commission has decided to adopt Rule 906(a) substantially as
re-proposed, with conforming changes related to including branch ID and
execution agent ID among the UICs that must be provided to the
registered SDR \730\ and other minor technical changes.\731\
---------------------------------------------------------------------------

    \730\ As discussed above, see supra Section II(C), the
Commission has added ``branch ID'' and ``execution agent ID'' to the
UICs required to be reported under Regulation SBSR. The Commission
believes that reporting the branch ID and the execution agent ID for
both counterparties to a security-based swap, if applicable, to a
registered SDR will assist the Commission and other relevant
authorities in overseeing the security-based swap market.
Accordingly, the Commission has included branch ID and execution
agent ID as UICs that registered SDRs must obtain pursuant to Rule
906(a).
    \731\ The Commission has determined to use the term
``counterparty ID'' rather than ``participant ID'' and to use the
term ``trading desk ID'' rather than ``desk ID'' throughout
Regulation SBSR. See supra Sections II(B)(3)(b) and II(C)(3)(c). In
addition, the Commission has inserted the word ``direct''
immediately before each instance of the word ``counterparty.'' When
the Commission re-proposed Rule 906(a), it made conforming changes
to reflect the introduction of the ``reporting side'' concept and to
clarify that relevant UICs for the non-reporting side must be
reported only for direct counterparties. The word ``counterparty''
occurs in two places in final Rule 906(a), but the re-proposed rule
inserted ``direct'' before ``counterparty'' only after the first
occurrence. Final Rule 906(a) inserts ``direct'' before
``counterparty'' both times that the word ``counterparty'' is used.
Final Rule 906(a) also includes modifications that clarify that the
term ``participant,'' as used in Rule 906(a), means a participant in
a registered SDR. The Commission has made similar modifications
throughout final Rule 906. The Commission also is revising the final
sentence of Rule 906(a) to clarify that the participant referred to
in that sentence is a participant of a registered SDR, and to
clarify that a participant that receives a Rule 906(a) report from a
registered SDR is responsible for providing missing UIC information
for its side of each security-based swap referenced in the report.
The participant is not responsible for providing any missing UIC
information pertaining to the other side of the transaction.
Accordingly, the last sentence of Rule 906(a) states: ``A
participant of a registered security-based swap data repository that
receives such a report shall provide the missing information with
respect to its side of each security-based swap referenced in the
report to the registered security-based swap data repository within
24 hours.'' In addition, the Commission is revising the rule to
refer to execution agents to conform to Rule 901(d)(1)(i). Finally,
to more accurately reflect the requirements of the rule, the
Commission is changing the title of the rule to ``Identifying
missing UIC information.''
---------------------------------------------------------------------------

    The Commission received two comment letters from the same commenter
addressing proposed Rule 906(a). The first letter, which responded to
the initial proposal, stated that regulators must have the UICs of both
counterparties to a security-based swap to accurately track
exposures.\732\ The commenter believed that, ideally, this process
would be supported electronically and that the use of third-party
services should meet this requirement.\733\
---------------------------------------------------------------------------

    \732\ See DTCC II at 16. This commenter also suggested that desk
IDs and trader IDs should not be required to be reported due to the
fact that desk structures are changed relatively frequently and
traders often rotate to different desks or transfer to different
firms. See DTCC II at 11. This suggestion is addressed above in
Section II(C)(3)(c).
    \733\ See DTCC II at 16.
---------------------------------------------------------------------------

    The Commission generally shares the commenter's view that
registered SDRs should maintain UICs for both sides of a security-based
swap.\734\ The Commission notes that Rule 901(d) requires the reporting
side to report the branch ID, broker ID, execution agent ID, trader ID,
and trading desk ID--as applicable--only for the direct counterparty on
its side. Rule 901(d)(1) requires the reporting side to report only the
counterparty ID or execution agent ID, as applicable, of a counterparty
on the other side. The Commission could have required the reporting
side to provide UIC information for both sides of the transaction, but
this would obligate a non-reporting side to furnish its UIC information
to the reporting side so that the additional UICs could be reported by
the reporting side. There are circumstances where a non-reporting side
might be unable or unwilling to provide its UIC information to the
reporting side. Therefore, the Commission is instead requiring the
registered SDR to obtain these UICs from the non-reporting side through
the Rule 906(a) process.\735\ Obtaining UICs for both sides will
enhance the Commission's ability to carry out its responsibility to
oversee the security-based swap market, because the Commission will be
able to identify individual traders and business units that are
involved in security-based swap transactions.\736\
---------------------------------------------------------------------------

    \734\ However, if the non-reporting side for the security-based
swap does not meet the definition of ``participant'' in Rule 900(u),
Rule 906(a) would not require the registered SDR to request UIC
information from the non-reporting side. This result is consistent
with the Regulation SBSR Proposing Release. See 75 FR 75240 (``Thus,
the Commission anticipates that there would be some SBSs reported to
and captured by a registered SDR where only one counterparty of the
SBS is a participant'').
    \735\ Rule 906(a) provides: ``A registered security-based swap
data repository shall identify any security-based swap reported to
it for which the registered security-based swap data repository does
not have the counterparty ID and (if applicable) the broker ID,
branch ID, execution agent ID, trading desk ID, and trader ID of
each direct counterparty. Once a day, the registered security-based
swap data repository shall send a report to each participant of the
registered security-based swap data repository or, if applicable, an
execution agent, identifying, for each security-based swap to which
that participant is a counterparty, the security-based swap(s) for
which the registered security-based swap data repository lacks
counterparty ID and (if applicable) broker ID, branch ID, execution
agent ID, desk ID, and trader ID. A participant of a registered
security-based swap data repository that receives such a report
shall provide the missing information with respect to its side of
each security-based swap referenced in the report to the registered
security-based swap data repository within 24 hours.'' Rule 900(u)
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).''
    \736\ Nothing in Regulation SBSR prevents a non-reporting side
from voluntarily providing all of its applicable UICs to the
reporting side, so that the reporting side could, as agent, report
all of the non-reporting side's UICs together with the rest of the
data elements required by Rules 901(c) and 901(d). If this were to
occur, the registered SDR would not need to send a Rule 906(a)
report to the non-reporting side inquiring about the non-reporting
side's missing UICs.
---------------------------------------------------------------------------

    In a subsequent comment letter, in response to the re-proposal of
Regulation SBSR, the same commenter expressed concern that Rule 906(a)
could require a registered SDR to send reports to and obtain
information from persons who might not be participants of that
registered SDR.\737\ More generally, this commenter suggested that
registered SDRs should not police security-based swap reports for
deficiencies or unpopulated data fields in any manner that requires the
registered SDR to take affirmative action to obtain information.\738\
---------------------------------------------------------------------------

    \737\ See DTCC V at 13. As noted above, however, Rule 906(a), as
adopted, requires the registered SDR to obtain UIC information only
from non-reporting sides that are participants of that registered
SDR.
    \738\ See DTCC V at 13.
---------------------------------------------------------------------------

    The Commission disagrees with the commenter's suggestion that
registered SDRs should have no duty to review the completeness of
security-based swap reports or obtain missing information from
participants. To the contrary, the Commission believes that registered
SDRs are best situated to review reported data for completeness because
they have a statutory and regulatory duty to accept and maintain
security-based swap data, as prescribed by the Commission.\739\
Imposing an affirmative duty on registered SDRs to verify the
completeness of reported data and to

obtain missing data should increase the reliability of data maintained
by registered SDRs while decreasing the possibility of registered SDRs
providing incomplete reports to relevant authorities. This, in turn,
will facilitate oversight of the security-based swap market, which is a
primary objective Title VII.
---------------------------------------------------------------------------

    \739\ See 15 U.S.C. 78m(n)(5).
---------------------------------------------------------------------------

    Rule 906(a) requires registered SDRs to communicate with
participants that are not reporting sides under Regulation SBSR. As
discussed above, these communications are required to ensure that a
registered SDR maintains complete UIC information for both sides of
each security-based swap transaction that is reported to the registered
SDR. The Commission recognizes that some non-reporting sides may not
wish to connect directly to a registered SDR because they may not want
to incur the costs of establishing a direct connection. Rule 906(a)
does not prescribe the means registered SDRs must use to obtain
information from non-reporting sides. As a result, registered SDRs have
broad discretion to establish a methodology for notifying non-reporting
sides of missing UIC information and obtaining UIC reports from the
non-reporting side. For example, a registered SDR could send
notifications and receive reports via email, in accordance with its
policies and procedures.\740\ Registered SDRs should consider allowing
non-reporting sides to provide the information required by Rule 906(a)
in a minimally-burdensome manner.
---------------------------------------------------------------------------

    \740\ See supra Section IV (discussing Rule 907(a)(2)).
---------------------------------------------------------------------------

    Historical security-based swaps must be reported to a registered
SDR pursuant to Rule 901(i). The Commission acknowledges that broker
IDs, branch IDs, execution agent IDs, trading desk IDs, and trader IDs
do not yet exist and will not exist until assigned by registered SDRs.
Therefore, these UICs are not data elements applicable to historical
security-based swaps. Accordingly, registered SDRs are not required
under Rule 906(a) to identify these UICs as missing or to communicate
to non-reporting side participants that they are missing, and non-
reporting side participants are not required by Rule 906(a) to provide
these UICs to a registered SDR with respect to any historical security-
based swaps.

B. Duty To Provide Ultimate Parent and Affiliate Information to
Registered SDRs--Rule 906(b)

    To assist the Commission and other relevant authorities in
monitoring systemic risk, a registered SDR should be able to identify
and calculate the security-based swap exposures of its participants on
an enterprise-wide basis.\741\ Therefore, the Commission proposed Rule
906(b), which would have required each participant of a registered SDR
to provide to the registered SDR information sufficient to identify its
ultimate parent(s) and any affiliate(s) of the participant that also
are participants of the registered SDR. Proposed Rule 906(b) would have
required a person to provide parent and affiliate information to a
registered SDR immediately upon becoming a participant.\742\ Proposed
Rule 906(b) also would have required a participant to promptly notify
the registered SDR of any changes to reported parent or affiliate
information.
---------------------------------------------------------------------------

    \741\ The Commission notes that Rule 13n-5(b)(2) under the
Exchange Act provides: ``Every security-based swap data repository
shall establish, maintain, and enforce written policies and
procedures reasonably designed to calculate positions for all
persons with open security-based swaps for which the security-based
swap data repository maintains records.''
    \742\ The policies and procedures of a registered SDR will
establish on-boarding procedures for participants.
---------------------------------------------------------------------------

    The Commission also proposed rules to define the relationships that
could give rise to reporting obligations under Rule 906(b). Proposed
Rule 900 would have defined an ``affiliate'' as ``any person that,
directly or indirectly, controls, is controlled by, or is under common
control with, a person'' and ``control'' as ``the possession, direct or
indirect, of the power to direct or cause the direction of the
management and policies of a person, whether through the ownership of
voting securities, by contract, or otherwise.'' \743\ The Commission
also proposed definitions of ``parent'' and ``ultimate parent'' to
identify particular categories of affiliated entities based on a
person's ability to control an affiliate. Specifically, proposed Rule
900 would have defined ``parent'' to mean ``a legal person that
controls a participant'' and ``ultimate parent'' as ``a legal person
that controls a participant and that itself has no parent.'' The
Commission also proposed to define ``ultimate parent ID'' as ``the UIC
assigned to an ultimate parent of a participant.''
---------------------------------------------------------------------------

    \743\ Proposed Rule 900 further would have provided that a
person would be presumed to control another person if the person:
``(1) [i]s a director, general partner or officer exercising
executive responsibility (or having similar status or functions);
(2) [d]irectly or indirectly has the right to vote 25 percent or
more of a class of voting securities or has the power to sell or
direct the sale of 25 percent or more of a class of voting
securities; or (3) [i]n the case of a partnership, has the right to
receive, upon dissolution, or has contributed, 25 percent or more of
the capital.''
---------------------------------------------------------------------------

    The Commission re-proposed the definitions of ``affiliate,''
``control,'' ``parent,'' ``ultimate parent,'' and ``ultimate parent
ID,'' and Rule 906(b) without change in the Cross-Border Proposing
Release.\744\
---------------------------------------------------------------------------

    \744\ See 78 FR 31210-11. The definition of ``affiliate'' was
re-proposed as Rule 900(a). The definitions of ``control,''
``parent,'' and ``ultimate parent'' were re-proposed as Rules
900(f), 900(r), and 900(ll), respectively. Re-proposed Rule 900(mm)
contained the definition of ``ultimate parent ID.''
---------------------------------------------------------------------------

    After considering the comments received, which are discussed below,
the Commission is adopting Rule 906(b), as proposed and re-proposed,
subject to two clarifying changes.\745\ Obtaining ultimate parent and
affiliate information will assist the Commission in monitoring
enterprise-wide risks related to security-based swaps. If participants
are not required to identify which of their affiliates also are
participants of a particular registered SDR, the Commission or other
relevant authorities might be unable to calculate the security-based
swap exposures of that ownership group using data held in the
registered SDR. As a result, systemic risk might build undetected
within an ownership group, even if all security-based swaps for that
enterprise were reported to the same registered SDR. The lack of
transparency regarding OTC derivatives exposures within the same
ownership group was one of the factors that hampered regulators'
ability to respond to the financial crisis of 2007-08.\746\
---------------------------------------------------------------------------

    \745\ Specifically, the Commission is modifying Rule 906(b) to
clarify that the term ``participant,'' means a participant in a
registered SDR. The Commission also is replacing the term
``participant ID'' with ``counterparty ID.''
    \746\ See Financial Crisis Inquiry Commission, ``The Financial
Crisis Inquiry Report: Final Report of the National Commission on
the Causes of the Financial and Economic Crisis in the United
States,'' January 2011, at xxi, available at: http://www.gpo.gov/fdsys/pkg/GPO-FCIC/pdf/GPO-FCIC.pdf, last visited September 22, 2014
(explaining that relevant authorities ``lacked a full understanding
of the risks and interconnections in the financial markets'' prior
to and during the financial crisis, including, among other things,
the exposures created by Lehman Brothers' derivatives contracts).
---------------------------------------------------------------------------

    The Commission believes that a reasonable means of monitoring
security-based swap positions on a group-wide basis is by requiring
each participant of a registered SDR to provide information sufficient
to identify the participant's ultimate parent(s) and any affiliate(s)
of the participant that also are participants of the registered SDR,
using ultimate parent IDs and counterparty IDs.\747\ Rule

906(b), as adopted, imposes an affirmative obligation on participants
of a registered SDR to provide this ownership and affiliation
information to a registered SDR immediately upon becoming a participant
of that SDR. The participant also must notify the registered SDR
promptly of any changes to that information. To minimize burdens on
participants and to align the burdens as closely as possible with the
purpose behind the requirement, Rule 906(b) does not require a
participant of a registered SDR to provide information to the
registered SDR about all of its affiliates, but only those that are
also participants of the same registered SDR.
---------------------------------------------------------------------------

    \747\ Among other things, Rule 906(b) should enable the
Commission and other relevant authorities to identify quickly
security-based swaps of a corporate group that have been reported to
the registered SDR, including security-based swaps held by
securitization vehicles that are controlled by financial
institutions.
---------------------------------------------------------------------------

    The Commission received three comments addressing proposed Rule
906(b).\748\ One commenter supported the proposed rule, stating that
parent and affiliate information, along with other information required
to be reported by Regulation SBSR, is critical to providing regulators
with a comprehensive view of the swaps market and assuring that
publicly reported data is accurate and meaningful.\749\ This commenter
further stated that registered SDRs should have the power to obtain
parent and affiliate information from firms, because this information
would help to illustrate the full group level exposures of firms and
the impact of the failure of any participant.\750\ The Commission
generally agrees with the commenter's points and continues to believe
that identifying security-based swap exposures within an ownership
group is critical to monitoring market activity and detecting potential
systemic risks. The existence of data vendors that provide parent and
affiliate information may reduce any burdens on participants associated
with reporting such information to a registered SDR,\751\ but the
Commission does not view this as an adequate substitute for having the
information reported to and readily available from registered SDRs.
Title VII's regulatory reporting requirement is designed to allow the
Commission and other relevant authorities to have access to
comprehensive information about security-based swap activity in
registered SDRs. The Commission believes that it would be inimical to
that end for relevant authorities to have all the transaction
information in registered SDRs but be forced to rely on information
from outside of registered SDRs to link positions held by affiliates
within the same corporate group.
---------------------------------------------------------------------------

    \748\ See DTCC II at 13-14; ICI I at 6; GS1 Proposal at 43-44.
    \749\ See DTCC II at 13-14.
    \750\ See id. at 17. This commenter believed that a registered
SDR likely would obtain parent and affiliate information from a data
vendor and allow participants to review and approve the data.
    \751\ See id.
---------------------------------------------------------------------------

    Two commenters suggested clarifications or modifications to the
proposed rule.\752\ One commenter expressed concerns about how Rule
906(b) would apply to agents, noting that investment advisers
frequently execute a single security-based swap transaction on behalf
of multiple accounts and allocate the notional amount of the
transaction among these accounts at the end of the day.\753\ The
commenter stated that advisers often do not know all of the affiliates
of their clients and, as a result, might be unable to comply with Rule
906(b).\754\ The commenter recommended that ``the Commission clarify
that an adviser that has implemented reasonable policies and procedures
to obtain the required information about affiliates and documented its
efforts to obtain the information from its clients be deemed to have
satisfied [Rule 906(b) of] Regulation SBSR.'' \755\
---------------------------------------------------------------------------

    \752\ See ICI I at 6; GS1 Proposal at 43-44.
    \753\ See ICI I at 6, note 9.
    \754\ See id.
    \755\ Id.
---------------------------------------------------------------------------

    The Commission believes that it is unnecessary to modify Rule
906(b) in response to this comment. The Commission notes that Rule
906(b) imposes no obligations on an execution agent, such as an
investment adviser that executes a single security-based swap on behalf
of multiple accounts and allocates the notional amount of the
transaction among those accounts at the end of the day. Rather, it
would be the counterparty itself that would have the responsibility
under Rule 906(b).
    Another commenter expressed the view that the information required
to be reported by Rule 906(b) should be placed in prescribed XBRL
templates or other such input mechanisms that would capture this
information at its source for all downstream processes in the financial
supply chain to use.\756\ The Commission has determined not to specify
the manner or format in which security-based swap counterparties must
provide ultimate parent and affiliate information to a registered SDR.
The Commission believes that it would be preferable to allow each
registered SDR to determine a suitable way to receive and maintain
ultimate parent and affiliate information about its participants. The
Commission notes that Rule 907(a)(6), as adopted, requires a registered
SDR to establish and maintain written policies and procedures for
periodically obtaining from each participant information that
identifies the participant's ultimate parent(s) and any other
participant(s) with which the counterparty is affiliated, using
ultimate parent IDs and counterparty IDs.\757\
---------------------------------------------------------------------------

    \756\ See GS1 Proposal at 43.
    \757\ As originally proposed, Rule 907(a)(6) would have required
a registered SDR to establish and maintain written policies and
procedures ``[f]or periodically obtaining from each participant
information that identifies the participant's ultimate parent(s) and
any other participant(s) with which the counterparty is affiliated,
using ultimate parent IDs and participant IDs'' (emphasis added).
The Commission re-proposed Rule 907(a)(6) with the word
``participant'' in place of the word ``counterparty.''
---------------------------------------------------------------------------

    The Commission received three comments on the definitions of
``control'' and ``affiliate.'' \758\ No commenters specifically
addressed the definitions of ``parent,'' ``ultimate parent,'' or
``ultimate parent ID.'' After carefully evaluating these comments, the
Commission is adopting the definitions of ``affiliate,'' ``control,''
``parent,'' ``ultimate parent,'' and ``ultimate parent ID'' as proposed
and re-proposed.\759\
---------------------------------------------------------------------------

    \758\ See DTCC II at 17; Multiple Associations Letter at 7-8;
SIFMA I at 6.
    \759\ Final Rule 900(a) defines ``affiliate,'' while the
definitions of ``control,'' ``parent,'' ``ultimate parent'' and
``ultimate parent ID'' are in Rules 900(h), 900(t), 900(oo), and
900(pp), respectively.
---------------------------------------------------------------------------

    One commenter stated its view that the proposed definition of
``control'' was improper.\760\ This commenter believed that the
proposed 25% threshold for presuming control was too low, and that
obtaining the information required by Rule 906(b) from entities with
which a security-based swap market participant has less than a majority
ownership relationship would be overly burdensome, and, in some cases,
not practicable.\761\ The commenter recommended that the Commission
amend the definition to presume control based on no less than majority
ownership.\762\
---------------------------------------------------------------------------

    \760\ See SIFMA I at 6.
    \761\ See id.
    \762\ See id.
---------------------------------------------------------------------------

    The Commission disagrees that, for purposes of Regulation SBSR,
control should be presumed to exist only if there is majority
ownership. Rule 906(b) is designed to assist the Commission and other
relevant authorities in monitoring group-wide security-based swap
exposures by enabling a registered SDR to provide them with the
information necessary to calculate positions in security-based swaps
held within the same ownership group that are reported to that
registered SDR. If the Commission were to adopt definitions of
``control'' and ``affiliate'' that were based on majority ownership,

participants would be required to identify fewer entities as
affiliates, even if certain indicia of affiliation were present. The
Commission believes that, to carry out its oversight function for the
security-based swap market, it should err on the side of inclusion
rather than exclusion when considering which positions are part of the
same ownership group for general oversight purposes.
    The Commission also notes that the definition of ``control'' as
adopted in Rule 900(h) is consistent with the definition used in other
Commission rules and forms,\763\ so market participants should be
accustomed to applying this definition in the conduct of their business
activities. Furthermore, the CFTC's swap data reporting rules employ a
materially similar definition of ``control'' for purposes of
determining whether two market participants are affiliated with each
other.\764\ If the Commission were to adopt a different definition of
``control,'' market participants would need to determine their
affiliates under both sets of rules, thereby imposing what the
Commission believes would be unnecessary costs on market participants.
---------------------------------------------------------------------------

    \763\ See, e.g., Rule 300(f) of Regulation ATS under the
Exchange Act, 17 CFR 242.300(f); Rule 19g2-1(b)(2) under the
Exchange Act, 17 CFR 240.19g2-1(b)(2); Form 1 (Application for, and
Amendments to Application for, Registration as a National Securities
Exchange or Exemption from Registration Pursuant to Section 5 of the
Exchange Act); Form BD (Uniform Application for Broker-Dealer
Registration). See also Rule 3a55-4(b)(2) under the Exchange Act, 17
CFR 240.3a55-4(b)(2) (defining control to mean ownership of 20% or
more of an issuer's equity, or the ability to direct the voting of
20% or more of the issuer's voting equity).
    \764\ See 17 CFR 45.6(a) (defining ``control'' in the context of
the CFTC's LEI system); 17 CFR 45.6(e)(2).
---------------------------------------------------------------------------

    One commenter suggested that the Commission and the CFTC use a
consistent definition of ``affiliate'' throughout the Title VII
rulemakings \765\ and recommended that the Commission and CFTC use the
definition of ``affiliated group'' in the Commissions' proposed joint
rulemaking to further define the terms swap dealer, security-based swap
dealer, major swap participant, major security-based swap participant,
and eligible contract participant (``Entity Definitions Proposing
Release'').\766\ The Commission does not believe it is appropriate to
adopt, for purposes of Regulation SBSR, the definition of ``affiliated
group'' that was proposed in the Entity Definitions Proposing Release.
The final rules defining ``swap dealer,'' ``security-based swap
dealer,'' ``major swap participant,'' ``major security-based swap
participant,'' and ``eligible contract participant'' (``Final Entity
Definition Rules'') did not adopt a definition of ``affiliated group.''
\767\ When the Commission and CFTC adopted the Final Entity Definition
Rules they specifically rejected the notion that an ``affiliated
group'' should include only those entities that report information or
prepare financial statements on a consolidated basis as a prerequisite
for being affiliated because they did not believe that whether or not
two entities are affiliated should change according to changes in
accounting standards.\768\ The Commission continues to believe that
changes in accounting standards should not determine whether two
entities are affiliated and therefore declines to adopt the definition
of ``affiliated group'' that it proposed in the Entity Definitions
Proposing Release.
---------------------------------------------------------------------------

    \765\ See Multiple Associations Letter at 7-8.
    \766\ Securities Exchange Act Release No. 63452 (December 7,
2010), 75 FR 80174 (December 21, 2010). In the Entity Definitions
Proposing Release, ``affiliated group'' would have been used to
describe the range of counterparties that a security-based swap
market participant would need to count for purposes of determining
whether it qualified for a de minimis exception from the definition
of ``security-based swap dealer.'' For purposes of the Entity
Definitions Proposing Release, the Commissions stated that an
affiliated group would be defined as ``any group of entities that is
under common control and that reports information or prepares its
financial statements on a consolidated basis.'' See 75 FR 80180,
note 43.
    \767\ Securities Exchange Act Release No. 66868 (April 27,
2012), 77 FR 30596 (May 23, 2012).
    \768\ See id. at 30625.
---------------------------------------------------------------------------

C. Policies and Procedures of Registered Security-Based Swap Dealers
and Registered Major Security-Based Swap Participants To Support
Reporting--Rule 906(c)

    For the security-based swap reporting requirements established by
the Dodd-Frank Act to achieve the objectives of enhancing price
transparency and providing regulators with access to data to help carry
out their oversight responsibilities, the information that participants
provide to registered SDRs must be reliable. Ultimately, the majority
of security-based swaps likely will be reported by registered security-
based swap dealers and registered major security-based swap
participants. The Commission believes that requiring these participants
to adopt policies and procedures to address their security-based swap
reporting obligations will increase the accuracy and reliability of the
transaction reports that they submit to registered SDRs.
    Proposed Rule 906(c) would have required a participant that is a
security-based swap dealer or major security-based swap participant to
establish, maintain, and enforce written policies and procedures that
are reasonably designed to ensure that the participant complies with
any obligations to report information to a registered SDR in a manner
consistent with Regulation SBSR and the policies and procedures of any
registered SDR of which it is a participant. The policies and
procedures contemplated by proposed Rule 906(c) were intended to
promote complete and accurate reporting of security-based swap
information by participants that are security-based swap dealers and
major security-based swap participants, consistent with their
obligations under the Dodd-Frank Act and Regulation SBSR. Proposed Rule
906(c) also would have required a security-based swap dealer or major
security-based swap participant to review and update its policies and
procedures at least annually. The Commission re-proposed Rule 906(c)
without change as part of the Cross-Border Proposing Release.\769\ The
one commenter who addressed this aspect of Regulation SBSR stated that
proposed Rule 906(c) is ``a necessary part of risk governance and
compliance.'' \770\
---------------------------------------------------------------------------

    \769\ See 78 FR 31214.
    \770\ Barnard I at 3.
---------------------------------------------------------------------------

    The Commission agrees and is adopting Rule 906(c), largely as
proposed and re-proposed, subject to two modifications.\771\ As
proposed and re-proposed, Rule 906(c) would have required security-
based swap dealers and major security-based swap participants to
establish, maintain, and enforce written policies and procedures to
support security-based swap transaction reporting. As discussed above,
Rule 906(c), as adopted, imposes this duty only on registered security-
based swap dealers and registered major security-based swap
participants.\772\ Second, Rule 906(c), as adopted, does not include
the phrase ``and the policies and procedures of any registered
security-based swap data repository of which it is a participant.'' The
Commission believes that it is sufficient to require that the policies
and procedures of registered security-based swap dealers and registered
major security-based swap participants be reasonably designed to ensure
compliance with the reporting

obligations under Regulation SBSR.\773\ Additionally, the Commission
anticipates that SDRs will enter into contractual arrangements with
reporting sides for the reporting of transactions required to be
reported under Regulation SBSR, and that such arrangements likely will
stipulate the various rights and obligations of the parties when
reporting security-based swap transactions.
---------------------------------------------------------------------------

    \771\ The Commission also revised Rule 906(c), to clarify that
the term ``participant'' means a participant of a registered SDR.
    \772\ See supra Section V(B)(1) (explaining that, during the
period before the Commission has adopted rules for the registration
of security-based swap dealers and major security-based swap
participants, the Commission seeks to avoid imposing costs on market
participants who otherwise would have to assess whether they are
security-based swap dealers or major security-based swap
participants).
    \773\ The Commission notes that a reporting side is also
required to electronically transmit information required under
Regulation SBSR to a registered SDR in a format required by that
SDR. See Rule 901(h); note 268, supra, and accompanying text.
---------------------------------------------------------------------------

    Rule 906(c) is designed to promote greater accuracy and
completeness of reported security-based swap transaction data by
requiring the participants that will bear substantial reporting
obligations under Regulation SBSR to adopt policies and procedures that
are reasonably designed to ensure that their reports are accurate and
reliable. If these participants do not have written policies and
procedures for carrying out their reporting duties, compliance with
Regulation SBSR might depend too heavily on key individuals or ad hoc
and unreliable processes. The Commission, therefore, believes that
registered security-based swap dealers and registered major security-
based swap participants should be required to establish written
policies and procedures which, because they are written and can be
shared throughout the organization, should be independent of any
specific individuals. Requiring such participants to adopt and maintain
written policies and procedures relevant to their reporting
responsibilities, as required under Rule 906(c), should help to improve
the degree and quality of overall compliance with the reporting
requirements of Regulation SBSR. Periodic review of the policies and
procedures, as required by Rule 906(c), should help ensure that these
policies and procedures remain well functioning over time.
    The value of requiring policies and procedures in promoting
regulatory compliance is well-established. Internal control systems
have long been used to strengthen the integrity of financial reporting.
For example, Congress recognized the importance of internal control
systems in the Foreign Corrupt Practices Act, which requires public
companies to maintain a system of internal accounting controls.\774\
Broker-dealers also must maintain policies and procedures for various
purposes.\775\ The Commission believes that requiring each registered
security-based swap dealer and registered major security-based swap
participant to adopt and maintain written policies and procedures
designed to promote compliance with Regulation SBSR is consistent with
Congress's goals in adopting the Dodd-Frank Act.
---------------------------------------------------------------------------

    \774\ See 15 U.S.C. 78m(b)(2)(B).
    \775\ See, e.g., FINRA Conduct Rule 3010(b) (requiring FINRA
member broker-dealers to establish and maintain written procedures
``that are reasonably designed to achieve compliance with applicable
securities laws and regulations, and with the applicable Rules of
[the NASD]''); FINRA Conduct Rule 3012 (requiring FINRA member
broker-dealers to establish and maintain written supervisory
procedures to ensure that internal policies and procedures are
followed and achieve their intended objectives).
---------------------------------------------------------------------------

    The policies and procedures required by Rule 906(c) could address,
among other things: (1) The reporting process and designation of
responsibility for reporting security-based swap transactions; (2) the
process for systematizing orally negotiated security-based swap
transactions; (3) order management system outages or malfunctions, and
when and how back-up systems are to be used in connection with required
reporting; (4) verification and validation of all information relating
to security-based swap transactions reported to a registered SDR; (5) a
training program for employees responsible for security-based swap
transaction reporting; (6) control procedures relating to security-
based swap transaction reporting and designation of personnel
responsible for testing and verifying such policies and procedures; and
(7) reviewing and assessing the performance and operational capability
of any third party that carries out any duty required by Regulation
SBSR on behalf of the registered security-based swap dealer or
registered major security-based swap participant.\776\
---------------------------------------------------------------------------

    \776\ See 75 FR 75234.
---------------------------------------------------------------------------

XIV. Other Aspects of Policies and Procedures of Registered SDRs

A. Public Availability of Policies and Procedures

    Rule 907(c), as proposed and re-proposed, would have required a
registered SDR to make its policies and procedures publicly available
on its Web site. The Commission did not receive any comments on Rule
907(c) and is adopting it as proposed and re-proposed. This public
availability requirement will allow all interested parties to
understand how the registered SDR is utilizing the flexibility it has
in operating the transaction reporting and dissemination system. Being
able to review the current policies and procedures will provide an
opportunity for participants to make suggestions to the registered SDR
for altering and improving those policies and procedures, in light of
new products or circumstances, consistent with the principles set out
in Regulation SBSR.

B. Updating of Policies and Procedures

    Proposed Rule 907(d) would have required a registered SDR to
``review, and update as necessary, the policies and procedures required
by [Regulation SBSR] at least annually.'' Proposed Rule 907(d) also
would have required the registered SDR to indicate the date on which
its policies and procedures were last reviewed. The Cross-Border
Proposing Release re-proposed Rule 907(d) without revision.
    The Commission did not receive any comments on Rule 907(d) and is
adopting it as proposed and re-proposed. The Commission continues to
believe that a registered SDR should periodically review its policies
and procedures to ensure that they remain well-functioning over time.
The Commission also continues to believe that requiring registered SDRs
to indicate the date on which their policies and procedures were last
reviewed will allow regulators and SDR participants to understand which
version of the policies and procedures are current. A registered SDR
could satisfy this obligation by, for example, noting when individual
sections were last updated or by reissuing the entirety of the policies
and procedures with an ``as of'' date. The Commission notes that,
regardless of the method chosen and although only the most current
version of a registered SDR's policies and procedures must be publicly
available pursuant to Rule 907, the registered SDR must retain prior
versions of those policies and procedures for regulatory purposes
pursuant to Rule 13n-7(b) under the Exchange Act,\777\ as adopted by
the Commission.\778\ These records would help the Commission, if
conducting a review of a registered SDR's past actions, to understand
what policies and procedures were in force at the time.
---------------------------------------------------------------------------

    \777\ 17 CFR 240.13n-7(b)(1) (``Every security-based swap data
repository shall keep and preserve at least one copy of all
documents, including all documents and policies and procedures
required by the Act and the rules and regulations thereunder'').
    \778\ See SDR Adopting Release.
---------------------------------------------------------------------------

C. Provision of Certain Reports to the Commission

    Under Title VII, the Commission is responsible for regulating and
overseeing the security-based swap market, including the trade
reporting obligations imposed by Regulation

SBSR.\779\ The Commission believes that, to carry out this
responsibility, it will be necessary to obtain from each registered SDR
information related to the timeliness, accuracy, and completeness of
data reported to the registered SDR by the SDR's participants. Required
data submissions that are untimely,\780\ inaccurate,\781\ or incomplete
\782\ could compromise the regulatory data that the Commission would
utilize to carry out its oversight responsibilities. Furthermore,
required data submissions that are untimely, inaccurate, or incomplete
could diminish the value of publicly disseminated reports that are
meant to promote transparency and price discovery.
---------------------------------------------------------------------------

    \779\ Under Title VII, registered SDRs are not self-regulatory
organizations and thus lack the enforcement authority that self-
regulatory organizations have over their members under the Exchange
Act. Any information or reports requested by the Commission under
Rule 907(e) would assist the Commission in examining for and
enforcing compliance with Regulation SBSR by reporting parties.
    \780\ For example, a registered SDR would be able to determine
that a reporting side had reported late if the date and time of
submission were more than 24 hours after the date and time of
execution reported by the reporting side (or, if 24 hours after the
time of execution would have fallen on a day that was not a business
day, then after that same time on the next business day). See Rule
901(j).
    \781\ Some examples of clearly inaccurate data would include
using lettered text in a field that clearly requires a number (or
vice versa), or using a UIC that corresponds to no valid LEI or to a
UIC issued or endorsed by the registered SDR.
    \782\ An example of an incomplete report would be leaving one or
more required reporting fields blank.
---------------------------------------------------------------------------

    Accordingly, the Commission proposed and re-proposed Rule 907(e),
which would have required a registered SDR to ``have the capacity to
provide to the Commission, upon request, information or reports related
to the timeliness, accuracy, and completeness of data reported to it''
pursuant to Regulation SBSR and the registered SDR's policies and
procedures. The sole commenter on this provision agreed that an SDR
should be able to ``readily provide the Commission with any relevant
information,'' but noted that an SDR might not be in the best position
to confirm the accuracy of the trade information it receives.\783\ The
commenter believed that ultimate responsibility for the submission of
accurate and complete information belongs with the reporting side, and
that Rule 907(e) should be revised to reflect that an SDR's information
will ``only be as timely, accurate, and complete as provided to it by
parties to the trade.'' \784\
---------------------------------------------------------------------------

    \783\ DTCC V at 14.
    \784\ Id.
---------------------------------------------------------------------------

    The Commission is adopting Rule 907(e) with a minor revision. The
final rule provides that a registered SDR ``shall provide, upon
request, information or reports . . .'' rather than, as proposed and
re-proposed, that a registered SDR ``shall have the capacity to provide
. . .'' This language better conveys the Commission's expectation that,
not only must a registered SDR have the capacity to provide the
relevant information or reports, it must in fact provide such
information or reports when the Commission requests. The Commission
believes that this revision accords with the commenter who stated that
an SDR should be able to ``readily provide the Commission with any
relevant information.'' \785\
---------------------------------------------------------------------------

    \785\ See note 783, supra.
---------------------------------------------------------------------------

    However, the Commission is not revising Rule 907(e) to reflect that
an SDR's information will ``only be as timely, accurate, and complete
as provided to it by parties to the trade,'' as requested by the
commenter.\786\ The Commission appreciates that there could be certain
data elements submitted by reporting sides that a registered SDR could
not reasonably be expected to know are inaccurate. For example, if the
reporting side submits a valid trader ID for trader X when in fact the
transaction was carried out by trader Y, the Commission would not
expect a Rule 907(e) report provided by a registered SDR to reflect
this fact. The Commission notes, however, that Rule 13n-5(b)(1)(iii)
under the Exchange Act requires an SDR to ``establish, maintain, and
enforce written policies and procedures reasonably designed to satisfy
itself that the transaction data that has been submitted to the
security-based swap data repository is complete and accurate.'' Thus,
the Commission could require a registered SDR to include in a Rule
907(e) report any instances where a reporting side reported a trader ID
that fails the SDR's validation rules, because the SDR is in a position
to know which trader IDs (and other UICs) are consistent with UICs
assigned to traders of its participants.\787\
---------------------------------------------------------------------------

    \786\ Id.
    \787\ See also Section 13(n)(5)(B) of the Exchange Act, 15
U.S.C. 78m(n)(5)(B) (requiring an SDR to ``confirm with both
counterparties to the security-based swap the accuracy of the data
that was submitted''); Rule 13n-4(b)(3) under the Exchange Act
(implementing that requirement).
---------------------------------------------------------------------------

XV. Rule 908--Cross-Border Reach of Regulation SBSR

    Security-based swap business currently takes place across national
borders, with agreements negotiated and executed between counterparties
in different jurisdictions (which might then be booked and risk-managed
in still other jurisdictions).\788\ Given the global nature of the
market and to help ensure an effective regime for regulatory reporting
and public dissemination of security-based swap transactions under
Title VII, it is important that Regulation SBSR identify which
transactions in this global market will be subject to these Title VII
requirements. Regulation SBSR, as initially proposed in November 2010,
included Rule 908, which sought to address the cross-border application
of the regulatory reporting and public dissemination requirements. In
the Cross-Border Proposing Release, issued in May 2013, the Commission
re-proposed Rule 908 with substantial revisions. Commenters' views on
re-proposed Rule 908 and the final rule, as adopted by the Commission,
are discussed in detail below, following a discussion of the
Commission's approach to cross-border application of its authority
under Title VII and the Exchange Act generally.
---------------------------------------------------------------------------

    \788\ Security-based swap market data indicates that many
security-based swap transactions involve activity in more than one
jurisdiction. See infra Section XXII(B)(1)(b) (noting that data in
the Trade Information Warehouse reveals that approximately 13% of
price-forming transactions in North American single-name CDS
transaction from January 2008 to December 2013 were between two
U.S.-domiciled counterparties; 48% of such transactions were cross-
border transactions between a U.S.-domiciled counterparty and a
foreign-domiciled counterparty; and an additional 39% were between
two foreign-domiciled counterparties).
---------------------------------------------------------------------------

A. General Considerations

    As stated in the Cross-Border Adopting Release, the Commission
continues to believe that a territorial approach to the application of
Title VII--including the requirements relating to regulatory reporting
and public dissemination of security-based swap transactions--is
appropriate.\789\ This approach, properly understood, is grounded in
the text of the relevant statutory provisions and is designed to help
ensure that the Commission's application of the relevant provisions is
consistent with the goals that the statute was intended to
achieve.\790\ Once the Commission has identified the activity regulated
by the statutory provision, it then determines whether a person is
engaged in conduct that the statutory provision regulates and whether
this conduct occurs within the United States.\791\
---------------------------------------------------------------------------

    \789\ See 79 FR 47287.
    \790\ See Morrison v. Nat'l Australia Bank, Ltd., 130 S. Ct.
2869, 2884 (2010) (identifying focus of statutory language to
determine what conduct was relevant in determining whether the
statute was being applied to domestic conduct).
    \791\ When the statutory text does not describe the relevant
activity with specificity or provides for further Commission
interpretation of statutory terms or requirements, this analysis may
require the Commission to identify through interpretation of the
statutory text the specific activity that is relevant under the
statute or to incorporate prior interpretations of the relevant
statutory text. See Cross-Border Adopting Release, 79 FR 47287
(explaining the Commission's approach to interpreting Title VII
requirements).

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

    Under the foregoing analysis, when a U.S. person enters into a
security-based swap, the security-based swap necessarily exists at
least in part within the United States. The definition of ``U.S.
person''--adopted in the Cross-Border Adopting Release and incorporated
by reference into Regulation SBSR--is intended, in part, to identify
those persons for whom it is reasonable to infer that a significant
portion of their financial and legal relationships is likely to exist
within the United States, and that it is therefore reasonable to
conclude that risk arising from their security-based swap activities
could manifest itself within the United States, regardless of the
location of their counterparties, given the ongoing nature of the
obligations that result from security-based swap transactions.\792\
Under its territorial approach, the Commission seeks to apply Title
VII's regulatory reporting and public dissemination requirements in a
consistent manner to differing organizational structures that serve
similar economic purposes, and thereby avoid creating different
regulatory outcomes for differing legal arrangements that raise similar
policy considerations and pose similar economic risks to the United
States.\793\ Therefore, as discussed in the Cross-Border Adopting
Release, this territorial application of Title VII requirements extends
to the activities of U.S. person conducted through a foreign branch or
office \794\ and to the activities of a non-U.S. person for which the
U.S. person provides a recourse guarantee.\795\
---------------------------------------------------------------------------

    \792\ See 79 FR 47288-89. As discussed below, the Commission is
adopting a definition of ``U.S. person'' in Regulation SBSR that
cross-references the definition adopted as part of the Cross-Border
Adopting Release.
    \793\ See id. at 47344.
    \794\ See id. at 47289.
    \795\ See id. at 47289-90.
---------------------------------------------------------------------------

    The Commission further notes that Section 15F(f)(1)(A) of the
Exchange Act \796\ provides that each registered security-based swap