Backdated Reporting

Reconciliation Points

Status: Best Practice Finalised, Last Updated: 15/02/2024

Question:
Reconciliation Points:

1. Reconciliation is based on positions and not transactions (hence on the TSR - trade state report and not the TAR - trade activity report).
2. All eligible for reconciliation submissions are paired first.
3. Positions that were open and naturally matured or terminated during the outage will appear in latest reconciliation up until 30 days but not on the TSR.
4. Currently in BAU, post maturity or termination of an outstanding position, the respective position drops off TSR, but remains in the reconciliation report 30 days from the day of maturity OR termination. So provided that both parties submit their respective historical alleges at the same time, the respective positions will drop off TSR and if they fall in the 30-day reconciliation post maturity/termination interval the two alleged positions will appear in the reconciliation report until 30 days.

Best Practice:
(SFTR-820)

Pairing & Matching Process

Status: Best Practice Finalised, Last Updated: 15/02/2024

Question:

Understanding the trigger for the “pairing & matching process”

1. 1. The transaction state report (sometimes called the TSR or trade state report) is the input to the pairing & matching process.
2. 2. The TAR Trade Activity Report (ESMA call this the DAR - daily activity report) is all submissions accepted by the Trade Repository for a given day, not all submissions update the TSR.
3. 3. The TAR is not the input to the Pairing & Matching process.
4. 4. All eligible for reconciliation submissions are paired first.
5. 5. The reconciliation process pairs and matches positions. The reconciliation process at DTCC therefore includes the following stages:

   • Intra-TR Pairing: This process locates the other side of the trade or collateral, based on the unique keys defined within DTCC’s TR. Pairing is based on the three fields when an accepted submission is first made for a particular trade with that unique key, Reporting Counterparty, Other Counterparty, and Unique Transaction Identifier.
   • Intra-TR Matching: If the other side of the trade is located (paired) within DTCC’s TR, the reconcilable fields on both records are compared and the outcome is provided.
   • Inter-TR Pairing: If the other side of the trade or collateral is not located within DTCC’s TR, the TR attempts to locate this information at the other registered TRs, based on the unique key (Reporting Counterparty + Other Counterparty + Unique Transaction Identifier).
   • Inter-TR Matching: If the other side is located (paired) at another TR, the reconcilable fields on both records are exchanged and compared. The outcome is then provided.
   • The trade is assigned a status of Unpaired if the other side of the trade cannot be located. Both the loan and any linked collateral are excluded from the reconciliation process for trades with a status of Unpaired.
   • The reconciliation process therefore is made up of Pairing and then Matching.

Best Practice:
(SFTR-821)

BDR NEWT/ETRM Summary

Status: Best Practice Finalised, Last Updated: 15/02/2024

Question:
Summary: NEWT / ETRM:

• Note where references to DTCC event date vs. reporting date logic in this context takes place it means that the logic is checking to see if the ED is one day prior to the RD or greater than one day.

• This is important as where reporting no more than one day after the ED, certain action types hit the TSR, if not, then only the TAR would be hit.

NEWT / ETRM:

• T vs. T+1 Submissions

• Assuming both sides of the trade have to report and both submission dates are the same.

• Where submission dates are not the same the field populations would need to match.

• Where fields do not match on different submission dates trades can end up paired but not matched on the TSR report, this is because the TR currently compares the event date from day 2 and not on day 1.

• Once both sides of the trade are terminated with an ETRM then both will be removed off of the TSR and appear on the latest reconciliation report for 30 days.

• ED - Event Date

• RD - Reporting Date

• NEWT:

• Action type with an historical ED (being 22.1.24) and a current RD (being 7.2.24) and also with a current ED (being T) and a current RD (being T+1) will:

• Hit the TAR

• Hit the TSR

• Pair (pairing both cptys to one UTI)

• Match (checking the fields for validation) and

• Be presented for reconciliation

• ETRM:

• Action type where positions opened and closed historically via ETRM will not appear in latest TSR may appear in Reconciliation report for a subsequent 30-days from day of termination.

