The Division of Trading and Markets of the Securities and Exchange Commission (“Commission”) has prepared the following responses to questions regarding regulatory reporting and public dissemination of security-based swap transactions under Regulation SBSR. These statements represent the views of the staff of the Division of Trading and Markets. They are not a rule, regulation, or statement of the Commission. The Commission has neither approved nor disapproved the statements. These statements, like all staff statements, have no legal force or effect: they do not alter or amend applicable law, and they create no new or additional obligations for any person.

Q1: Rule 901(j) of Regulation SBSR provides that the timeframe for reporting the information required under Rules 901(c) and 901(d) of Regulation SBSR is 24 hours after the time of execution of the security-based swap. However, the Commission has issued a No-Action Statement with respect to Regulation SBSR providing generally that, if registered SDRs and their participants follow the CFTC’s swap reporting and public dissemination protocols and apply those protocols to security-based swap reporting, there will not be a basis for a Commission enforcement action with respect to certain provisions of Regulation SBSR that differ from the CFTC’s reporting and public dissemination rules (Parts 45 and 43, respectively).[1] May a person who has a duty to report a transaction avail itself of both the 24-hour reporting deadline provided in Rule 901(j) as well as the No-Action Statement?

A1: The Commission’s No-Action Statement regarding Regulation SBSR was premised on the idea that most security-based swap market participants are also participants in the swap markets, and have invested in systems and developed policies and procedures to satisfy the swap reporting requirements imposed by CFTC rules. Furthermore, the Commission stated that it was “mindful of the time and costs that may be incurred by swap data repositories and swap market participants to implement aspects of the SBS reporting rules that have no analog in, or are not wholly consistent with, the swap reporting rules,”[2] particularly in view of the fact that the CFTC had proposed significant amendments to those rules and significant time and costs would be incurred to comply with those amendments.[3] Under the CFTC rules, a swap transaction must be reported as soon as practicable after the time of execution.[4] Under the CFTC’s approach, market participants are not permitted to “hold” a swap transaction or run a “timer” to delay reporting it. The staff understands, however, that certain market participants are considering changing their systems to hold a transaction report of a security-based swap for up to 24 hours after execution before reporting it to a registered SDR, availing themselves of the No-Action Statement and reporting the security-based swap using the protocols developed for swap reporting but under the timeframe set forth in Regulation SBSR instead of the timeframe prescribed by CFTC rules and referenced in the No-Action Statement. In the staff’s view, such practice would be inconsistent with the No-Action Statement. Accordingly, if the staff discovers after 8 November 2021 that market participants are taking this approach, the staff will consider recommending remedial action to the Commission, up to and including that the Commission revise or even withdraw the No-Action Statement. [Modified: Oct. 21, 2021]

Q2: Rule 901(e)(1)(ii) of Regulation SBSR requires a registered clearing agency to report whether or not it has accepted a security-based swap for clearing. Rule 901(e)(2) requires all reports of life cycle events (including the termination of an alpha transaction by a registered clearing agency) to include the transaction ID of the original transaction. Rule 901(a)(3) requires the reporting side for the alpha transaction also to provide the registered clearing agency with the transaction ID of the alpha and the identity of the registered SDR to which the alpha has been reported. If the reporting side of an alpha fails to provide the transaction ID and the SDR identity to the registered clearing agency, would the registered clearing agency be in violation of Rule 901(e)(1)(ii) for failing to report whether or not it has accepted the alpha for clearing?

A2: Rule 906(c) requires various registered entities that have duties under Regulation SBSR, including registered clearing agencies, to establish, maintain, and enforce written policies and procedures that are reasonably designed to ensure that they carry out those duties. For a registered entity that is also a self-regulatory organization (“SRO”), such policies and procedures generally are submitted to the Commission as proposed rules under Rule 19b-4. One of the duties of a registered clearing agency is to report to the SDR that received an alpha transaction whether or not the clearing agency has accepted the alpha for clearing. The clearing agency is reliant on its clearing member to provide the transaction ID of the alpha and the SDR identity. Therefore, the clearing agency should adopt rules reasonably designed to ensure that its members provide the transaction ID and the SDR identity for each alpha. It could occur that a member fails to carry out its duties under such a rule. Nevertheless, a registered clearing agency is an SRO under the Exchange Act and, as such, is required (absent reasonable justification or excuse) to enforce compliance by its members with the duties stipulated in its own rules. Question 14 below also addresses this topic. [Modified: May 23, 2024]

