BRRD Transaction Reporting: Understanding Your Financial Contracts

Introduction

On 7 June 2016, the EU Commission adopted a Delegated Regulation (and related Annex) specifying a minimum set of information on financial contracts that must be maintained by institutions and the circumstances in which the requirement should be imposed, as required by Article 71(7) of the Bank Recovery and Resolution Directive^[1] (BRRD).  If neither the EU Council nor the EU Parliament object, the Delegated Regulation will enter into force 20 days after its publication in the Official Journal of the EU.  This is currently expected to take place towards the end of Q3 / beginning of Q4 2016.

Scope

Broadly, an institution which is subject to the BRRD is required to maintain “detailed records” of “financial contracts” where its resolution plan contemplates that it would be subject to resolution rather than standard insolvency proceedings^[2].  Institutions that are likely to be placed into insolvency are not automatically subject to the requirement, but this does not prevent authorities from imposing the same or similar requirements on them.^[3]

“Financial contracts”

The definition of “financial contract” is very wide.  It includes (a) securities contracts, (b) commodities contracts, (c) futures and forwards contracts, (d) swap agreements, (e) inter-bank borrowing agreements where the term of the borrowing is three months or less, and (f) master agreements for any of the aforementioned.^[4]

The nature of “detailed records”^[5]

The Delegated Regulation specifies only a minimum – and not an exhaustive – set of information which should be maintained by firms.  This is intended to strike a balance between the need to achieve an appropriate level of convergence in record keeping whilst enabling authorities to impose additional requirements where considered appropriate.    The Annex to this article provides a full list of the required data points, together with a suggestion of where each point of data may be sourced in practice.

Information should be “collected in advance”^[6] as well as “maintained”^[7] and “retained”^[8] on an “ongoing basis”.  It must be made available and transmitted to authorities within any requested timeframe.^[9]  There is no prescribed format or template in which data is to be maintained or provided to authorities but it remains open to authorities to specify one.

Verdict: does it achieve its purpose?

In part.  The requirement is designed to support the effective and efficient application of resolution powers and resolution tools with regard to institutions with different types of business^[10], particularly the power to temporarily suspend termination rights.^[11]  The current data set will certainly help to monitor the build-up of exposure within the financial system.  Authorities will also be able to understand whether certain barriers to resolution exist (such as the absence of a contractual bail-in clause in a contract governed by a non-EU governing law).  However, the Delegated Regulation suffers both from a lack of coverage and a lack of detail.  By way of example, under the BRRD, the power to temporarily suspend the termination rights of:

• a counterparty to an institution under resolution – is contingent on the party under resolution continuing to perform its payment, delivery and collateralisation obligations^[12];
• a counterparty to an institution which benefits from a parent company guarantee (or other form of credit support) in circumstances where the credit support provider is under resolution – is contingent upon (a) the termination rights being based solely on the insolvency or financial condition of the parent; and (b) the resolution authority having transferred all of the assets and liabilities of the subsidiary or having provided the counterparty with some other “adequate” form of protection^[13].

If these conditions are not met, the resolution authority has no right to suspend termination rights.  As such, in order to effectively monitor the way in which they can exercise their powers, resolution authorities must understand in detail (a) the nature of payment/delivery/collateral obligations within each financial contract, (b) parent company credit support arrangements, and (c) termination rights.  One glaring omission from the data points to be maintained by firms in relation to (a) would seem to be information regarding ‘payment dates’ under the transaction in question.  There is also a complete absence of information relating to parent company credit support arrangements.  In addition, we have, as yet, no guidance on how to capture ‘Termination Rights’^[14].  This clause requires firms to indicate whether a counterparty’s termination rights in relation to a financial contract are based on the firm’s insolvency or financial condition.  However, in practice, there may be a number of clauses that are potentially in scope under this heading – some of which are highly complex in nature – such as bankruptcy Events of Default, Cross-Default, Credit Event Upon Merger, ratings downgrade triggers and ‘MAC’ clauses.

The practical compliance challenge

Compliance with the Delegated Regulation creates a number of practical challenges.  Chief amongst these is the fact that the data points which must be maintained are likely to come from many sources, all of which will have to be monitored on an on-going basis.  A number of data points will have to be mined from master agreements – including “Governing law”^[15], “Termination Right”^[16], “Master Agreement type”^[17] and “Master Agreement version”^[18].  Other data points will be sourced from confirmations, such as “Effective Date”^[19], “Maturity Date”^[20] and “Termination Date”^[21].  Yet other data will have to come from internal systems, such as “Country of the other Counterparty”^[22], “Value of contract”^[23] and collateralisation information^[24].  More problematic, some data will have to be sourced externally.  For example, in practice, contractual recognition of bail-in, suspension of termination rights and application of resolution powers provisions^[25] will often have been incorporated into documentation by way of one or more ISDA protocols.  The extent to which firms routinely, consistently and continuously monitor changes in protocol data is, at best, questionable, bringing into question the accuracy of data in this area.  Perhaps most challenging of all, the “Type of liability/claim”^[26] data point will require firms to analyse transactions against complex and vague regulatory requirements, namely the bail-in provisions of the BRRD.

