BJSS Case Study - Regulatory Compliance v1.0 (US)

Dodd-Frank Compliance

DELIVERING REGULATORY COMPLIANCE FOR A GLOBAL TRADING ORGANIZATION WITH BJSS ENTERPRISE AGILE

A BJSS CASE STUDY

A BJSS CASE STUDY | Delivering Regulatory Compliance for a Global Trading Organization with BJSS Enterprise Agile

1

Contents

This Case Study is for IT decision makers in organizations affected by the Dodd-Frank Act. It describes a successful engagement where the BJSS Enterprise Agile approach ensured regulatory compliance for a global trading company despite uncertain and changing regulatory requirements and outlines the planning, organiation and other critical success factors for those undertaking similar projects.

Executive Summary 2

Regulatory Landscape 2

Programme Overview 3

Key Challenges 3

Project Approach 4

Project Organization 4

Critical Success Factors and Lessons Learned 5

Results of Project 6

BJSS Enterprise Agile 6

References 6

About BJSS 7

Delivering Regulatory Compliance for a Global Trading Organization with BJSS Enterprise Agile | A BJSS CASE STUDY

2

Executive SummaryThe Dodd-Frank Wall Street Reform and Consumer Protection Act (‘Dodd-Frank Act’) pertaining to the reporting and valuing of certain swaps and options comes into force in mid February 2013. For organisations that trade swaps and options this has meant a significant change in business working practices and supporting IT functions.

BJSS provided a senior team to a large, multinational trading company to manage a key part of their overall Dodd-Frank Act compliance programme and the engineering of systems and components in order to comply with said regulation. Changes to support compliance were completed and made available to the business one month prior to enforcement date and two-and-a-half months prior to business go live. This paper describes the challenges and BJSS’ approach that led to successful delivery and compliance.

Regulatory LandscapeOn July 21st 2010 the Dodd-Frank Wall Street Reform and Consumer Protection Act was passed into law in the US with the aim ‘to promote financial stability of the United States by improving accountability and transparency in the financial system.’ To comply, businesses must identify impacted systems, assess their compliance with impending regulatory changes, and if required, modify systems to comply within required timelines. In many cases enhancements to Front, Middle, and Back Office systems are required. Businesses that do not comply risk losing their license to operate and incurring heavy fines.

This act consists of 16 titles, of which the 7th is ‘VII – Wall Street Transparency and Accountability’ with the objective of establishing a comprehensive regulatory framework for swaps and Security-based swaps aimed at reducing risk, increasing transparency and promoting market integrity within the financial system. Key components include:

• Registration & regulation of swap Dealers and Major swap Participants,

• Imposing clearing and trade execution requirements on swaps. In-scope instruments include Interest Rate swaps, Basis swaps, Currency swaps, Credit Default swaps, Energy swaps, Commodity swaps and options on commodities,

• Creating rigorous recordkeeping & real-time reporting standards,

• Enhancing the rulemaking and enforcement authority of the Commissions.

Regulatory Agencies include the Commodity Futures Trading Commission (CFTC) to oversee the regulation of swaps and the Securities and Exchange Commission (SEC) to oversee regulation of security-based swaps.

The Dodd-Frank Act requires companies, classified as a swaps Dealer or Major swap Participant2, to maintain margin standards and reporting requirements in support of their swap trading. They must allocate capital to cover credit and market risk in addition to specific reporting and recordkeeping requirements including:

• All uncleared swaps must be reported to a Swap Data Repository (SDR) or CFTC

• ‘Real Time’ reporting of most swap transaction data

• Daily Large Trader Report by counterparty detailing open positions and notional value

• Keep all records throughout existence of swap and five years after its termination

• Preserve sufficient information to conduct a comprehensive trade reconstruction at the transaction level

Complex regulations, incomplete compliance rules and changing compliance dates create a challenging environment in which to achieve compliance. Davis Polk1 observed ‘Of the 398 total rulemaking requirements, 136 (34.2%) have been met with f inalized rules and rules have been proposed that would meet 133 (33.4%) more. Rules have not yet been proposed to meet 129 (32.4%) rulemaking requirements.’ They are not written for the end-user banker,

