This article summarises the validation and processing changes that KOR will make to facilitate compliance with the updated Reporting Entity Guidance and Technical Guidance published in February 2025
ASIC published v1.1 of its Schedule 1 Technical Guidance and Reporting Entity Guidance and Minimum TR Validation Guidance on 7th February 2025, and compliance with the updated guidance is required no later than 1st August 2025.
These documents set out updates covering validation changes, clarifications, and corrections to the v1.0 guidance published prior to the ASIC go-live in October 2024. KOR is making changes to validation rules where the changes permit new fields and reporting patterns, and to facilitate the reporting of new fields. All changes are backwards compatible.
Price and Strike Price
ASIC has updated its guidance and validation requirements to permit Price to be left blank where Strike Price is provided for Commodity and Equity, to facilitate the reporting of non-Price Parameter Return Swaps such as Volatility or Variance Swaps. KOR is adjusting Price validation to match this practice.
Counterparty 1 and 2 Execution Agents
ASIC has added the optional field Counterparty 2 Execution Agent to support the identification of an additional entity on the transaction. KOR is adding this new field and amending validations on Counterparty 1 Execution Agent to allow the value NOAP where Counterparty 2 Execution Agent is Applicable with no Counterparty 1 Execution Agent value, as required by the ISO 20022 structure for Execution Agents.
Effective Date
ASIC has amended the minimum validations for Effective Date to allow Effective Date to be reported earlier than the date element of the Execution timestamp. This is intended to facilitate the reporting of transactions resulting from novation or clearing, where the novation or clearing event initiating the transaction occurs in the middle of an observation period for a reference rate or index on the pre-existing transaction.
In these circumstances, the observation period for the resulting transaction is expected to match the pre-existing transaction, implying an effective date before the execution timestamp. KOR is amending Effective Date validation to allow this date to fall earlier than the Execution timestamp.