ISDA Publishes 2013 EMIR NFC Representation Protocol

Introduction

On 8 March 2013, ISDA published its “ISDA 2013 EMIR NFC Representation Protocol” (the “EMIR Protocol”), the purpose of which is to enable parties to amend ISDA Master Agreements to reflect their status under EMIR as either:

• • financial counterparties (FC);

• • non-financial counterparties to which the clearing obligation applies (NFC+), or

• non-financial counterparties to which the clearing obligation does not apply (NFC-).

Each adherent to the EMIR Protocol is required to make a repeating representation in relation to each transaction as to its status as either a Non-representing Party (i.e. an FC), NFC+ or NFC-. Broadly, if a misrepresentation occurs by virtue of the fact that an FC or an NFC+ represents incorrectly that it is an NFC-, the procedures detailed below will apply.

If the underlying transaction was eligible for clearing

If the deadline for clearing has not passed, the parties must use all reasonable efforts to make such changes to the transaction or take such other steps as will facilitate clearing by the applicable regulatory deadline. Note that this may involve a party making a “Balancing Payment” to the other party in order to reflect pricing differences (if any) which flow from the change of environment between cleared and non-cleared.

If the deadline for clearing has passed without clearing taking place, the consequences essentially depend on whether the parties have agreed a separate execution and give-up agreement which deals with the specific reasons why clearing did not occur in the instant case. If so, that agreement will dictate the consequences which flow from the failure to clear. If not, an Additional Termination Event, as further detailed below will occur.

If the underlying transaction was not eligible for clearing

In these circumstances, the parties should use all reasonable efforts to make such changes to the transaction or take such other steps as are necessary in order to comply with the EMIR risk mitigation regulatory technical standards (the “Risk Mitigation RTS”). This must be accomplished by the later of:

• • 6 business days following the date on which both parties became aware of the original misrepresentation, and

• the end of the grace period applicable to parties that were previously NFC- (and therefore not subject to the Risk Mitigation RTS), but have since become either an FC or an NFC+ (and so have now become subject to the Risk Mitigation RTS).

A “Balancing Risk Mitigation Payment Amount” may be payable by one party to the other party in order to reflect pricing differences (if any) which result from compliance with the Risk Mitigation RTS.

If the parties are unable to comply with the Risk Mitigation RTS by the applicable deadline, an Additional Termination Event, as further detailed below, will occur.

Additional Termination Event

If an Additional Termination Event occurs:

• any party which made a misrepresentation regarding its status as an NFC- will be an “Affected Party” for the purposes of the ISDA Master Agreement;
• both parties will be “Affected Parties” for the purposes of section 6(b)(iv) of the ISDA Master Agreement; and
• payments on early termination will be calculated on the assumption that:
  • • any Affected Party was NOT subject to the clearing obligation (whether or not this was actually the case); and
  • Loss will apply.

It is worth noting that neither a misrepresentation about NFC- status nor a failure to take action to modify a problem transaction will constitute an Event of Default pursuant to the underlying ISDA Master Agreement. In addition, the failure of a party to take action to modify a problem transaction will not prevent it from being able to designate an Early Termination Date as a result of the occurrence of an Additional Termination Event under the EMIR Protocol.

The drafting of the EMIR Protocol is rather opaque in parts to say the least.  In particular, identifying the correct notification that must be sent to an EMIR Protocol counterparty following a change of status can be problematic.  It is also difficult to track the obligations which flow from a breach of representation regarding NFC- status.  In an effort to break through the legalese, we have summarised both of these aspects of the EMIR Protocol in the form of a table (in the schedule below) and a process flowchart.  For any market participants who would like a copy of the flow diagram, please just drop me an email and I’ll happily forward it on.

 Schedule

Notifications to be sent on change of status

Current Status	Required Status after Notification	Notice to Serve
FC	NFC+	NFC+ Representation Notice
FC	NFC-	NFC Representation Notice
NFC+	FC	Non-representation Notice
NFC+	NFC-	Non-Clearing Status Notice
NFC-	FC	Non-representation Notice
NFC-	NFC+	Clearing Status Notice

Contact Us