are comprehensive and far-reaching in their organizational impact and are undergoing many revisions during the draft process: they are a constant moving target. The Dodd-Frank Act impacts many parts of the business and creates a technology headache of enterprise scale.

To achieve compliance, many corporations and financial institutions have established a Program Management Office (PMO) with corporate-wide responsibility. The challenge of implementation is multiplied significantly as stakeholders across different divisions and geographies must reprioritize work and coordinate changes to legacy systems, processes and supervising/audit functions in order to achieve compliance. Many corporate functions will change:

Commercial Teams• Changes to deal entry and trading book

structure,

• Real-time deal entry,

• Potential restrictions on trading cash settlement instructions.

Product Control• Real-time deal validation and reporting

(15 minute post deal entry).

Credit• Perform exposure reconciliation at the

individual deal level.

Trade Completion• Administer CFTC forms – large trader

reporting,

• Pre-trade validation – transaction confirmed prior to execution,

• Positive confirmation for all applicable 3rd party transactions.

IT• Changes to many legacy systems,

Communicate regularly with all stakeholders about the importance and progress of the compliance programme.


3

• New system(s) to capture and safe store

required information for regulatory

compliance and audit.

Know Your Client (KYC)• Need to know if counterparty is

classified as a swap dealer, major swap

dealer, financial entity, or a patent entity.

Programme OverviewThis major multi-national corporation started

their regulatory change programme in late

2011 to implement both US and EU regulatory

requirements. At that time the programme

was partitioned into distinct work streams

to deliver business and technical change to

comply with enacted legislative changes.

The programme reported into a senior IT

executive and the Financial Regulatory Reform

Programme Manager. Lower level governance

and management boards were established to

control the key work streams.

BJSS was engaged to manage and deliver the

implementation of US regulatory compliance

for their swaps business, which included real-

time reporting of swap transactions, swap data

recordkeeping and reporting, and compliance

with swap clearing requirements.

BJSS was accountable for overall program

delivery, which included conducting

a technology gap analysis, establishing

requirements, engaging with regulatory subject

matter experts (SMEs), forward planning

(based upon rules approvals and publications,

consideration of business change and training),

and delivery of a tactical solution to satisfy

tight timeframes and limited ability to modify

the application portfolio. BJSS also led the

architecture function, integration testing and

initial implementation management.

Several Dodd-Frank Act rules defined the

primary scope for the engagement:

Part 43 ‘Real-Time Public Reporting of Swap Transaction Data’Reporting PET data for new US swap deals within 15 minutes (30 minutes in year 1).

Part 45 ‘Swap Data Recordkeeping and Reporting Requirements’Recordkeeping and reporting US swap creation data (PET and confirmation) and continuation data (lifecycle events and valuations).

Part 46 ‘Swap Data Recordkeeping and Reporting Requirements: Pre-Enactment and Transition Swaps’A backfill report of PET data for all US swap deals in existence from 21st July 2010 to Dodd-Frank compliance date.

Historic changes (aka continuation) thereof.

Part 39 ‘End-User Exception to the Clearing Requirement for Swaps’

Key ChallengesThere were many challenges to achieving regulatory compliance:

• Obtaining clear specifications and commitments from key stakeholders, including Swap Data Repositories (SDR), legal and compliance, programme level stakeholders, and line of business representatives.

• Vague and non-finalized regulations, late interpretation of regulations, late changing SDR Application Programming Interfaces (APIs) and late delivery of API implementation. This risk was mitigated by on-going dialogue with SDR and SMEs while managing changes through an Agile programme.

• IntercontinentalExchange (ICE) valuations required at the mark level – Required much data analysis and design and ultimately changes to the valuation application.

• Reconciling requirements against APIs provided by ICE eConfirm / EFET-DTCC. Lack of documentation and ambiguous rules led to difficulty mapping data to SDR APIs. Risk was mitigated through continuous testing and verifying results as API specifications changed.