Q3: Do “retail” security-based swaps have to be reported to a registered SDR?

A3: Yes. In recent years, the Commission has settled enforcement actions against certain platforms because the products they offered to retail investors were security-based swaps, and these platforms were charged with failing to follow the Commission’s rules regarding security-based swaps. Platforms that offer retail security-based swaps must be cognizant of all applicable Title VII requirements, including the trade reporting requirements under Regulation SBSR. Beginning on 8 November 2021, all new security-based swaps must be reported to a registered SDR, even those that are developed and sold as part of a “retail” program. In addition, Rule 901(i) of Regulation SBSR imposes a duty to report all historical security-based swaps (which term includes any security-based swap executed after the date of enactment of the Dodd-Frank Act, which was 21 July 2010). [Modified: Oct. 21, 2021]

Q4: A security-based swap is executed on 7 November 2021 (i.e., before Compliance Date 1). The parties effect a life cycle event to this transaction on 8 November 2021. Does the life cycle event need to be reported before Compliance Date 3 for the reporting of historical security-based swaps (i.e., 14 April 2022)?

A4: Historical security-based swaps must be reported by Compliance Date 3, not on Compliance Date 3. A registered SDR may offer the functionality to its participants to begin reporting historical security-based swaps before Compliance Date 3. If the reporting side to the security-based swap in the example elects to report the security-based swap before Compliance Date 3, the duty to report life cycle events is triggered by the reporting of the historical security-based swap. If the reporting side elects not to report the security-based swap until Compliance Date 3, the duty to report life cycle events associated with that security-based swap will not trigger until after Compliance Date 3. [Modified: Oct. 21, 2021]

Q5: Firm A and Firm B entered into a security-based swap in June 2014. Firm A registers with the Commission as a security-based swap dealer in October 2021; Firm B is not required to register and does not register as a security-based swap dealer. Who has the duty to report the June 2014 security-based swap?

A5: Firm A, because it is a security-based swap dealer. [Modified: Oct. 21, 2021]

Q6: Firm A and Firm B entered into a security-based swap in June 2014. Both Firm A and Firm B register with the Commission as security-based swap dealers. In June 2014, when the transaction was negotiated, neither firm knew whether it would register as a security-based swap dealer and neither side made any arrangement for which side would incur the duty to report by the required date for historical security-based swaps. The firms believe that it would be difficult presently to select which side will be the reporting party for the June 2014 security-based swap and other historical security-based swaps between them. May each firm simply report all of the historical security-based swaps to which it is a party, even if that results in double-reporting (i.e., the same transaction is reported by both Firm A and Firm B)?

A6: No. The firms must select which side will be the reporting side, and only the reporting side may report the trade. [Modified: Oct. 21, 2021]

Q7: Firm A and Firm B are both non-U.S. persons and both have affiliated U.S. personnel. On June 1, 2017, they executed a security-based swap. However, in anticipation of Compliance Date 3, neither side is sure whether its personnel were involved in arranging, negotiating, or executing that particular security-based swap. Does the transaction have to be reported at all? If so, which side is the reporting side?

A7: Both sides must examine their records to ascertain whether any of their U.S. personnel were involved in arranging, negotiating, or executing the transaction. If one side (assume Firm A) can confirm that its personnel were not involved in arranging, negotiating, or executing the transaction—or that it has no records available that can answer that question—that side has no duty under Regulation SBSR with respect to that transaction. If one side (assume Firm B) does confirm that its personnel were involved in arranging, negotiating, or executing the transaction, that side should consult the other side (Firm A). If Firm A reports that its personnel did not arrange, negotiate, or execute the transaction, or that records that can answer that inquiry are not available, then Firm B is the reporting side. If Firm A and Firm B both utilized U.S. personnel to arrange, negotiate, or execute the transaction, they must select which will be the reporting side. [Modified: Oct. 21, 2021]

