that it receives the trade report. These requirements are designed to
help inform the Commission as to the length of time between the
execution of a transaction and when the transaction is reported to a
registered SDR, which should provide useful data to the Commission in
analyzing trends in reporting timeframes. These timeframes would
provide some insight into the beliefs of market participants regarding
the length of the reporting delay that they deem necessary to minimize
the market impact of a transaction. Observing trades being reported to
a registered SDR with varying delays after execution could provide the
Commission with greater insight as to what market participants consider
to be market-impacting trades. Further, the Commission believes that
this approach would address, during the interim phase, the concerns of
the commenters who believed that a public dissemination regime with
inappropriately low block trade thresholds could harm market liquidity,
and those who argued that market participants would need an extended
period of time to comply with the requirements to report within shorter
timeframes.
    Although any participant could take the full 24 hours to report a
given trade, there may be incentives to submit trade reports in
substantially less than 24 hours. The Commission understands that, in
some cases, entities that are likely to become SB SEFs (``pre-SEFs'')
may want to broadcast trades executed electronically across their
platforms to all subscribers in order to catalyze trading by other
counterparties at the same price.\525\ This ``work-up'' process,
according to a commenter, is designed to foster liquidity in the
security-based swap market and to facilitate the execution of larger-
sized transactions.\526\ If pre-SEFs and their participants want to
continue their current practices and broadcast a subset of their
executed trades across the platform in real time to facilitate work-
ups, they will be subject to Rule 902(d), which embargos transaction
information until the information is transmitted to a registered
SDR.\527\ Therefore, any pre-SEF or user of a pre-SEF that wants to
continue to have real-time information about a completed trade
broadcast as part of a work-up must ensure that the initial transaction
is reported to a registered SDR no later than the time at which it is
broadcast to users of the pre-SEF.
---------------------------------------------------------------------------

    \525\ See supra Section VI(F) (discussing Embargo Rule).
    \526\ See GFI Letter at 3.
    \527\ See supra Section VI(F).
---------------------------------------------------------------------------

    In response to commenters who advocated shorter reporting time
frames or block trade delays, the Commission notes that it anticipates
further refining the reporting timeframes when it proposes and
implements final block

trade rules, at which point reporting sides will have had more time to
test and implement their reporting systems and processes. This approach
was recommended by several commenters.\528\
---------------------------------------------------------------------------

    \528\ See Institutional Investors Letter at 4 (recommending that
the CFTC collect market data for one year before adopting rules
relating to block trades); MFA II, Recommended Timeline at 4; WMBAA
III at 6; FIA/FSF/ISDA/SIFMA Letter at 6 (appropriate block trade
thresholds, and therefore real-time reporting requirements, can be
established only after the commencement of SDR reporting to
regulators and careful analysis of security-based swap market
transaction data). This approach is also broadly consistent with the
implementation of the TRACE system, which shortened reporting
requirements over time. Several commenters recommended a phased
reporting approach analogous to TRACE. See CCMR I at 2; Cleary II at
20; DTCC II at 9-10; FINRA Letter at 4-5; ISDA/SIFMA I at 10; ISDA/
SIFMA Block Trade Study at 2; UBS Letter at 2-3; WMBAA II at 5.
---------------------------------------------------------------------------

2. Reporting Timeframe for Trades Executed Prior to Weekends or U.S.
Federal Holidays
    While most transactions will have 24 hours within which to be
reported, Rule 901(j) also provides that, ``if 24 hours after the time
of execution would fall on a day that is not a business day, [the
transaction must be reported] by the same time on the next day that is
a business day.'' The Commission's intent is to afford security-based
swap counterparties--during the interim phase--the equivalent of at
least an entire business day to hedge their positions, if they so
desire, before the transaction must be reported and publicly
disseminated. Without clarifying that, during the interim phase,
reporting requirements fall only on business days, for a transaction
executed on the day before a weekend or holiday, the counterparties
would have less than the number of business hours of a regular business
day to hedge a transaction if reporting were required within 24 hours
of execution.
    The Commission is also adopting a definition of ``business day'' to
clarify the ``not a business day'' provision. ``Business day'' is
defined in Rule 900(f) as ``a day, based on U.S. Eastern Time, other
than a Saturday, Sunday, or a U.S. federal holiday.'' Counterparties to
the trade may be in different time zones and/or jurisdictions; in the
absence of Rule 900(f) there could be confusion about whether the ``not
a business day'' provision referred to the jurisdiction and time zone
of one side or the jurisdiction and time zone of the other. Because
Regulation SBSR is designed to implement Title VII's regulatory
reporting and public dissemination requirements for the U.S. security-
based swap market, the Commission is designating U.S. Eastern Time
(which may be either Eastern Standard Time or Eastern Daylight Time) as
the time zone on which the reporting side should base its reporting for
purposes of Rules 900(f) and 901(j). The Commission also is excluding
U.S. federal holidays from the definition of ``business day.'' The
following examples are designed to help explain the application of this
provision:
     Example 1. A trader executes a trade at 04:59 UTC on
Friday (11:59 p.m. EST on Thursday). This particular Friday is not a
U.S. federal holiday. The reporting side must report by 04:59 UTC on
Saturday (11:59 p.m. EST on Friday).
     Example 2. A trader executes a trade at 05:01 UTC on
Friday (12:01 a.m. EST on Friday). The reporting side must report by
05:01 UTC on Monday (12:01 a.m. EST on Monday), provided that this
particular Monday is not a U.S. federal holiday.
     Example 3. A trader executes a trade at 14:42 UTC on
Friday (9:42 a.m. EST on Friday). The reporting side must report by
14:42 UTC on Monday (9:42 a.m. EST on Monday), provided that this
particular Monday is not a U.S. federal holiday.
     Example 4. A trader executes a trade at 13:42 UTC on
Friday (9:42 a.m. EDT on Friday). The following Monday is Labor Day, a
U.S. federal holiday. The reporting party must report by 13:42 UTC on
Tuesday (9:42 a.m. EDT on Tuesday).
     Example 5. A trader executes a trade at 16:45 UTC on
Wednesday, November 26, 2014 (11:45 a.m. EST on Wednesday, November 26,
2014). Thursday, November 27, 2014 is Thanksgiving, a U.S. federal
holiday. The reporting party must report by 16:45 UTC on Friday,
November 28, 2014 (11:45 a.m. EST on Friday, November 28, 2014).
     Example 6. A trader executes a trade at 16:45 UTC on a
Wednesday (11:45 a.m. EST on Wednesday). Thursday is not a U.S. federal
holiday, but a large blizzard causes emergency closures in New York
City and several other U.S. cities. The reporting party must report by
16:45 UTC on Thursday (11:45 a.m. EST on Thursday).
3. Other Revisions To Accommodate the Interim Phase
    In addition to the changes noted above, the Commission is adopting
the following technical changes to Regulation SBSR to implement the
interim phase of reporting and public dissemination. First, the
Commission is not adopting certain sections of rule text that referred
to block trades and marking those sections as ``Reserved.'' Rule
900(c), as re-proposed, would have defined a ``block trade'' as a large
notional security-based swap transaction that meets the criteria set
forth in proposed Rule 907(b). Rule 907(b), as proposed and re-
proposed, would have required a registered SDR to establish and
maintain policies and procedures ``for calculating and publicizing
block trade thresholds for all security-based swap instruments reported
to the registered security-based swap data repository in accordance
with the criteria and formula for determining block size as specified
by the Commission.'' Rule 907(b), as proposed and re-proposed, also
would have excluded equity TRS instruments and any security-based swap
contemplated by Section 13(m)(1)(C)(iv) of the Exchange Act \529\ from
the definition of ``block trade.'' Because the Commission anticipates
soliciting public comment on block thresholds and other rules related
to block trades--including what role (if any) registered SDRs should
play in calculating those thresholds--the Commission is not at this
time defining the term ``block trade'' in Rule 900(c) or adopting Rule
907(b). Similarly, because the Commission is not at this time adopting
the requirement to report in real time, the Commission is not adopting
a definition of ``real time'' in Rule 900.
---------------------------------------------------------------------------

    \529\ 15 U.S.C. 78m(m)(1)(C)(iv).
---------------------------------------------------------------------------

    Second, the Commission has determined not to utilize the term
``security-based swap instrument'' \530\ in Regulation SBSR. The
Commission devised the original definition of ``security-based swap
instrument'' in connection with its overall analysis of the block trade
issue. In the Regulation SBSR Proposing Release, the Commission stated
its preliminary belief that it would not be appropriate to establish
different block trade thresholds for similar instruments with different
maturities. Thus, the proposed definition of ``security-based swap
instrument'' did not include any distinction based on tenor or date
until expiration.\531\
---------------------------------------------------------------------------

    \530\ Proposed Rule 900 would have defined ``security-based swap
instrument'' to mean ``each security-based swap in the same asset
class, with the same underlying reference asset, reference issuer,
or reference index.'' This definition was included, without change,
in re-proposed Rule 900(dd).
    \531\ See 75 FR 75231.
---------------------------------------------------------------------------

    One commenter discussed the concept of security-based swap
instruments in the context of its overall discussion of block trade
issues.\532\ The commenter argued that a different block size threshold
would have to be

calculated for each category of security-based swap instrument, so the
boundaries of those categories would greatly impact market
participants' ability to engage in block trading. The commenter
recommended, therefore, that instruments be classified in as few
categories as possible.\533\ Another commenter argued that the
definition of ``security-based swap instrument'' ``should provide for
more granular distinctions between different types of transaction
within a single asset class to avoid grouping together transactions
with quite different characteristics.'' \534\
---------------------------------------------------------------------------

    \532\ See CCMR I at 3.
    \533\ See id.
    \534\ ISDA/SIFMA I at 10.
---------------------------------------------------------------------------

    The Commission anticipates soliciting public comment on block trade
thresholds at a later date. Because the initial intent of the term
``security-based swap instrument'' was to delineate separate categories
of security-based swaps that could have separate block trade
thresholds, the Commission is not adopting the term ``security-based
swap instrument'' at this time. The Commission anticipates soliciting
public comment on whether and how to establish different categories of
security-based swaps--and what, if any, block thresholds and
dissemination delays will apply to those different categories--when it
solicits comment on block thresholds.
    Further, proposed Rule 902(b) would have specified the delay for
dissemination of certain information about block trades to the public
as well as what information a registered SDR should disseminate
immediately. Because the Commission anticipates that it will re-propose
all aspects of Regulation SBSR as they pertain to block trades, the
Commission is not adopting Rule 902(b) at this time.
    Rules 901(j), as adopted, require the reporting of both primary and
secondary trade information, respectively, for a security-based swap no
later than 24 hours after the time of execution (or acceptance for
clearing in the case of a security-based swap that is subject to
regulatory reporting and public dissemination solely by operation of
Rule 908(a)(1)(ii)), or, if 24 hours after the time of execution or
acceptance for clearing, as applicable, would fall on a day that is not
a business day, by the same time on the next day that is a business
day. Re-proposed Rule 901(d)(2) would have required the reporting side
to report what final Rule 901(d) now terms the ``secondary trade
information'' promptly, but in any event, no later than: (1) 15 minutes
after the time of execution for a security-based swap that is executed
and confirmed electronically; (2) 30 minutes after the time of
execution for a security-based swap that is confirmed electronically
but not executed electronically; or (3) 24 hours after the time of
execution for a security-based swap that is not executed or confirmed
electronically. In proposing these reporting timeframes, the Commission
recognized that the amount of time required for counterparties to
report the information required under proposed Rule 901(d)(1) depended
upon, among other things, the extent to which the security-based swap
was customized and whether the security-based swap was executed or
confirmed electronically or manually.\535\
---------------------------------------------------------------------------

    \535\ See Regulation SBSR Proposing Release, 75 FR 75219. The
Commission believed that the information required under Rule
901(d)(1) would be available relatively quickly for a security-based
swap that was executed and confirmed electronically because most of
the required information would already be in an electronic format.
On the other hand, the Commission recognized that, for security-
based swaps that are not executed or confirmed electronically,
additional time might be needed to systematize the information
required under Rule 901(d)(1) and put it into the appropriate
format. See id.
---------------------------------------------------------------------------

    Generally, commenters' views regarding the regulatory reporting