• Latest TAR will be updated as normal.

• ETRM is applicable to matching.

• Termination date is a reconciled field, so if the parties send ETRMs for different termination dates (or one party sends ETRM and the other does not) they would see matching breaks in the TR reconciliation.

Best Practice:

(SFTR-822)

BDR MODI/CORR T+1:

Status: Best Practice Finalised, Last Updated: 15/02/2024

Question:
Historical submissions:
Summary: MODI / CORR: where ED is greater than +1 day prior to the RD:

· Note where references to DTCC event date vs. reporting date logic in this context takes place it means that the logic is checking to see if the ED is one day prior to the RD or greater than one day.
· This is important as where reporting is no more than one day after the ED, certain action types hit the TSR; if not, then only the TAR would be hit.

Historical Submissions:

MODI / CORR:

· T vs. T+1 Submissions
· Assuming both sides of the trade have to report and both submission dates are the same.
· Where submission dates are not the same the field populations would need to match.
· Where fields do not match on different submission dates trades can end up paired but not matched on the TSR report, this is because the TR currently compares the event date from day 2 and not on day 1.
· Once both sides of the trade are terminated with an ETRM then both will be removed off of the TSR and appear on the latest reconciliation report for 30 days.

· ED - Event Date
· RD - Reporting Date

· MODI & CORR:
· Action types with an historical ED (being 22.1.24) and a current RD (being 7.2.24) will:
· Hit the TAR
· Will not Hit the TSR
· Possible to Pair (pairing both cptys to one UTI driven by initial NEWT)
· MODI & CORR's that do not have a current ED and RD where the ED is only +1 day prior to the RD will impact the successful matching and reconciliation reports.
· Historical event dates on MODI/CORR will be ACK’d as long as the modification is not on a maturity date.
· Any historical MODIs/CORRs to update maturity date would not be ACKNOWLEDGED; the T+1 event date logic is required here hence ED has to be +1 day prior to RD.

Best Practice:
(SFTR-823)

BDR MODI/CORR greater than T+1:

Status: Best Practice Finalised, Last Updated: 15/02/2024

Question:

Summary: MODI / CORR: where ED is only +1 day prior to the RD:

· Note where references to DTCC event date vs. reporting date logic in this context takes place it means that the logic is checking to see if the ED is one day prior to the RD or greater than one day.
· This is important as where reporting is no more than one day after the ED, certain action types hit the TSR; if not, then only the TAR would be hit.

Current Submissions:

MODI / CORR:

· T vs. T+1 Submissions
· Assuming both sides of the trade have to report and both submission dates are the same.
· Where submission dates are not the same the field populations would need to match.
· Where fields do not match on different submission dates trades can end up paired but not matched on the TSR report, this is because the TR currently compares the event date from day 2 and not on day 1.
· Once both sides of the trade are terminated with an ETRM then both will be removed off of the TSR and appear on the latest reconciliation report for 30 days.

· ED - Event Date
· RD - Reporting Date

· MODI & CORR:
· Action types with an current ED (being T) and a current RD (being T+1) will:
· Hit the TAR
· Hit the latest TSR (once an ETRM is actioned and places the trade on the 30-day Reconciliation Report it should show the latest picture which would have been driven by the MODI or CORR action)
· Pair (pairing both cptys to one UTI)
· Match will take place (checking the fields for validation) and
· Be presented for reconciliation

Best Practice:
(SFTR-824)

Trade State Report Summary:

Status: Best Practice Finalised, Last Updated: 15/02/2024

Question:
TSR - Trade State Report priority - In short:

Where firms can get a replayed post outage NEWT report submitted on the same day as their cpty and in both cases where the ED is one day prior to the RD or even if the ED is greater than 1 day prior to the RD and, where firms can send a MODI with an ED that is only +1 day prior to the RD - this will bring the TSR up to date, will allow for pairing, matching and be presented for reconciliation to take place from that date.

· Historical NEWTs will appear on TSR and Reconciliation and TAR
· Historical MODI/CORR will NOT appear on TSR and Reconciliation BUT will appear in TAR.
· MODI/CORRs with T+1 logic intact will appear on TSR and Reconciliation and TAR

