In brief
- The article discusses the unique nature of regulatory projects in the financial industry, focusing on reporting rules and their implementation.
- Regulatory projects involve multiple stakeholders to implement high-level requirements, adhere to regulatory criteria, and deliver work within a specified timeframe.
- Principal elements of regulatory projects include criteria for inclusion/exclusion, reporting criteria, over-reporting prevention, weightage-based reporting, unique transaction reporting, reporting frequency and reporting quality.
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:
- Their project will require several business analysts, developers, technical architects, project managers and quality assurance personnel
- Which high-level requirements are the most important
- The least amount of work needed to follow the regulatory requirements within a given period
Principal elements of regulatory projects
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.
Project implementation team
- For a workable regulatory project, you need two or three developers, one business analyst, one technical analyst and two or three good QAs. One of the QAs should have a sound background in automation so you can book trades automatically. You can use Unified Functional Testing (UFT) to book all required trades automatically and perform actions on them, so you’re free to focus on testing regulatory reports
- Because regulatory projects are sensitive to change, project managers need to focus on the smallest workable product rather than implementing everything at once
High-level estimate
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.
Testing
You need to consider the following testing activities for any regulatory project:
Best practices:
- To avoid human errors, get your vendor to automatically upload SSI details in your application. It will make the process faster and smoother
- Deploy internal controls to upload SSIs into production once you’ve implemented your product and the vendor warranty expires
- Use good SMEs with knowledge of SWIFT and trade settlements to set up your SSIs
- Verify that confirmation text follows the bank policy. Work with your compliance and legal departments to get their confirmation
Core requirements
Here are the initial regulatory project user stories to help you develop T-shirt side estimates.
Ops should be able to:
- View a trade in the application
- View trades booked today and the total number of trades
- View trades that are ACKed and NACKed by regulators
- Have a unique system-generated tracking number for every transaction
- See a booked trade into the applications when the product is OTC (any OTC), or a counterparty domiciled in a particular country (inclusion criteria)
- Replay trades from technical- and business-exception queues
- View reports sent to regulators
Key takeaways
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 Zoreza Global 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.
Yogesh Kshirsagar
Yogesh has 19 years of IT experience in banking and finance. Before joining Zoreza Global, he held leadership positions across the UK, United States, Singapore, Malaysia, and India, working with clients like Standard Chartered, Credit Suisse, American Express, CLSA, Natixis, Bank of Ireland and MUFG Securities. He specializes in regulatory reporting, anti-money laundering, client lifecycle management and investment banking. Yogesh also writes and speaks about these topics. Any spare time is spent with his daughter, jogging, reading or experimenting with new ideas.