timeframes in proposed Rule 901(d)(2) were mixed. While some commenters
expressed concerns that the proposed timeframes were too lenient or
incentivized slower technologies,\536\ other commenters expressed the
view that the reporting timeframes in proposed Rule 901(d)(2) were not
practicable.\537\ One of these commenters noted the likelihood of
errors if reporting timeframes were too short.\538\ Another commenter
urged the Commission to strike an appropriate balance between speed and
accuracy in establishing timeframes for regulatory reporting.\539\ One
commenter suggested that, initially, the Rule 901(d) regulatory
reporting timeframes should be set closer to current market capability,
with electronically confirmable trades reported within 24 hours.\540\
This commenter recommended a phase-in period to allow reporting parties
to develop the necessary reporting capabilities, after which time
shorter timeframes could be implemented.\541\
---------------------------------------------------------------------------

    \536\ See Better Markets I at 9 (noting that technology that
would permit reporting within much shorter timeframes is widely
available, and that market participants routinely adhere to much
shorter timeframes for their own business and internal reporting);
Tradeweb Letter at 5 (different reporting timeframes based on the
method of execution potentially could create incentives for market
participants not to take advantage of available technology); SDMA I
at 3 (stating, with reference to the CFTC's proposed rules, that
different reporting timeframes based on method of execution could
create a `race to the slowest' among swap execution facilities, with
market participants favoring slower-reporting swap execution
facilities over more efficient and transparent facilities).
    \537\ See MFA Letter at 5; DTCC II at 12.
    \538\ See MFA Letter at 5.
    \539\ See ISDA/SIFMA I at 9.
    \540\ See DTCC II at 12.
    \541\ See id.
---------------------------------------------------------------------------

    The Commission is not adopting the reporting timeframes proposed in
Rule 901(d)(2), and is therefore renumbering Rule 901(d)(1) as Rule
901(d).\542\ Because Rule 901(j), as adopted, allows reporting sides up
to 24 hours to report the primary trade information pursuant to Rule
901(c) (or until the same time on the next business day if the trade
occurs less than 24 hours before a weekend or federal holiday), the
Commission believes that it is appropriate also to modify the timeframe
for reporting the secondary trade information set forth in Rule 901(d)
to harmonize with the Rule 901(c) requirement. Although both the
primary and secondary trade information must be reported within 24
hours of the time of execution or acceptance for clearing, as
applicable (or until the same time on the next business day if the
trade occurs less than 24 hours before a weekend or federal holiday),
Rule 901 does not require that all of the information enumerated in
Rules 901(c) and 901(d) be provided in a single trade report. Thus, a
reporting side could, if permitted by the policies and procedures of
the relevant registered SDR, make an initial report of the primary
trade information followed by a subsequent report containing secondary
trade information, so long as both reports were provided within the
timeframe prescribed by Rule 901(j).\543\
---------------------------------------------------------------------------

    \542\ See supra Section II(C)(2).
    \543\ However, the registered SDR's policies and procedures
adopted under Rule 907(a)(1) generally should explain to reporting
sides how to report if all the security-based swap transaction data
required by Rules 901(c) and 901(d) is being reported
simultaneously, and how to report if responsive data are being
provided at separate times. In the latter case, the registered SDR
should provide the reporting side with the transaction ID after the
reporting side reports the information required by Rule 901(c). The
reporting side would then include the transaction ID with its
submission of data required by Rule 901(d), thereby allowing the
registered SDR to match the Rule 901(c) report with the subsequent
Rule 901(d) report.
---------------------------------------------------------------------------

    The Commission acknowledges the issues raised by the commenters
regarding the proposed reporting timeframes, and, in particular, the
concerns that unreasonably short reporting timeframes would result in
the submission of inaccurate transaction information. The Commission
believes that the 24-hour reporting timeframe being adopted in Rule
901(j) strikes an appropriate balance, for the interim phase, between
the need for prompt reporting of security-based swap transaction
information and allowing

reporting entities sufficient time to develop fast and robust reporting
capability. The Commission notes that some commenters supported a 24-
hour reporting timeframe as consistent with existing industry reporting
capability,\544\ and believes that this timeframe addresses commenters'
concerns that some elements of the required information might not be
available within the initially proposed reporting timeframes.\545\
---------------------------------------------------------------------------

    \544\ See DTCC II at 12; MFA at 5.
    \545\ See Cleary II at 15-16.
---------------------------------------------------------------------------

    Finally, Rule 901(d)(2), as proposed and re-proposed, would have
established reporting timeframes based on whether a security-based swap
is executed and/or confirmed electronically. The term ``confirm''
appeared only in Rule 901(d)(2), as proposed and re-proposed.\546\
Because this term does not appear in Rule 901(d)(2), as adopted, the
Commission has determined not to adopt a definition for the term
``confirm'' in final Rule 900.\547\
---------------------------------------------------------------------------

    \546\ Rule 900(e), as re-proposed, defined ``confirm'' as ``the
production of a confirmation that is agreed to by the parties to be
definitive and complete and that has been manually, electronically,
or, by some other legally equivalent means, signed.''
    \547\ One commenter suggested that the Commission use the term
``issued,'' rather than ``confirm'' to better reflect existing
market practice with respect to confirming the terms of a security-
based swap. See ISDA IV at 10. The deletion of the term ``confirm''
from Regulation SBSR, as adopted, addresses this concern.
---------------------------------------------------------------------------

4. Dissemination of Notional Amount
    The Commission is mindful of comments expressing concern about
dissemination of the full notional amount for block trades.\548\ For
example, two commenters expressed the view that disseminating the
notional amount of a block trade could jeopardize the anonymity of the
counterparties.\549\ One commenter, who noted that TRACE never requires
the dissemination of the exact notional amount of block transactions,
suggested that the Commission had not fully explained its rationale for
not adopting this approach for security-based swaps.\550\ Numerous
commenters supported dissemination of the notional amount of block
trades through a ``masking'' or ``size plus'' convention comparable to
that used by TRACE, in which transactions larger than a specified size
would be reported as ``size plus.'' \551\
---------------------------------------------------------------------------

    \548\ See Cleary II at 13 (``we would recommend that the SEC
gather further data on the costs and benefits of disclosing notional
size before requiring such disclosure for all transactions''); ISDA/
SIFMA I at 5 (size of a block trade transaction should not be
disclosed at any time); ISDA/SIFMA II at 8 (same); ISDA/SIFMA Block
Trade Study at 26-27 (noting that reporting of notional amounts of
block trades will hamper the execution of large-sized trades and
recommending dissemination of capped volume information); Phoenix
Letter at 3; SIFMA I at 5; UBS Letter at 2 (arguing actual notional
amount of an illiquid security-based swap would provide information
to the market about potential hedging activity); WMBAA II at 7
(arguing that dissemination of the full notional amount could
jeopardize the anonymity of counterparties to the trade).
    \549\ See WMBAA II at 7 (also noting that the result may be that
counterparties are less willing to engage in large transactions);
Phoenix Letter at 3 (stating that reporting block trades at the same
time as non-block trades could jeopardize the anonymity of the block
trade).
    \550\ See Cleary II at 13.
    \551\ See WMBAA II at 7; ISDA/SIFMA I at 5; ISDA/SIFMA Block
Trade Study at 2, 26-27; Vanguard Letter at 5; Goldman Sachs Letter
at 6; SIFMA I at 5; J.P. Morgan Letter at 12-13; MFA I at 4; MFA III
at 8; UBS Letter at 2; FIA/FSF/ISDA/SIFMA Letter at 6; Phoenix
Letter at 3; ISDA IV at 16.
---------------------------------------------------------------------------

    Under Rule 902(a), as adopted, a registered SDR is required to
publicly disseminate (for all dissemination-eligible transactions
\552\), immediately upon receipt of the transaction report, all of the
elements required by Rule 901(c), including the true notional amount of
the transaction (as opposed to a ``capped'' or ``bucketed'' notional
amount). The Commission believes the T+24 hour approach during the
interim phase should address commenters' concerns about disseminating
the true notional amount of a transaction, including concerns about
preserving the anonymity of counterparties.\553\ One commenter
expressed concern about reporting blocks and non-blocks in the same
timeframe, which, the commenter stated, would prevent market
participants from being able to hedge the trade.\554\ The Commission
believes that a 24-hour timeframe for reporting of transaction
information should address any concerns about disseminating the true
notional amount of any transaction and allow market participants who
choose to hedge adequate time to accomplish a majority of their hedging
activity before transaction data is publicly disseminated.\555\ During
the interim phase when no transaction must be reported in less than 24
hours after execution, the Commission will be able to collect and
analyze transaction information to develop an understanding of how
market participants are reacting to the introduction of mandated post-
trade transparency. The Commission expects to study, among other
things, the frequency with which security-based swap market
participants transact in non-standard notional amounts, and will
attempt to observe whether the market reacts differently to last-sale
prints of any non-standard sizes versus more conventional sizes. Based
on such data and analysis, the Commission anticipates considering
whether it may be appropriate to establish notional caps or rounding
conventions in disseminated reports.
---------------------------------------------------------------------------

    \552\ See Rule 902(c) (requiring that certain types of security-
based swaps not be publicly disseminated).
    \553\ One commenter appears to agree generally with this
approach. See J.P. Morgan Letter at 14 (`` `un-masked' trade-by-
trade notional amounts should eventually be disseminated . . . in
order to facilitate analysis of market trends by market participants
and the academic community'').
    \554\ See Phoenix Letter at 3.
    \555\ The Commission further notes that equity total return
swaps are synthetic substitutes for positions in the underlying
equity security or securities; therefore, the Commission believes
that it would not be appropriate to allow masking for a synthetic
substitute when there is no masking exceptions to public
dissemination in the cash equities markets.
---------------------------------------------------------------------------

5. Analysis Period
    As discussed in Section XXII(C)(3)(a), infra, during the interim
phase, the Commission will have access to more useful data about how
different security-based swap trades of different sizes and with
different reporting delays might be affecting subsequent behavior in
the market, as well as any additional data and analysis that might be
submitted by third parties.\556\ Furthermore, once implemented,
reporting sides will be required under Regulation SBSR to submit their
security-based swap execution times to a registered SDR. As noted
above, security-based swap transaction data currently stored in DTCC-
TIW includes the time of reporting but not the time of the
execution.\557\ Having the execution time instead of only the reporting
time will allow a more robust and granular analysis of any hedging that
may or may not occur within the first 24-hour period after execution.
---------------------------------------------------------------------------

    \556\ See ICI II at 7 (``We also support the SEC re-opening for
comment certain issues related to block trades--such as the required
time delays--in connection with the future SEC proposal regarding
how to define block trades'').
    \557\ See Hedging Analysis at 5.
---------------------------------------------------------------------------

    The Commission is directing its staff to use data collected during
the interim phase to publish a report for each asset class of security-
based swaps assessing the impact of post-trade transparency on that
asset class. The Appendix to Rule 901 of Regulation SBSR sets forth the
guidelines for these reports, which must be completed no later than two
years following the initiation of public dissemination of SBS
transaction data by the first registered SDR in each asset class.\558\
---------------------------------------------------------------------------

    \558\ See infra Section XXII(C)(3)(a) (describing the importance
of conducting additional data analysis during the interim phase).
---------------------------------------------------------------------------

    The completion of the staff's report for an asset class will mark
the beginning of an analysis period, during which the Commission
anticipates

considering the report, any public comments received on the report, and
any other relevant data and information, including the Commission's
original proposal to define ``real time'' in the context of Section
13(m) of the Exchange Act to mean ``as soon as technologically
practicable, but in no event later than 15 minutes after the time of
execution of a security-based swap transaction.'' \559\ Based on this
analysis, the Commission anticipates that it will prepare a proposal
that would address, among other things: (1) The criteria for
determining what constitutes a large notional security-based swap
transaction (block trade) for particular markets and contracts; and (2)
the appropriate time delay for disseminating large notional security-
based swap transactions (block trades) to the public.\560\ The
Commission believes that the approach of studying security-based swap
market activity once post-trade transparency is implemented, but before
adopting block trade rules, accords with the recommendations of several
commenters.\561\
---------------------------------------------------------------------------

    \559\ See Regulation SBSR Proposing Release, 75 FR 75284.
    \560\ See 15 U.S.C. 78m(m)(1)(E)(ii)-(iii). The Commission
