Effective project management for regulatory compliance

Transcription

1 Effective project management for regulatory compliance How an Agile approach can ensure project success Copyright 2015, GFT 01

2 Be agile enough to jump aboard the regulatory train Since the 2008 banking crisis, regulators across the globe have been working on ways to mitigate risk, improve transparency and provide more stability in financial markets. However, a lack of cooperation between regional regulators has created a highly fragmented landscape, with various overlapping and misaligned guidelines being proposed. The lack of a coherent and consistent global strategy has, understandably, led to mass confusion and uncertainty throughout the financial services industry. In some cases, the defined regulatory rules and approach from individual jurisdictions vary dramatically, creating a situation where market participants will find it extremely difficult to be fully compliant with the different requirements of each regulator. However, in July 2013, the European Commission (EU) and the US Commodity Futures Trading Commission (CFTC) did manage to reach an agreement on a range of aspects concerning the cross border treatment of over-the-counter (OTC) derivatives. This is likely to impact current implementations of Dodd-Frank reporting, and influence the direction of future European Market Infrastructure Regulation (EMIR) initiatives. Other regional regulatory bodies such as the Hong Kong Monetary Authority (HKMA), the Monetary Authority of Singapore (MAS) and the Financial Supervisory Commission (FSC) in Taiwan are also enforcing their own regional variations of regulations covering the same financial instruments. In addition to the spotlight being placed on OTC derivatives, other directives published in recent months that will also require compliance include: the Alternative Investment Fund Managers Directive (AIFMD), Solvency II, Basel III, the Capital Requirements Directive (CRD) IV, and Undertakings for Collective Investment in Transferable Securities (UCITS) VI. The combined effect of these regulations will be far reaching, requiring a large amount of ongoing change to the regulatory and compliance systems of market participants across the industry. A lack of cooperation between regional regulators has created a highly fragmented landscape, with various overlapping and misaligned guidelines being proposed 02 Copyright 2015, GFT

3 Managing compliance in a sea of regulatory change With so much regulation being imposed, each with its own timescale and individual jurisdiction, managing regulatory compliance projects within affected financial market participants can be extremely challenging. From the examples below, it is clear that the overwhelming level of information to be digested is often evolving and unclear, or is yet to be clarified by the regulator. Example 1: The US Dodd-Frank Act In response to the 2008 banking crisis, US legislation was passed in the form of the Dodd-Frank Wall Street Reform and Consumer Protection Act of 2010, mandating that all participants trading in OTC derivatives should report their trading activity to the US regulators. This resulted in the creation of a broad range of rules governing almost every aspect of derivatives trading, including trade reporting. Under Dodd-Frank, the original rules stated that regulatory reporting for all OTC derivative asset classes (Rates, Credit, FX, Commodities and Equities) should be in place for a limited scope of functionality by the end of A second phase release would follow soon after, to address the remaining requirements. Development teams were mobilised by many market participants and work was undertaken to meet these deadlines. Towards the end of 2011, the CFTC revised the rules, stating that a full set of reporting functionality should be provided for a reduced asset class list (Rates and Credit) followed by a second phase that included (FX, Commodities and Equities). The reporting deadline was also delayed until the end of 2012, which presented a significant change in approach, requiring more functional development up front. A survey conducted on the 3rd anniversary of the ratification of the Dodd-Frank Act has indicated that still only 40% of the rules have been finalised; and this already amounts to some 15,000,000 words! Example 2: EMIR The European Market Infrastructure Regulation (EMIR) seeks to regulate the trading of OTC derivatives throughout the European Union. It covers reporting and clearing obligations, defines rules for central counterparties and introduces measures to reduce the counterparty credit risk and operational risk for bilaterally cleared OTC derivatives. The timeline for EMIR trade reporting originally defined a deadline of 23rd September 2013 for interest rate and credit default swaps, and a deadline of 1st January 2014 for the remaining asset classes (FX, Commodities and Equities). Recently, the European Securities and Markets Authority (ESMA) moved the reporting deadline to 12th February 2014 for all asset classes. Whilst this did allow a little more time for implementing solutions for the initial tranche of asset classes, it also created more pressure on the final deadline, due to the increased level of testing and release activities occurring simultaneously. To further complicate matters, ESMA s recommendation to delay exchange traded derivatives (ETD) reporting due to lack of clarity in the marketplace was rejected by the EU Commission. Initially, it was anticipated that ETD transactions would not need to be reported until This revelation has proved extremely troublesome for those firms who have deferred the implementation of an ETD trade reporting solution, since they are now obliged to report from the 12th February 2014 deadline. Copyright 2015, GFT 03

