Worked example

Many global banks are significant financiers of the commodity sector. Banks provide commodity loans to commodity producers and traders secured by the underlying commodity.  At the same time as the commodity finance is extended, the commodity bank secures the loan by simultaneously hedging the commodity price exposure.

The reality for many banks is that their front and back office risk management systems are neither integrated nor significantly robust to manage a swift or significant change to underlying price risk. The recent collapse of oil prices has impacted upon not just unhedged oil positions, but debt and fx exposures, together with heightened sovereign risk from oil exposed currencies.  Credit exposures increase just as significantly as underlying commodity exposure, particularly amongst the more highly leveraged oil producers or exposed trade houses.

The commodity bank does not have integrated front office and credit systems. For example the front office systems are reporting t+1 and the credit risk systems t+2.

An oil price collapse occurs. The bank has many customers with ‘over the counter’ oil, FX & interest rate swaps, including oil producers, commodity trade houses & airlines.  

Regulators require both timely and accurate reports. Regulators want accurate market and credit risk exposures for oil exposed portfolios.  The reports have to be produced on a ‘same day marked to market basis’ or  six hours (t+0)  after the NY close of WTI futures.

The commodity bank cannot produce the required reports by the deadline. Without a congruent data viewpoint, disparate data from front, middle and back  office dealing and credit risk systems cannot be both aggregated and integrated.

Why? The bank does not have data congruence across its systems:

  • Structures: Whilst the trade detail and price data for each transaction is the same there may be differences in the way it is captured and recorded. Simple things might be one system using barrels and the other tons.
  • Scope: Risk data in both systems can vary according to predetermined algorithms and the type of exposure being measured (credit vs market)
  • Meanings: Labels and terms in each system can be different, or carry differing interpretations
  • Timings: Each system can have differing times for ‘end of day cutoff’ (t+0, t+1, t+2).
  • Identifiers: Counterparty classifications may be different in the two systems, creating complex matching problem.

 

In the worked example we present three big ideas:

  1. The congruent panoply
  2. A global language
  3. Industrialisaton

 

ModelDR achieves data congruence by separating the ‘wiring’ of the data from the data itself. The Data Point Model (DPM) allows the data design to be broken into its smallest parts; the data points. The DPM provides the tools to redesign the viewpoint by rewiring the data points together in a Model DR designed ‘congruent panopoly’

ModelDR uses the DPM to redesign or ‘industrialise’ the data. Financial institutions have countless business processes and systems. Each process and system has many thousands of concepts, rules and data points.  By ‘industrialising’  myriad data systems through the adoption of Model DR, banks are able to build new system architecture and, most importantly, satisfy regulatory demands for an ‘end to end’ data governance framework.

 

The ModelDR industrialisation process:

  • assists banks to improve data quality
  • demonstrates full traceability
  • reacts proactively with information assets, not reactively
  • meets regulatory demands for strategic, not tactical, solutions

In the example, we show how existing systems are reverse engineered and a new, congruent viewpoint built.