Q8: A non-U.S. person who is guaranteed by a U.S. person that is a security-based swap dealer executes a security-based swap with a person who is relying on the exception to the de minimis counting requirements for transactions that are arranged, negotiated, or executed by U.S. personnel (i.e., is a “relying entity”) and the relying entity is in fact using U.S. personnel to arrange, negotiate, or execute the particular transaction. Who is the reporting side?

A8: The relying entity would be the reporting side. As discussed under the first numbered item in the Commission’s No-Action Statement regarding Regulation SBSR,[5] the Commission will not have a basis for an enforcement action if a person with a duty to report a transaction under Rule 901(a) of Regulation SBSR would not have the duty to report in a comparable scenario under the CFTC’s rules in force at the time. The staff understands that the CFTC’s swap reporting rules do not take into account, when assigning the duty to report a swap transaction, whether a counterparty is guaranteed or the registration status of the guarantor.[6] Therefore, the non-U.S. person (although guaranteed by a U.S. person) has no duty to report the security-based swap, and the duty falls to the relying entity.[7] [Modified: Oct. 21, 2021]

Q9: I am aware of the Commission’s No-Action Statement, which expresses the Commission’s general approach that, if market participants follow CFTC reporting protocols for the pendency of the Statement, the Commission would not bring an enforcement action for not complying with SEC-specific rules enumerated in the Statement. In certain matters, the CFTC rule in Part 43 or Part 45 is not clear, but the rule has been clarified by interpretive guidance issued by the CFTC staff. If I follow the CFTC staff’s interpretive guidance, will I be viewed by the Commission staff as adhering to the CFTC reporting protocols?

A9: Yes. [Modified: Oct. 21, 2021]

Q10: Rule 901(c)(1) of Regulation SBSR requires the reporting side to report the product ID, or the information required to be reported by Rule 901(c)(1) if no product ID is available or if the product ID does not include such required information. For purposes of Rule 901(c)(1), if a security-based swap references customized baskets, may a reporting party list “Basket,” “Bespoke,” or a similar generic identifier as the product ID?

A10: No. Rule 901(c)(1) requires the reported information for each security-based swap to include, among other things, “the specific underlying reference asset(s), reference issuer(s), or reference index.” The underlier information could be embedded in a product ID, but if a product ID is not available or if the product ID does not include the underlier information to that degree of granularity, then Rule 901(c) requires reporting of all of the underlying assets, issuers, or indices.[8] The No-Action Statement with respect to Regulation SBSR does not address the requirements of Rule 901(c)(1).[9] Further, Rule 902(a) requires a registered SDR to publicly disseminate, for each transaction, the primary trade information required to be reported by Rule 901(c).[10] The fact that the reportable security-based swap might be based on a customized narrow-based basket that a counterparty deems proprietary does not affect the requirement to report the individual assets, issuers, or indices in the custom basket, and for the registered SDR to disseminate, among other things, all of the components of the basket.[11] [Modified: Aug. 11, 2022]

Q11: Who is the staff contact at the Commission for Regulation SBSR questions or to communicate security-based swap data reporting issues?

A11: Questions regarding Regulation SBSR, as well as notifications of reporting issues, can be sent to regsbsr@sec.gov. [Modified: Aug. 11, 2022]

Q12: Can a security-based swap be modified or amended from a positive notional amount to a zero notional amount and then amended back to a positive notional amount, all under one unique transaction identifier (“UTI”)?

A12: No. As the Commission has stated, “[a] termination represents the change in the notional amount of the transaction from a positive amount to zero.”[12] Accordingly, if a security-based swap is modified or amended from a positive notional amount to zero, based on an exercise of discretion and not through predetermined criteria or a predetermined self-executing formula(s), such modification or amendment would be considered a termination of the security-based swap transaction. Subsequent security-based swaps with a positive notional amount exposure with the same counterparty are new security-based swaps requiring new UTIs.[13] [Modified: May 23, 2024]

