Appendix B
| No: 42056371 | Date(g): 23/3/2021 | Date(h): 10/8/1442 | Status: In-Force |
| List of reportable life cycle events for OTC derivative transactions: | ||||||||||||||||||
| ||||||||||||||||||
Depending on the action type that is reported and populated in table 2: item 52 “Action type”, fields may have adopted any of the following status: | ||||||||||||||||||
| • | Mandatory (M): the field is strictly required and validations of format and content are applied. | |||||||||||||||||
| • | Conditionally mandatory (C): the field is required if the specific conditions set out in the validation rules are met. Format and content validations are applied as well. | |||||||||||||||||
| • | Potential (P): the field shall be populated if applicable depending on the transaction characteristics or to the reported life cycle event (for modifications and or corrections all fields, except those that are mandatory regardless the reported life cycle event, could potentially be modified or corrected and therefore populated). Only format and content validations are applied when the field is populated. | |||||||||||||||||
| • | Not relevant (-): the field shall be left blank. | |||||||||||||||||
List of life cycle events reporting scenarios for OTC derivative transactions:
1. Submission of a new trade with no available “Unique trade ID” generated by the international generating entity
In cases of a transaction between a KSA Bank and a foreign counterparty, if at the regulatory deadline to submit a new trade (T+1), table 2 item 15 “Unique trade ID” is not informed by the international generating entity, the field can be provisionally left blank. In such cases, once the Trade ID is informed, a Modification report (table 2 item 53 “Action type” populated with “M”) must be submitted by the reporting counterparty in order to populate the "Unique trade ID" informed by the international generating entity.
2. Modifications to the terms of a contract
When both counterparties agree to modify any of the terms of an OTC derivative contract, the reporting counterparty shall submit a modification report (table 2 item 53 “Action type” populated with the value “M”) in which, besides additional applicable validation rules described in this document, table 2 item 14 “Internal unique trade ID” shall be populated with a code that is fully coincident with a previously reported “Internal unique trade ID”. The “Internal unique trade ID” cannot be subject to modification.
In cases where the aim of the modification is to turn blank a previously populated field, the field in question shall be populated with the value “null”.
3. Novations
For reporting purposes, in cases of novations to the original report relating to the existing derivative, the reporting counterparty should send a termination report (table 2 item 53“Action type” populated with the value “C”). The reporting counterparty should then send a new report with table 2 item 53 “Action type” populated with the value “N” relating to the new derivative contract arisen from the novation.
This is applicable to trades that are novated for the purpose of clearing a certain trade in a CCP. In such case, the original trade (pre-novation) shall be reported in T+1 with table 2 item 53 “Action type” populated with the value “N” and once it is novated the reporting counterparty should send a termination report (table 2 item 53 “Action type” populated with the value “C”) and submit a new report with table 2 item 53 “Action type” populated with the value “N” relating to the new derivative contract arisen from the novation. In the case that the novation takes place before T+1, the reporting counterparty shall only submit a single report (post-novation) with table 2 item 53 “Action type” populated with the value “N” and table 1 item 2 “ID of the other Counterparty” populated with the LEI of the CCP.
4. Detection of an error in an already submitted report
If the reporting counterparty (or the other counterparty upon communication to the reporting counterparty) detects that a report (no matter its nature or “Action type”) was submitted by error, the reporting counterparty is required to submit an error report (table 2 item 53 “Action type” populated with the value “E”) in order to eliminate the erroneous report. besides mandatory fields described in the first bullet of this paragraph, table 2 item 14 “Internal unique trade ID” shall be populated with a code that is fully coincident with a previously reported “Internal unique trade ID”.
5. Submission of an early termination report
In the case that a trade ends before reaching its original maturity date, the reporting counterparty shall submit an early termination report (table 2 item 53 “Action type” populated with value C”). Besides mandatory fields described in bullet 1 of this paragraph, table 2 item 27 “Early termination date” shall be populated. Furthermore, table 2 item 14 “Internal unique trade ID” shall be populated with a code that is fully coincident with a previously reported “Internal unique trade ID”. The “Internal unique trade ID” cannot be subject to correction.
6. Notional increase or decrease
For reporting purposes, in the event of an increase or decrease in the notional amount of an existing contract (partial termination but not fully close-out), the reporting counterparty shall submit a modification report (table 2 item 53 “Action type” populated with the value “M”) modifying the “Notional” (table 2 item 19).
7. Correction of a previously submitted report
If the reporting counterparty (or the other counterparty upon communication to the reporting counterparty) detects an incorrectly reported field, the reporting counterparty shall submit a correction report (table 2: item 53 “Action type” populated with the value “R”) in which, besides additional applicable validation rules described in this document, Table 2 item 14 “Internal unique trade ID” shall be populated with a code that is fully coincident with a previously reported “Internal unique trade ID”. Only mandatory and the corrected fields shall be populated.
8. Valuation update
Valuation update reports shall be submitted on a daily basis. Besides additional applicable validation rules described throughout this document, Table 2 item 14 “Internal unique trade ID” shall be populated with a code that is fully coincident with a previously reported “Internal unique trade ID”.
9. FX Overnight trades
FX spot (D+2) and FX overnight trades (D+1) are not considered OTC derivatives, so they are not required to be reported.
10. Backloading requirement for reporting entities
In order to meet regulatory needs and to reduce the substantial and costly adjustments that reporting entities need to make to comply with the backloading requirement, OTC derivatives transactions on Equity, Credit and Commodity asset classes that are still outstanding as of the effective date (June 1st 2021), will need to be submitted through new reports (table 2 item 53 “Action type” populated with value “N”). For Backloading purposes, reporting Bank must also report transactions which matured between January 1st 2021 and May 31st 2021. Reporting must be completed by the effective date.
After the submission of each new report, the updated valuation of the contract (table 2 item 53 “Action type” populated with value “V”) should start to be reported on a daily basis as well. See applicable rules described in the “Scope of Reporting” in this document in order to identify the counterparty of the transaction that is subject to the reporting-backloading obligation for each legacy trade.
OTC derivatives transactions on Equity, Credit and Commodity asset classes whose maturity date had been reached before December 31st 2020, will not be subject to the backloading obligation.
11. Reporting of Waad OTC derivatives
"Arbun" derivatives should be identified and reported like a call/put option.
Any Waad OTC derivative must be reported to SATR on the agreement date as a Forward, informing about the expected “effective date”, “settlement date” and “expiration date”. If the transaction is not to be settled an early termination (“C”) event must be reported as soon as the reporting counterparty is certain of it. If the transaction is finally settled but with a different “effective date”, ”settlement date” or “expiration date” or any other previously reported field, a modification (“M”) event must be reported.