Timeliness calculations - CFTC

What do the timeliness indicators mean?

• - an accepted message that was reported on time
• - any public message where there is more than 15 minutes left to report or any other type of message where there is more than 1 hour left to report
• - any public message with less than 15 minutes to report or any other message where there is less than 1 hour left to report
• means the submission is late
• means calculating timeliness does not apply for the message
• means missing and/or invalid values were submitted for the fields needed to calculate timeliness

---

How is timeliness calculated? 

When a message is submitted to the repository, KOR calculates the time it was required to be submitted based on information provided on the message and the applicable regulations. 

A message be accepted AND validated to be on time. Submitting a message with rejections before the required submission timestamp does not count - the clean resubmission of that message will be considered on time only if it passes all validations before the required submission timestamp.

On Rejected messages, time Timeliness values are not present only if the required information was missing or invalid to calculate.

Business days

What is a business day?

CFTC Transaction Message: Creation Data timeliness

This logic applies to messages where:

• Message type = Transaction
• Action type = NEWT
• Event type ≠ PTNG

CFTC Transaction Message: Continuation Data timeliness

This logic applies to messages where:

• Message type = Transaction
• Action type ≠ NEWT
• Event type ≠ CORR

CFTC Public Message: Creation Data timeliness

This logic applies to messages where:

• Message type = Public
• Action type = NEWT
• Event type ≠ PTNG
• Mandatory clearing indicator = True
• Block trade election indicator /Large Notional Swap Indicator = True

note: calculations based on execution timestamp.

As the regulation requires public data to be reported ASATP but does not clearly define the "no later than" timeline, for trades that qualify for the block/large notional delay, KOR considers the message late if it is reporter after the prescribed delay time.

* end of day (EPT) on execution timestamp date unless executed on a non business day, then end of day (EPT) on the next business day

This logic applies to messages where:

• Message type = Public
• Action type = NEWT
• Event type ≠ PTNG
• Mandatory clearing indicator = False or Null (OR TRUE and [Clearing Exceptions And Exemptions Counterparty 1] or [Clearing Exceptions And Exemptions Counterparty 2] is populated)
• Block trade election indicator  /Large Notional Swap Indicator = True

note: calculations based on execution timestamp.

As the regulation requires public data to be reported ASATP but does not clearly define the "no later than" timeline, for trades that qualify for the block/large notional delay, KOR considers the message later if it is reporter after the prescribed delay time.

* end of day (EPT) on execution timestamp date unless executed on a non business day, then end of day (EPT) on the next business day

 

This logic applies to messages where:

• Message type = Public
• Action type = NEWT
• Event type ≠ PTNG
• Block trade election indicator  /Large Notional Swap Indicator = False

note: calculations based on execution timestamp.

* indicates is reported by a designed platform

CFTC Public Message: Continuation Data timeliness

This logic applies to messages where:

• Message type = Public
• Action type ≠ NEWT
• Action type ≠ CORR
• Block trade election indicator  /Large Notional Swap Indicator = any

note: calculations based on event timestamp.

Reporter Identifier	Counterparty 1 designation	Counterparty 2 designation	Required submission timestamp
Does NOT = CP1	any	any	15 min
= CP1	SD or MSP	any	15 min
= CP1	any	SD or MSP	15 min
= CP1	non-SD/MSP/DCO	non-SD/MSP/DCO	1 hr

CFTC Valuation Message:  timeliness

This logic applies to messages where:

• Message type = Valuation

CFTC Collateral Message:  timeliness

This logic applies to messages where:

• Message type = Collateral

How do I know if my message was late? 

KOR populates the following fields which are used/produced for timeliness:

• Message submitted timestamp    Date and time of the submission of the report to the trade repository. 
• Message processed timestamp    Date and time KOR SDR completed processing of the submission. 
• Message Required Submission Timestamp    KOR SDRs calculation of when the message is required to be reported. 
• Message Submission Late Indicator    Based on KOR's value in the field: Message Required Submission Timestamp, once the submission passes all validations, then KOR shall evaluate if the message was submitted late or not. 
• Message Submission Late Length    When KOR's value in the field: Message Submission Late, is "True" then KOR SRD shall calculate the length of time the message is late by.

When does the 15-minute reporting window begin ? 

In general, the regulation states that "The time delay for the real-time public reporting of a block trade or large notional off-facility swap begins upon execution".
Furthermore, "execution" is defined as "an agreement by the parties, by any method, to the terms of a swap that legally binds the parties to such swap terms under applicable law".
The above regulation together with the definition would imply that there be a formal agreement or confirmation between the two sides before the reporting window begins.