Q13: With respect to pricing and payment data for credit swaps, is it sufficient to report only one of the following data elements – fixed rate, spread, or other payment type of upfront payment – if the transaction also includes one or both of the other elements (e.g., only report information for the fixed rate data element even though the transaction also includes an upfront payment)?

A13: No. In the staff’s view, relevant pricing and payment information must be submitted to the SBSDR. Each SBSDR registered with the Commission also is registered with the CFTC as a swap data repository (“SDR”) and applied for SEC registration representing that it intends to rely on the No-Action Statement. Furthermore, Rule 901(h) requires a person having a duty to report information under Regulation SBSR to electronically transmit that information to an SBSDR in a format required by the SBSDR.[14] Given the position taken by the Commission in the No-Action Statement, staff understands that security-based swap transaction data is being reported to SBSDRs consistent with the requirements of the CFTC Technical Specification.[15] In order to meet the validation rules under the CFTC Technical Specification that have been implemented by SBSDRs, a reporting side must report “at least” one of these three data elements: (1) fixed rate; (2) spread; or (3) other payment type of upfront payment.[16] However, that is a minimal requirement, for purposes of reporting validation, that must be met for a record to be accepted by an SDR or, in this case, an SBSDR.[17] Consistent with that principle, the CFTC Technical Specification explains that various data elements related to payments are “reported multiple times in the case of multiple payments.”[18] Moreover, the CFTC Technical Specification explicitly states that a “data element may be reported for scenarios outside of what is listed in the validation rules column,” and explains that data elements that are “Optional” for validation purposes “shall be reported if applicable for the transaction.”[19] The CFTC Technical Specification also states that information on upfront payments would be submitted in the “Other payment type” field, and defines upfront payment as “the initial payment made by one of the counterparties either to bring a transaction to fair value or for any other reason that may be the cause of an off-market transaction.”[20]

It is common market practice for certain credit default swaps to require fixed rate payments. For example, in some markets, the fixed rate payments (i.e., the coupon payments) are customarily set at one percent for investment grade debt and five percent for high yield debt. However, these credit default swap transactions often also include upfront payments that are exchanged between the counterparties to bring the transaction to fair market value at the inception of the transaction. Given the reliance by SBSDRs on the No-Action Statement and the implementation by SBSDRs of the CFTC Technical Specification, in this situation, the data submitted to the SBSDR by market participants must include information for the fixed rate payment and other payment type (e.g., upfront payment) data elements so that the data reported includes sufficient information to calculate the fair value of the transaction (i.e., the conventional spread), as contemplated by the description of the “Other payment type” field.[21] This is also consistent with what the Commission stated when adopting Rule 901(c)(2) of Regulation SBSR, observing “that information concerning the amount(s) and currenc(ies) of any up-front payment(s) will help regulators and market observers understand the reported price of a security-based swap, and that the public dissemination of this information will further the transparency goals of Title VII.”[22] If a transaction includes both types of payments (e.g., fixed rate and upfront payments), only submitting the fixed rate information (i.e., the data submitted to the SBSDR only includes the fixed rate payment), or only submitting the upfront payment, would lead to incomplete information regarding the fair value of the transaction. [Modified: May 23, 2024]

Q14: As a follow-up to question 2 above, what are the obligations of the reporting side of an alpha transaction with respect to providing the registered clearing agency with information regarding the original transaction? If an alpha trade is submitted for clearing but is not accepted for clearing, what are the obligations of the reporting side of an alpha transaction with respect to Rule 901(c)(6), which requires submission of information that the SBS will be submitted to clearing?

A14: Staff reiterate the obligation, pursuant to Rule 901(a)(3), for the reporting side of an alpha transaction to provide the registered clearing agency with the transaction ID of the original transaction, pursuant to the clearing agency’s rules, which are required to be reasonably designed to ensure that its members provide the transaction ID and the SBSDR identity for each alpha transaction. Additionally, pursuant to Rule 901(c)(6), it is staff’s view that for an alpha trade that is not accepted for clearing, the reporting side of the alpha transaction generally would be expected to update the information submitted to the SBSDR to indicate that it is no longer an “intent to clear” transaction, if applicable. [Modified: May 23, 2024]