Testing Counterparty Risk Systems

View Presentation or Alternative Download Site

Ahh the world of the OBSI (Off Balance Sheet Instrument) can be a domain full of opacity and while the regulators have been looking to reduce conspicuousness of OTC (Over The Counter) trading practices, investment banks themselves often struggle to embed a pellucid system for measuring counterparty risk.

Like all things, if you want to improve something you are probably going to have to change the way it works or perhaps the way the business works with it.  Additionally investment banks are continually inventing new structured products to capture unique market opportunities or to differentiate themselves from other players in the market and regulators are putting a lot of emphasis on reporting position, depth and leverage for risk – well depth and leverage may not be done cleanly but that requirement will come in time.

Click to read more on how we go about testing counterparty risk systems.

Complexity of Counterparty Risk

Counterparty risk is itself nebulous in the debate around confusion in the derivatives market because of its unique complexity and scope.  There are also several reasons why this risk function is so difficult to operate, modify and improve which can be summarised in the following statement:

"Counterparty Risk has a wide scope across the organisation and web like tentacles that touch so many departments including but not limited to finance, positional exposure monitoring, regulatory reporting, liquidity management, treasury, deal structuring and clearance."

A counterparty risk system takes feeds from the front office yet passes deal clearance confirmations back to the trading room and it is inexorably interconnected with pricing, middle office, settlement and collateral management.  It is also becoming central in Credit Value Adjustment (CVA) and credit hedging.

Simply as a function counterparty risk creates a total risk value for each counterparty by convoluting a netted potential future exposure (PFE) calculated from position taking and the market value on the trading platform, then it combines that number with the probability of default from the credit scoring system. These are unique metrics as we know however they are gathered from different ends of the business - The PFE from the trading systems and the credit score from the credit officers.

To darken the world slightly, there isn’t much published on this risk discipline, either out there in cyberspace or in the bookshop.  Perhaps one of the best summary basic documents on what is truly required from a counterparty risk function can be found here on this quite dated yet concise ISDA white paper. Even though I classify this as a summary, it is over fifty pages of reading.

 

Testing Counterparty Risk

When a bank introduces a new tradable instrument which is often or there are changes to regulation which is likely to be frequent post credit crisis, actually, if there is any modification to a component (product, system or policy) that feeds in or out of the counterparty risk labyrinth; then the core counterparty system itself needs strict regression testing.   For those that are not familiar with testing risk systems or regression testing this link flicks to a definition.  This is a process by which one seeks to uncover software glitches due to changes that are made in one part of the functional service driving faults in another discrete area of the system, possibly somewhere else in bank in this case.

  
The most common technique for regression testing revolves around executing a set of test scripts that walk an analyst through a step of actions that should generate an expected outcome that is commonly known. This outcome needs to be accepted and approved by the business when specific data is passed into the counterparty risk system and referred back to the business.  If say a currency curve used for fitting an exposure is changed or its source is altered, outputs such as regulatory reporting or exposure monitoring can also be impacted. This is because these reports also use an exposure calculation engine which is dependent and sensitive to the FX rates data.

The General Experience

A test cycle can actually take days and involve hundreds of people; like cooking a meal, a lot time needs to go into preparation.  In each case the test environment needs to be carefully configured and that is often shared amongst many teams in the bank.  Then if the test outcome is unfavourable which can often be the case because there are so many moving parts, the counterparty risk analyst has to run another set of test cycles.  

The most complex areas of testing generally sit around valuing the PFE and CLU numbers which have to be outside an error band.  

"The definition of what is correct or what the test output should be valued at is also not that straight forward to define. This is driven by diversity of pricing algorithms and there are often several debateable ways in which some instruments can be valued - In reality, moving goal posts are hard to test against."

Structured / exotic deals which have many cash flows often with optionality, can be particularly problematic to assimilate in the system.  Rates trades can have breaks and FX options on currencies in an emerging market are often settled as Non Deliverable Forwards and should be priced on a different NDF curve.

I have taken to write a small paper on the method for testing a counterparty risk system.  This can be found by following this link view presentation.

I would also be interested in hearing from other credit and counterparty risk analysts on their perspicacity around this topic.