• Impact of ‘Swaps to Futures’ which removes regulatory reporting for majority of products. In October, ICE/CME announced that exchanged cleared swaps do not have reporting requirements, which invalidated a key part of the solution design.

• Unclear rules regarding who is responsible for reporting trade required the negotiation of trade-reporting rules with each counterparty.

• Concerns as to whether the systems were capturing the required data (e.g. lifecycle events, indication of collateralisation and end-user exceptions etc.) were resolved by convening Business Analysts and SMEs into joint sessions in order to interpret requirements and map data needs to data provided by existing systems.

• Cross stream/silo development. Extensive project management time was required to coordinate work across multiple applications, supported by different systems integrators, employing different development methodologies.

• Continuous changes across multiple systems required continuous end-to-end integration testing.

• Multiple releases causing release congestion. A formal process to put releases live was established, including regression testing, Operational Acceptance Testing (OAT), change management control, and portfolio management and coordination.

• Enforcement dates required releasing software into production during the normal end-of-year freeze period, which required significant dialog with Internal

Control and Change Management.

Run Technical Testing early to provide timely feedback on performance, scalability and supportability.


4

Project ApproachAfter evaluating several approaches BJSS and

the client selected a tactical solution to ensure

delivery within required timeframe, minimize

application modifications, and contain costs to

allocated project budget.

Work was segmented into five work streams:

Application DevelopmentCoding and system/regression testing of four

core legacy systems, developed with a variety

of software delivery models and development

of a new application to capture specific

compliance data, manage communication with

the SDR and provide auditing facilities in direct

relation to the Dodd-Frank Act. This was built

by an internal team using a formalized Scrum

development approach. A trading assistant

provided the Product Owner (PO) role, which

ensured that the business was actively engaged

in determining the structure and behaviour of

the interface.

Quality Assurance & Testing

Core to success was integrating changes

across multiple systems to produce a cohesive

solution. The integration testing was run

and managed by a Test Manager and a team

of three Testers that adopted a scrum-like,

iterative approach to build and execute test

scripts, including the implementation of an

automated test harness. This allowed the

creation and submission of hundreds of deals

in a reliable, repeatable and rapid fashion and

allowed regular and complete regression tests

to be run. This helped the overall project by

providing rapid feedback on changes.

Technical Testing was run early in the project and provided early feedback on the performance, scalability and supportability of the system.

The line of business ran the User Acceptance Test (UAT) to confirm proper operation of the business processes and correct values reported to the SDR.

The Test Manager coordinated all testing activity under a single Quality Assurance (QA) program, which ensured that each team properly performed their testing function and the summation of all activity ensured a comprehensive QA approach.

ImplementationThe client’s standard implementation process required Operational Acceptance Test (OAT) to be conducted prior to go-live, including execution and validation of application and database implementation procedures and a ‘dress rehearsal’.

Shared ServicesShared Services provided environments and release management services to all projects, including maintenance of a standard integration-testing environment.

New legal entityThe business required a new legal entity for swap dealing, which was implemented in four months.

Project Organization The key project leadership roles were:

Project Manager (PM)A highly knowledgeable person with a clear vision and focus on delivery. This role reported to the Programme Manager responsible for company-wide compliance with financial regulatory reforms. Responsibilities included

Q2 Q3 Q4 Q1 2013

App Dev & Sys Test

Trade Confirmation Dev/Test

Front Office Dodd-Frank Repository Dev & Sys Test

Valuations ETL Dev & Sys Test

Part 46 Analysis & Plan Part 46 Dev

Initial Integrated Test & Prep IntegrationTesting RegressionTestFinal Testing

Tech Test Prep Tech Test ICE SDR Testing

UAT

Application Development

Quality Assurance & Testing

Implementation Plan

Legal Entity Pre Reqs

Design & Build

Int Test & Go Live

Shared Services Environment Delivery

Implementation

New Legal Entity

OAT Setup OAT Testing ELS

Incremental Software Release

ELSOAT

Figure 1: High Level Project Plan