4 The case for an agile project methodology It seems logical that when working on a regulatory project, managers should adopt a rigid Waterfall method, where requirements are defined, reviewed and signed-off before proceeding to the next step of the lifecycle. However, we believe this logic is flawed. Given the pressures faced by financial market participants as outlined above, it is very difficult, if not impossible, to get full sign-off of all the requirements in a project where the regulator has not yet decided the final approach. Often, major clarifications are issued by the regulator at a later date and managers would therefore need to make significant assumptions in order to proceed with the project. Utilising an Agile approach, any assumptions that are made can be regularly evaluated, and the project objectives modified if they are found to no longer be valid. By starting with the pieces that you know you can build, you will undoubtedly gain a head-start. For example, if you were building a house, you would not wait to buy the roof slates before laying the foundations. In an environment where requirements are continuously changing, the Waterfall approach will not allow managers enough flexibility to adapt and respond to change. Adhering rigidly to the Waterfall approach can lead to a state where the project is stuck in the requirements gathering phase, continuously changing and yet never moving forward. This puts pressure on the subsequent phases of the project, necessitating short-cuts and compromises further down the line, which can affect quality and the scope of the delivery. In extreme cases, where the regulator does not finalise interfaces or message formats until very close to the imposed deadline, a Waterfall project is very likely to fail completely. An exemplary approach to regulatory reporting By adopting an Agile approach, the project team can focus on building what they know, and not expend effort on what remains uncertain. They can concentrate on the consistent aspects of the programme, regardless of the final version of the regulatory rules. Building the product backlog For such widespread regulatory reporting, it is clear that the reporting system will require access to the entire population of all trades undertaken by the firm, a proportion of which will need to be reported based on a defined set of rules. By focusing on the aspects of the system that are rules agnostic it is possible to start defining system requirements and continue adding stories to the product backlog before the reporting rules are finalised. The first step should be to build those components that are common to all regulatory submissions, followed by other specific detailed requirements as and when they become clear. It is important not to become paralysed by a lack of clarity around the final formatting and creation of messages or reports to be sent to the regulator. Focus on the core functionality first. In this case, a story can be created that involves a trade being entered into a trading system and the information being published downstream for the reporting system to receive and process. Defining a vertical slice in this way will allow work to commence that includes establishing connectivity to the trade processing system and the publication of the entire trade population, which can then be made available to the downstream systems. Assumptions can be made about the trade data available and the spine of the system can be built in preparation for the rules still to be finalised. In an environment where requirements are continuously changing, the Waterfall approach will not allow managers enough flexibility to adapt and respond to change The architecture should be designed in a way that responds well to change, with a clear separation of responsibilities between modules. Executing the sprints As further rules are refined and become available, additional backlog items can be created that define the reporting process workflow and message structure. Sprints can be constructed in vertical slices that move forward with the end-to-end aspects of the projects, with upstream trading systems being brought into check by the regulatory timelines, balanced by other variables such as trade numbers or trading volumes. In the scenario presented earlier where the CFTC changed the scope of function- 04 Copyright 2015, GFT

5 ality and product sets, the spine of the system had already been built, complete with integration into the primary trading system, and subsequent sprints were adjusted to take account of the new direction. This would not have been possible in a purely Waterfall model. This approach also works where additional regulators are brought into scope, defining requirements with implementation deadlines too close for comfort. Refactoring of the code base and additional workflows can be added to the system by creating new backlog items. These can then be built into subsequent sprints, giving a head-start when new regulatory rules emerge. As further rules are refined and become available, additional backlog items can be created that define the reporting process workflow and message structure. Responding to change In regulatory projects, particularly reporting, there are many elements that can be subject to a change in requirements. Examples of these variable requirements are as follows: Reporting format What formats are required e.g. financial products markup language (FpML) messages, comma separated values (CSV) files etc? Communication channels What is the channel requirement e.g. Message queues, file uploads etc? Historical trade data What type and volume of historical trade data executed prior to the regulatory reporting deadline is required? During the lifetime of a project, it is highly likely that some, if not all of these dimensions will change, and the project team need to be able to respond quickly to those changes. By adopting an Agile approach with a product backlog, where requirements change, existing backlog entries can be amended and system refinements incorporated into subsequent future sprints. In contrast, if requirements change during the development phase of a Waterfall project, significant reworking of the analysis and design phases will need to be undertaken, which is highly inefficient. Trade population Which product sets fall within regulatory reporting scope for a given regulator, and how does this differ to other regulators? What are the regulatory rules that define trade eligibility for reporting? Trade attributes Are they available within existing trading systems, or do they need to be derived? Is the set of reporting fields mandatory? Does the management team have a desire to report on additional non-mandatory fields? Non-functional system requirements What is required in terms of reporting frequency and latency? Copyright 2015, GFT 05