anticipates that these proposed rules also would address certain
issues raised by commenters during the comment period for Regulation
SBSR. For example, several commenters proposed calculation
methodologies for block trade thresholds. See, e.g., Goldman Sachs
Letter at 4-6; ISDA/SIFMA I at 4; Better Markets I at 6; WMBAA II at
3; ISDA/SIFMA Block Trade Study at 26; Cleary II at 14 (supporting
various tests or methodologies for establishing block trade
thresholds). Commenters suggested various approaches for how often
block thresholds should be updated. See ISDA/SIFMA I at 5 (stating
that block trade thresholds should be updated at least every three
months because liquidity in the OTC markets may change quickly);
ISDA/SIFMA II at 8 (stating that the block trading exemption rules
should be updated quarterly); ISDA/SIFMA Block Trade Study at 2
(stating that the reporting rules should be re-evaluated regularly
to ensure that they reflect the changing characteristics of the
market); ICI I at 3 (stating that block trade thresholds would need
to be reviewed more than once a year to remain meaningful); WMBAA II
at 5 (recommending that block trade thresholds be updated at
appropriate intervals); MFA III at 8 (stating that an SB SEF's swap
review committee should periodically determine what constitutes a
``block'' for each security-based swap or security-based swap class
that the SF SEF trades). See also Barclays Letter at 5 (generally
supporting a 30-calendar-day look-back for determining block size
thresholds).
    \561\ See Institutional Investors Letter at 4 (recommending that
the CFTC collect market data for one year before adopting rules
relating to block trades); MFA II, Recommended Timeline at 4; WMBAA
III at 6; FIA/FSF/ISDA/SIFMA Letter at 6 (appropriate block trade
thresholds, and therefore real-time reporting requirements, can be
established only after the commencement of SDR reporting to
regulators and careful analysis of security-based swap market
transaction data). This approach is also broadly consistent with the
implementation of the TRACE system, which shortened reporting
requirements over time. Several commenters recommended a phased
reporting approach analogous to TRACE. See CCMR I at 2; Cleary II at
20; DTCC II at 9-10; FINRA Letter at 4-5; ISDA/SIFMA I at 10; ISDA/
SIFMA Block Trade Study at 2; UBS Letter at 2-3; WMBAA II at 5.
---------------------------------------------------------------------------

VIII. Reporting and Public Dissemination of Security-Based Swaps
Involving Allocation

    This section explains the application of Regulation SBSR to certain
security-based swaps executed by an asset manager on behalf of multiple
clients--transactions involving what are sometimes referred to as
``bunched orders.'' \562\ To execute a bunched order, an asset manager
negotiates and executes a security-based swap with a counterparty,
typically a security-based swap dealer, on behalf of multiple clients.
The bunched order could be executed on- or off-platform. The asset
manager would allocate a fractional amount of the aggregate notional
amount of the transaction to each client, either at the time of
execution or some time after execution. Allocation results in the
termination of the executed bunched order and the creation of new
security-based swaps between the security-based swap dealer and the
accounts managed by the asset manager.\563\ By executing a bunched
order, the asset manager avoids having to negotiate the account-level
transactions individually, and obtains exposure for each account on the
same terms (except, perhaps, for size).
---------------------------------------------------------------------------

    \562\ The Commission recognizes that market participants may use