Best Practice:
(SFTR-825)

BDR COLU Reports:

Status: Best Practice Finalised, Last Updated: 15/02/2024

Question:
COLU Reports for collateral:

1. As COLU updates are not “delta” reports (they are outstanding balance reports) and all relevant collateral data fields within the range 2.75 to 2.94 must be repeated in each collateral update report, even if only one of these fields has changed.
2. Typically MODI's or CORR's are not used to correct or update COLU message by sending a latest COLU message report will overwrite the previous COLU message report, this means COLU messages for back reporting should be easier to send than MODI and CORR reporting messages as explained above.
3. COLU message (Net or Trade) also follow the event date +1 logic for TSR/Reconciliation population.
4. For trade-based collateral your event date must be less than the value date on the collateral message for the submission to be ACKNOWLEDGED
5. If the COLU submission does not abide by the event date + 1 logic, the COLU will not appear on TSR and Reconciliation BUT will appear in the latest TAR

Best Practice:
(SFTR-826)

One or Two-sided reconciliation?

Status: Best Practice Finalised, Last Updated: 15/02/2024

Question:
Two-sided reporting requiring reconciliation:

Raising Awareness:
1. When assessing your individual firm challenges to report its worth thinking about is your reporting vs. your cpty two sided or one sided.
2. In the spirit of the SFTR regulation all "back reporting" should be done whether this is one sided or two sided.
3. One sided reports will not be paired, matched, or be presented for reconciliation.

Best Practice:
(SFTR-827)

a) Trades open before outage and remain open during outage:

Status: Best Practice Finalised, Last Updated: 15/02/2024

Question:
a) Trades open before outage and remain open during outage:

As best practice when submitting any back reporting agree the Reporting Date bilaterally with your cpty so T or T+1. Trades not sent at the same time and date will not pair and match, not hit the TSR or be presented for reconciliation.

1. 1. The backlog of new trade reports will automatically be recorded in the first Trade State Report via the first reported NEWT to be compiled after resumption of service.
2. 2. The first NEWT report with no subsequent lifecycle events and with an historic ED - Event Date and a current RD - Reporting Date will populate the TAR report, the TSR report and trigger the pairing & matching process and be presented for reconciliation.
3. 3. Lifecycle events would not have been sent on trades that were open prior to the outage and remain open during the outage.
4. 4. Where full lifecycle events in chronological order can be replayed by current systems then firms can make that decision and bilaterally agree this with their cptys.
5. 5. Upon lifecycle events being reported via a MODI or CORR action type and where the ED - Event Date is greater than +1 day prior to the RD - Reporting date this will hit the TAR report. This is an example where the trade could pair (pairing both cptys to one UTI - as driven by the initial NEWT) but not match (checking the fields for validation) and thus not reconcile. You cannot get to matching & reconciliation via hitting a TAR report only a TSR report.

   • Historical event dates on MODI will be ACK’d as long as the modification is not on a maturity date.
   • Only MODIs that meet the T+1 event timeframe will be reflected on the TSR/Reconciliation reports; those that do not meet the requirement will not update TSR/Reconciliation.
   • Any historical MODIs to update maturity date would not be ACKNOWLEDGED; the T+1 event date logic is required here.

6. 6. Where alternative reporting system methods are used, maybe best to report the first NEWT with no subsequent lifecycle events as this updates the TSR and then each day on-going where internal systems allow for a daily MODI or CORR this will update the TSR report automatically.
7. 7. However, where systems do not allow for a daily MODI or CORR action type firms will have to manually effect a MODI or CORR with the latest ED - Event Date and RE - Reporting Date. This "rectifier" MODI/CORR action will update the TSR and trigger the pairing & matching process and be presented for reconciliation. This also is mentioned under ESMA Q&A 6(a)) this is where the latest is greatest statement comes to life.

Best Practice:
(SFTR-828)

b) Trades open before outage and close during outage:

Status: Best Practice Finalised, Last Updated: 15/02/2024