How we can help

DRS specialises in helping clients which have documentation and data that needs to be managed.  Our contract analytics capabilities enable clients to rapidly and efficiently gain both insight into contractual obligations and comfort regarding regulatory compliance.  We can help you to understand the requirements of Article 71 of the BRRD and to both scope and implement your plan to comply.  Our services directly impact the bottom line by facilitating smarter business decisions – mitigating risk, strengthening compliance, unlocking commercial opportunity and improving operational efficiency.  They are particularly well-suited to those firms without the permanent headcount to resource projects of this type or the appetite to recruit, train and manage significant numbers of temporary staff.

 

Annex

	Field	Description of information to be maintained in detailed records of financial contracts	Data Source
	Section 1 – Parties to the financial contract
1	Record keeping timestamp	Date and time of record entry	System generated
2	Type of ID of the reporting counterparty	Type of code used to identify the reporting counterparty	Other internal system
3	Reporting Counterparty ID	Unique code (Legal Entity Identifier (LEI), where available) identifying the reporting counterparty.	Other internal system
4	Type of ID of the other counterparty	Type of the code used to identify the other counterparty	Internal KYC system
5	ID of the other counterparty	Unique code (LEI, where available) identifying the other counterparty of the financial contract. This field shall be filled from the perspective of the reporting counterparty. In the case of an individual, a client code shall be used in a consistent manner.	Internal KYC system
6	Name of the reporting counterparty	Corporate name of the reporting counterparty. This field can be left blank where LEI is used to identify the reporting counterparty	Other internal system
7	Domicile of the reporting counterparty	Information on the registered office, consisting of full address, city and country of the reporting counterparty. This field can be left blank where LEI is used to identify the reporting counterparty	Other internal system
8	Country of the other Counterparty	The country code of the country where the registered office of the other counterparty is located or, if the other counterparty is a natural person, of the country of residence	Internal KYC system
9	Governing law	Identify the law governing the financial contract.	Legal agreements database
10	Contractual recognition – Write down and conversion powers (only for contracts governed by third country law subject to the requirement of the contractual term under the first subparagraph of Article 55(1) of Directive 2014/59/EU)	The contractual term required under Article 55(1) of the Directive 2014/59/EU When such contractual term is included in a master agreement and applies to all trades governed by that master agreement, it can be recorded at the master agreement level.	Legal agreements database / Protocol data
11	Contractual recognition – Suspension of termination rights (only for contracts governed by third country law)	The contractual term by which the creditor or party to the agreement creating the liability recognises the power of the resolution authority of a Member State to suspend termination rights. When such contractual term is included in a master agreement and applies to all trades governed by that master agreement, it can be recorded at the master agreement level.	Legal agreements database / Protocol data
12	Contractual recognition – Resolution powers (only for contracts governed by third country law)	The contractual term, if any, by which the creditor or party to the agreement creating the liability recognises the power of a Member State resolution authority to apply resolution powers other than those identified in fields 10 and field 11. When such contractual term is included in a master agreement and applies to all trades governed by that master agreement, it can be recorded at the master agreement level.	Legal agreements database / Protocol data
13	Core business lines	Identify which core business line or core business lines the financial contract it relates to, if any.	Trade capture system
14	Value of contract	Mark-to-market valuation of the financial contract, or mark-to-model valuation used in application of Article 11(2) of Regulation (EU) No 648/2012 and reported in application of Article 9 of Regulation (EU) No 648/2012 and delegated and implementing regulations adopted thereunder. The CCP‘s valuation to be used for a cleared trade.	Trade capture system
15	Currency of the value	The currency used for the valuation of the financial contract	Trade capture system
16	Valuation timestamp	Date and time of the last valuation. For mark-to-market valuation, the date and time of publishing of reference prices shall be reported.	Trade capture system
17	Valuation type	Indicate whether valuation was performed mark-to-market or mark-to-model or provided by the CCP.	Trade capture system
18	Collateralisation	Indicate whether a collateral agreement between the counterparties exists. Where the financial contract is covered by the reporting requirements under Article 9 of Regulation (EU) No 648/2012 and delegated and implementing regulations adopted thereunder, information on collateralisation shall be provided as required by those requirements.	Legal agreements database
19	Collateral portfolio	Indicate whether the collateralisation was performed on a portfolio basis. Portfolio means the collateral calculated on the basis of net positions resulting from a set of contracts, rather than per trade.	Collateral management system
20	Collateral portfolio code	If collateral is reported on a portfolio basis, the portfolio should be identified by a unique code determined by the reporting counterparty.	Collateral management system
21	Initial margin posted	Value of the initial margin posted by the reporting counterparty to the other counterparty. Where the initial margin is posted on a portfolio basis, this field should include the overall values of the initial margin posted for the portfolio.	Collateral management system
22	Currency of the initial margin posted	Specify the currency of the initial margin posted	Collateral management system
23	Variation margin posted	Value of the variation margin posted, including cash settled, by the reporting counterparty to the other counterparty. Where the variation margin is posted on a portfolio basis, this field should include the overall value of the variation margin posted for the portfolio.	Collateral management system
24	Currency of the variation margin posted	Specify the currency of variation margin posted	Collateral management system
25	Initial margin received	Value of the initial margin received by the reporting counterparty from the other counterparty. Where the initial margin is received on a portfolio basis, this field should include the overall value of the initial margin received for the portfolio.	Collateral management system
26	Currency of the initial margin received	Specify the currency of the initial margin received.	Collateral management system
27	Variation margin received	Value of the variation margin received, including cash settled, by the reporting counterparty from the other counterparty. Where the variation margin is received on a portfolio basis, this field should include the overall value of the variation margin received for the portfolio.	Collateral management system
28	Currency of the variation margin received	Specify the currency of the variation margin received	Collateral management system
	Section 2a – Financial contract type