Assign SMEs to track rule changes and interpret their meaning on behalf of the

implementation teams.


5

full delivery and budgetary responsibility, chair

of management board, project planning and

control, risk management and coordination of

multiple work streams.

Technical Architect (TA)The TA defined and co-ordinated changes

across multiple systems, many of them legacy,

to ensure the resultant solution met the

reporting timeframe requirements, was robust

and resilient, and did not impact normal

trading activity.

The TA also required a close understanding

of the regulator’s requirements and how they

were interpretted by the SDRs. The TA was

required to extract the required information

from multiple systems, correlate and transform

it into a consistent format to feed into the

SDR.

Business Analyst (BA)The impact of the Dodd-Frank Act has

a significant impact to the business, its

compliance framework and governance

activities.

The BA’s role was to ensure that business activities could be accurately and effectively supported by proposed technical solution.

Test Manager (TM)The TM engaged with the multiple delivery teams to obtain and chase code delivery dates, adopting an overall QA role to ensure the right level of testing had taken place before delivery to the end-to-end integration testing team.

The two week Agile sprint cycle4 provided a crucial mechanism to adjust to the shifting priorities as elements of the solution were delivered into enterprise-level test environments ensuring that the appropriate level of testing was carried out for internal and external production releases.

The adoption of a ‘Show & Tell’ approach helped to generate engagement with the Product Owner at the sprint reviews.

The daily test team scrum ensured that changes in the constantly evolving regulatory requirements were flagged early so that test design and execution priorities could be quickly adjusted to minimize lost test effort. As a result of early engagement of the test team a

test automation solution was immediately built,

allowing the team to quickly build test cases to

support changing requirements during the test

execution phases of the project.

The Test Manager coordinated closely with

the Shared Services lead on test environment

matters, provided assurance across the

testing deliverables and developed the test

completion report.

Critical Success Factors and Lessons LearnedFive key factors drove successful completion:

1. Aligning Business with the ProjectSpend time proactively communicating and

actively managing stakeholders (Lines of

Business, IT, Operations, Legal, Information

Security, Compliance, Audit, Administration

etc.). Spend time explaining the importance of

the compliance programme to all stakeholders

and create a cross-functional management

board that meets weekly. Leaders may not

understand the importance of starting early

in order to allocate sufficient time to achieve

compliance.

An external, respected consultant may provide

the required perspective that creates a

common understanding, view and programme

to ensure compliance. Due to compliance

dates, multiple groups may need to work

together to create manual work-around

procedures to balance risk, cost, and time.

Cross-group collaboration helps develop

innovative solutions.

2. A Strong Project Management TeamThe rate and complexity of changes means

that a dedicated core team comprinsing

a senior programme manager, BAs, TA,

and Test Manager with a shared vision and

focus on delivering a pragmatic solution is

E2E Testers

Project Manager

IT ExecutiveFinancial Regulatory

Reform PM

Dodd-FrankBusiness Change PM

Technical ArchitectBusiness AnalystTest ManagerWorkstreamDelivery Leads

ETL Developer

Figure 2: Project Organization

Appoint an experienced project management team with a strong focus on managing and mitigating risk.


6

critical for success. Risk must be ruthlessly

monitored and mitigated, while understanding

dependencies and implementing a robust

change control programme.

3. Understanding the LegislationSeveral industry participants are involved in

compliance (CFTC, SEC, SDR, exchanges).

Understanding a rule change or clarification is

a complex and time-consuming activity. It is

therefore imperative to assign SMEs to track

these changes and interpret their meaning on

behalf of the implementation teams.

4. Adopting an Agile ApproachThe dynamic nature of the Dodd-Frank

Act meant that the project required an

Agile approach – in the absence of firm

requirements the project team had to work

through a continually changing ‘statement of

assumptions’, in sprints, across a company with

multiple development teams. The project

team adopted the practice of daily stand-ups

and weekly catch-ups with work stream leads

and key stakeholders.

5. Early Investment in End-to-end

Integration TestingThe test team was formed at project inception