Question:
b) Trades open before outage and close during outage:

1. 1. For OPEN trades that are terminated or matured during the outage downtime, it will be possible to retrospectively terminate them.
2. 2. Terminating open trades is the only action that can retrospectively change Trade State Reports (see Q&A 7(c)).

   • Note here you are sending an ETRM on an OPEN trade not a trade that already has a populated maturity date and trying to modify or amend that - see Maturity Date Trades section.

3. 3. To be clear here the ETRM works similarly to the NEWT with no subsequent lifecycle events meaning, you can report an ETRM with an historic ED - Event Date and a current RD- Reporting Date and this will be ACK'd.

   • An ETRM can be submitted with a historical event date however it will not appear on the latest TSR as the position wont exist anymore, however it will show up on the reconciliation for 30 days per existing logic.
   • Note that the event date on ETRM should be less than or equal to the termination date in order for the submission to be ACK’d.

Best Practice:
(SFTR-829)

c) Trades open during the outage and closed during the outage:

Status: Best Practice Finalised, Last Updated: 15/02/2024

Question:
c) Trades open during the outage and closed during the outage:

1. 1. As best practice, agree the Reporting Date bilaterally with your counterparty (cpty) for T or T+1. Trades not sent at the same time and date will not pair and match, not hit the TSR or be presented for reconciliation.
2. 2. If both cptys on both sides can send/report the NEWT on the same day (T or T+1), it should be acknowledged, paired, matched, and update the current trade state report. This example would be a historic event date with a current reporting date on a NEWT.
3. 3. Replayed lifecycles would have historic ED (Event Dates) with a current RD (Reporting Date) and would hit the TAR (trade activity report) only.

   • Where lifecycle events cannot be replayed, a MODI or CORR with a current ED (Event Date) and a current RD (Reporting Date) is required to update the latest TSR report, trigger the pairing & matching process, and be presented for reconciliation.

4. 4. ETRMS need to be submitted with a historical event date (based on actual term date) to be acknowledged with termination and event date aligned.
5. 5. Note that you are sending an ETRM on an OPEN or Fixed Term trade, not a trade with a populated maturity date you are trying to modify or amend.
6. 6. Overall Notes:

   • The key is reporting the NEWT and ETRM with the historic event date.
   • Firms can also report historic MODIs (prior to ETRM) with a historic event date for accurate back reporting/audit. No events are expected to hit TSR (as position is closed).
   • ETRMS should be reported with the actual term date for accuracy.

7. 7. Refer to comments already made under points a) and b) that are also relevant here.

Best Practice:
(SFTR-830)

d) Trades open during the outage and remain open after the outage:

Status: Best Practice Finalised, Last Updated: 15/02/2024
Question:
d) Trades open during the outage and remain open after the outage:

1. As best practice when submitting any back reporting agree the Reporting Date bilaterally with your cpty so T or T+1. Trades not sent at the same time and date will not pair and match, not hit the TSR or be presented for reconciliation.
2. "Stop the bleed”…replay new messages when new trades were booked during the outage.
3. If both cptys on both sides of the trade send the NEWT reports on the same day say T or T+1, then this should be ACKNOWLEDGED pair, match, and update the current trade state report. This would be a historic event date with a current reporting date on a NEWT.
4. If lifecycles can be replayed, they would have historic ED - Event Dates with a current RD - Reporting Date and would hit the TAR - trade activity report only which can only get to the pairing stage (pairing both cptys to one UTI) unless it's an orphan trade hence one sided due to other cpty not reporting or other cpty in a different regime i.e. FCA vs. ESMA.
5. Where lifecycle events cannot be replayed for some reason then a MODI or CORR current ED - Event Date is required with a current RD - Reporting Date to update the TSR report and trigger the pairing & matching process and be presented for reconciliation.
6. In short: Standalone NEWT with historical event date will ACK and will be included on the TSR, TAR and Reconciliation, any subsequent MODI must follow the T+1 logic to appear on TSR.

Best Practice:
(SFTR-831)

Maturity Date Trades