29	Type of the financial contract	Classify the financial contract according to Article 2(100) of Directive 2014/59/EU	Other internal system / manual review
30	Financial contract ID	Unique trade ID where the financial contract is covered by the reporting requirements under Article 9 of Regulation (EU) No 648/2012 and delegated and implementing regulations adopted thereunder. For any other financial contract, ID assigned by the reporting counterparty.	Trade capture system
	Section 2b – Details on the transaction
31	Effective date	Date when obligations under the financial contract come into effect.	Trade capture system
32	Maturity date	Original date of expiry of the reported financial contract. An early termination shall not be recorded in this field.	Trade capture system
33	Termination date	Termination date in the case of an early termination of the reported financial contract. If not different from maturity date, this field shall be left blank.	Trade capture system
34	Termination right	Indicate whether the other counterparty’s termination right under the reported financial contract is based on the insolvency or financial condition of the institution under resolution. Where such contractual term is included in a master agreement and applies to all trades governed by that master agreement, it can be recorded at the master agreement level.	Legal agreements database / confirmations
35	Master Agreement type	Reference to the name of the relevant master agreement, if used for the reported financial contract (e.g. ISDA Master Agreement; Master Power Purchase and Sale Agreement; International ForEx Master Agreement; European Master Agreement or any local master agreements).	Legal agreements database
36	Master Agreement version	Reference to the year of the master agreement version used for the reported trade, if applicable (e.g. 1992, 2002, etc.).	Legal agreements database
37	Netting agreement	If the financial contract is a part of a netting arrangement as defined in Article 2(1)(98) of Directive 2014/59/EU, a unique reference of the netting arrangement.	Legal agreements database
38	Type of liability/claim	Indicate whether liabilities arising from the financial contract are: Entirely excluded from bail-in pursuant to Article 44(2) of Directive 2014/59/EU; Partially excluded from bail-in pursuant to Article 44(2) of Directive 2014/59/EU; Not excluded from bail-in pursuant to Article 44(2) of Directive 2014/59/EU.	Legal Analysis
	Section 2c – Clearing
39	Clearing obligation	Indicate whether the reported financial contract belongs to a class of OTC derivatives that has been declared subject to the clearing obligation and both counterparties to the contract are subject to the clearing obligation under Regulation (EU) No 648/2012, as of the time of execution of the financial contract.	Trade capture system
40	Cleared	Indicates whether clearing has taken place.	Trade capture system
41	Clearing timestamp	Time and date when clearing took place.	Trade capture system
42	CCP	In the case of a financial contract that has been cleared, the unique code for the CCP that has cleared the financial contract.	Trade capture system
43	Intragroup	Indicate whether the financial contract was entered into as an intragroup transaction, defined in Article 3 of Regulation (EU) No 648/2012.	Trade capture system

 

 

 

 

 

[1] Directive 2014/59/EU

[2] Article 1

[3] Article 1(2)

[4] BRRD, Article 2(1)(100)

[5] Article 2 and the Annex

[6] Page 2 of Explanatory Memorandum to Delegated Regulation

[7] Article 2(1) of the Delegated Regulation

[8] Article 2(1) of the Delegated Regulation

[9] Article 2(3)

[10] Page 3 of Explanatory Memorandum to Delegated Regulation

[11] BRRD, Article 71(1)

[12] BRRD, Article 71(1)

[13] BRRD, Article 71(2)

[14] Data point 34

[15] Data point 9

[16] Data point 34

[17] Data point 35

[18] Data point 36

[19] Data point 31

[20] Data point 32

[21] Data point 33

[22] Data point 8

[23] Data point 14

[24] Data points 18 to 28

[25] Data points 10-12

[26] Data point 38

Contact Us