a variety of other terms to refer to such transactions, including
``blocks,'' ``parent/child'' transactions, and ``splits.'' The
Commission has determined to use a single term, ``bunched orders,''
for purposes of this release, as this appears to be a widely
accepted term. See, e.g., ``Bunched orders challenge SEFs,''
MarketsMedia (March 25, 2014), available at http://marketsmedia.com/bunched-orders-challenge-sefs/ (last visited September 22, 2014);
``Cleared bunched trades could become mandatory rule,'' Futures and
Options World (October 31, 2013) (available at http://www.fow.com/3273356/Cleared-bunched-trades-could-become-mandatory-rule.html
(last visited September 22, 2014).
    \563\ In aggregate, the notional amount of the security-based
swaps that result from the allocation is the same as the notional
amount of the executed bunched order.
---------------------------------------------------------------------------

A. Discussion of Comments Received and Application of Regulation SBSR

    In response to the Regulation SBSR Proposing Release, one commenter
stated that asset managers commonly use bunched orders and allocations
in the OTC derivatives market, and recommended that publicly
disseminating the execution of a bunched order--without the allocation
information--would satisfy the transparency objective of Title VII and
be consistent with TRACE reporting.\564\ The commenter also expressed
the view that the reporting party for a bunched order execution should
be obligated to report allocation information, which would be necessary
to indicate the final placement of risk derived from the initial
trade.\565\ The discussion below explains how Regulation SBSR's
regulatory reporting and public dissemination requirements apply to
executed bunched orders that are subject to the reporting hierarchy in
Rule 901(a)(2)(ii) and the security-based swaps that result from the
allocation of these transactions, to the extent that the resulting
security-based swaps are not cleared. The Regulation SBSR Proposed
Amendments Release is proposing guidance for reporting platform-
executed bunched orders that will be submitted to clearing and
security-based swaps that result from the allocation of a bunched order
if the resulting security-based swaps are cleared.
---------------------------------------------------------------------------

    \564\ See ISDA/SIFMA I at 7-8. See also ISDA IV at 10, 13
(asserting that the bunched order execution could be disseminated
publicly, but that post-allocation activities should be excluded
from public dissemination).
    \565\ See id. at 8.
---------------------------------------------------------------------------

    Regulation SBSR requires bunched order executions to be reported
like other security-based swaps. The reporting side for a bunched order
execution subject to the reporting hierarchy in Rule 901(a)(2)(ii)
\566\ must report the information required by Rules 901(c) and 901(d)
for the bunched order execution, including the notional amount of the
bunched order execution, to a registered SDR.\567\ The information
described in final Rule 901(c) will be publicly disseminated under
final Rule 902(a), like any other security-based swap transaction that
does not fall within the enumerated exceptions to public dissemination
in Rule 902(c).\568\ The Commission believes that it is appropriate to
enhance price discovery, and thus consistent with the statutory
provisions governing public dissemination of security-based swaps, to
require public dissemination of a single transaction report showing the
aggregate notional amount of the bunched order execution (i.e., the
size

prior to allocation).\569\ The public thereby will know the full size
of the bunched order execution and that this size was negotiated at a
single price. The reporting side for a bunched order execution also
must report life cycle events for the bunched order execution--
including the termination of the executed bunched order that result
from its allocation--to the registered SDR that receives the initial
report of the transaction.
---------------------------------------------------------------------------

    \566\ See supra Section V. A bunched order execution will be
subject to this reporting hierarchy unless it is executed on a
platform and submitted to clearing.
    \567\ Rule 901(d)(1) requires the reporting side for a security-
based swap to report ``the counterparty ID or the execution agent ID
of each counterparty, as applicable.'' The Commission notes that an
asset manager acts as an execution agent for the clients that
receive allocations of an executed bunched order.
    \568\ See supra Section VI.
    \569\ See 15 U.S.C. 13(m)(1)(B) (authorizing the Commission to
make security-based swap transaction and pricing data available to
the public ``in such form and at such times as the Commission
determines appropriate to enhance price discovery'').
---------------------------------------------------------------------------

    When a bunched order execution is allocated, new security-based
swaps are created that must be reported to a registered SDR pursuant to
Rule 901(a). To clarify that point, the introductory language to final
Rule 901(a) states that a ``security-based swap, including a security-
based swap that results from the allocation, termination, novation, or
assignment of another security-based swap, shall be reported'' as
provided in the rest of the rule.\570\ Reporting of the security-based
swaps resulting from the allocation of a bunched order execution should
assure that the Commission and other relevant authorities know the
final placement of risk that results from the bunched order
execution.\571\ As with any other security-based swap, the reporting
side for a security-based swap resulting from an allocation is
determined by Rule 901(a). Also, as with any other security-based swap,
the reporting side must make the required report within 24 hours of the
time that the new security-based swap is created--not within 24 hours
of the time of execution of the original bunched order.\572\ Under Rule
901(d)(10), the reporting side for a security-based swap resulting from
an allocation must report the transaction ID of the executed bunched
order as part of the report of the new security-based swap.\573\ This
requirement will allow the Commission and other relevant authorities to
link a report of a bunched order execution to the smaller security-
based swaps that result from the allocation of the bunched order
execution. Because these related transactions can be linked across
registered SDRs using the transaction ID of the bunched order
execution, the Commission believes that it is not necessary or
appropriate to require that the security-based swaps resulting from the
allocation be reported to the same registered SDR that received the
transaction report of the original transaction.
---------------------------------------------------------------------------

    \570\ See supra Section V(C)(5).
    \571\ As stated above, allocation also results in the
termination of the bunched order execution, which is a life cycle
event of the original transaction. This life cycle event must be
reported, in accordance with Rule 901(e), to the registered SDR that
receives the report of the original bunched order execution.
    \572\ If 24 hours after the time of allocation would fall on a
day that is not a business day, the report of the security-based
swaps resulting from the allocation would be due by the same time on
the next day that is a business day. See Rule 901(j). One commenter
requested that Regulation SBSR reflect that the timeframe for
reporting security-based swaps resulting from a bunched order
execution commence upon receipt of the identity of the
counterparties to the bunched order execution by the reporting party
during its own business hours. See ISDA IV at 10. The Commission
believes that the requirement that the reporting side make the
required report within 24 hours of the time that the new security-
based swap is created is responsive to this comment.
    \573\ Rule 901(d)(10), as adopted, provides that, if a
``security-based swap arises from the allocation, termination,
novation, or assignment of one or more existing security-based
swaps,'' the reporting side must report ``the transaction ID of the
allocated, terminated, assigned, or novated security-based
swap(s),'' subject to one exception that would not apply to an
allocation that is not submitted for clearing.
---------------------------------------------------------------------------

    The Commission agrees with the commenters who recommended that
publicly disseminating the execution of a bunched order--without the
allocation information--would satisfy the transparency objective of
Title VII.\574\ Therefore, Regulation SBSR does not require a
registered SDR to publicly disseminate reports of the new security-
based swaps that result from an allocation. In fact, as described
above, Rule 902(c)(7), as adopted, prohibits a registered SDR from
disseminating ``[a]ny information regarding the allocation of a
security-based swap.'' \575\ This approach also accords with the
recommendation of the commenter who urged that the aggregate notional
amount prior to allocation be disseminated, rather than the individual
transaction sizes, in order to preserve anonymity of the asset manager
and its clients.\576\
---------------------------------------------------------------------------

    \574\ See ISDA/SIFMA I at 7-8; ISDA IV at 10, 13.
    \575\ See supra Section VI(D).
    \576\ See MFA I at 2-3 (``Counterparties are often aware of an
investment manager's standard fund allocation methodology and
therefore, reporting transactions at the allocated level . . . will
make evident an allocation scheme that other participants can easily
associate with a particular investment manager'').
---------------------------------------------------------------------------

    The Commission notes that Rule 907(a)(1), as adopted, requires a
registered SDR to establish and maintain policies and procedures that,
among other things, enumerate the specific data elements of a security-
based swap that must be reported. Registered SDRs should consider
describing, as part of these policies and procedures, the means by
which persons with a duty to report bunched order executions--and the
new security-based swaps that result from the allocation--must report
the information required by Rules 901(c) and 901(d).

B. Example: Reporting and Public Dissemination for an Uncleared Bunched
Order Execution

    The following example demonstrates how Regulation SBSR applies to a
bunched order execution that will not be cleared and the security-based
swaps that result from the allocation of that bunched order execution.
Assume that an asset manager, acting on behalf of several investment
fund clients, executes a bunched order with a registered security-based
swap dealer. Assume that the transaction is not submitted to clearing
and there are no indirect counterparties on either side. The execution
of the bunched order could occur either on a platform or not.
1. Reporting the Executed Bunched Order
    Under Rule 901(a)(2)(ii), as adopted, the registered security-based
swap dealer is the reporting side for the bunched order execution
because only one side of the transaction includes a registered
security-based swap dealer. Under final Rules 901(c) and 901(d), the
registered security-based swap dealer has up to 24 hours after the time
of execution of the bunched order to report all applicable primary and
secondary trade information to a registered SDR. The registered
security-based swap dealer must report the entire notional amount of
the executed bunched order as part of the Rule 901(c) primary trade
information.\577\ Rule 902(a) requires the registered SDR to publicly
disseminate a single last-sale print showing the aggregate notional
amount of the bunched order execution immediately upon receiving the
report from the registered security-based swap dealer.
---------------------------------------------------------------------------

    \577\ See Rule 901(c)(4) (requiring reporting of the notional
amount of a security-based swap and the currency in which the
notional amount is denominated).
---------------------------------------------------------------------------

 2. Reporting the Allocations
    Regulation SBSR also requires reporting to a registered SDR of the
security-based swaps that result from allocation of the bunched order
execution.\578\ As the reporting side for the executed bunched order,
the registered security-based swap dealer must make a life cycle event
report, in accordance with Rule 901(e), to notify the registered SDR
that received the report of the executed bunched order

that the trade has been allocated, which terminates the security-based
swap. Pursuant to Rule 901(a)(2)(ii), the registered security-based
swap dealer also is the reporting side for each security-based swap
resulting from allocation of the bunched order execution because only
one side of the transaction includes a registered security-based swap
dealer.\579\ If the asset manager provides the allocation information
to the registered security-based swap dealer prior to or
contemporaneous with the bunched order execution, the registered
security-based swap dealer could report the bunched order execution and
the security-based swaps that result from its allocation to a
registered SDR at the same time.\580\ If the asset manager does not
provide the allocation information to the registered security-based
swap dealer until some time after execution of the bunched order, the
registered security-based swap dealer must report each security-based
swap resulting from the allocation within 24 hours of the allocation.
In either case, the reports of the security-based swaps resulting from
the allocation of the bunched order execution must include the
counterparty IDs of each investment fund and the notional amount of
each security-based swap resulting from the allocation. In either case,
Rule 901(d)(10) requires each report of a security-based swap resulting
from the allocation to include the transaction ID of the bunched order
execution so that the Commission and other relevant authorities will
have the ability to link each resulting transaction with the initial
bunched order execution.
---------------------------------------------------------------------------

    \578\ See Rule 901(a) (requiring that a security-based swap,
``including a security-based swap that results from the allocation,
termination, novation, or assignment of another security-based swap
shall be reported'' as provided in the rest of the rule).
    \579\ The Commission assumes that the investment funds would not
be registered security-based swap dealers for purposes of these
examples.
    \580\ Even though the reports could be made at the same time,
Rule 901(a) requires a report of a bunched order execution and an
associated allocation to be maintained as separate records by a
registered SDR because the execution of the bunched order and the
allocations are separate reportable security-based swap
transactions.
---------------------------------------------------------------------------

IX. Inter-Affiliate Security-Based Swaps

A. Background and Summary of Final Rule

    Regulation SBSR, as initially proposed, did not contemplate any
exception from reporting for inter-affiliate security-based swaps. In
the Regulation SBSR Proposing Release, the Commission expressed the
preliminary view that a report of an inter-affiliate security-based
swap should be publicly disseminated with an indicator identifying the
transaction as an inter-affiliate security-based swap.\581\ The
Commission noted that, for such transactions, ``there might not be an
arm's length negotiation over the terms of the [security-based swap]
transaction, and disseminating a report of the transaction without
noting that fact would be inimical to price discovery.'' \582\ Rule
907(a)(4), as proposed, would have required a registered SDR to
establish and maintain written policies and procedures describing,
among other things, how reporting parties would report--and consistent
with the enhancement of price discovery, how the registered SDR would
publicly disseminate--security-based swap transactions that do not
involve an opportunity to negotiate any material terms, other than the
counterparty.\583\
---------------------------------------------------------------------------

    \581\ See 75 FR 75214-15.
    \582\ Id. at 75215.
    \583\ See id. at 75237.
---------------------------------------------------------------------------

    The Commission received several comments regarding inter-affiliate
security-based swaps in response to the Regulation SBSR Proposing
Release and discussed those comments in the Cross-Border Proposing
Release.\584\ Although the Cross-Border Proposing Release did not
propose to revise any portion of Regulation SBSR with regard to the
treatment of inter-affiliate security-based swaps, the Commission
provided some preliminary thoughts on how Regulation SBSR could be
applied to them, particularly as regards to public dissemination, in a
manner that could address commenters' concerns without taking the step
of suppressing all inter-affiliate transactions from public
dissemination.\585\ In response to the Cross-Border Proposing Release,
the Commission received additional comments, described below, regarding
the application of Regulation SBSR to inter-affiliate security-based
swaps.
---------------------------------------------------------------------------

    \584\ See 78 FR 31069-72.
    \585\ See id. at 31071-72.
---------------------------------------------------------------------------

    Regulation SBSR, as adopted, applies to all security-based swaps,
including inter-affiliate security-based swaps. The Commission has
considered, but is not adopting, any exemption from Regulation SBSR's
regulatory reporting or public dissemination requirements for inter-
affiliate security-based swaps. Therefore, Rules 901(c) and 901(d)
require reporting of inter-affiliate security-based swaps; Rule 901(i)
requires reporting of historical inter-affiliate security-based swaps;
and Rule 902 requires public dissemination of inter-affiliate security-
based swaps. Furthermore, Rule 907(a)(4) requires a registered SDR to
establish and maintain policies and procedures that, among other
things, identify characteristics of or circumstances associated with
the execution or reporting of a security-based swap that could, in the
fair and reasonable estimation of the registered SDR, cause a person
without knowledge of such characteristics or circumstances to receive a
distorted view of the market. As discussed in Section VI(G), supra, the
Commission generally believes that a registered SDR should establish a
flag for inter-affiliate security-based swaps to help market observers
better understand the information that is publicly disseminated.

B. Discussion of Comments

1. Regulatory Reporting of Inter-Affiliate Security-Based Swaps
    Most of the comments relating to inter-affiliate security-based
swaps, in response to both the initial proposal and the Cross-Border
Proposing Release (which re-proposed Regulation SBSR in its entirety),
pertained to public dissemination. However, one commenter stated that,
because inter-affiliate transactions should not be publicly
disseminated, it also should be unnecessary to ``collect'' information
about them.\586\ Another commenter on the Regulation SBSR Proposing
Release argued that, for a foreign entity registered as a bank holding
company and subject to the consolidated supervision of the Federal
Reserve System, the reporting of inter-affiliate transactions would be
superfluous because the Federal Reserve has ``ample authority to
monitor transactions among affiliates,'' \587\ suggesting that even
regulatory reporting of inter-affiliate security-based swaps should not
be necessary.\588\ In the Cross-Border Proposing Release, the
Commission specifically asked whether commenters believed that cross-
border inter-affiliate security-based swaps should be excluded from the
regulatory reporting requirements of Regulation SBSR and, if so, under
what circumstances such security-based swaps should be excluded.\589\
No commenters on the Cross-Border Proposing Release responded to this
particular question pertaining to regulatory reporting.
---------------------------------------------------------------------------

    \586\ Cravath Letter at 9.
    \587\ Japanese Banks Letter at 5.
    \588\ See also Multiple Associations IV at 6 (stating that
``many of the transaction-based requirements in Title VII, such as .
. . trade reporting rules, generally do not further legislative or
regulatory purposes when applied to inter-affiliate swaps,'' but
without specifying whether the comment was with respect to
regulatory reporting, public dissemination, or both).
    \589\ See 78 FR 31072.

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

    The Commission continues to believe that the Commission and other
relevant authorities should have ready access to information about the
specific counterparties that hold positions in all security-based swaps
subject to Regulation SBSR. While it is true that the Federal Reserve
or perhaps another relevant authority might exercise consolidated
supervision over a group, such supervision might not provide the
Commission and other relevant authorities with current and specific
information about security-based swap positions held by the group's
subsidiaries. As a result, it would likely be more difficult for
relevant authorities to conduct general market analysis or surveillance
of market behavior, and could present difficulties during a crisis,
when ready access to accurate and timely information about specific
risk exposures might be crucial. Furthermore, the statutory provisions
that require regulatory reporting of security-based swap transactions
state that ``each'' security-based swap shall be reported; these
statutory provisions do not by their terms limit the reporting
requirement to transactions having particular characteristics (such as
being negotiated at arm's length).\590\ Even absent these constraints,
for the reasons described above, the Commission does not believe that
an exemption from regulatory reporting for these transactions would be
appropriate. Therefore, Regulation SBSR subjects inter-affiliate
security-based swaps to regulatory reporting.\591\
---------------------------------------------------------------------------

    \590\ Section 13A(a)(1) of the Exchange Act, 15 U.S.C. 78m-
1(a)(1), provides that each security-based swap that is not accepted
for clearing shall be subject to regulatory reporting. Section
13(m)(1)(G) of the Exchange Act, 15 U.S.C. 78m(m)(1)(G), provides
that each security-based swap (whether cleared or uncleared) shall
be reported to a registered SDR.
    \591\ In addition, one group of commenters acknowledged that ``a
number of rules that apply to the core operations of a registered
entity will perforce apply to such entity's inter-affiliate swap
transactions and could further Dodd-Frank policy purposes.''
Multiple Associations Letter at 9. These commenters stated that
inter-affiliate transactions would need to be taken into account in
calculating an entity's capital requirements, and that internal
recordkeeping requirements are essential to the oversight of the
security-based swap business. See id. The Commission notes that
regulatory reporting of all security-based swaps, including inter-
affiliate security-based swaps, will assist the Commission and other
relevant authorities in overseeing compliance with these capital and
recordkeeping requirements, as the regulatory report of an entity's
security-based swap activity could provide an external check of the
internal records of such entities' positions and activities.
---------------------------------------------------------------------------

2. Public Dissemination of Inter-Affiliate Security-Based Swaps
    As discussed below, some commenters raised concerns regarding the
public dissemination of inter-affiliate security-based swaps. After
carefully considering the issues raised by these commenters, the
Commission has determined to adopt Regulation SBSR with no exemption
from the public dissemination requirements for inter-affiliate
security-based swaps.
    As a preliminary matter, the Commission notes that, once a
security-based swap transaction has been reported to a registered SDR,
the counterparties assume no additional burdens associated with public
dissemination of the transaction. That function will be carried out
solely by the registered SDR. Thus, requiring registered SDRs to
publicly disseminate security-based swaps, including inter-affiliate
security-based swaps, will not increase the compliance burden on
security-based swap counterparties.
    One commenter argued that inter-affiliate security-based swaps
should not be subject to public dissemination because ``public
reporting could confuse market participants with irrelevant
information'' and suggested that ``the Commissions collect data on
these transactions but not require dissemination to the public at
large.'' \592\ Another commenter stated that an inter-affiliate
transaction ``does not contain any additional price information beyond
that contained in the transaction with the customer.'' \593\ One group
of commenters argued that publicly disseminating inter-affiliate
transactions ``will distort the establishment of position limits,
analysis of open interest, determinations of block trade thresholds and
performance of other important regulatory analysis, functions and
enforcement activities that require an accurate assessment of the
[security-based] swaps market.'' \594\ These commenters stated,
further, that inter-affiliate security-based swaps ``could be required
to be publicly reported in multiple jurisdictions, even though they are
not suitable for reporting in any jurisdiction.'' \595\
---------------------------------------------------------------------------

    \592\ Cleary II at 17. See also SIFMA/FIA/Roundtable Letter at
A-44 (stating that ``real-time reporting of inter-affiliate
[security-based swaps] . . . would distort market information and
thus have a detrimental market and commercial impact'').
    \593\ ISDA/SIFMA I at 13. See also ISDA IV at 13 (recommending
that inter-affiliate trades should not be subject to public
dissemination).
    \594\ Multiple Associations Letter at 11-12. See also ISDA I at
5 (stating, in the context of pre-enactment security-based swaps,
that inter-affiliate security-based swaps should not be subject to
reporting).
    \595\ Multiple Associations Letter at 16.
---------------------------------------------------------------------------

    An accurate assessment of the security-based swap market will be
necessary for a wide range of functions, potentially including--as
noted by this group of commenters--analysis of open interest and the
establishment of block trade thresholds.\596\ The Commission believes
that users of security-based swap market data--whether regulators,
SDRs, market participants, or the public at large--should have an
accurate and undistorted view of the market. However, it does not
follow that public dissemination of inter-affiliate security-based
swaps will necessarily prevent an accurate assessment of the security-
based swap market.
---------------------------------------------------------------------------

    \596\ See id. at 11-12.
---------------------------------------------------------------------------

    The need to distinguish reports of initial transactions from
subsequent inter-affiliate transactions exists whether or not the
latter are publicly disseminated. As noted above, the Commission is
requiring each registered SDR to adopt, among others, policies and
procedures for flagging transaction reports that have special
circumstances.\597\ This flagging mechanism is designed to provide
regulators with a more accurate view of the security-based swap market,
and the same mechanism can be applied to publicly disseminated last-
sale reports to give market observers the same view. The Commission
continues to believe that the commenters' concerns about the
potentially limited price discovery value of inter-affiliate security-
based swaps can be addressed through the public dissemination of
relevant data that flags such limitations, rather than suppressing
these transactions from public dissemination entirely. Additionally,
even if the report of an initial security-based swap transaction has
been publicly disseminated in another jurisdiction, the Commission
believes that it would be preferable to disseminate a report of the
subsequent inter-affiliate transaction with an appropriate condition
flag rather than suppressing a report of the inter-affiliate

transaction from public dissemination through a registered SDR. Public
dissemination of such a transaction by a registered SDR would help to
assure that information concerning the transaction was readily
available to participants in the U.S. market and other market
observers.
---------------------------------------------------------------------------

    \597\ These policies and procedures could address not only
reporting of whether a security-based swap is an inter-affiliate
transaction, but also whether the initial security-based swap was
executed in a jurisdiction with public dissemination requirements.
This could be either the United States or another jurisdiction that
imposes last-sale transparency requirements similar to those in
Regulation SBSR. Further, these policies and procedures also could
address whether to indicate the approximate time when the initial
security-based swap was executed. For example, there could be
condition flags for the initial security-based swap having been
executed within the past 24 hours, between one and seven days
before, or longer than seven days before. An indication that the
initial trade was executed less than 24 hours before could provide
significant price discovery value, while an indication that the
initial trade was executed over a week before could, all things
being equal, have less. However, even information about a trade
executed over a week ago (or more) could have price discovery value
for security-based swaps that trade infrequently.
---------------------------------------------------------------------------

    One group of commenters argued that ``use of inter-affiliate
[security-based swaps] not only allows risks to reside where they are
more efficiently managed, but it also has a net positive effect on an
institution's assets and liquidity, as well as on its efficiency in
deploying capital. For these reasons, we believe that there should be
an inter-affiliate exemption from the public dissemination
requirements.'' \598\ Another commenter raised similar concerns,
arguing that ``public reporting of inter-affiliate transactions could
seriously interfere with the internal risk management practices of a
corporate group'' and that ``[p]ublic disclosure of a transaction
between affiliates could prompt other market participants to act in a
way that would prevent the corporate group from following through with
its risk management strategy by, for instance, causing adverse price
movements in the market that the risk-carrying affiliate would use to
hedge.'' \599\ The Commission agrees generally that corporate groups
should engage in appropriate risk management practices. However, the
Commission does not agree that Regulation SBSR, as adopted, is inimical
to effective risk management. The Commission notes that, during the
first phase of Regulation SBSR, all security-based swaps--regardless of
size--must be reported within 24 hours from the time of execution and--
except with regard to transactions falling within Rule 902(c)--
immediately publicly disseminated. As discussed in Section VII, supra,
this reporting timeframe is designed, in part, to minimize any
potential for market disruption resulting from public dissemination of
any security-based swap transaction during the interim phase of
Regulation SBSR. The Commission anticipates that, during the interim
period, it will collect and analyze data concerning the sizes of
transactions that potentially affect liquidity in the market. If the
Commission ultimately determines that some form of block trade
exception to real-time public dissemination is appropriate, an inter-
affiliate security-based swap of block size would be able to avail
itself of that exception. The Commission sees no basis for concluding,
at this time, that inter-affiliate security-based swaps are more
difficult to hedge than other types of security-based swaps, or that
the hedging of these transactions presents unique concerns that would
not also arise in connection with the hedging of a security-based swap
that was not an inter-affiliate transaction. Therefore, the Commission
does not agree with the commenters' concern that public dissemination
of inter-affiliate security-based swaps will impede the ability of
corporate groups to hedge.
---------------------------------------------------------------------------

    \598\ SIFMA/FIA/Roundtable Letter at A-44.
    \599\ Cleary II at 17.
---------------------------------------------------------------------------

    Another group of commenters argued that ``affiliates often enter
into these swaps on terms linked to an external trade being hedged. If
markets have moved before the inter-affiliate trade is entered into on
the SEF or reported as an off-exchange trade, market participants could
also misconstrue the market's true direction and depth.'' \600\ This
comment suggests that last-sale reports of transactions that appear out
of the order in which the transactions in fact occurred could mislead
market observers. The Commission shares this concern but does not
conclude that the appropriate response is to suppress all inter-
affiliate transactions from public dissemination. The Commission
believes instead that this issue can be addressed by requiring the
dissemination of the date and time of execution on the last-sale
report.\601\ This requirement is designed to allow market observers to
construct a time-sequenced record of all transactions in the security-
based swap market and thereby counteract the possibility that certain
transactions could be reported and publicly disseminated out of the
order in which they were in fact executed.
---------------------------------------------------------------------------

    \600\ See Multiple Associations Letter at 12.
    \601\ See Rule 901(c)(2).
---------------------------------------------------------------------------

    Some commenters stated that inter-affiliate security-based swaps
``are typically risk transfers with no market impact.'' \602\ This
statement does not exclude the possibility that some inter-affiliate
security-based swaps might have a market impact. The Commission sees no
basis to conclude at this time that inter-affiliate security-based
swaps do not provide price discovery value or other useful information
to market observers. Market observers might be able to discern useful
information from the last-sale reports of some inter-affiliate
security-based swaps, and the Commission believes that market observers
should be given the opportunity to do so--particularly given the Title
VII mandate that all security-based swaps shall be publicly
disseminated. The value of this information to market observers is
unknown at this time, because market observers have never before had
the opportunity to view comprehensive last-sale information from the
security-based swap market. Suppressing all inter-affiliate security-
based swaps from public dissemination would eliminate any potential
that market observers could develop ways to utilize this information.
Thus, under the final rules, market observers who wish to evaluate the
entire record of transactions, including inter-affiliate transactions,
will have the opportunity to do so. As discussed above, the Commission
disagrees with the commenters who argued that ``[r]equiring real-time
reporting of inter-affiliate [security-based swaps] . . . would distort
market information and thus have a detrimental market and commercial
impact.'' \603\ Because such transactions will be flagged, market
observers can simply--if they wish--remove from their analysis any
transactions having an inter-affiliate flag.
---------------------------------------------------------------------------

    \602\ SIFMA/FIA/Roundtable Letter at A-44; Multiple Associations
Letter at 11 (emphasis added).
    \603\ SIFMA/FIA/Roundtable Letter at A-44.
---------------------------------------------------------------------------

    The Commission sees one circumstance where public dissemination of
an inter-affiliate transaction could have significant price discovery
value: When the initial transaction is effected in a foreign
jurisdiction without a public dissemination requirement and is not
otherwise subject to public dissemination under Regulation SBSR, and
the subsequent inter-affiliate transaction--between one of the original
counterparties and one of its affiliate--would be publicly disseminated
if it fell within Rule 908(a)(1). Commenters' views that public
dissemination of an inter-affiliate transaction would be duplicative
and distorting are premised on the view that the initial transaction
is, in fact, publicly disseminated, which may not always be the
case.\604\ Therefore, public dissemination of the subsequent inter-
affiliate transaction might be the only way for the market to obtain
any pricing information about the related pair of transactions.\605\ In
the Cross-Border Proposing Release, the Commission specifically noted
this

circumstance and requested comment on it.\606\ No commenters responded.
---------------------------------------------------------------------------

    \604\ See Multiple Associations Letter at 12 (``The market-
facing swaps already will have been reported and therefore, to
require that inter-affiliate swaps also be reported will duplicate
information'').
    \605\ In addition, even if the initial transaction is publicly
disseminated, the Commission does not believe that publicly
disseminating the second, inter-affiliate transaction would cause
observers to obtain a distorted view of the market, as long as the
second transaction is flagged as an inter-affiliate transaction. See
supra Section VI(G).
    \606\ See 78 FR 31072.
---------------------------------------------------------------------------

    Finally, one commenter on the Cross-Border Proposing Release argued
that the Commission should propose a comprehensive rule regarding
inter-affiliate security-based swaps ``before finalizing the
substantive underlying rules governing the SBS markets.'' \607\ The
commenter reasoned that ``a separate proposed rule, like the Cross-
Border Proposal, is necessary to ensure that market participants are
accorded sufficient opportunity to comment on the interplay between the
Commission's proposed rules and inter-affiliate trades.'' \608\
---------------------------------------------------------------------------

    \607\ SIFMA/FIA/Roundtable Letter at A-28.
    \608\ Id. at A-30.
---------------------------------------------------------------------------

    The Commission notes that Regulation SBSR, as initially proposed,
did not contemplate any exception for inter-affiliate security-based
swaps, and the Regulation SBSR Proposing Release discussed at various
points how proposed Regulation SBSR would apply to inter-affiliate
transactions.\609\ The Commission received comments regarding the
reporting of inter-affiliate transactions in response to both the
Regulation SBSR Proposing Release and the Cross-Border Proposing
Release. Commenters on the Cross-Border Proposing Release's discussion
of the application of Regulation SBSR to inter-affiliate security-based
swaps did not raise any new issues that had not already been raised in
response to the Regulation SBSR Proposing Release. In addition, as
noted above, the Commission discussed in the Cross-Border Proposing
Release the comments regarding inter-affiliate transactions submitted
in response to the Regulation SBSR Proposing Release.\610\ After
carefully considering all of these comments, the Commission believes
that commenters had sufficient opportunity to present their views on
inter-affiliate transactions in Regulation SBSR and therefore it is
appropriate at this time to adopt final rules relating to regulatory
reporting and public dissemination of security-based swaps, including
inter-affiliate security-based swaps.
---------------------------------------------------------------------------

    \609\ See 75 FR 75215, 75234, 75237.
    \610\ See 78 FR 31069-72.
---------------------------------------------------------------------------

X. Rule 903--Use of Codes

    Regulation SBSR, as adopted, permits or, in some instances,
requires security-based swap counterparties to report coded information
to registered SDRs. These codes, known as unique identification codes
(``UICs''), will be used to identify products, transactions, and legal
entities, as well as certain business units and employees of legal
entities.\611\ Rule 903 of Regulation SBSR establishes standards for
assigning and using coded information in security-based swap reporting
and dissemination to help ensure that codes are assigned in an orderly
manner and that regulators, market participants, and the public are
able to interpret coded information stored and disseminated by
registered SDRs.
---------------------------------------------------------------------------

    \611\ See supra Section II (describing UICs that must be
reported to registered SDRs pursuant to Regulation SBSR).
---------------------------------------------------------------------------

A. Proposed Treatment of Coded Information

    As initially proposed, Regulation SBSR would have established a
process for assigning UICs in Rule 900 and addressed the standards for
using coded information in Rule 903. Proposed Rule 900 would have
provided that a ``unique identification code'' or ``UIC'' would be the
unique code assigned to a person, unit of a person, or product by or on
behalf of an internationally recognized standards-setting body
(``IRSB'') that imposes fees and usage restrictions that are fair and
reasonable and not unreasonably discriminatory. The proposed definition
of ``UIC'' further would have provided that, if there existed no IRSB
meeting these criteria, a registered SDR would have been required to
assign all necessary UICs using its own methodology. Similarly, if an
IRSB meeting the criteria existed but had not assigned a relevant UIC,
the registered SDR would have been required to assign that UIC using
its own methodology. When the Commission re-proposed Regulation SBSR as
part of the Cross-Border Proposing Release, it designated the
definition of ``UIC'' as re-proposed Rule 900(nn) but made no changes
to the substance of the definition.\612\
---------------------------------------------------------------------------

    \612\ See 78 FR 31211-12.
---------------------------------------------------------------------------

    Rule 903, as originally proposed, would have permitted the use of
codes in place of certain data elements for purposes of reporting and
publicly disseminating the information required under proposed Rules
901 and 902 of Regulation SBSR, provided that the information to
interpret such codes is ``widely available on a non-fee basis.'' When
the Commission re-proposed Rule 903, it replaced the term ``reporting
party'' with ``reporting side'' but otherwise made no substantive
revisions to the rule.\613\
---------------------------------------------------------------------------

    \613\ See id. at 31213.
---------------------------------------------------------------------------

B. Comments Received and Final Rule 903

1. Relocation of UIC Provisions Into Rule 903
    Final Rule 903 is divided into paragraphs (a) and (b). Rule 903(a)
sets out the requirements that registered SDRs must follow when
assigning UICs. Similar requirements were initially proposed as part of
the definition of ``UIC'' in Rule 900, and re-proposed without revision
in Rule 900(nn). The Commission now believes that it would be more
consistent with the overall structure of Regulation SBSR to move any
substantive requirements from the definitions rule (Rule 900) and into
an operative rule. Therefore, the Commission's substantive requirements
for a registered SDR's use of UICs are now located in final Rule
903.\614\ As described below, the Commission is adopting these
requirements substantially as proposed, but with certain changes as
described below. In particular, Rule 903(a), as adopted, includes new
language regarding Commission recognition of international systems for
assigning UICs. In addition, final Rule 903(a) provides that, if the
Commission has recognized such a system that assigns UICs to persons,
each participant of a registered SDR shall obtain a UIC from or through
that system for identifying itself, and each participant that acts as a
guarantor of a direct counterparty's performance of any obligation
under a security-based swap that is subject to Rule 908(a) shall, if
the direct counterparty has not already done so, obtain a UIC for
identifying the direct counterparty from or through that system, if
that system permits third-party registration without a requirement to
obtain prior permission of the direct counterparty.
---------------------------------------------------------------------------

    \614\ Accordingly, the Commission is now adopting a simplified
definition of ``UIC.'' See Rule 900(qq) (defining ``UIC'' as ``a
unique identification code assigned to a person, unit of a person,
product, or transaction''). See also infra Section X(B)(2)
(discussing final Rule 903(a)).
---------------------------------------------------------------------------

    Final Rule 903(b) imposes certain restrictions on how coded
information may be reported and publicly disseminated. Rule 903(b)
substantially incorporates the earlier versions of Rule 903, with
certain conforming and technical changes described below.
2. Comments Regarding UICs and Final Rule 903(a)
    The Commission received several comments on the proposed rules
relating to UICs and the development of internationally recognized LEIs
generally. One commenter expressed concern that, absent a methodology

outlined by a standard-setting body, multiple UICs could be assigned by
different regulators to the same financial entity, thereby creating
compliance burdens, operational difficulties, and opportunities for
confusion.\615\ Another commenter believed that, absent internationally
recognized LEIs, requiring SDR-specific UICs would create
inconsistencies among different SDRs.\616\ This commenter recommended
that the Commission postpone this requirement until an international
taxonomy exists that can be applied consistently.\617\ A third
commenter stated that it is imperative that a single source of
reference data and unambiguous identifiers be established.\618\ A
fourth commenter argued that ``[s]ignificant progress in establishing
the GLEIS has been made to date, and the time for further expanding the
use of the LEI through rulemaking is favorable.'' \619\ A fifth
commenter noted that the CFTC's swap reporting rules require the use of
LEIs and urged the Commission, for the sake of clarity and consistency,
to replace its reference to ``unique counterparty identifiers'' with
``Legal Entity Identifiers,'' unless the Commission's rule was intended
to include identifiers beyond LEIs.\620\ A sixth commenter suggested
that the rules reflect primary use of the LEI as a party identifier and
the need to use an LEI ``when available,'' recognizing that a reporting
party may request but cannot compel its counterparties to obtain an
LEI.\621\
---------------------------------------------------------------------------

    \615\ See ICI I at 6.
    \616\ See DTCC V at 14 (also noting that, while global standards
for identification codes are likely to exist for some data fields,
certain global identifiers will not exist).
    \617\ See id. See also Bloomberg Letter at 1 (``an identifier
system should be comprehensive and global'').
    \618\ See Benchmark Letter at 1.
    \619\ See letter from Kenneth E. Bentsen, Jr., President and
CEO, SIFMA, to the Honorable Jacob J. Lew, Chairman, Financial
Stability Oversight Council, dated April 11, 2014, available at
http://www.sifma.org/newsroom/2014/sifma_pushes_for_broad_use_of_leis_to_promote_financial_stability/
(last visited January 13, 2015). In a prior comment letter, this
commenter recommended that ``industry utilities'' be considered for
assigning unique IDs for legal entities/market participants, as well
as for transactions and products. See ISDA/SIFMA I at 8. See also
SWIFT Letter at 2 (expressing support for a global standard for
identifying security-based swap market participants); DTCC X
(stating that there has been significant adoption globally on
transaction ID, product ID, and LEI standards).
    \620\ See Levin Letter at 4.
    \621\ See ISDA IV at 12. Regulation SBSR, as adopted, does not
compel a counterparty on a reporting side to a security-based swap
to obtain an LEI for a counterparty on the other side of the
transaction.
---------------------------------------------------------------------------

    The Commission is adopting in Rule 903(a) the provisions relating
to the process for assigning UICs largely as proposed and re-proposed,
but--reflecting the comments described above--is including two new
requirements: (1) That the Commission recognize an IRSS before the use
of UICs from that IRSS becomes mandatory under Regulation SBSR; and (2)
that, if the Commission has recognized an IRSS that assigns UICs to
persons, each participant of a registered SDR shall obtain a UIC from
or through that IRSS. As noted below, the Commission is recognizing the
GLEIS as an IRSS for assigning LEIs. Final Rule 903(a) states: ``If an
internationally recognized standards-setting system that imposes fees
and usage restrictions on persons that obtain UICs for their own usage
that are fair and reasonable and not unreasonably discriminatory and
that meets the requirements of paragraph (b) of this section is
recognized by the Commission and has assigned a UIC to a person, unit
of a person, or product (or has endorsed a methodology for assigning
transaction IDs), the registered security-based swap data repository
shall employ that UIC (or methodology for assigning transaction IDs).
If no such system has been recognized by the Commission, or a
recognized system has not assigned a UIC to a particular person, unit
of a person, or product (or has not endorsed a methodology for
assigning transaction IDs), the registered security-based swap data
repository shall assign a UIC to that person, unit of person, or
product using its own methodology (or endorse a methodology for
assigning transaction IDs). If the Commission has recognized such a
system that assigns UICs to persons, each participant of a registered
security-based swap data repository shall obtain a UIC from or through
that system for identifying itself, and each participant that acts as a
guarantor of a direct counterparty's performance of any obligation
under a security-based swap that is subject to Sec.  242.908(a) shall,
if the direct counterparty has not already done so, obtain a UIC for
identifying the direct counterparty from or through that system, if
that system permits third-party registration without a requirement to
obtain prior permission of the direct counterparty.'' \622\
---------------------------------------------------------------------------

    \622\ See infra Section X(B)(3) (explaining the Commission's
rationale for adopting final Rule 903(a)).
---------------------------------------------------------------------------

    The Commission shares commenters' desire to have identifiers that
are widely recognized, which would increase efficiency at both the SDR
and market participant level. To avoid confusion about when an IRSS
meets the standards of Rule 903, the Commission has modified the rule
to provide that UICs issued by a particular IRSS would not become
mandatory under Regulation SBSR unless the Commission has recognized
the IRSS. As detailed below, the Commission is recognizing the GLEIS,
applying the standards provided in Rule 903. The Commission will apply
the standards provided in Rule 903 to any future assessment of whether
an IRSS should be recognized as a provider of UICs for purposes of
Regulation SBSR. Specifically, the Commission will consider whether the
IRSS imposes fees and usage restrictions on persons that obtain UICs
for their own usage that are fair and reasonable and not unreasonably
discriminatory, and whether the information necessary to interpret the
codes assigned by or through the IRSS is widely available to users of
the information on a non-fee basis and without usage restrictions.\623\
---------------------------------------------------------------------------

    \623\ See infra Section X(B)(3) (discussing final Rule 903(b)).
---------------------------------------------------------------------------

    Since Regulation SBSR was initially proposed in 2010, significant
strides have been made in the development of a globally recognized LEI.
The Commission hereby recognizes the GLEIS, which operates under a
regulatory oversight committee (``ROC''), as an internationally
recognized standards-setting system (``IRSS'') \624\ that meets the
requirements of Rule 903 of Regulation SBSR. The Commission notes that
the LEI Regulatory Oversight Committee (``LEI ROC'') currently includes
members that are official bodies from over 40 jurisdictions.\625\ LEIs
are being issued by over 30 pre-local operating units (``pre-LOUs'')
around the globe, including the Global Markets Entity Identifier
(``GMEI'') Utility in the United States.\626\ Furthermore, the
Commission believes that the GLEIS imposes fees and usage restrictions
on persons that obtain UICs

for their own usage that are fair and reasonable and not unreasonably
discriminatory under Rule 903(a).\627\ The Commission also understands
that the GLEIS does not impose any fees for usage of or access to its
LEIs, and that all of the associated reference data needed to
understand, process, and utilize the LEIs are widely and freely
available and not subject to any usage restrictions.\628\ Therefore,
the Commission believes that the LEIs issued by or through the GLEIS
meet the standards of Rule 903(b), which are discussed in the section
immediately below. The Commission also notes that it would expect to
revisit its recognition of the GLEIS if the GLEIS were to modify its
operations in a manner that causes it no longer to meet the standards
of Rule 903. The Commission believes that the provisions of Rule 903--
coupled with the Commission's recognition of the GLEIS--will facilitate
the reporting and analysis of security-based swap transaction data,
because (1) each participant of a registered SDR must be identified
using the same LEI for all transactions reported pursuant to Regulation
SBSR, and regardless of which registered SDR holds records of its
transactions, and (2) a participant, when it acts as guarantor of a
direct counterparty to a security-based swap that is subject to Rule
908(b), is required to obtain an LEI from or through the GLEIS if the
direct counterparty does not already have an LEI and if the system
permits third-party registration without a requirement to obtain prior
permission of the direct counterparty.\629\
---------------------------------------------------------------------------

    \624\ Regulation SBSR, as proposed and re-proposed, would have
employed the term ``internationally recognized standards-setting
body'' rather than ``internationally recognized standards-setting
system,'' which is used in Regulation SBSR, as adopted. The
Commission made this revision to better reflect the process of LEI
issuance. LEIs are being assigned by a number of different bodies in
different jurisdictions being coordinated through a global system,
rather than by a single body.
    \625\ The Commission is a member of the Executive Committee of
the LEI ROC. The LEI ROC is a stand-alone committee established
pursuant to recommendations by the Financial Stability Board
(``FSB'') that was subsequently endorsed by the Group of 20 nations.
See Financial Stability Board (``FSB''), A Global Legal Entity
Identifier for Financial Markets (June 8, 2012), available at http://www.leiroc.org/publications/gls/roc_20120608.pdf (last visited
September 22, 2014); http://www.treasury.gov/resource-center/international/g7-g20/Documents/G20%20Ministerial%20Communique%20November%204-5-2012-Mexico%20City.pdf (last visited September 22, 2014).
    \626\ See https://www.gmeiutility.org/index.jsp.
    \627\ See FSB, A Global Legal Entity Identifier for Financial
Markets, at 20 (``Fees, where and when imposed, should be modest and
set on a non-profit cost-recovery basis'') and at 20, note 20 (``It
is possible that some jurisdictions could be willing to fund the LEI
issuance from public sources and provide LEIs to its local entities
free of charge''). As of December 26, 2014, the cost of obtaining an
LEI from the GMEI Utility was $200, plus a $20 surcharge for the LEI
Central Operating Unit. The annual cost of maintaining an LEI from
the GMEI Utility was $100, plus a $20 surcharge for the LEI Central
Operating Unit. See https://www.gmeiutility.org/frequentlyAskedQuestions.jsp.
    \628\ See, e.g., http://www.financialstabilityboard.org/wp-content/uploads/r_120608.pdf?page_moved=1, at 9 (``Access to the LEI
and associated reference data will be free and open to all users,
and there should be no `bundling' of other services alongside the
LEI by providers which forces users to pay directly or indirectly
for the LEI''). In addition, LEI information can be downloaded at no
cost from pre-LOU Web sites. See, e.g., https://www.gmeiutility.org/
(providing a link for downloading an FTP file containing LEI
information).
    \629\ The Commission understands that the GLEIS permits one firm
to register a second firm when the first firm has a controlling
interest over the second. See https://www.gmeiutility.org/frequentlyAskedQuestions.jsp (``Who can register an entity for the
LEI?'').
---------------------------------------------------------------------------

    As noted above, one commenter recommended that, for clarity and
consistency with the CFTC's swap reporting rules, the Commission refer
to LEIs, rather than UICs, unless the Commission intended to include
identifiers beyond LEIs.\630\ Although the Commission agrees that the
use of the term ``LEI'' would provide greater consistency with the
CFTC's rules, Regulation SBSR continues to refer to UICs, rather than
LEIs, for two reasons. First, as the commenter suggested, the term
``UIC'' in Regulation SBSR includes identifiers in addition to LEIs,
such as identifiers for products, transactions, business units of legal
entities (i.e., branches and trading desks), and individual
traders.\631\ Second, the GLEIS does not extend to natural persons or
sub-legal entity business units, such as a branches and trading desks.
Because at present the Commission has not recognized an IRSS for these
types of UICs, a registered SDR is required to assign UICs to these
entities using its own methodology. Thus, because Regulation SBSR
refers to identifiers in addition to LEIs, Regulation SBSR continues to
refer to UICs rather than LEIs.
---------------------------------------------------------------------------

    \630\ See Levin Letter at 4.
    \631\ Rule 900(qq), as adopted, defines UIC to mean ``a unique
identification code assigned to a person, unit of a person, product,
or transaction.''
---------------------------------------------------------------------------

    The Commission acknowledges that, under final Rule 903(a),
different registered SDRs could, in theory, assign different UICs to
the same person, unit of a person, or product. Inconsistent UICs could
require the Commission and other relevant authorities to map the UICs
assigned by one registered SDR to the corresponding UICs assigned by
other registered SDRs to obtain a complete picture of the market
activity pertaining to a particular person or business unit.\632\
Although mapping may present certain challenges, the Commission
believes that this approach is better than the likely alternative of
having market participants assign UICs to identify persons, units of
persons, or products according to their own methodologies.\633\ In
other words, the Commission believes that UICs, even if they are SDR-
specific, will provide a streamlined way of reporting, disseminating,
and interpreting security-based swap information.\634\ The Commission
believes that requiring registered SDRs to develop their own UICs--but
only for UICs that are not assigned by or through an IRSS that has been
recognized by the Commission--will result in less confusion than the
currently available alternatives, such as allowing each reporting side
to utilize its own nomenclature conventions, which would subsequently
have to be normalized by registered SDRs themselves or by the
Commission.
---------------------------------------------------------------------------

    \632\ To avoid this possibility with respect to the
identification of legal persons that are participants of at least
one registered SDR, the Commission has recognized the GLEIS--by or
through which LEIs are issued--as an IRSS that meets the criteria of
Rule 903. The Commission is requiring that, if the Commission has
recognized such a system that assigns UICs to persons, each
participant of a registered SDR shall obtain a UIC from or through
that system. The Commission notes that a single person may act in
various capacities in the security-based swap market. For example, a
person could be a direct counterparty with respect to some
transactions while acting as a broker with respect to other
transactions. If that person is a participant of a registered SDR,
that person must obtain an LEI from or through the GLEIS to identify
itself in all applicable security-based swap transaction reports,
regardless of the capacity in which the person acted with respect to
a particular transaction.
    \633\ The Commission notes, however, that Regulation SBSR does
not prohibit one registered SDR from utilizing the UICs that were
originally assigned by another SDR.
    \634\ See infra Section XIX (discussing regulatory implications
of having multiple registered SDRs).
---------------------------------------------------------------------------

    The Commission further understands that, at this time, neither the
GLEIS nor any other IRSS has assigned product IDs or established a
methodology for assigning transaction IDs. Therefore, a registered SDR
also is required under Rule 903(a) to assign, or endorse a methodology
for assigning, product IDs and transaction IDs. One commenter
recommended that ``industry utilities'' be considered for assigning
unique IDs, including transaction IDs and product IDs.\635\ With
respect to product IDs, Rule 903(a) provides a registered SDR with
flexibility to assign a product ID created by an industry utility, in
the absence of an IRSS recognized by the Commission that issues product
IDs. Thus, if an industry utility developed product IDs,\636\ a
registered SDR could endorse that industry utility as the means for
assigning such product IDs, and require use of those product IDs for
reporting and publicly dissemination transaction information in its
policies and procedures required by Rule 907(a).
---------------------------------------------------------------------------

    \635\ See ISDA/SIFMA I at 8. See also ISDA IV at 12 (requesting
that the Commission acknowledge the ISDA OTC Taxonomy as an
acceptable product ID for reporting under Regulation SBSR and
recognize that reporting parties, as opposed to SDRs, are generally
best positioned to assign these values). In the context of the
development of product IDs, the Commission is not at this time
making any determination as to whether the ISDA OTC Taxonomy system
constitutes an IRSS under Regulation SBSR, or whether the product
IDs issued under the ISDA OTC Taxonomy system meet the criteria of
Rule 903.
    \636\ See id.
---------------------------------------------------------------------------

    With respect to transaction IDs, a registered SDR--in the absence
of an IRSS recognized by the Commission that has endorsed a methodology
for assigning transaction IDs--is required to

assign transaction IDs or endorse a methodology for assigning
transaction IDs.\637\ A number of commenters recommended that
Regulation SBSR permit transaction IDs generated by persons other than
a registered SDR.\638\ The Commission generally agrees with these
comments, and has revised the UIC provisions relating to transaction
IDs as follows. Although Rule 900, as proposed and re-proposed, would
have defined ``transaction ID'' as ``the unique identification code
assigned by registered security-based swap data repository to a
specific security-based swap,'' the definition of ``UIC'' in proposed
Rule 900(nn) did not mention transaction IDs. The final definition of
``UIC'' includes transaction IDs in addition to identification codes
for persons, units of persons, and products. The final definition of
``transaction ID'' is ``the UIC assigned to a specific security-based
swap transaction,'' without the limitation that it be assigned by a
registered SDR. The Commission agrees with these commenters that
requiring a registered SDR to use transaction IDs assigned only by a
registered SDR would not be practical. The Commission believes that it
would be more efficient and consistent with current practice in the
security-based swap market to allow transaction IDs to be assigned at
or shortly after execution, by a counterparty, platform, or post-trade
processor. Final Rule 903(a) includes language that contemplates that
an IRSS or registered SDR may ``endorse a methodology for assigning
transaction IDs.'' This formulation makes clear that transaction IDs
need not be assigned by an IRSS or registered SDR itself, but can be
assigned by security-based swap counterparties, platforms, or post-
trade processors using the IRSS's or registered SDR's methodology. Any
entity that assigns the transaction ID must do so in accordance with
the methodology endorsed by a recognized IRSS or, in the absence of a
recognized IRSS that has endorsed a methodology for assigning
transaction IDs, by the registered SDR that will receive the report of
the transaction.\639\
---------------------------------------------------------------------------

    \637\ See Rule 903(a). See also supra Section III(B)(2)
(discussing transaction IDs).
    \638\ See DTCC V at 14 (recommending that the Commission allow
flexibility for a registered SDR to accept transaction IDs already
generated by the reporting side or to assign transaction IDs where
such request is made); ISDA III at 2; ISDA IV at 11; Tradeweb Letter
at 5 (arguing that SB SEFs and exchanges should be permitted to
assign transaction IDs).
    \639\ See Rule 903(a). Thus, for example, a counterparty or
platform must not generate 40-character transaction IDs if the
registered SDR requires and can accept only 32-character transaction
IDs.
---------------------------------------------------------------------------

    Two commenters addressed the types of entities that can act as
IRSSs. One of these commenters recommended that for-profit entities be
permitted to act as reference data registration authorities,\640\ while
the other commenter argued that LEIs should be issued by a not-for-
profit entity that operates on the principle of cost recovery, and that
the industry should determine the appropriate model for cost
recovery.\641\ The Commission does not believe that it is necessary or
appropriate to specify the type of entity--for-profit or non-profit--
that can establish or operate an IRSS. Whichever the case, final Rule
903(a) specifies that the UICs issued by an IRSS may be used under
Regulation SBSR only if the IRSS that imposes fees and usage
restrictions that are fair and reasonable and not unreasonably
discriminatory and that meets the criteria of Rule 903(b) has been
recognized by the Commission. In other words, the overall character of
the IRSS's operation does not matter for purposes of compliance with
Regulation SBSR (i.e., whether it is a for-profit or non-profit entity)
so long as any fees and usage restrictions imposed with respect to UICs
meets the requirements of Rule 903(a). In addition, any codes used as,
or as part of, UICs under Regulation SBSR must meet the standards of
Rule 903(b), which are described below.
---------------------------------------------------------------------------

    \640\ See GS1 Proposal at 53.
    \641\ See ISDA/SIFMA I at 8.
---------------------------------------------------------------------------

3. Comments on Proposed Rule 903 and Final Rule 903(b)
    Commenters expressed differing views regarding whether the
providers of UICs--and product IDs in particular--should be able to
charge fees for the codes or for the information necessary to interpret
the codes. One commenter supported the proposed requirement that
information necessary to interpret reported or publicly disseminated
codes be available free of charge.\642\ However, a second commenter--a
provider of product identification codes for security-based swaps--
stated that Regulation SBSR should not require product identifiers to
be freely available.\643\ This commenter noted that maintaining a
reliable identification system for security-based swaps requires a
substantial level of investment, and recommended that the providers of
product identification codes be permitted to charge commercially
reasonable fees for developing and maintaining the codes.\644\ A third
commenter recommended that existing licensing codes be used for product
IDs to the extent possible, because using existing codes would be
easier for registered SDRs; the use of new codes would require ongoing
maintenance and the development of specific processes for reporting,
which could result in poorer quality data submissions.\645\
---------------------------------------------------------------------------

    \642\ See Barnard I at 3 (noting that making this information
available for free could eliminate confusion).
    \643\ See Markit I at 6 (stating that identifier systems
provided on an automated basis and/or for free ``generally are not
adequate for the intended goals'').
    \644\ See id.
    \645\ See DTCC II at 16. The commenter supported the continued
use of existing license codes, including the Markit Reference Entity
Database (``RED'')TM codes currently used in trade
confirmations for credit derivatives and the Reuters Instrument
Codes (``RIC'') used in electronic messages for equity derivatives.
The commenter further noted that without RED codes, the description
of a reference entity in submitted data could vary, even in minor
ways (e.g., the punctuation used in an abbreviation), creating
difficulties for the SDR that would be required to correctly
identify the reference entity. This commenter also suggested that
the Commission adopt a rule that would provide existing licensing
codes at a reduced cost for small volume market participants. As
described below, final Rule 903(b) permits the use of codes in
security-based swap reports under Regulation SBSR only if the
information necessary to interpret the codes is widely available on
a non-fee basis.
---------------------------------------------------------------------------

    After careful consideration of these comments, the Commission
continues to believe that the information necessary to interpret any
codes used by registered SDRs must be ``widely available on a non-fee
basis.'' Thus, the Commission is adopting this key feature of Rule
903(b) as proposed and re-proposed. A primary goal of Title VII is to
use reporting and public dissemination of security-based swap data as a
means of monitoring risks and increasing transparency, both to
regulators and the public, of the security-based swap markets. If the
transaction data that are reported and publicly disseminated contain
codes and the information necessary to interpret such codes is not
widely available on a non-fee basis, these Title VII goals could be
frustrated. In the absence of Rule 903(b), a registered SDR could
require--or acquiesce in the use of--proprietary, fee-based
identification codes, thereby requiring all users of the security-based
swap market data to pay the code creator, directly or indirectly, for
the information necessary to interpret the codes. Users of the data
also might be subject to usage restrictions imposed by the code
creator.
    Currently, the security-based swap market data typically include
fee-based codes, and all market participants and market observers must
pay license fees and agree to various usage restrictions to

obtain the information necessary to interpret the codes. The Commission
believes that allowing continuation of the status quo would not satisfy
the Title VII mandate to increase security-based swap market
transparency through public dissemination. If information to understand
embedded codes is not widely available on a non-fee basis, information
asymmetries would likely continue to exist between large market
participants who pay for the codes and others market participants. One
commenter suggested that alternatives could be developed to the status
quo of using fee-based codes in security-based swap market data.\646\
The Commission welcomes the development of such alternatives, and
believes that Rule 903(b), as adopted, will likely encourage such
development.
---------------------------------------------------------------------------

    \646\ See Bloomberg Letter at 2. This commenter stated that it
would be possible to develop a public domain symbology for security-
based swap reference entities that relied on products in the public
domain to ``provide an unchanging, unique, global and inexpensive
identifier.'' According to this commenter, its proprietary symbology
product for securities could provide a starting point for a
security-based swap symbology product.
---------------------------------------------------------------------------

    Furthermore, the Commission believes that the public dissemination
requirements in Title VII should allow observers of the market to
incorporate the information contained in public reports of security-
based swaps into any decisions they might take regarding whether and
how to participate in the market (or even to avoid participation), and
for intermediaries in the market to incorporate this information to
provide better advice to their clients about the market. The Commission
does not believe that these objectives would be advanced if the ability
of market participants to understand public reports of security-based
swap transactions were conditioned on agreeing to pay fees to a code
creator. The Commission similarly believes that subjecting the public's
use of this information to restrictions imposed by a code creator also
could frustrate the objectives of public dissemination. In addition,
allowing continuation of the status quo would retard the ability of the
Commission and other relevant authorities to obtain and analyze
comprehensive security-based swap information.
    The Commission recognizes the usefulness of codes. They make
reporting more efficient because providing just one code--a product ID,
for example--can eliminate the need to report multiple data elements
individually. Codes also facilitate the standardized representation of
security-based swap data and thereby make reporting (and understanding
reported data) more reliable and efficient.\647\ With respect to
product IDs specifically, the Commission believes that unless an IRSS
has been recognized by the Commission and can assign product IDs,
registered SDRs should be free to choose between using an existing
mechanism for assigning product IDs--assuming it is consistent with
Rule 903(b)--and developing a new product classification system. If all
existing product identification codes require users of the transaction
information to pay a fee, then a registered SDR may not require or
permit use of those codes for reporting and public dissemination. The
registered SDR would be required to issue UICs using its own
methodology and make the information necessary to interpret those codes
available on a non-fee basis.
---------------------------------------------------------------------------

    \647\ For example, in the absence of an LEI, different persons
might refer to a particular legal entity as ``XYZ,'' ``XYZ Corp.'',
or ``XYZ Corporation.'' Confusion about whether all of these terms
refer to same entity would be minimized, if not wholly eliminated,
if all parties referred to the entity using the same code (e.g.,
``ABCD12345'').
---------------------------------------------------------------------------

    In light of the requirement in Rule 903(b) that the information
necessary to interpret coded information be widely available on a non-
fee basis, it would be inconsistent with the rule for a registered SDR
to permit information to be reported pursuant to Rule 901, or to
publicly disseminate information pursuant to Rule 902, using codes in
place of certain data elements if the registered SDR imposes, or
permits the imposition of, any usage restrictions on the disseminated
information. The purpose of Rule 903(b) is to help ensure that the
public is able to utilize the last-sale information provided by
Regulation SBSR without limitation or expense.
    The commenter that provides product identification codes for
security-based swaps also noted that proposed Regulation SBSR would
allow an IRSB that develops counterparty identifiers to charge fees,
and believed that providers of product IDs should receive comparable
treatment.\648\ In response to this comment, the Commission believes
that it is appropriate to make minor revisions to the rule language to
clarify its original intent and thereby eliminate any apparent
contradiction between the two paragraphs of Rule 903. When the
Commission originally proposed that an IRSB could impose fees and usage
restrictions as long as they were fair and reasonable and not
unreasonably discriminatory, the Commission intended that language to
apply to persons that obtain UICs for their own usage (such as a legal
entity that seeks to identify itself as a counterparty when engaging in
security-based swap transactions), not ultimate users of the
information (such as third parties who might wish to enter into a
security-based swap with that entity as the reference entity). The
Commission believes that this distinction is consistent with
international efforts to develop a global LEI.\649\
---------------------------------------------------------------------------

    \648\ See Markit Letter at 6.
    \649\ See Charter of the Regulator Oversight Committee for the
Global Legal Entity Identifier (LEI) System (November 5, 2012),
http://www.leiroc.org/publications/gls/roc_20121105.pdf (last
visited September 22, 2014) (``ROC Charter''). The ROC Charter
provides that the mission of the ROC is ``to uphold the governance
principles of and to oversee the Global LEI System, in the broad
public interest.'' Id. at 1. The ROC Charter further provides that,
in protecting the broad public interest, the objectives of the ROC
include ``open and free access to publicly available data from the
Global LEI System,'' and specifically includes the following
principle: ``all public data should be readily available on a
continuous basis, easily and widely accessible using modern
technology, and free of charge.'' Id. at 2 (emphasis added). At the
same time, the ROC Charter states that ``any entities required, or
eligible, to obtain an LEI [must be] able to acquire one under open
and non-discriminatory terms.'' Id. One such term is that ``fees,
where and when imposed by the [Central Operating Unit], are set on a
non-profit cost-recovery basis.'' Id.
---------------------------------------------------------------------------

    In Rule 903(a), as adopted, the Commission is inserting after the
words ``fees and usage standards'' the new words ``on persons that
obtain UICs for their own usage.'' \650\ This language clarifies that
it is consistent with Rule 903(a) for a registered SDR to accept codes
for which the code creator assesses fair and reasonable fees on market
participants that need to identify themselves, their agents, or parts
of their organizations when engaging in financial activities. For
example, Rule 903(a) would permit a registered SDR to charge
participants that need to acquire UICs that are assigned by registered
SDRs, such as counterparty IDs, ultimate parent IDs, branch IDs,
trading desk IDs, and trader IDs.
---------------------------------------------------------------------------

    \650\ Final Rule 903(a) thus provides: ``If an internationally
recognized standards-setting system that imposes fees and usage
restrictions on persons that obtain UICs for their own usage that
are fair and reasonable and not unreasonably discriminatory is
recognized by the Commission and has assigned a UIC to a person,
unit of a person, or product (or has endorsed a methodology for
assigning transaction IDs), the registered security-based swap data
repository shall employ that UIC (or methodology for assigning
transaction IDs). If no such system has been recognized by the
Commission, or a recognized system has not assigned a UIC to a
particular person, unit of a person, or product (or has not endorsed
a methodology for assigning transaction IDs), the registered
security-based swap data repository shall assign a UIC to that
person, unit of person, or product using its own methodology (or
endorse a methodology for assigning transaction IDs)'' (emphasis
added).
---------------------------------------------------------------------------

    In Rule 903(b), as adopted, the Commission is inserting the words
``to users of the information'' immediately

after the phrase ``widely available.'' \651\ The users of information
referred to in final Rule 903(b) could include the Commission, other
relevant authorities, or any person who wishes to view or utilize the
publicly disseminated security-based swap transaction data for any
purpose. As noted above, the Commission does not believe that access to
this information should be impeded by having to pay fees or agree to
usage restrictions in order to understand any coded information that
might be contained in the transaction data.
---------------------------------------------------------------------------

    \651\ Final Rule 903(b) thus provides: ``A registered security-
based swap data repository may permit information to be reported
pursuant to Sec.  242.901, and may publicly disseminate that
information pursuant to Sec.  242.902, using codes in place of
certain data elements, provided that the information necessary to
interpret such codes is widely available to users of the information
on a non-fee basis'' (emphasis added).
---------------------------------------------------------------------------

    The Commission notes that Rule 903(b) prevents registered SDRs and
code creators from impeding a person's ability to obtain the
information necessary to interpret coded information used in reporting
or public dissemination under Regulation SBSR. Rule 903(b) is not
intended to prevent a registered SDR from charging for its SDR
services. To the contrary, registered SDRs are expressly permitted to
charge fees for their SDR services that are fair and reasonable and not
unreasonably discriminatory.\652\
---------------------------------------------------------------------------

    \652\ See Rule 13n-4(c)(1)(i) under the Exchange Act, which is
part of the SDR Adopting Release. But see Regulation SBSR Proposed
Amendments Release, Section VI (proposing to prohibit SDRs from
charging fees for publicly disseminating regulatorily mandated
transaction data).
---------------------------------------------------------------------------

    The Commission notes that it is making an additional revision to
the language in re-proposed in Rule 903 to conform final Rule 903(b) to
the Commission's original intent and to avoid any potential conflict
with final Rule 901(h). Rule 901(h), as adopted, provides that the
reporting side shall electronically transmit the information required
under Rule 901 to a registered SDR ``in a format required by the
registered [SDR].'' Under re-proposed Rule 903, the reporting side
could ``provide information to a registered [SDR] . . . using codes in
place of certain data elements.'' \653\ This language in re-proposed
903 could have been read to give the reporting side discretion to
select what codes it could use for reporting transaction information to
a registered SDR., The Commission has revised final Rule 903(b) to more
clearly reflect its original intent: That reporting sides shall report
information in a format required by the registered SDR.\654\ Thus, Rule
903(b), as adopted, provides that a registered SDR ``may permit
information to be reported . . . using codes in place of certain data
elements.'' The Commission believes that final Rule 903(b), read
together with final Rule 901(h), makes clear that a reporting side may
provide coded information to a registered SDR only to the extent
permitted by the registered SDR and only in a format required by the
SDR. Therefore, the reporting side may not exercise its own discretion
when selecting codes to use in its reports to the registered SDR,
regardless of whether the codes otherwise comport with Rule 903.
---------------------------------------------------------------------------

    \653\ Specifically, re-proposed Rule 903 provided that ``The
reporting side may provide information to a registered security-
based swap data repository pursuant to Sec.  242.901 and a
registered security-based swap data repository may publicly
disseminate information pursuant to Sec.  242.902 using codes in
place of certain data elements, provided that the information
necessary to interpret such codes is widely available on a non-fee
basis.''
    \654\ See supra Section IV (discussing Rule 901(h)). See also
Rule 907(a)(5) (requiring a registered SDR to establish and maintain
policies and procedures for assigning UICs in a manner consistent
with Rule 903); Rule 907(a)(2) (requiring a registered SDR to
establish and maintain policies and procedures that specify, among
other things, protocols for submitting information, including but
not limited to UICs).
---------------------------------------------------------------------------

    Finally, one commenter expressed concern that, although Regulation
SBSR, as initially proposed, would have required that the information
necessary to interpret codes be made available for free, the proposal
would not have prevented a code creator from charging for other
uses.\655\ In this commenter's view, ``[a] widely used identifier can
become a de facto standard for anyone doing business in the relevant
marketplace. This creates the potential for abuse, defeating the entire
purpose of promoting the broad availability of identifiers.'' \656\
This commenter believed instead that, ``[a]s long as all market
participants have the unfettered freedom to introduce alternative
identifiers and to map those identifiers to the standard, however,
multiple, competing identifiers can provide an inexpensive solution.''
\657\ The Commission shares the commenter's concern that identification
codes not become a tool for monopolistic abuse. This is why the
Commission is requiring in Rule 903(b) that, if such codes will be used
for reporting or publicly disseminating security-based swap transaction
data, ``the information necessary to interpret such codes [must be]
widely available to users of the information on a non-fee basis.''
Thus, the Commission does not believe it will be necessary for market
participants to introduce alternative identifiers, although Regulation
SBSR would not prohibit them from doing so.
---------------------------------------------------------------------------

    \655\ See Bloomberg Letter at 2.
    \656\ Id.
    \657\ Id.
---------------------------------------------------------------------------

C. Policies and Procedures of Registered SDRs Relating to UICs

    As proposed and re-proposed, Rule 907(a)(5) would have required a
registered SDR to establish and maintain written policies and
procedures for assigning: (1) A transaction ID to each security-based
swap that is reported to it; and (2) UICs established by or on behalf
of an IRSB that imposes fees and usage restrictions that are fair and
reasonable and not unreasonably discriminatory (or, if no standards-
setting body meets these criteria or a standards-setting body meets
these criteria but has not assigned a UIC to a particular person, unit
of a person, or product, assigning a UIC using its own methodology).
    The Commission received several comments, noted above, that
discussed utilization of UICs generally and considered them in
connection with Rule 907(a)(5).\658\ The Commission also received a
comment that generally encouraged the Commission to adopt a convention
for assigning unique IDs and incorporating a pilot or early adopter
program for certain products and participants that would allow for end-
to-end testing and proof of concept.\659\
---------------------------------------------------------------------------

    \658\ See supra notes 615 to 618 and accompanying text.
    \659\ See ISDA/SIFMA I at 8.
---------------------------------------------------------------------------

    As discussed above, the Commission believes that UICs--even if
utilized on an SDR-specific basis in the absence of UICs issued by a
recognized IRSS--will create a more consistent and transparent system
for reporting and analyzing security-based swap transactions.
Therefore, the Commission continues to believe that it is important for
registered SDRs to have policies and procedures providing for the
issuance of such UICs and is adopting a modified version of Rule
907(a)(5) that requires registered SDRs to establish written policies
and procedures ``[f]or assigning UICs in a manner consistent with [Rule
903].'' This is a conforming change to be consistent with the
Commission's decision to locate the substantive requirements for the
assignment of UICs in Rule 903.\660\ With respect to the comment
received, the Commission believes that market participants can work
with entities that are likely to register with the Commission as SDRs
on pilot programs for certain products and conventions for assigning
UICs. However, the Commission does not believe it would be appropriate
for the Commission itself to adopt such

conventions; the Commission believes instead that greater expertise in
coding data will reside in the industry and, in particular, at