ASIC and MAS Rewrites go live – what’s changed?
From today, firms with ASIC and MAS reporting obligations are operating under a new landscape.
Just like the recent EMIR Refit and CFTC ReWrite before that, both rewrites introduce many changes to align with global harmonisation of G20 derivatives reporting. Congratulations to all industry participants involved in the implementation, which is no mean feat so soon after last month’s UK EMIR Refit go live.
Let’s recap: what are some of the main changes to both regimes?
- Mandatory usage of ISO 20022 XML format – the cessation of CSV and FPML formats means firms have had to either build internally or procure the ability to send and receive messages in ISO 20022 XML format from a third party.
- A significantly increased data set, due to the addition of new fields – firms have had to interpret these new fields by analysing technical specs and guideline documents to ensure that they are sourcing the right values and where not available, create customised logic to synthetically manufacture the correct values.
- Adoption of the Unique Product Identifier – firms have had to incorporate the correct UPI data against reportable transactions for subsequent reporting.
ACKs and NACKs
Ideally, the completion of all of this work culminates into reports being successfully accepted by the respective Trade Repository (TR), commonly referred to as an ‘ACK’ message. A high ‘ACK’ rate indicates that the report messages submitted by the reporting firm, successfully conforms to the required standards and schemas and also meets the business validation requirements that prevents non-sensible data (for example, omitting option type details when the derivative is an option).
Achieving a high ‘ACK’ rate or conversely, low ‘NACKs’ (rejections) is definitely a positive first step towards a successful go-live.
Is your reporting valid but wrong?
Unfortunately, the work doesn’t end there because the risk of ‘valid but wrong’ reporting can still exist on a report messages that have been ‘ACK’ed’. The valid but wrong scenario occurs when reports pass the validation rules, but the data within the reports is inaccurate. Validations are often syntax rules that require firms to report their data in the right format. For example, if the value reported in a counterparty field does not contain a valid LEI ie a 20 digit alphanumeric that exists in the GLEIF database.
To stay on the right side of the regulators in Australia and Singapore, firms would be remiss to ignore the need to have adequate controls in place to ensure that submitted reports are an accurate, complete and timely representation of reportable derivatives. Kaizen’s ReportShield solutions provide a completely independent assessment of the quality of your reporting by testing all data fields on all reports, with results available on our easy to use dashboard.
To gain confidence in the quality of your reported data (and avoid the valid but wrong scenario), please get in touch for a free healthcheck of your reported ASIC or MAS data.
