By Phil Walsh
Following Openlink’s acquisition of CubeLogic, it is perhaps not entirely clear for Openlink clients as to the respective merits of Endur/Findur and the Credit Cube with regards to managing credit risk. In this article I attempt to provide clarification by comparing the two Openlink applications’ support for the following, key functional requirements for credit risk analysts:
- Reference Data Management
- Limit Management and Exposure Calculations
- Margining Management
- Netting Framework
- Data Interrogation and Reconciliation
- Exposure Consolidation
Reference Data Management
The Credit Cube’s front-end supports inputting a rich level of counterparty credit management related data. Given that the Credit Cube is distinctly designed to act as a credit risk application that is fed with data from an upstream trading application, as part of its integration framework it’s also relatively straightforward to automatically create new counterparties once entered into the source trading system.
Endur also supports inputting a wide array of counterparty reference data. Endur’s primary advantages for managing reference data are:
- The ability to extend the data model for objects such as legal entities, trading and collateral agreements, the trades themselves and for this additional data to be embedded within queries, reports and exposure monitoring largely as though the reference data was captured using standard attributes;
- Through its TPM (Trade Process Management) framework, interdepartmental (e.g. back office, credit, compliance, legal and credit) workflows can be constructed for creating and maintaining counterparty reference data.
Limit Management and Exposure Calculations
With regards to setting limits and monitoring exposures against limits, the Credit Cube is ready made to support common requirements for energy trading organisations, such as volumetric, settlement and/or MTM limits. Historically, whilst also possible to construct ‘exposure definitions’ within Endur to monitor limits against the same exposure values, some level of customisation was required. More recently, however, ‘standard packages’ are available from Openlink which reduce if not remove the need for customisation of standard exposure measurement and limit monitoring. In addition, Endur provides a much more powerful framework than the Credit Cube in this broad aspect of credit management for the following reasons:
– Ability to support a broader array of exposure calculations
Endur is shipped with a wide variety of financial and analytical calculations. It also provides a framework for embedding custom calculations and – regardless of whether standard or custom – calculations can be parameterised through simulation and scenario definitions (e.g. what-if scenarios, VaR methodology variants), with heavy calculations distributable to a computational grid.
The Credit Cube is primarily able to support monitoring of exposures that are calculated in the upstream trading application. It can support calculating exposures that can easily be derived or approximated from the source values, but this is limited compared to the wide array of financial exposures that can be calculated in Endur.
– Near/real-time limit monitoring of exposure
Endur offers a dedicated framework for monitoring limits in near/real-time, which can utilise the same underlying framework described in the previous point, but also allows for some approximation where it is not computationally feasible to fully re-run exposures for all trades on a frequent basis.
If real-time exposure monitoring is not a necessity, but some level of intra-day updates are required, the Credit Cube can be scheduled to be updated periodically through the day, although this still requires the source trading system to perform a good deal of the heavy lifting by re-calculating the underlying exposures (primarily MTM), which in turn also requires intra-day market data updates in the source trading system.
– Workflow management
In addition to the vanilla limit breach messaging in Endur, the TPM framework can be utilised to build sophisticated workflows around limit breaching for generating warnings, escalations, multi-level approvals and triggering collateral calls.
In relation to how exposures should be netted, related to the previous section, the Credit Cube again provides an easy framework for defining the common requirements for energy trading organisations: a simple netting framework where users select which trade types and trading products that are covered by the netting agreement and whether each of the three components of the overall exposure (MTM, Accrual and ARAP) should each be netted.
It can be argued that Endur provides more flexibility with regards to constructing netting logic than the Credit Cube, as ultimately netting logic can be customised if required using Endur’s APIs. However, at least from a usability perspective, Endur does not score as highly as it could as user interface netting parameters are disparately spread across a range of potential attributes: the legal entity, the credit exposure definition, the trading agreement, settlement definitions.
– Credit Support Annex
Whilst both applications support modelling of key features of CSAs, such as independent amounts, minimum transfer amounts, thresholds and rounding rules, the Credit Cube provides a more ‘out-of-the-box’ capability when defining CSAs, particularly for rating based threshold amounts. Equivalent modelling in Endur either requires non-trivial customisation or licencing of ‘additional packages’ on top of the core risk management framework.
The Credit Cube supports modelling cash and letters of credit as collateral, and calculating interest on cash deposits. In comparison, Endur has a far more extensive capability for modelling collateral and interest calculations, although this may be more than necessary for most energy trading organisations.
– Margin Calls
The Credit Cube is shipped with starting workflow and margin call letter examples, which may only require minimal extension to provide the user with a working margin call solution. In Endur, with its TPM framework, sophisticated margin call workflows can be constructed, yet this is not out-of-the-box.
The Credit Cube is very friendly and familiar to the end user for ad-hoc reporting given that the data is accessible in Excel pivot tables, via Analysis Services. The cube layer provides additional ‘intelligence’ beyond exposing the data fed from the source system and the reference data maintained in the Credit Cube itself, providing the end-user with features such as:
- Hierarchical pivoting for attributes such as legal entities, parent company guarantees and letters of credit;
- Derived exposures resulting from the netting agreement settings;
- Ability to convert trade level exposures to any user-selected currency;
- ‘Traffic light’ indicators of exposure status against limits;
- Forward time horizon views showing decaying of current exposures.
More formal, scheduled reports can be constructed using MS SQL Server’s SSRS, and more recently dashboard reporting can be provided via Tableau.
For Endur, there is a dedicated user interface for monitoring real-time limits, but the primary reporting tool from a credit risk perspective is RiskPak. RiskPak is an additional licensable analytics and reporting module that provides users with the following key capabilities:
- A wide array of off-the-shelf reports that can be run through the front-end, scheduled within the end-of-day workflow process or triggered through a TPM workflow;
- Run risk calculations not readily available through the core revaluation engine, such as PFE;
- Parameterise the reports through a wide range of input parameters, similarly to the core revaluation engine, but with enhanced ways of constructing stress test definitions.
Custom credit risk reporting can to some degree be built using the APIs shipped with the base application (JVS) but to build reports of similar sophistication to those provided in RiskPak requires an OpenComponents development licence.
Yet, for all the potential sophistication that Endur offers for credit risk reporting, the Credit Cube provides far greater appeal to end users for reporting exposures given the Excel pivot table outlet for the cube measures and dimensions.
Data Interrogation and Reconciliation
Given the Excel pivot table reporting capability, the Credit Cube provides – at least superficially – an appealing ability to be able to expand and drill-down to trade level exposures, input values and static data. Ultimately, though, reconciliation becomes more of an issue once the data is passed to a downstream application and it is only the source system which will provide the ability to retrieve the trade’s full details. Whilst Endur may not provide the ease of reporting drill-down that is achievable in the Credit Cube, Endur will not only easily provide the full trade details but also allow the user to retrieve previously computed financial values/exposures and perform on-the-fly what-if calculations.
A primary intention of the Credit Cube is to be able to consolidate credit exposures from multiple source trading applications. This is achieved by a combination of developing extracts from the source applications to adhere to a pre-defined table/file structure coupled with the Credit Cube’s ‘aliasing’ framework. Aliasing allows users to align source system trade attributes to a common naming convention, such as trade types, curves, books, counterparties.
Whilst Endur has an open technical framework, consolidating exposures in Endur from other trading applications typically involves attempting to re-model the transactions within Endur and associated custom trade interfaces to feed the trades from the source system to Endur. If there is a good reason why the trades are not being modelled in Endur in the first place, then it is questionable that the effort required to re-model the trades in Endur for credit risk management is likely to achieve the end requirement.
The Credit Cube provides an alternative and/or complimentary credit risk offering to Endur for energy trading organisations whose limit, workflow and collateral management requirements are relatively rudimentary. The Credit Cube can also be considered to be complimentary for existing Openlink Endur clients where there is a need to consolidate credit exposures with other trading applications, albeit again for managing the more basic risk management requirements. Where credit risk requirements are more complex, and Endur is the sole trading application, then Endur itself provides a more appropriate credit risk management platform.
Given that Endur itself does not provide risk users with the equivalent slicing-and-dicing, ad-hoc reporting capability of large volumes of trade level exposures as a MS SQL cube, it could be viewed that Openlink’s acquisition of CubeLogic is a way of providing a cube outlet for reporting its own credit-related data. However this is not a view that I share given the earlier point made that the Credit Cube can only receive data from the source trading application that is designed to do so. If attempting to close the gap between Endur and this type of reporting requirement, I would consider more of a general, non-credit risk specific gap that is well covered by my colleague Graham Roberts in his P&L reporting article.