We’re helping many of our banking clients to effect the implementation of regulatory change. These programmes are extensive and complex. In order to help get our head around this, we took some time to reflect and identify key themes in these programmes.

Taking a macro view allows us to consider how to implement these changes in a flexible and scalable manner. Our belief is that institutions that are setup to roll out compliance change effectively and quickly will be in a better position to focus on the business rather than the upheaval of change and we want to be sure that we’re supporting our clients on this journey.

Many of the new regulations find their genesis in the Pittsburg G20 commitments (2009) where heads of state committed to reforming financial markets by reducing risk and improving transparency of the derivatives markets globally. Dodd-Frank (America) and EMIR (Europe) are some of the first to impact the sector, but there will be more.

The broader intention of many of the regulations is similar and so there are practical commonalities throughout their implementation.

Reporting to global trade repositories

In an effort to improve transparency in the markets, both Dodd-Frank and EMIR require banks to report trades to a global trade repository (e.g. the DTCC).

Certain trades need to be reported on a near-real time basis, others will need to be aggregated before reporting. In order to achieve this, significant consideration needs to be given to both software architecture (e.g. cross-platform messaging, unique trade referencing, cross platform-integration, data warehousing, etc.) and hardware (data bandwidth internally and externally). Furthermore, the regulator specifies what fields are reportable and the trade repository (e.g. the DTCC) will have additional data requirements which they want to receive on top of this.

It is also important to be mindful of which trades are reportable. Typically this is dependent on the counterparty and the product type. For example, under Dodd-Frank certain commodity swaps which are intended to be physically settled are excluded from the ‘swap’ definition, and so they are not required to be reported. At a business level, this means that deep understanding of particular trading products is required within the transaction reporting teams in order to specify which trades are to be reported. At a systems implementation level, this brings added complexity as the system needs to differentiate between different types of trades and treat them differently.

Client on-boarding – knowing which buckets to classify your clients into has never been this important

All of the G20 reforms require banks to classify their counterparts into multiple different categories.

As an example, under Dodd Frank, banks need to know whether their clients are considered “Financial Entities” and whether they are “US persons”. This information is needed to be able to determine the amount of business done with these types of clients, which in turn impacts whether the bank needs to register as a Swap Dealer with the CFTC (a US regulator).

Under EMIR, banks need to know whether their counterparts are considered “Financial Counterparts” or “Non-Financial Counterparts”. If the latter, do they fall above (NFC +) or below (NFC -) a specified threshold of derivative trading activities? This has many implications, one of which is how much time they are permitted to confirm the trade with the counterpart. For example, if the counterpart is an NFC + and the bank trades equities with them, they’re allowed only 2 days to have confirmed all legal and trade details with them (volume, price, timelines etc). On the other hand, if they are NFC – they’re allowed 5 days to do so.

What we’re illustrating here is that when classifying counterparts, although the definitions and implications are different, the procedures for taking on new clients and the system impacts are very similar. When I’m on-boarding a client, I need to consider which category they fall into as the implications are significantly and materially different across categories.

Building consistent client on-boarding procedures and flexible systems becomes essential. And when considering this in light of the fact that additional counterparty classifications are going to continue to crop up as the remaining G20 commitments are fulfilled, taking a cross-silo view of the procedures becomes crucial.

Change management – who needs to know?

Change can be unsettling, especially in a world where the penalties associated with not changing the business can threaten the ability of the business to operate.

Ask anyone involved in a derivatives reform programme and they’ll tell you there have been a few hairs turned to grey over the past year. These regulations may have been intended to bring transparency to the market, but they certainly weren’t intended to be simple. Nevertheless, they are becoming so entrenched in the way banks operate and they’re impacting daily operations to such an extent, that pretty much everyone working in the bank needs to have a basic knowledge of the regulation and its impact.

One of our investment banking clients has itself a set of clients who are small-medium sized corporates and who, by the nature of their business, are indirectly impacted by these regulations. Very few of them have dedicated Compliance departments, and so they look to their investment bank for advice in understanding their obligations under the legislation. Naturally, the sales team and client account managers at the bank can’t be giving their clients legal advice because the implications of giving the incorrect advice is far too great. That said, client-facing staff certainly do need to have some training in the regulation to understand, at a minimum, which of their clients could be impacted.

Change management is a very important aspect of any programme of work, and this is no exception. Building a work stream into the programme structure which is dedicated to internal communications, including training, is a very important part of a compliance change programme.

Navigating these stormy waters needs great captains. Who is steering your ship?

To effect sizable change, it is necessary to have engaged, courageous and inspirational leadership.

As with any complex change programme, a regulatory programme needs a group of people at the helm who are accountable for making these important decisions. They are the folk who know that it’s necessary to change the business model to prevent losing US clients, or that implementing a new confirmations system isn’t in line with the overarching business strategy, or that a decision is so significant it needs to be escalated to the organisation’s executive committee.

There are inevitably a multitude of these decisions which will need to be made over the course of a regulatory programme’s lifetime and so it’s important that the Steering Committee or Project Board is comprised of all the right representatives (Operations, Front Office, Compliance, Risk etc.) and that they’re kept informed of all the risks.

In this continuously changing landscape with so many moving parts it’s not always easy to see the wood from the trees, and so how the project team work together and engage their governing body becomes all the more important.

“Compliance speak” is different from “business speak” and “IT speak”. How do teams bring together their expertise to deliver pragmatically?

There is a need for someone who can ensure that there is a common understanding across the various stakeholder groups. Typically, this is a BA’s role.

Let’s illustrate with an example. Under Dodd-Frank and EMIR, only certain types of trades are considered “reportable”. There’s a specific legal phrase in the technical standards which identifies whether the trade is within the regulatory scope and therefore reportable or not. Consequently, IT needs to have a set of rules that can be built into code in order to identify which trades to report.

The first question from IT in this instance will be ‘How do we determine whether the trade is physically delivered or not?’. There is a need to identify which attributes of the trade entity in the system can be used to determine this.

Legal’s response will inevitably be that it depends on the situation and on what the counterparty’s intention is at the time of entering into the legal agreement. Do they intend to take physical delivery? Would the bank commit to delivering $500k in gold at the end of the contract? Or are they more likely close it out and enter into a new agreement – keep it rolling? In most instances this level of detail would be captured in the legal terms of business, not flagged in any trading system.

Of course, whilst this response is accurate, it’s not conducive to building system rules. A pragmatic solution is required from the BA to do further analysis of the trade data to be able to identify whether there are in fact any specific attributes which could be used to identify these types of trades, or whether changes to the trade systems are required to encapsulate this requirement.

The post Making sense of chaos in the compliance space appeared first on BSG (UK).

The post Understanding Dodd-Frank appeared first on BSG (UK).