6 Engaging the users - operational efficiency Against a backdrop of increasing regulatory pressure, operations teams can ill afford to be inefficient in their dayto-day responsibilities. In the Waterfall approach, users of a system are traditionally only involved during the requirements gathering and user acceptance testing (UAT) phases. For the type of regulatory driven project we have been discussing, this can lead to a significant disconnection with the user base, due to the potentially protracted timescale involved. In the Agile approach, working software is delivered by each sprint ; software that can be tested by the end users, and deployed into production if required. In this way, users can have early visibility of the system, and any issues with workflow or system usability can be addressed earlier in the project life cycle. For the regulatory reporting project, if the users are not involved from an early stage, project teams run the risk of delivering a system that requires manual operational workarounds, or daily processes that are difficult to execute. Operations teams have an obligation to meet certain reporting deadlines and where trades fail, due to technical or data-related issues, mechanisms to fulfil those obligations must be in place. By engaging users throughout the Agile development process, the mechanisms required can form part of the product backlog and be prioritised accordingly. One particular example is the requirement for the ability to replay messages through the reporting system if they fail due to incorrect static data. The operations team would amend the data in the golden source system and then push the trade through the reporting engine again. An initial approach might involve a manual batch process, but a second phase could be developed, when time permits, to enable replays via a graphical user interface (GUI), displaying an outstanding message queue. By working closely with the users, the initial system can be developed to meet the mandatory regulatory deadlines, with possible compromises agreed along the way. The system can then be refined in subsequent sprints. In the Waterfall approach, users of a system are traditionally only involved during the requirements gathering and user acceptance testing (UAT) phases. Failure is not an option In the undesirable scenario where it is impossible to meet the regulatory deadlines, if a pure Waterfall approach has been adopted, the system will simply not be delivered until all the defined requirements are met. With an Agile approach, working software is delivered and can be further enhanced and deployed along the way. As a responsible manager with the ambition of achieving full and demonstrable compliance, which can then be presented to the relevant regulatory bodies, you must ask yourself certain questions. Would you rather be 0% compliant due to a missed deadline or X% compliant (where 0% < X < 100%)? GFT Technologies AG and Agile project management GFT Technologies AG specialists are experts in delivering high quality projects using Agile methods. Our flexible approach to project management is particularly suited to the delivery of bespoke regulatory compliance engagements and we have extensive experience of implementing bespoke compliance solutions at some of the world s foremost financial institutions. Leveraging their deep knowledge of both business and technology, our specialists work alongside their counterparts at tier 1 investment banks, asset managers, clearing houses and exchanges to ensure that they are fully up to speed with, and prepared for, upcoming regulatory requirements and deadlines. Recent examples of our work include: Delivering a tailored solution to suit a more Agile approach to our client s enterprise architecture, ensuring the team and key stakeholders held regular workshops. This helped our client, who had adopted a compromise reporting solution based on legacy architecture when faced with stringent and impending regulatory compliance deadlines. Helping a client throughout the two phase programme of testing an FX trading application supporting Prime Brokerage activities. This engagement was executed using an Agile testing approach which ensured cost effectiveness and flexibility during both the prototype and production stages 06 Copyright 2015, GFT

7 The information that GFT Technologies AG has provided in this document: (i) is general in nature; (ii) represents the views of the authors at the date of publication; (iii) does not constitute professional advice; (iv) does not represent a complete statement of the approaches or steps that a reader might take (which may vary accordingly to individual factors and circumstances, necessary for a business to accomplish any particular business goal); (v) does not constitute a recommendation of any particular approach; (vi) should not be relied upon to address or solve any particular matter; and (vii) is provided on an as-is basis. GFT Technologies AG assumes no liability for any action taken in reliance on the information contained in this document or for direct or indirect damages resulting from use of this paper, its content, or services. Copyright 2015, GFT 07

8 Featured specialists Paul Watson Robert McGeachy Specialist in Project Management Specialist in Capital Markets Paul is an experienced project, programme and portfolio management specialist, having worked for over 18 years in the financial services sector. He has worked on a number of GFT Technologies AG projects across front office, risk and regulation, predominantly utilising an Agile approach for clients within investment banks and wealth management firms. Prior to joining the Governance discipline at GFT Technologies AG, Paul worked at Merrill Lynch and Morgan Stanley managing medium-sized teams spread across multiple locations. He graduated with a BA (Hons) in Computer Science from the University of Cambridge before attending the University of Newcastle, where he completed a master s degree in the same subject. Robert joined GFT Technologies AG in March 2012 as Managing Director (based in Toronto), having worked in financial services for over 20 years. Prior to joining GFT Technologies AG he was Managing Director at Waterline Group. Robert specialises in foreign exchange, corporate trust, and overall project delivery, in particular he has experience in utilising Agile methods to develop bespoke roadmaps for clients. He is an expert in the creation of business strategies, operational process, organisational re-engineering and the application of technology to solve critical business problems. About GFT GFT is one of the world s leading solutions providers in the finance sector offering consulting, implementation and maintenance for a broad range of IT applications. Combining technological expertise and seamless project management with a deep understanding of the financial industry, GFT is a reliable partner for well-known companies all around the globe. Headquartered in Germany, GFT has stood for technological expertise, innovative strength and outstanding quality for over 25 years. gft.com 08 Copyright 2015, GFT