Back Office Conference 02 10 2009


Published on

Marcus Evans presentation held in 2009

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Back Office Conference 02 10 2009

  1. 1. 2 nd Annual Back-Office Conference Establishing an efficient flow of information from the Front to Back Offices to minimize operational risk
  2. 2. <ul><li>Overhauling systems that hinder essential communication between the offices. </li></ul><ul><li>Standardizing methods of documentation to guarantee all are kept up to speed. </li></ul><ul><li>Examining practices for eliminating errors or ensuring that a discrepancy is immediately made known to all involved should one be found. </li></ul><ul><li>Making sure that the proper firewalls are in place so that fraud cannot occur. </li></ul><ul><li>Keeping the right people doing the right things at the right time. </li></ul>AGENDA
  3. 3. “ The ideal transaction processing system would be a seamless entity capable of passing deal data all the way from the front office to the back with no human intervention.” Obvious, but is it cost effective and a realistic ambition? Overhauling systems that hinder essential communication between the offices
  4. 4. <ul><li>Overhauling systems that hinder essential communication </li></ul><ul><li>between the offices ( continued ) </li></ul><ul><ul><li>Focus on what needs to be communicated and what data elements are needed. Avoid a situation where the tools set the rules, but steer towards an environment where the “rules defines the tools. ” </li></ul></ul><ul><ul><li>An overall data flow overview exist that displays the life cycle of a transaction regardless of implemented systems . </li></ul></ul><ul><ul><li>Straight through processing (STPI) should be considered to enhance the use of same types of files and data. </li></ul></ul><ul><ul><li>Evaluate whether systems should interface or be integrated. </li></ul></ul><ul><ul><ul><ul><li>Interfacing allows data to be transmitted between two systems that do not normally share the same database tables by use of a utility, adaptor or added code. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Integration requires modifying systems to work together in a 'seamless' fashion.&quot; </li></ul></ul></ul></ul>
  5. 5. <ul><li>Identify the business requirements necessary for Front, Middle and Back Office operations. Expectation of what should be reported by each “Office” in aggregate and detail must be defined. </li></ul><ul><li>An overall common definition of what constitutes a transaction and what needs to be recorded exists. If it needs to be measured, it must be recorded. </li></ul><ul><li>The business requirements must be formulated by actual business end users themselves who will be ultimately the ones to certify that integration between the offices works or not. How well does our systems and each of our offices meet regulatory/stakeholder expectations for the ability to Quantify / Monitor and Manage? </li></ul><ul><li>Transaction standards / message types / formats should be established and audited between each of the offices with clear definition of what data elements are required. </li></ul>Overhauling systems that hinder essential communication between the offices ( continued )
  6. 6. <ul><li>Standardizing methods of documentation to guarantee </li></ul><ul><li>all are kept to speed </li></ul><ul><ul><li>What should be documented ? (What, Why and When) – Create an overview of technical and business context documentation. </li></ul></ul><ul><ul><li>Adopt standardized documentation data flow format / requirements in cooperation with stakeholders – consider the use of experts to document data flows and what needs to be documented. </li></ul></ul><ul><ul><li>Focus on documenting data flow, calculation methods and reports. </li></ul></ul><ul><ul><li>Describe business context / purpose, recording process, calculation method and reporting method. In essence, put equal emphasis on purpose as the details of transaction flow and reporting. </li></ul></ul><ul><ul><li>Make sure documentation and overviews are included in training programs. </li></ul></ul>
  7. 7. What should be documented <ul><li>Architecture </li></ul>A data flow overview of all recordings, processes, storage and reports of data regardless of systems, offices, automatic or/and manual processes. <ul><li>Data flow within office and between offices </li></ul>A specific overview of recordings, processes, inventory and reports of data including integration method templates with other offices/systems. <ul><li>The format and use of message types / transaction types with other systems </li></ul>Description of methods and format of data integration with other systems including record layouts, fields and relevant communication rules (standards). <ul><li>The ability to use, review and modify data recordings </li></ul>A detailed description of the ability to record, edit and modify data within systems (automatic and manual processes). <ul><li>Processing of data within each office (calculations) </li></ul>A structured documentation of data processes implemented (automatic, manual) to transform data within each office. <ul><li>Aggregation of data </li></ul>Description and summation of data routines and storage of main summation procedures within systems. <ul><li>Reports </li></ul>Detailed description of data reports with audit trail to a,b,c,d,e,f identifying data elements as well as the description of data processes preceding the report layout.
  8. 8. <ul><li>Examining practices for eliminating error or ensuring that a </li></ul><ul><li>discrepancy is immediately made known to all involved </li></ul><ul><li>should one be found </li></ul><ul><ul><li>What quantification, monitoring processes have been deemed important on a daily and/or periodic basis? </li></ul></ul><ul><ul><li>How does the organization log deviances – and what type of deviances are recorded? </li></ul></ul><ul><ul><ul><li>Transactional </li></ul></ul></ul><ul><ul><ul><li>Calculation based – recordings from various systems in agreement and independently verified? </li></ul></ul></ul><ul><ul><li>Reconciliation processes between internal and external data sources essential as well as providing an independent review of these processes. </li></ul></ul><ul><ul><li>Communicate status of Operational Errors to stake holders. Mistakes are expected to be made – what is important is that processes are in place to enhance, improve systems. </li></ul></ul>
  9. 9. Draft - Operational Status Summary (Month of May-2008) By tracking Categories of operational errors over specific time periods, an organization can track operational risk / performance against total recorded transactions and thereby institute processes for improvements and focus, CATEGORY Occurrences $ Impact % of total Trend last month Wrong price 17 ($10,456) 0.68% Wrong volume 8 ($45,000) 0.32% Wrong counterpart 12 $0.00 0.48% Wrong premium 5 ($45,000) 0.20% Wrong location 7 ($76,000) 0.28% Wrong commodity 8 ($89,435) 0.32% Wrong time period 10 $56,700 0.40% Unconfirmed transaction 17 ($145,000) 0.68% Wrong settlement amount 2 ($43,000) 0.08% Un recorded transaction 3 ($34,000) 0.12% Wrong scheduled volume 5 ($76,000) 0.20% 94 ($507,191) 3.76%
  10. 10. Draft - Operational Status Summary CATEGORY Deviances $ Impact Action <ul><li>Daily confirmation: Exchange transactions </li></ul>None NA NA <ul><li>Daily confirmation: OTC physical and financial transactions </li></ul>None NA NA <ul><li>Daily settlement margin accounts (Exchange/ISDA) </li></ul>2 deviances <ul><ul><li>($265,000) </li></ul></ul>Recorded in Interim Account, reconciliation started <ul><li>Daily reconciliation cash wires against internal / external records </li></ul>None NA NA <ul><li>Daily P&L attribution </li></ul>None NA NA <ul><li>Daily Risk Metrics attribution </li></ul>None NA NA <ul><li>Daily Audit trail accounting – deal capture systems </li></ul>None NA NA
  11. 11. <ul><li>Making sure that the proper firewalls are in place so </li></ul><ul><li>that fraud cannot occur </li></ul><ul><ul><li>Internal definition of “fraud” supported by processes and monitoring reports eliminating possibility of fraud situations that addresses the following; </li></ul></ul><ul><ul><ul><li>Identify categories of fraud (Logins, systems, wire, confirmations, reconciliations). </li></ul></ul></ul><ul><ul><ul><li>Determine what monitoring process should be in place to report incidents. </li></ul></ul></ul><ul><ul><li>Make sure processes are communicated and independently reported and agree on how to manage situations through a breach policy. </li></ul></ul><ul><ul><li>Proactively position control functions through systems, policies and monitoring reports and consequences (breach implications). </li></ul></ul><ul><ul><li>Reassess: a) periodically to assess organization definitions and capability to detect. </li></ul></ul>
  12. 12. Guidelines - Fraud Control (Draft example) CATEGORY STATUS <ul><li>Establish controls that reduce the opportunity for unauthorized use of organizational resources (firewalls, email scanning, ID Access) </li></ul><ul><li>Delineating clear lines of responsibility, providing sufficient employee monitoring, segregation duties for operational processes and regularly rotating staff in key positions. </li></ul><ul><li>Using thorough recruitment screening and educating employees about the legal repercussions of being involved in illegal activities - to act as a deterrent. </li></ul><ul><li>Instituting control such as automated detection systems and advanced analytical technologies that look for suspicious behavior and anomalous patterns that may require investigations. </li></ul><ul><li>Corporations will need to define and understand the layout of internal data and the business process data flows in order to determine the necessary sources of data feeds for fraud solutions . </li></ul><ul><li>Proper security breach protocols including the use of laptops in insecure areas, accountability for security procedures, consequences for failing to follow security protocols </li></ul>
  13. 13. <ul><li>Keeping the right people doing the right things at the right </li></ul><ul><li>time </li></ul><ul><ul><li>Keep on top of operational tasks – what is the production pattern for each of the offices – who is doing what / when. </li></ul></ul><ul><ul><li>Is a daily operational plan in place to address sequence of tasks and when they should be completed with dependencies? </li></ul></ul><ul><ul><li>Identify for your business model / context - what skill set needs to be in place for each of the offices? </li></ul></ul><ul><ul><ul><li>Acumen across offices – What skill set and understanding is essential for each of the offices? </li></ul></ul></ul><ul><ul><ul><li>Acumen specific to office – What skill set will be proprietary? </li></ul></ul></ul>
  14. 14. Daily Operational Plan ( Draft for illustrative purposes ) Time Process Dependency Resource Tracking 08:00 AM Double check wire status of all accounts and reset credit Lines in systems Fed-wire / Swift report completed in SAP Back-Office group 1 Daily log report for counterpart account status to be completed 08:45 AM Option exercise Electricity and Natural Gas Option Exercise report Deal Capture Mid-Office Group 1 Daily log of exercise in deal capture system 09:00 AM Daily forecast of base load demand and load demand Weather demand report Forecasting Forecast logged in scheduling system 09:20 AM Daily unit characteristics report to be completed Unit operational report (PCI) Mid-Office Group 1 Characteristics logged in deal- capture system 09:40 AM Electricity to be scheduled by node. Natural Gas to be scheduled Production of aggregate schedule by deal capture system Mid-Office Group 1 Log of scheduling aggregation in deal capture and scheduling system 09:45 AM Day ahead financial settlement (shadow report to be completed all commodities) Financial settlement prices to be read into deal capture system Back-Office group 1 Log of settlement prices in deal capture system 09:45 AM Week ahead position report to be completed all commodities Computation of all position components Mid-Office Group 1 Position components logged in system by date
  15. 15. BIBLIOGRAPHY <ul><li>Bjornar Eide has been a Director of Risk Management for Sempra Energy Utilities since September 2005. Bjornar oversees the risk governance structure for San Diego Gas & Electric and Southern California Gas Company. He is a member of the Risk Management Committee for each of the utilities, which is responsible for managing each of the utility’s exposure to market, credit, liquidity and operational risk. Bjornar has over 15 years of experience from energy markets, serving in a variety of capacities in an international environment. Prior to joining Sempra Energy Utilities, he worked as an independent strategic risk consultant for a variety of clients in Europe and the US focusing on strategic risk management related issues and the design of risk assessment capability. As a Director of Risk Management for NRG (from 2000 – 2002) he built up the risk management department and during his four year tenure with Statoil A/S as a portfolio manager, he actively managed positions that involved petroleum products, crude, natural gas & electricity including the build-up of the power marketing department. Eide holds an MBA in Finance from San Francisco State University and a BA in Business Administration from California Lutheran University. </li></ul>