and adopted Agile practices to review and

validate requirements early in the project

lifecycle, which reduced downstream defects.

A test framework that enabled automatic

execution of greater then 80% of all tests

was created, decreasing test turnaround time

for system changes, enabling more frequent

system changes and reducing effort wasted on

manual testing. This test framework remains

after project completion as the integration

environment to test future system changes.

Results of ProjectThe team delivered the project within budget,

ahead of required deployment date, and

without serious defects. At project closure,

over 20 outstanding change requests indicate

the impact of on-going regulatory refinements

and changes. Yet, all systems are production-

ready and compliant with the Dodd-Frank

Act as interpreted at time of closure. At the

formal project closure meeting, all senior

stakeholders expressed satisfaction with

project outcome.

BJSS Enterprise AgileBJSS has leveraged experience gained over 20

years of successfully delivering enterprise level

software development projects to refine the

‘BJSS Enterprise Agile’ approach4. The lessons

from developing distributed high performance,

high availability software systems combined

with elements of methodologies such as XP,

SCRUM, and the Unified Process provides a

practical toolkit for reliable delivery.

BJSS Enterprise Agile is neither a dogmatic

approach nor a rigid methodology - in our

experience neither are succesful on an

enterprise scale.

BJSS pragmnatic blend of tools, techniques

and highly capable technologists has enabled

consistently succesful project delivery within

environments traditionally dominated by more

rigid processes such as Waterfall.

Key aspects of BJSS Enterprise Agile include:

• Risk-first, Architecture Centric approach,

• Necessary and sufficient formality,

• Based on strong engineering and

management practices,

• Ability to scale to enterprise projects,

• Transparency,

• Practical and flexible.

References1. Dodd-Frank Progress Report, January 2013, Davis Polk.

http://www.davispolk.com/files/uploads/FIG/Jan2013_Dodd.Frank.Progress.Report.pdf

2. Proposed Rules Further Defining ‘Swap Dealer’, ‘Major Swap Participant’ and ‘Eligible Contract Participant’, CFTC.

http://www.cftc.gov/ucm/groups/public/@newsroom/documents/file/defs_factsheet.pdf

3. Dodd-Frank Act, H.R. 4173.

http://www.sec.gov/about/laws/wallstreetreform-cpa.pdf

4. BJSS Enterprise Agile.

http://bjss.co/ea

What is a Swap Data Repository?Swap Data Repositories (SDRs) are new entities created by the Dodd-Frank Act to provide a central facility for swap data reporting and recordkeeping. The Dodd-Frank Act mandates that all swaps, whether cleared or uncleared, are reported to registered SDRs.

The Dodd-Frank Act added new Section 21 to the Commodity Exchange Act (CEA), governing registration and regulation of SDRs and establishing registration requirements and core duties and responsibilities for SDRs.

http://www.cftc.gov/industryoversight/datarepositories/index.htm

Adopt an Agile approach to deal with changing requirements and work in short

‘sprints’ to minimize wasted effort.

About BJSS

BJSS is an established IT consultancy of 400 technologists delivering IT architecture, project management, business analysis, software design, development and testing services to an international client base.

Founded in 1993 with offices in London, New York, Leeds, Derby and Manchester, the company continues to experience strong growth thanks to a 100% track record of repeat business from clients in the capital markets, energy trading and retail sectors who have adopted its BJSS Enterprise Agile approach to complex software delivery.

12 Nicholas Lane, London, EC4N 7BN, United Kingdom+44 207 337 9800

140 Broadway, 46th Floor, New York, NY 10005, USA+1 212 858 7570

Coronet House, Queen Street, Leeds, LS1 2TW, United Kingdom+44 113 297 9797

82 King Street, Manchester, M2 4WQ, United Kingdom+44 161 935 8334

32 Friar Gate, Derby, DE1 1BX, United Kingdom+44 133 265 3030

BJSS Case Study - Regulatory Compliance v1.0 (US)

Documents

Transcript of BJSS Case Study - Regulatory Compliance v1.0 (US)