“energy defaults may be the new subprime!” See details on FTAlphaville here.
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.
In this example the commodity bank does not have integrated front office and credit systems, at least not on a synchronised basis i.e.: front office m to m = t+1, credit risk t+2. (more widely, the inability to generate ‘real time’ profit & loss reporting is a problem for most banks with global profit centres)
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.
The old approaches won’t work. A data warehouse copies the data from both systems into another database. As soon as data is copied and changed in format more complexity may be created. When another requirement with a new view point arises the data has to be copied again. This process is time consuming, open to error and usually does not leave an audit trail.
Model DR provides a new approach
Leading global banks are responding with new thinking about their data architecture and data management.
There are three big ideas:
- The congruent panopoly
- A global language
Model DR adopts the three big ideas and includes the following modelling features:
- data transformations are not applied.
- congruence by data point model, not physical data storage structures.
- data is used in As-Is format for processes like reporting and analytics.
Model DR 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’
Model DR 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 Model DR industrialisation process:
- assists banks to improve data quality
- demonstrate full traceability
- react proactively with information assets, not reactively
- meet regulatory demands for strategic, not tactical, solutions
Part 3: Worked examples
1: Data integration using Model DR
THIS NEED S TO BE RE WORKED it is not ‘WOW’ enough — if it was me and i was presented with this – i would continue to drop everything into a spreadsheet and splice up as i have always done –just not u but at the moment — it need s to demonstrate how good the DPM is — i think this will be achieved if you follow the steps below
1. credit system details
counterparty – trade date – credit exposure expiry date- volume – dealt price -current price (t+2) – total $ exposure – credit exposure
2. dealing system details
counterparty – trade date – settlement date – price fixing date – volume – dealt price -current price (t+1) – total $ exposure – marked to market p & l
you need to build a more complex DPM relationship and then point out how the congruent viewpoint has been created – particularly as the new view point has to provide a same day m to m (t+0)
everything below is ok – will just need re tooling once the new DPM is created[raw] [column size=”1/7″] [/column] [column size=”2/7″] [/column] [column size=”1/7″] [/column] [column size=”2/7″] [/column] [column size=”1/7″ last] [/column] [/raw]
Wire both models together into a congruent third view point in three steps:
- Transform both structures to data point model form.
- Define the logic of how the oil volume between the two views is related.
- Wire the data points from the three perspectives together.
Highlights of the new integrated view include:
- The new concepts “Congruent trade” has some attributes from both systems – the identifiers from both, the volume of oil from the credit system and the trading data from the front office system.
- The “Trade Date” and the “Transaction timestamp”, although having different names, are both defined as “Event times” in the global language. The data point model has the smarts to know that if “Trade Date” is equivalent to “Event time” and “Transaction timestamp” is equivalent to “Event time” then “Trade Date” is equivalent to “Transaction timestamp”.
- While the credit system keeps oil volumes in barrels and the front office systems used tons, the integrated viewpoint includes “Tons to Barrels transform”. The DPM has the smarts for the end users to be able to use either.
- Queries, reports, extracts and other process can now be written against the integrated data point model. Thus, they are written against a congruent view of both systems.
- The ModelDR data point model tool can be used to generate these solutions or they can be developed in existing tooling using the data point model as a specification.
If you would like to explore further how we and leading banks solve these problems, please contact us for an obligation free webinar with one of our world class practitioners. [button color=”default” link=”../contact” size=”default” target=”_self” block=”false”]Email us[/button] [/panel]