Effective project management for regulatory compliance

Full text

(1)

How an Agile approach

can ensure project success

Effective project

management

for regulatory

compliance

(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, under-standably, 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 partici-pants 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 Commod-ity 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 Singa-pore (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 Col-lective Investment in Transferable Securities (UCITS) VI. The combined effect of these regulations will be far reach-ing, requiring a large amount of ongoing change to the regulatory and compliance systems of market participants across the industry.

“A lack of cooperation between

regi-onal regulators has created a highly

fragmented landscape, with various

overlapping and misaligned

guideli-nes being proposed”

(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, mandat-ing that all participants tradmandat-ing in OTC derivatives should report their trading activity to the US regulators. This resulted in the creation of a broad range of rules govern-ing almost every aspect of derivatives tradgovern-ing, includgovern-ing trade reporting.

¬ Under Dodd-Frank, the original rules stated that regula-tory 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 2011. 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 func-tional development up front.

¬ A survey conducted on the 3rd anniversary of the ratifica-tion 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 through-out 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 2015. 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.

(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 require-ments 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 con-nectivity 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.

The architecture should be designed in a way that re-sponds well to change, with a clear separation of responsi-bilities between modules.

Executing the sprints

As further rules are refined and become available, addition-al 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

present-“In an environment where

require-ments are continuously changing,

the Waterfall approach will not allow

managers enough flexibility to adapt

and respond to change”

(5)

ality and product sets, the spine of the system had already been built, complete with integration into the primary trad-ing 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 implemen-tation 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, addition-al 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:

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?

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 sub-sequent future sprints. In contrast, if requirements change during the development phase of a Waterfall project, signifi-cant reworking of the analysis and design phases will need to be undertaken, which is highly inefficient.

(6)

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 achiev-ing 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% com-pliant due to a missed deadline or X% comcom-pliant (where 0% < X < 100%)?

GFT Technologies AG and Agile

project management

GFT Technologies AG specialists are experts in deliver-ing high quality projects usdeliver-ing Agile methods. Our flexible approach to project management is particularly suited to the delivery of bespoke regulatory compliance engage-ments and we have extensive experience of implement-ing bespoke compliance solutions at some of the world’s foremost financial institutions. Leveraging their deep knowledge of both business and technology, our special-ists 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 ap-proach 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 compli-ance 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 ef-fectiveness and flexibility during both the prototype and production stages

Engaging the users - operational efficiency

Against a backdrop of increasing regulatory pressure, operations teams can ill afford to be inefficient in their day-to-day responsibilities.

In the Waterfall approach, users of a system are tradition-ally 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 exe-cute. 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 ini-tial 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), display-ing an outstanddisplay-ing message queue.

By working closely with the users, the initial system can be developed to meet the mandatory regulatory dead-lines, 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.”

(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 profes-sional 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, neces-sary 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 Tech-nologies 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.

(8)

Featured specialists

Paul Watson

Specialist in Project Management

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 mul-tiple 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 McGeachy

Specialist in Capital Markets

Robert joined GFT Technologies AG in March 2012 as Man-aging 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, operation-al process, organisationoperation-al 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 techno-logical expertise, innovative strength and outstanding quality for over 25 years.

Figure

Updating...

References

Updating...

Related subjects : Regulatory Compliance