Chapter Twenty Three

Operational Aspects

Documentation and Execution

IN THIS CHAPTER, WE COVER some of the operational aspects of risk management: documentation and execution. Other aspects will be covered under the general control and operations in Chapter 29 of the Toolkit in Part Five.

DOCUMENTATION

Risk management is a documentation-intensive exercise, but it can be implemented easily—if appropriate efforts are put into establishing or writing out the one-time documentation, the rest of the processes can work strongly and seamlessly. Table 23.1 provides documentation generally in place for purposes of robust risk management.

TABLE 23.1 Some Documents for Risk Management Execution

Of these, we will focus on the International Swap Dealers Association (ISDA) agreement that is the gold standard for markets and risk management related documentation.

ISDA FRAMEWORK OF DOCUMENTS

The ISDA framework of agreements has become a market standard for comprehensive coverage of over-the-counter (OTC) types of derivative and market-related transactions.

The framework comprises:

• Master agreement
• Schedules
• Transaction confirmations
• Definitions
• Credit support annex (CSA)

ISDA: Background

Major company and bank defaults have, over time, led to increasing awareness of credit risk. The need to standardise market terms and documentation and have simpler and more common forms of settlement, standardisation, and definitions as OTC global transaction levels increased led to the formation of the ISDA in 1985, and the subsequent drafting of the ISDA framework and set of documents. Adoption by banks and the largest institutions around the world have since led to more extensive use of the ISDA framework and set of documents.

The ISDA agreements are simply agreements between two counterparties to a transaction or a set of transactions related to capital markets and credit, usually derivatives. These transactions are usually executed as OTC trades. The counterparties can be both professional counterparties (i.e., banks, market makers, and financial institutions) and nonprofessional (e.g., corporate). The ISDA framework provides guidelines on the transactions and on its terms, calculation, settlement, jurisdiction, payments, and credit treatment. It also provides the way forward in case of default, dispute, or termination.

In many cases nowadays, a default under the ISDA master agreement could trigger default clauses of funding facilities (or vice versa), with severe consequences. Hence, many transactions under ISDA have now reached par status with other liability transactions.

The overall advantages that such standardisation provides are immense. The ISDA framework contains provisions to govern multiple transactions, provides for exchange of separate confirmations on each transaction, and includes provisions for determining market values in case of early termination. Overdependence on the master agreement, however, has tended to put undue pressure on the wording of the agreement itself and its execution. Also, the legal risk of no documentation before dealing and the suitability of the counterparties to enter into nonstandard transactions are cause for some concern.

ISDA Master Agreement

The ISDA master agreement is the basic agreement between two counterparties that governs the fundamental obligation and contractual provisions for transactions executed between them. This is usually a one-time agreement that is updated only in case of any major changes or renegotiation. As parties to a master agreement, participants do not need to redraft and execute new general terms and conditions every time they enter into a transaction.

The master agreement is the core around which the rest of the document structure is created. In usual practice, the preprinted master agreement is altered only to insert the names of the parties. Customisation happens through the schedule that contains elections, additions, and amendments to the master agreement.

Read in conjunction with the schedule, the master agreement puts out all general terms and conditions necessary to allocate the risks of the transactions between the parties.

Neither the master agreement nor the schedules generally include the commercial terms of each transaction. Once the master agreement and schedules have been executed, the parties can enter into numerous transactions by agreeing to the material commercial terms through separate confirmations under the ISDA framework, without having to revisit or redraft the underlying terms contained in the master agreement.

There are two versions of the ISDA master agreement:

Figure 23.1 provides some of the key themes in the master agreement and in the schedules.

FIGURE 23.1 ISDA Master and Schedules

Events of default as defined in the ISDA are critical to the smooth running of the transactions. When defined up front, any breach could trigger termination of the transactions under the ISDA. Corporates would do well to go through these events and clauses as defined in the draft and negotiate them with thought-out numbers. Some events of default could be:

• Failure to pay on time
• Breach of the agreement
• Defaults relating to documentation (especially the CSA)
• Defaults under specified transactions
• Covenant breaches
• Bankruptcy
• Insolvency
• Liquidation
• Merger without assumption
• Cross-default events

The concept of a single agreement—wherein the ISDA master agreement, schedules, and transaction confirmations are considered part of the same agreement—is integral to the framework and forms part of the netting-based protection offered by the master agreement. The fact that all transactions are one contract allows for them to be closed out with a single net amount payable, should a default occur.

ISDA Schedules

The ISDA schedule customises the general terms of the ISDA framework to relationships between the parties, including local jurisdiction legal and regulatory provisions. The schedule supplements the master agreement and allows the parties to tailor terms to suit. It also includes common provisions that are areas of focus, such as termination provisions, payment provisions (such as payment measures and methods), material threshold amounts over which certain events are categorised officially as a default, offices or branches through which parties can act, setoff clauses, and others.

Setoff provisions provide a party a certain degree of relief from the other party’s bankruptcy by allowing obligations due and from the other party to be set off (viz., to be able to net off receivables with payables and consolidate the net amount receivable/payable). However, they do not provide relief from exposure to future positions that have not yet become due. Hence, the ISDA framework allows for termination provisions, which permit a creditor to terminate and liquidate transactions in the event of the other party’s bankruptcy or default under the agreement.

The agreement and all transactions under it may be terminated upon the occurrence of specified events:

• An event of default (which, when it occurs for a party, allows the other party to terminate the master agreement and liquidate all transactions with the first party)
• Termination events (the result of the actions of a third party that could provide the affected party with a grace period to cure the termination event before the other party can terminate and liquidate the master agreement)

It is important to highlight the underrated concept of cross-default here. A party’s failure to fulfil unrelated financial or operational payment on a relevant due date could automatically lead to an event of default under the ISDA agreement if such an event is covered under the cross-default clause. The occurrence of a cross-default gives the nondefaulting party the right to designate an early termination date.

Threshold amounts—material amounts (whether specific amounts or percentages) over which defaults are triggered—and grace periods provide some relief to affected parties and gives them an opportunity to regularise the credit conditions under the ISDA. These usually vary depending on the credit rating of each party.

Credit Support Annex

The annex is an optional document that is gaining increasing use. It is included in cases where collateral or a third-party support is required to fulfil the credit requirements of the ISDA agreement or if the threshold amounts of the exposure under the ISDA agreement have been exceeded.

An annex contains provisions on the collateral, including posting, return, types, and treatment.

Transaction Confirmation

While a large percentage of transactions, especially deals booked between professional counterparties or between banks and corporates, are entered into over the phone (on recorded lines, at least at the banks’ side) or on secure messaging systems, such as Thomson Reuters, the transactions are deemed complete only once the physical confirmation is signed and agreed to between the two parties. This physical confirmation is a legal document and included as part of the ISDA agreement where applicable.

Depending on the legality and information security requirements of each counterparty, these transaction confirmations can be in the form of printed documents, faxes, or emails. The form of the confirmation is set out in the master agreement. In some cases, a little time is allowed for objections or amendments to be raised and made. Dates, amounts, rates, payment mechanics, and settlement details are included in confirmations, and these are usually exchanged at the time of entering into the transaction to minimise the possibility of a dispute.

It is strongly recommended that all entities that undertake these transactions thoroughly understand the ISDA document and get trained on it. The ISDA requires understanding of market practices and legal language; hence, companies work closely with their legal teams in formulating and negotiating this documentation.

EXECUTION

A few elements of the execution aspects of risk management transactions are discussed here.

Transfer Pricing

If the objective of the firm’s risk management is to reduce the volatility of factors to the overall business numbers, it becomes important to pass on the benefits to the business. If Treasury is a profit centre, a prudent practice would be to guarantee a specific rate based on which business results are reported, with the residual gain (or loss) of the market and risk management activities residual with Treasury. If Treasury is a cost centre, the dynamic becomes more relevant, since Treasury itself will not see the hedging impact on any of the lines that are all finally allocated to the businesses or countries.

In this case, it becomes important to earmark the effective rate that is being passed on to the business. Since practically in many cases it is cumbersome to book individual hedges for each entity, especially if there are a lot of transactions, usual practice at a centralised Treasury is to book the transactions with the bank once and to allocate the rates internally for the same legal entity with different businesses, or with the bank in case of multiple entities.

In the former case, the transfer price at which the rates are allocated to the businesses could become a sensitive issue, especially if rates have moved significantly. Which rates do you pass on to which business unit? How do you allocate the rates to ensure a fair allocation?

There are many approaches to this. The first, and perhaps the most fair, would be to use the weighted average rate for each set of transactions on a monthly basis. At the end of each month, that transfer-priced rate will be provided to the planning department to use as an actual rate for conversion.

One disadvantage of this method is that if the transactions are of shorter maturity—perhaps even cash transactions for same-day value—then the rates have to be booked on a first-come, first-served basis. Another concern would be if one of the transactions comes up for early delivery and has to be settled at the prevalent market rate. The difference between the cancellation or early pickup rate and the transfer-priced rate would then have to be passed on to the relevant business as well.

What is required for the success of these processes and mechanisms is a good system backed by a strong process that can accommodate this degree of complexity.

Controls

Controls are essential for the Treasury policy, especially the risk management side, to be implemented efficiently. Independence of front-, middle-, and back-office roles from the perspectives of responsibility, handoff, and organisational reporting is essential. The booking process is especially susceptible to error, given the complexity of the operation and the many access channels between the counterparties. Proper control processes can also capture operational errors on the side of the bank. A more detailed discussion on control is done in the Toolkit in Part Five.

Booking

The booking process also is an area of focus.

Typically, the dealer in Treasury has access to the indicative term sheets that are used for decision making and closure on structure and approximate pricing. When the dealer has discussed and gotten internal approvals, and with appropriate authorisation in place, he or she closes the transaction on the phone or on the dealing systems. Ideally, the phone lines are recorded at the corporate Treasury, subject to legal conditions and relevant procedures. On the initiation of the deal, the dealer books the transaction in the system or originates a deal ticket. This is used for the basis of booking the deal in the back end and verified with the actual transaction confirmation under the ISDA, which should always be sent to independent operations. For a stronger process, even the operations team of the corporate can create a confirmation and send it to independent operations at the bank’s end. The deal is then verified and recorded in the system.

Delivery

The delivery process, like the booking process, is also independent of the front office or dealer. The operations teams from both ends liaise with each other to close the process. In case of a complicated transaction, the dealer may provide inputs but in no way should be allowed to handle the settlements or provide or influence reports based on which settlements are due to occur.

SUMMARY

We have covered some key practical aspects of control, operations, and execution in this chapter. A more detailed overview on controls and processes is given in the Toolkit in Part Five of the book.