UMR Phase 5 and 6 – Navigating The Complexities and Costs

Phase 5 of UMR is scheduled for September this year, with phase 6 going live in September 2022. This means that Newly In-Scope Counterparties (NISC) should be making sure that they are ready for the start of exchanging margin. Firms may already be familiar with exchanging variation margin, but the requirement to post two-way initial margin on their bilateral trading is going to add a new layer of complexity and costs.

Just how complex and costly is it going to get? There are plenty of experts who will tell you what you need to do to be ready for UMR.  And they all include a very long list of requirements, including exchanging detailed information with counterparties, using middleware solutions to validate margin, developing processes for dispute resolution and implementing complex IT solutions to support these tasks. The question though is “are all of these required?”

The solutions currently used were designed to support the larger players caught by the first four phases of UMR implementation. However, the firms impacted by phases 5 and 6 are much smaller. They execute far fewer trades and therefore the margin requirements are less volatile, and should be easier to reconcile. These NISCs also want to spend less and they don’t have the resources to support multiple systems and interfaces.

There must be a simpler solution. But before we consider that, we should first look at what firms are being told they need to do. A good example to take would be the documentation provided by ISDA.

ISDA provides a whole series of different publications available here Initial Margin Implementation & Processes – International Swaps and Derivatives Association

One of the most obvious to look at is “Unclear Margin Rules Project Checklist and Controls”. This lists nearly 60 tasks required for NCISs to be ready for UMR. However, given the smaller scale of the newly impacted firms, and that this is an updated version of the checklist produced for the first phases of UMR, it is worth questioning whether all the suggested tasks are either necessary or sensible.

There are 11 separate tasks listed for initial margin calculation alone, with a further 5 for risk and dispute management. The detail provided in this document though is much less prescriptive than that in “SDA-SIFMA-Initial-Margin-Phase-in-White-Paper originally July-2018” (which was written when Phase 5 and 6 were to be implemented in 2019 and 2020).

The document details a number of key requirements for NISCs around margin calculation covering connections to middleware providers, and testing and onboarding of the same. Here are just some sample extracts, which imply the need for a particular solution:

 

  • “Currently, in-scope swap dealers exchanging initial margin (largely under SIMM) use a single middleware reconciliation service provider to help them review and identify sources of disputes regarding initial margin calculations.”
  • “Standardization of the reconciliation process is critical to the reduction of counterparty risk. Without common and robust initial margin reconciliation and processing venues, initial margin management across a large number of market participants would be impracticable.”
  • “All connections will require testing for data integrity. Service providers will likely require consistent data from both counterparties in order to perform their calculation or reconciliation functionality.”

 

“Without such infrastructure providing a common interface and reconciliation scheme, initial margin dispute management would be an operationally burdensome and impractical task across multiple counterparty relationships”

This sample of statements from the document provides an onerous view of what would be expected of NISCs, and would be very costly for smaller firms to implement.  It’s easy to see why this type of infrastructure would be needed by the firms caught in the earlier phases of UMR, with lots of transactions and potential for dispute. But is it necessary between counterparties with a small number of portfolio changes on a daily basis?

Implementing a full middleware system may be excessive for some phase 5 and 6 NISCs, but there are still potential issues with margin calculation and reconciliation that will need a suitable solution to resolve.

On the assumption that the decision has been made to use SIMM as the margin algorithm, the first step to consider is the calculation of the sensitivities that form the basis of the margin calculation.

The “S” in SIMM may stand for standard, but there is no standard way in which the sensitivities are calculated as they are considered the inputs to the calculation and not part of the methodology.

It is almost inevitable that there will be differences in the sensitivities generated between the two counterparties trying to reconcile their margin. For options this would be expected if a different pricing model was used, but this can also be the case for simpler products. The bucketed PV01 generated for a plain vanilla swap is strongly dependent on the interpolation mechanism for example.

These sensitivities need to be output in CRIF, the standard format required for input into the SIMM model. The middleware systems will use this CRIF to try and reconcile on a trade by trade basis, but for this to work it will be necessary for everything to line up correctly, including trade IDs.

This is a complex process which is potentially prone to finding non-existent issues. It might highlight differences in sensitivities which, although significant in percentage terms for a given risk bucket, have very little impact on the overall margin calculated. This could just be that the risk has been allocated slightly differently between the 3M and 6M interest rate buckets for example.

This process for reconciliation is more complex than that which is currently used for cleared margin. This doesn’t necessarily make sense if you consider that the SIMM algorithm is simpler than the CCP algorithms. Additionally, It needs to be considered that this is a two way process, so it is in everybody’s interest for firms to get the calculation right, and not, for example, apply unexpected multipliers.

So what is the alternative? We would suggest that a more traditional process is used whereby the sensitivities are used to validate calls from counterparties by focussing on the change in margin:

 

  • Firms would receive the initial margin calls from their bank counterparties via statements in the traditional way.
  • These same statements should also include information on the margin being posted to them by the banks.
  • Implement a solution that performs a daily validation of the margin call (and the margin posted) by estimating the day-on-day change in margin using an approved SIMM calculator.

 

There are a number of reasons why this solution would be appropriate for the smaller firms captured by UMR phases 5 and 6:

 

  • Reconciling trade level sensitivities will generate unnecessary support noise, whereas the important thing is that the change in margin is what would be expected, given any change in portfolio and impact of market conditions.
  • Where it is difficult to calculate the sensitivities required as input to SIMM, and therefore to feed them into any middleware reconciliation solution, it would be possible to use Grid as a proxy for these parts of the portfolio. This would still allow the total margin requirement to be agreed to within an acceptable percentage.
  • This approach prevents clients from needing to sign up to an expensive and complex middleware reconciliation solution, whilst still having a mechanism to validate SIMM margin calls.

 

For the NISCs, where the volume of new trades or expiries is limited, a more traditional approach to margin call validation should provide a more efficient and cost-effective solution. A simple process that checks margin requirement changes and ensures that they reflect the daily change in risk of their portfolio will ensure that the correct margin is being charged under UMR, whilst reducing the cost of implementation and the ongoing support burden of trade level reconciliation breaks.