DRS’ Michael Beaton explores.
Time to Get a Handle on 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 (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. 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.
“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.
The nature of “detailed records”
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” as well as “maintained” and “retained” on an “ongoing basis”. It must be made available and transmitted to authorities within any requested timeframe. 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, particularly the power to temporarily suspend termination rights. 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;
- 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.
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’. 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”, “Termination Right”, “Master Agreement type” and “Master Agreement version”. Other data points will be sourced from confirmations, such as “Effective Date”, “Maturity Date” and “Termination Date”. Yet other data will have to come from internal systems, such as “Country of the other Counterparty”, “Value of contract” and collateralisation information. 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 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” 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.
|
|
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 |
