What’s so special about regulatory reporting projects?
Nov 2, 2022 by Yogesh Kshirsagar
To help oversee their national economies effectively, governments develop governance models for all transactions, whether over the counter (OTC) or in financial markets (e.g., the United States implemented the Dodd-Frank Act around 2008, which mandated that all OTC trades must be reported to the regulators).
Typically, reporting rules are based on the laws of the land; hence, regulatory projects are called “rule-based reporting.” And as laws are continually evolving, financial services organizations are obliged to make a special effort to keep up with developments.
So, the primary aim of this article is to explore the special nature of regulatory projects and apply lessons learned so we can tell clients:
Inclusion/exclusion criteria. These criteria define whether you should report a transaction. For instance, if your product is an interest-rate swap and your counterparty is in the United States, you must report it to a regulator (e.g., DTCC).
Reporting criteria. Reporting criteria show who informs a regulator about a transaction. If Citi and Standard Chartered make a swap deal, one of them must disclose it. If both reported the transaction, the redundant report would be guilty of “over-reporting.”
Over-reporting. Over-reporting creates extra work for operations teams, diverting them from genuine issues. Therefore, reporting systems and applications must provide a way of filtering transactions.
Weightage-based reporting rules. In my experience, regulatory reporting is based on the weightage in the system. For instance, when a transaction is reportable by both parties, the party with the higher weightage reports the transaction. To estimate the development and testing effort, consider testing around these weightages.
Unique transaction reporting. Ensure you report transactions using a unique transaction number. In Dodd-Frank reporting, each transaction and amendment gets a unique reference. Trade amendments (notional amendments are “transactional amendments”) must be reported, too. Regulators also check novation (counterparty amendments).
Reporting frequency. With timebound reporting requirements, most parties report transactions immediately using real-time reports, while others report by the end of the day. Applications should support all reporting types because a delay in reporting breaches regulatory requirements.
Reporting quality. Timing is critical for reporting, as is quality. So, make sure you’re getting acknowledgments (ACKs) and negative acknowledgments (NACKs) from regulators that you can understand. Receiving NACKs for all messages is not a good sign.
Often, IT companies install stubs (pseudo apps) for testing ACKs and NACKs because they have no connectivity with the regulators in a user acceptance testing (UAT) environment. This is also a significant limitation because once you get a real system, you must investigate what’s failing.
User interface. Another aspect of regulatory projects is user-interface testing. It shows the transactions passing through your system to regulators — how many are ACKed/NACKed and how many have technical issues.
The technical exception queue is often kept for transactions that fail due to technical reasons. A failure could be because a tag is missing, it’s empty, or the XML you have in the reporting application doesn’t meet regulatory requirements.
The business exception queue lists trades that are correct and valid. They’re held in a queue because something else is not working. Hence, factoring in the development and testing of these queues is imperative.
Types of transactions to report. To ensure we evaluate the system with all combinations, we should get operations to book the various types of transactions through all systems affected by the change. Therefore, if Murex is used for booking an IRS trade, we might also be able to book an IRS trade through Sophis. If these applications are unavailable during testing or development, use applications like Hermes to publish the relevant messages so you can continue testing.
When financial authorities first mandated derivatives reporting, several councils and advisers followed Dodd-Frank’s path, including HKMA, MAS and EMIR. Once you get an initial list of requirements for a regulatory project, you can implement the minimum viable product (MVP) reasonably quickly. However, MVP enhancements can take longer, depending on the requirement complexity. It took my team a short time to develop and test basic functionalities, and the UI needed trade reporting. Then, the team focused on trade amendments, novations and reporting modules. At a high level, 3-6 months should prove reasonable for delivering basic application functionalities.
You need to consider the following testing activities for any regulatory project:
Here are the initial regulatory project user stories to help you develop T-shirt side estimates.
Ops should be able to:
If you’re feeling overwhelmed, focus on reporting your transactions regardless of whether they’re getting ACKed or NACKed. Over time, you can work with regulators to correct any reporting problems.
Armed with this invaluable information, you’ll be able to visualize any RFP or deliverable of a regulatory project and win client confidence. If you’d like to find out how Luxoft can help you add extra business value, visit luxoft.com/capital-markets or contact us. We’ll be glad to share even more insights into achieving exceptional success with regulatory reporting.