Status: Best Practice Finalised, Last Updated: 15/02/2024

Question:
Maturity Date Trades:

1. Note: This is different to point b) above, as point b) above relates to an OPEN trade when applying the first Maturity Date. This point here is where the trade already has one maturity date and you are trying to apply / modify another new maturity date to the same trade.
2. Historic MODIs should be submitted with a historic event dates however to hit the latest TSR you need to ensure the ED- Event Date is one day prior to the RD - Reporting Date. If ED - Event Date is +1 day greater than the RD - Reporting Date your report will NACK.
3. This means that any extension during the outage downtime of the maturity date of callable loans, dynamic end-date evergreens and extendibles can never be reported as they will automatically die off on the reported initial maturity date.
4. This will be the big challenge - if a maturity date has been hit it cannot be revived.
5. Historical event dates on MODI/CORR will be ACK’d as long as the modification is not on a maturity date.
6. Any historical MODIs/CORRs to update maturity date would not be ACKNOWLEDGED; the T+1 event date logic is required here hence ED has to be +1 day prior to RD.

Best Practice:
(SFTR-832)

What cannot be back reported?

Status: Best Practice Finalised, Last Updated: 15/02/2024

Question:
What cannot be back reported?

1. Fixed Term Trades where a Maturity Date has already been populated within the NEWT message that was already sent prior to the industry "outage" - see tab Fixed Term Trades with MAT with reported maturity date

Best Practice:
(SFTR-833)

ETRM - Termination Date vs. Maturity Date:

Status: Best Practice Finalised, Last Updated: 15/02/2024

Question:
ETRM - Termination Date vs. Maturity Date:

1. Termination date is not a reportable value via a MODI (modification) via the trade validation rules, and, as an ETRM cannot be reported on a future date it’s not possible to amend the termination date i.e. once an ETRM is reported, you can’t move it forward via an ETRM and you can’t amend it via a MODI therefore that date of termination is finalised.
2. Its important to highlight that once a trade has been terminated or matured parties (borrowers) risk being unable to back-report historic lifecycles so should incorporate this in decision making when considering best approach moving forward.
3. Table 2 within the level III guidelines show it is possible to do a MODI post an ETRM action type, however, it depends on what field you are modifying and as mentioned the ETRM - Termination field cannot be modified.

Best Practice:
(SFTR-834)

CORR Rules post ETRM - Termination Date:

Status: Best Practice Finalised, Last Updated: 15/02/2024

Question:
CORR Rules post ETRM - Termination Date:

1. DTCC has implemented an additional stateful validation rule that requires CORR messages to provide a Termination date when an ETRM has previously been submitted.
2. The Usage Guidelines published in January indicates that once a trade has been early terminated, it cannot be reinstated, therefore any CORR messages following an ETRM for the same trade will require the Termination date field to be populated.
3. DTCC will be rejecting a CORR message where Termination date is populated when an ETRM has not previously been submitted.
4. In other words, you cannot modify a termination date once an ETRM has been successfully submitted i.e. you cannot reinstate a terminated trade.
5. So a post-ETRM CORR action type can only correct fields (see trade validation rules) other than Termination Date. And ETRM is final.

Best Practice:
(SFTR-835)

ETRM Action post a Current Event Date and Reporting Date MODI:

Status: Best Practice Finalised, Last Updated: 15/02/2024

Question:
ETRM Action post a Current Event Date and Reporting Date MODI:

***Please be aware this is more of an operational work around. Ensure you check in with the appropriate personnel or compliance team to verify your comfort with this approach. Objective is to reflect the correct audit trail****
1. See diagrams for visual on how to report a NEWT (pre or post outage), historical MODI, a current MODI and an ETRM
2. The main point here to be aware of is if post a NEWT you do a Historical MODI then a Current MODI, then an ETRM, the ETRM although reported with a historic event date and current reporting date will pick up the latest picture from the current MODI, remove this from the trade state report and place this current picture onto the 30-day reconciliation report.
Note: A position is reconciled throughout its life span, which is in this case the current MODI as it is the latest position reflected in TSR, it will further appear in recon report for 30 days after it has been terminated.
3. If you do not perform the current MODI in this sequence of events and your cpty does you could pair but you will not match and thus reconcile, this is why guidance is being given to check in with the right personnel.

Best Practice:
(SFTR-836)

Agency Lending Example:

Status: Best Practice Finalised, Last Updated: 15/02/2024

Question:
Agency Lending Example:

This is an example where back reporting is lost in translation:

1. 1. AL sends borrower allocation A for a new trade on the last day pre-outage (Day 1).

   • Trade remains open through outage and borrowers sends daily VALU, COLU or MODI reports to that trade using allocation A’s LEI and UTI throughout the outage (let's say that’s Day 2 through Day 20).
   • On resumption of service it turns out Allocation A was reallocated out of the trade early in the outage and replaced with Allocation B with a new UTI And LEI (Day 3 let's say).
   • Even if back reporting is correctly done it means the borrower will be sending a ETRM for Allocation A back dated to Day 3 but they will already have sent/reported previously VALU, COLU and MODI messages on the trade for days 4, 5,6 etc. all the way through, to Day 20.

     • There does not seem any obvious validation rules that would stop the ETRM for allocation A being submitted with event date of Day 3.
     • Its not obvious to suggest the previous data will be automatically cleared up so effectively would have a trade in the TR with a ETRM of Day 3 but lifecycle events all the way through to Day 20.
     • From a regulators perspective if they were to go back through the data using this example, they would see a trade opened, a few lifecycle events, a termination then many more days of lifecycle events dated after the trade closed. It could be asked what value this is.

   • 2. In this example its is suggested that it should be a case of the member highlighting how their reporting model worked during the outage. Even if the trade is not terminated regulators may highlight how MODI/VALU/COLU values were reported without the infrastructure in place for data transfer.

Best Practice:
(SFTR-837)

Options 1 & 2 for reporting + back dated thoughts:

Status: Best Practice Finalised, Last Updated: 15/02/2024

Question:
Options 1 & 2 for reporting + back dated thoughts:

1. 1. Option 1 going through current provider when up and running:

   • Respectful of all backdated events and trades in chronological order

     • 2. Option 2 some agent lenders have selected to go to an alternative route

       • In that case, alternative route offers a reporting on a go forward basis based on outstanding trades , so original size allocations are not in scope, however there is still a back reporting requirement:

         • If outstanding allocations, we can back report event date in the past that will update the TAR but not the latest TSR
         • If missed allocations we can update the TAR but not the latest TSR
         • For ETRM's where the trades are still open see point b) above
         • For ETRMs where a maturity date already exists see Maturity Date Trades section above.

Best Practice:
(SFTR-838)

SFTR Vendor solutions - Pairing & Matching:

Status: Best Practice Finalised, Last Updated: 15/02/2024
Question:

SFTR Vendor solutions - Pairing & Matching:

1. SFTR vendor solutions have Pre-Pairing & Matching procedures which from feedback to not affect or interfere with the trade repository pairing & matching procedures.
2. It’s also possible to send reports from one vendor and then into another prior to transactions being reported to the trade repository.
3. It seems Pre-matching platforms key pairing fields for the shell trade executed between the borrower and the agent should pair on following fields to get correct critical data for allocations reporting:
(1) Other counterparty LEI, (2) Reporting Counterparty LEI, (3) Agent Lender LEI, (4) Counterparty side, (5) Principal amount on value Date for Repos, (6) Security identifier for Securities lending, (7) security identifier for collateral, (8) Type of SFT, (9) Type of collateral component, (10) Quantity of Nominal Amount for securities lending
4. With a mix between asset manager and agent lender Collateral pairing criteria are:
(1) Other counterparty LEI, (2) Reporting Counterparty LEI, (3) Agent Lender LEI, (4) Signage of cash collateral amount or collateral quantity or nominal amount, (5) Security identifier, (6) Type of collateral component, (7) Collateralization of net exposure, (8) Collateral currency, (9) Master agreement

Best Practice:
(SFTR-839)