Anda di halaman 1dari 55

End of Day Process

BIP Bank of Ita Paraguay

18-September-2012
Alameda Santos 244 - 13th Floor Sao Paulo, SP 01419-002
TEL: 55 11 3085 8500

WEBSITE: http://www.olf.com

Confidential

Page 1 of 55

Contents
1. INTRODUCTION............................................................................................................................... 4 1.1 1.2 1.3 1.4 1.5 2. DISCLAIMER...................................................................................................................................... 4 OVERVIEW ........................................................................................................................................ 4 DOCUMENT LAYOUT ......................................................................................................................... 4 DOCUMENT OWNER .......................................................................................................................... 5 DOCUMENT HISTORY ........................................................................................................................ 5

BUSINESS REQUIREMENTS SUMMARY ................................................................................... 5 2.1 2.2 2.3 2.4 2.5 REQUIREMENT ID ............................................................................................................................. 5 GENERAL .......................................................................................................................................... 5 BUSINESS PROCESS ........................................................................................................................... 6 THE END OF DAY PROCESS ............................................................................................................... 8 PROPOSED FINDUR EOD PROCESS .................................................................................................... 9
2.5.1 Rolling the System Date(s) .............................................................................................................. 12 2.5.2 Importing & Saving Prices ........................................................................................................... 13 2.5.2.1 Saving Prices (Manually) ........................................................................................................... 14 2.5.2.2 Running the import task manually ............................................................................................. 16 2.5.3 Time Series...................................................................................................................................... 19 2.5.4 Missing Validations......................................................................................................................... 19 2.5.5 Price Fixings.................................................................................................................................... 19 2.5.6 Running Missing STD Missing Reset Report ................................................................................. 22 2.5.7 EOD Pre Checks job ....................................................................................................................... 23 2.5.8 End of Day Simulations .................................................................................................................. 23 2.5.8.1 Batch Simulations Defined ........................................................................................................ 24 2.5.8.2 Queries ....................................................................................................................................... 24 2.5.8.3 Defining EOD Simulation Results ............................................................................................. 26 2.5.8.4 Associating Portfolios queries to the EOD simulation (Batch Simulations) .............................. 27 2.5.8.5 EOD Simulation Batch Script .................................................................................................... 29 2.5.8.6 Running and Saving the EOD Simulation .................................................................................. 29 2.5.9 Running EOD Reports..................................................................................................................... 29 2.5.10 Accounting Postings ........................................................................................................................ 30 2.5.11 Accounting Interfaces...................................................................................................................... 30 2.5.12 Importing Cash Flows ..................................................................................................................... 30 2.5.13 Running EOD Simulations with cashflows ..................................................................................... 30 2.5.14 Running VaR Taks .......................................................................................................................... 31 2.5.15 Running EOD VAR Reports ........................................................................................................... 31 2.5.16 Maturing Trades .............................................................................................................................. 31 2.5.16.1 Transaction Matured Process ................................................................................................ 31 2.5.16.2 Purpose of maturing Trades .................................................................................................. 32 2.5.17 Rolling the business and processing date ........................................................................................ 32

3. 4.

AUTOMATED EOD PROCESS ......................................................................................................33 TECHNICAL SPECIFICATION .....................................................................................................35 4.1 SCRIPT NAME: STD AMENDED TRADE LISTING ..............................................................................35
4.1.1 4.1.2 4.1.3 4.1.4 4.1.5 Processing ....................................................................................................................................... 35 Logic ............................................................................................................................................... 35 Report Example ............................................................................................................................... 36 Error Handling ................................................................................................................................ 36 Logging Requirements .................................................................................................................... 36 Logic ............................................................................................................................................... 37 Report Example ............................................................................................................................... 38

4.2

SCRIPT NAME: STD TRADES DONE TODAY .....................................................................................37


4.2.1 4.2.2

Confidential

Page 2 of 55

4.2.3 4.2.4

Error Handling ................................................................................................................................ 38 Logging Requirements .................................................................................................................... 38 Logic ............................................................................................................................................... 39 Report Example ............................................................................................................................... 40 Error Handling ................................................................................................................................ 40 Logging Requirements .................................................................................................................... 40 Logic ............................................................................................................................................... 41 Report Example ............................................................................................................................... 42 Error Handling ................................................................................................................................ 42 Logging Requirements .................................................................................................................... 42 Logic ............................................................................................................................................... 43 Report Example ............................................................................................................................... 44 Error Handling ................................................................................................................................ 44 Logging Requirements .................................................................................................................... 44 Logic ............................................................................................................................................... 45 Report Example ............................................................................................................................... 46 Error Handling ................................................................................................................................ 48 Logging Requirements .................................................................................................................... 48 Logic ............................................................................................................................................... 49 Report Example ............................................................................................................................... 51 Error Handling ................................................................................................................................ 51 Logging Requirements .................................................................................................................... 51 Logic ............................................................................................................................................... 52 Report Example ............................................................................................................................... 53 Error Handling ................................................................................................................................ 53 Logging Requirements .................................................................................................................... 53

4.3

SCRIPT NAME: STD DELETED TRADE LISTING ................................................................................39


4.3.1 4.3.2 4.3.3 4.3.4

4.4

SCRIPT NAME: BACK DATED TRADE LISTING ..................................................................................41


4.4.1 4.4.2 4.4.3 4.4.4

4.5

SCRIPT NAME: STD MISSING RESETS ..............................................................................................43


4.5.1 4.5.2 4.5.3 4.5.4

4.6

SCRIPT NAME: STD EOD SUMMARY P/L ........................................................................................45


4.6.1 4.6.2 4.6.3 4.6.4

4.7

SCRIPT NAME: STD EOD PNL EXPLAINED .....................................................................................49


4.7.1 4.7.2 4.7.3 4.7.4

4.8

SCRIPT NAME: STD MATURED TRADE LISTING...............................................................................52


4.8.1 4.8.2 4.8.3 4.8.4

5.

APPENDIX A: LIST OF EOD SIMULATION RESULTS ...........................................................54 5.1 BANK OF PARAGUAY EOD SIMULATION LIST .................................................................................55

Confidential

Page 3 of 55

1. Introduction
1.1 Disclaimer

The information contained in this document is subject to change without notice. Changes, technical inaccuracies, and typographical errors will be corrected in subsequent editions of this document. The software and procedures described in this document constitute proprietary information of Open Link Financial, Inc., and is furnished only under a license agreement. The software may be used only in accordance with this agreement. No part of this document may be reproduced or transmitted in any form or by any means electronic or mechanical, including photocopying, recording, or facsimile, for any purpose other than the licensees own internal use without the express written consent of Open Link Financial, Inc. Trademarks Findur and Endur are trademarks of OpenLink Financial, Inc. Other product names mentioned in this manual may be trademarks or registered trademarks of their respective companies and are hereby acknowledged.

1.2

Overview

The information provided in this document explains at a detailed level the custom software that will be implemented by OLF to satisfy the requirements as specified by Ita Paraguay.

1.3

Document Layout

The document assumes the reader is familiar with the requirements as documented by Ita. The document is intended to describe the business requirements as documented, and otherwise communicated to OLF by Ita, and in following sections the technical details of how the requirements will be implemented by OLF.

Confidential

Page 4 of 55

1.4

Document Owner

The following table documents the OLF and client owners that contributed to the creation of the version of the document.
Owner Business Technical Client Owner P. Dweck / K. Leal / E.Tecedor A.Sore/ V.Silva Ita

1.5

Document History

The following table should be updated to reflect each version of the document. A new version will be established whenever a change is required to be made to a previously approved version of the document (see below).

Version 1.0

Date 18 Sep - 2012

Change Original

Author Phillip Dweck

Status Draft

2. Business Requirements Summary


2.1 Requirement ID

The requirements for an End of Day (EOD) process have not been formalized by Ita Paraguay. Thus, this document will attempt to formalize an end of day processing however Ita should review the proposed process and suggest amendments to this document if deemed necessary.

2.2

General

The purpose of this document is to describe to the user the proposed setup and process EOD for Ita. Ita will run a single EOD process after the roll of the trading date. This process can occur after the expected transaction processing day has ended or early the next day.

Confidential

Page 5 of 55

2.3

Business Process

This section of the document will outline Itas EOD business process as envisioned by OLF. Ita Paraguay will run a single EOD process prior to the roll of the business day in the system. This process may occur after the expected transaction processing day has ended or early next day. The trading date may be rolled separately from the business date so that EOD processing can occur without impacting transaction entry. Ita Paraguay (BIP) requires the End of Day to be processed at D0. This is because accounting postings need to be processed and sent from Findur to accounting at 10 PM each night. The EOD entire process however will be finalized in the following morning when cash flows from the banking portfolio will be interfaced into Findur and VaR results will be computed. Only after these results are calculated in the morning the End of day will be completed. Open Link expects a member of BIP to be there during the night and in the morning when the end of day batch is being run. This will ensure that the end of day process will run smoothly and issues will be corrected as needed. EOD Timeline
Process FX data file becomes available End of trading day Market Data file becomes available EOD process starts Accounting postings interface starts Cash flows interfaced into Findur EOD Finishes Time D 0 - 3.00 PM D 0 -6.00 PM D 0 -8.00 PM D 0 - 8.01 PM D 0 - 10.00PM D 1 7.00 AM D1 7.30 AM

Confidential

Page 6 of 55

Assumptions BIP will import three sets of data into Findur. Interfaces have already been created by OLF and will be tested thoroughly by BIP during UAT. BIP will obtain FX data directly from the a web service that receives the data from the central bank. The central bank publishes exchange rates at 2.00 PM in the afternoon and Findur must be able to import them before EOD starts. BIP will obtain market data (non FX indexes) directly from a file generated from IM / NK. Ita Holding will publish a file containing this data in a network folder at 8.30 PM. Cash flows from the banking portfolio will be available in the next morning prior to the beginning of trading at 5.00 AM. Findur will import these cash flows at 7.00 AM through the run off interface and then calculated VAR results in the morning. A member of BIP will manually enter the FX exposition into Findur at the End of the trading day. This is to ensure that VaR computations will occur as designed in the morning before commencement of trading. A member of BIP will create a file containg the curve transfer data for the day. OLF personnel has already developed an interface to import this data, however this must occur prior to the start of EOD. BIP will have qualified personnel following the EOD process and fixing issues as they arise. The End of Day process will not run in a non good business day following the Paraguayan calendar.

Confidential

Page 7 of 55

2.4

The End of Day Process

The main steps of the EOD process are outlined by the picture below. These steps will be further explained in the following sections.

Roll Trading Date

Import FX & Market data

Verify EOD Data

Accounting Postings

Run Trade Listings

Run Sims & Reports

Import Cash Flows

Run Risk Reports

Mature Trades

Roll Processing & Business Date

Confidential

Page 8 of 55

2.5

Proposed Findur EOD Process

The EOD process will need to run several steps in a sequential order. This document will discuss each step in detail on how it is set up, as well as, the purpose of the required action. 1. Trading Date is rolled to the Next Good Business Day (NGBD). 2. FX rates are imported into Findur via a script, and saved to the Universal, Closing and historical datasets. 3. Rates for the transfer curve are imported into Findur via a script, and saved to the Universal, Closing and historical datasets. 4. Market data (curve data) is imported into Findur via a script, and saved to the Universal, Closing and historical datasets. 5. Time Series Update Rates / DFs are updated into the time series module to generate new correlation matrix and price volatility. 6. The following report is run: a. STD: Missed Validations is run to ensure all transactions have a validated status. 7. Price Fixings are processed to all transactions 8. The following report is run: a. STD: Missing Resets report is run to ensure all price fixings occur properly. 9. EOD will stop if 6 or 8 fail. 10. The following exception / information reports are run: a. STD Amended Trade Listing b. STD Transaction Audit Trail c. Trades done Today Listing (It has not been decided by ITA, but this could serve as a trader check out report) d. STD Deleted / Cancelled Trade Listing e. STD Back Dated Trade Listing 11. EOD Simulations are run via the Batch Simulation, and EOD results are saved within Findur. The batch simulation is called via the STD_Batch_Simulations. 12. EOD Reports are run, this has yet to be decided by Ita. OLF recommends the following EOD reports:

Confidential

Page 9 of 55

a. STD EOD Summary PNL b. STD EOD PNL Explained c. BIP_Finance_Report 13. Accounting postings are processed through STD acct explode. 14. Accounting interface send information to BIP accounting system. 15. Cash flows are imported into Findur through run off interface 16. EOD Simulations are rerun via a script with a new batch simulation that includes the cash flow portfolio. 17. The following risk reports are run: a. DV 01 b. VAR 1 c. GAPS MTM d. TRANSFER 18. Trades are matured through STD EOD Mature trades 19. Business and processing Date are rolled to the Next Good Business Day (NGBD).
Step Manager Process sub component Roll Trading Date Load and save exchange rates. Load and Save transfer curves Load and save official curves. Generate new correlation matrix / vols Run Missed validations Run Fixings Scripts or task name Output File Name

1 2

Ops Market

STD_EOD_Date_Roll_Tradedate Interface con Cotizaciones

N.A N.A

Market

Input_Transfer

N.A

Market

Interface con IM/NK

N.A

Time Series

May not need script o do this step

N.A

Trading

STD_Missed_Validations

STD_MISSED_VALIDATIONS.PDF

Trading

STD_EOD_ResetDealsByQID

N.A

Confidential

Page 10 of 55

7 8

Trading Trading

Run Missing resets Check EOD Exception Reports.

STD_Missing_Reset Custom Reports 6 and 8 will move to a fail status if exceptions are found. STD_Amended_Trade_Listing STD_Trades_Done_Today STD_Transaction_Audit_Trail STD_Deleted / Cancelled Trade Listings STD_Back_Dated_Trade_Listing

STD_Missing_Reset.PDF N.A

Trading

Run exception / information reports

N.A

10

Trading

Run EOD Simulations Run EOD Reports

STD_Batch_Simulation

N.A

11

Trading

STD_EOD_Summary PNL STD EOD PNL Explained BIP_Finance_Report

N.A

12

Acctg

Run Account explode Run acctg interfaces Cash Flows interface RUN EOD SIMS with cash flow porfolio Run VAR Run Risk Reports

STD_Acct_AutoEODExplode

N.A

13 14

Trading Trading

BIP_Interface_Contabilidade Run Off

N.A N.A

15

Trading

STD_Batch_Sims

N.A

15 16

Trading Trading

BIP_VaR BIP_DV1 BIP_Transfer BIP_VAR BIP_GAP

N.A BIP_DV1.xls / BIP_Transfer.PDF BIP_VAR_Banking.PDF / BIP_VAR_Trading.PDF / BIP_VAR_Total.PDF/ BIP_VAR_consolidated / BIP_GAP.PDF

Confidential

Page 11 of 55

18

Trading

Run EOD Matured Trades Roll Business & Processing Date

STD_EOD_Mature_Trades

STD_EOD_Mature_Trades.PDF

19

Ops

STD_EOD_Date_Roll

N.A

2.5.1 Rolling the System Date(s)


The first step of the EOD process is to roll the trading date to the next good business date. This will ensure that all trades inputted in the system after the EOD process started will enter in the system in next business date. This step will be automated in the workflow through a script but the user could manually roll the trading date by accessing the system date roll: First the user will roll the trading date via the operations manager. The user will access the Operations Manager Daily Operations Tab System Date Roll. Within this screen the user can roll the trading date.
Master Central > Operation Manager > System Date Roll > Roll Trading Date

Confidential

Page 12 of 55

Note on System Dates 2.5.2 Importing & Saving Prices

The price import scripts will save historical, universal and closing datasets for FX and discounting curves. It will also update any existing historical prices if needs updating. Closing Prices: From the Menu in the below screen shot the user will select Prices Rate Save Close. This will save the prices for that specific business day as the closing prices. Historical Prices: This will create a record in the historical table for the default reference source on the curve definition. If a curve has multiple reference sources the settle prices corresponding to the additional reference sources must be added directly to the historical table. Universal Prices: This will save the closing prices as the best available prices within the database, whereby when the system date is roll those prices are used in terms of calculation for MTM until the next days prices are published.

Confidential

Page 13 of 55

2.5.2.1Saving Prices (Manually)


Users also have the ability to save prices manually. The processes are described in the following sections. 1. Open the Market Manager 2. Click on File Load Indexes. Load all Official Indexes 3. Open the index that you wish to update 4. Update the data 5. Click on File and then save then click on Save Universal, Save Close, Save Historical

Confidential

Page 14 of 55

Confidential

Page 15 of 55

2.5.2.2Running the import task manually


Alternatively, users may the import task manually. 1. Running the import task task 2. Open The Trading Manager 3. Click on Load Task 4. Select import task (eg.Interface Cartera) 5. Click on Run Task 6. Wait for succeed status

Confidential

Page 16 of 55

Confidential

Page 17 of 55

Confidential

Page 18 of 55

2.5.3 Time Series


The fourth step of the EOD process is to import the historical data into the time series module. The time series module is the module responsible for generating the historical price volatility data and the correlation matrix. Open Link will provide a script to update the data and generate the new price vols and correlation automatically. Please refer to the VaR guide for instruction on how to do this manually. In order to execute the task automatically follow the steps as described above in 2.5.2.2

2.5.4 Missing Validations


Users should be familiar with the STD Missing Validations report. This report identifies transactions in the database with the status of new, amended new, and cancelled new, and buyout new. This report is run by the STD missing validations task It is good practice to require all trades to have a validated status before running the end of day. Thus, this report is is typically executed in the preEOD process. If one or more deals are found with a missing validation, this script will exit with a FAILED status. If NO deals with missing validations are found, this script will exit with a status of SUCCEEDED. The FAILED and SUCCEEDED statuses are useful when configuring the script (task) to run in a workflow, so that exception processing can be triggered if deals with missing validations are found.

2.5.5 Price Fixings


After prices have been imported into the Findur, they will need to be associated to the transactions within Findur. This process is known as Price Fixings. The purpose of price fixing is to set the price or rate for a given trade for a given date. The price fixings process will be automated through the STD EOD Reset Deals by QID. This script will fix transactions (e.g. for prices, interest rates, FX rates, prepayment factors) for a day given a transaction query of deals. It can run either adhoc (on trades on the Trading Manager browser) or on a given saved query. By default, it will fix deals for the current business date. The fixing values are derived from the appropriate fixing indexes. Nonetheless, users should be familiar with the manual fixing process so that mistakes may be corrected.

Confidential

Page 19 of 55

This process resides within the Operations Manager of Findur, under the Daily Operations tab labeled Instrument Fixings.

Daily Operations Tab

The Instrument Fixings Process is query driven (a query for BIP has already been created - Instrument_Fixings_Query). Typically the query will retrieve all trades that have an Unknown price for the current day (also known as unknown reset). Once the query runs a list of trade will return that fit that query criteria. Once the query returns with the respective deals the user will next click the blue check mark button (Denoted by A) which signifies to the system that all transaction will need to be Fixed. Next, the user will click the Process button (Denoted by B). Next, users will click Process (Denoted by C).This will affix the prices to their respective transaction. The fixed deals will appear in the fixing window highlighted by brown with a known status as denoted by D. If all transactions have been fixed for the current business day correctly then no transactions will appear within this window. Once fixings have been completed the user should re-run the query thereby making sure all transaction have been fixed.

Confidential

Page 20 of 55

B C

Confidential

Page 21 of 55

2.5.6 Running Missing STD Missing Reset Report


The missing resets report identifies transactions that will not value or revalue properly because one or more required resets (Fixings) are missing. This report is typically executed in the pre-EOD process to ensure that resets are fixed and that valid closing prices are applied. Users should be familiar with the STD Missing Reset Report. The report is run via the task STD_Missing_Resets . If one or more deals is found with a missing reset, this script will exit with a FAILED status. If NO deals with missing resets are found, this script will exit with a status of SUCCEEDED. The FAILED and SUCCEEDED statuses are useful when configuring the script (task) to run in a workflow, so that exception processing can be triggered if deals with missing resets are found.

Confidential

Page 22 of 55

Note on Rollback Function

During the course of business it is possible that the price import process might import the incorrect prices, or another error with prices does occur. If this does occur the user can run a query to retrieve all deals that have been fixed for that day and run the Roll Back process. This query can be user defined, by index, pricing date, etc. This will unfix all deals prices that have been fixed. After the deals have been unfixed the pricing import process will need to be re-run, as well as, the fixings with the correct price. Additionally, since a jump will occur in many simulation results due to this change a simulation result called Impact of Resets will explain these changes in price. This result is included in various end of day reports. Please note that the rollback function should be used only in extreme cases (i.e.: several index prices are imported incorrectly, etc.). The roll back function is used on an index basis rather then a deal basis. When the rollback function is used it will retrieve all transaction(s) that are associated to the index where the price will need to be rolled back. This is a necessary function since all simulation results are based off the price of the transaction. The roll back function should only be used if several hundred transactions are affected. Therefore, OLF suggested that if a price is entered incorrectly Ita personal should modify the historical prices table. There are no other alternatives if a incorrect price is recorded into Findur.

2.5.7 EOD Pre Checks job


A custom task will be written to exit the EOD workflow if either or both tasks - 2.5.4 and 2.5.6 exit with a fail status. Reports will be available to advise the user of the missing validations and missing resets. The user following the EOD process should fix the issue and the start the EOD process again from step start.

2.5.8 End of Day Simulations


Once fixings have occurred the EOD Simulations are run on each portfolio via a combination of saved queries (on the portfolio level), EOD simulation results, and the batch simulation script.

Confidential

Page 23 of 55

2.5.8.1Batch Simulations Defined


A Batch simulation is a necessary component of the End of Day processing because it produces much of PNL, Risk and accounting content for the remaining EOD process. This batch produces the official valuation. When the simulation is run, the system calculates results in each portfolio and stores them to the database. The Batch simulations is called via the STD_Btach_Sims task. The Batch Simulations is a set of saved EOD simulations (results) whereby once ran are saved to the database on the portfolio level. The batch simulation is dependent upon the following pre-requisites: Portfolios Queries Named Portfolio simulation Batch simulation Modify standard batch simulation script

2.5.8.2Queries
First the user will need to create a set of queries that will be based off each internal business unit, internal portfolio, trade date, Tran type, trade type, and Tran status.

Confidential

Page 24 of 55

Below is the description of each field and why it is necessary for the query to be configured this way. Trans Status: Includes only validated deals. No other statuses should ever be used. Deals with a status of Amended or Canceled must never be included in a batch simulation. Simulation results that need to retrieve deals in other statuses (such as Impact of Cancellation, which needs to retrieve canceled deals) will automatically retrieve any deals that they need, even though your query did not include them explicitly. Deals with a status of Canceled, for example, may still have an MTM and a Delta. Including them in a simulation will cause misleading and/or incorrect values. Ins Type: Must excluded composers (i.e.: COM) from the EOD queries. If the EOD process were to include composer deals all EOD results would be double counted. Additionally, bringing in linked deals that exist in other portfolios, which would cause the EOD Simulation to fail. Int Portfolio: Specify only one portfolio. EOD Saved Queries cannot retrieve deals in more than one portfolio. In general, one query is created for each portfolio, and there is one row in the Batch Simulation for each query/portfolio. Trade Date: Identify trades with an input date <= today. It is important that the user has input date <= today. This will allow users to enter trades for the next day and the operation department may need to rerun the EOD simulations from the previous day. They can roll the date back one day, and re-run the EOD simulations, this process will not include the new trades.

Once the query has been created the user will need to save this query to the database. OLF suggest that the following naming convention is used: EOD_Business Unit Name_PORTOFLIO NAME_Query This allows the user to easily identify the saved EOD queries when setting up the EOD batch simulations. NOTE: This MUST be done for each internal business unit / portfolio combination. Otherwise if the query is not set up those transactions in the missing query will NOT be reported on within the EOD process.

Confidential

Page 25 of 55

Please note that this is a one time setup unless a new business unit / portfolio combination is created. The following EOD Queries have been configured within Findur with the respective business unit / portfolio name:
Portfolio BONOS BONOS CORP CALLMO O CALL T CASHFLOW Query EOD_BIP_BONOS Portfolio LRM Query EOD_BIP_LRM EOD_BIP_PRESTAMOS EOD_BIP_REPO EOD_BIP_TIME_DEP

EOD_BIP_BONOS_CORP PRESTAMOS EOD_BIP_CALLMO-O EOD_BIP_CALL-T EOD_BIP_CASHFLOW REPO TIME DEP

Please note that if the portfolio name or business unit structure changes the queries will need to be updated with the new business unit / portfolio name.

2.5.8.3Defining EOD Simulation Results


EOD simulations are no different in terms of calculation to running the same simulation on a transaction at anytime (also known as a Ad-Hoc simulation). The difference is that EOD simulation results are saved to the database. Currently OLF will have a base group of EOD simulation results (for a list of current EOD simulation results please refer to Appendix A) that will be used for Ita; however, during the UAT phase and as new reporting requirements appear more simulation results may be added to the EOD simulation results. User can set up EOD simulation results they can access this via the Trading Manager File Reval. The following screen will appear for the user. Here the user can associate more Findur Results by clicking on the results area and selecting the appropriate simulation results.

Confidential

Page 26 of 55

Additionally, the user can apply different scenarios to the simulation results. For example, one set of EOD results can have discounting applied to results, and another EOD simulation set can have another discounting applied to the EOD results. The batch simulation created for Ita will run this named simulation BIP_EOD_if_Day - for all portfolios using the queries described in section 2.5.8.2. The next section will describe how to set up this batch simulation. The user may also set up different scenarios in this simulation. The scenarios that OLF personnel created in the simulations are used in custom calculations customised for BIP.

2.5.8.4Associating Portfolios queries to the EOD simulation (Batch Simulations)


Once the Saved Simulations & EOD simulations have been created the user will next need to assign each EOD saved query to an EOD Simulation Result. For this to occur the user will click on the Operations Manager select the Services Tab and select Batch Simulation.

Confidential

Page 27 of 55

Within the Batch Simulation Definition screen the user will associate each query to the saved Simulation. Once each portfolio is associated to the respective simulation the Batch Simulation will need to be saved by giving the batch simulation definition name within the Reference field. Then click save.

Confidential

Page 28 of 55

The Batch Simulation EOD_ALL_Portfolios -shown above has already been created by OLF personnel. As we can see from the picture this batch is running the EOD simulation for all Ita portfolios queries created previously.

2.5.8.5EOD Simulation Batch Script


Next, the user will need to associate the Saved Batch Simulation Name to the Batch Simulation script. The user will access the STD_BATCH_SIMULATION script via the Trading Manager and associate the saved Batch simulation name within this script, and save the script with the necessary Batch simulation saved name. The script has already been modified by OLF personnel to cal the EOD_All_Portfolios batch simulation. Please note that this is a one time setup; however, if a new portfolio is added to Ita internal book structure this portfolio will need to be added.

2.5.8.6Running and Saving the EOD Simulation


After the above have been done the user will access STD_BATCH_SIMULATION script and run it each day, this will run and save all EOD simulation results for that specific day. OLF will automate this in the EOD workflow.

2.5.9 Running EOD Reports


Once EOD simulations have been computed, all EOD reports will be run and saved to the database. This has yet to be defined by Ita. However, OLF is recommending some standard EOD reports for Ita to begin using. The two tasks below will be configured in the workflow by OLF personnel, but it may be removed if Ita does not require them. STD EOD Summary PNL - This report compares the mark-to-market and P/L values for yesterday and today for each instrument. This report summarizes the changes in MTM detailed in the STD_EOD_PNL_Explained report. STD EOD PNL Explained - The End-of-Day Profit and Loss Explained Report explains changes in the unrealized profit/loss values (Unrealized PNL result) between the previous business day and the current day. There is one report generated for each portfolio. The first section of the report summarizes the results for the portfolio. The second section details the impact associated with changes to each curve in the portfolio.

Confidential

Page 29 of 55

BIP_Finance_Report This report has been created by OLF personnel to fulfill the BIPs requirements.

2.5.10 Accounting Postings


Some of the results from the batch simulation form the basis for the accounting postings. Ita Paraguay requires posting to be performed each day before 10.PM. OLF will automate this process in the workflow through a task called STD_acc_event_explode. Alternatively, the user could also run this process through the accounting desktop.

2.5.11 Accounting Interfaces


An accounting interface will run after postings have been completed. Ita Paraguay requires this to happen at 10 PM each night. This process will be automated in the workflow. The task responsible for this interface is called BIP_Interface_Contabilidade . Alternatively the user may also run this task manually if for any reason the EOD process fails.

2.5.12 Importing Cash Flows


In the following morning at 5.00 AM the cash flow from BIP banking portfolio will be available through an excel file. Ita requires these cash flows to be imported into Findur before running the risk computations. These cash flows will be imported through the run off interface. The EOD automated workflow will contain a step that run this interface automatically at 7.00 AM.

2.5.13 Running EOD Simulations with cashflows


Once cash flows have been imported, Findur will need to re-run the end of day simulations through a batch simulation. This is because Findur needs to include the cash flows portfolio in its calculations. This process will be automated in a similar fashion as described in 2.5.8. At this stage however, the EOD will call another batch simulation that also associates the cash flow portfolio with the end of day simulation. The script that calls this end of day simulation will also be modified because now this needs to call a different batch.

Batch Simulation Script

BIP_EOD_All_Potfoloios+Cashflow EOD_BIP_Batch_Sims_Morning

Confidential

Page 30 of 55

2.5.14 Running VaR Taks


Open Link a personnel has created a custom script that will generate the VaR calculations needed by BIP. This script is run by a task called BIP_VaR. This task will run a series of simulations in a sequential order. This script calls the simulations from within and thus no batch sims need to be created to perform such calculations.

2.5.15 Running EOD VAR Reports


Once EOD VAR simulations have been computed, all VAR reports will be run and saved to the database. BIP_DV01.xls BIP_Transfer.PDF BIP_VAR_Banking.PDF BIP_VAR_Trading.PDF BIP_VAR_Total.PDF/ BIP_VAR_consolidated BIP_GAP.PDF

2.5.16 Maturing Trades


Maturing Trades is a requirement and strongly recommended to successfully running The OpenLink System. The mature trades process will change the transaction status from Validated to Matured. The only trades that would go through this process are those transactions that have completely settled, and have no value. By changing the transaction status from Validated to Matured those deal would no longer go though the EOD process, and thus save processing time. Furthermore, the transaction is not deleted out of Findur. The transaction status to the deal has changed. There are ways to un-mature trades if they accidentally get matured. Due to the trading nature at Ita OLF and Ita agree that the mature trades process will run on transactions whereby the system date is 180 days after the settlement of the deal.

2.5.16.1 Transaction Matured Process


Trades get matured via the standard script STD_EOD_Mature_Trades It retrieves for transactions with a "Close" event date less than or equal to the current date. The user can set any delay (such as 180 days or greater) this is dependent on the business process at Ita.
Confidential
Page 31 of 55

2.5.16.2 Purpose of maturing Trades


Once trades are at a status of Matured, they will no longer be included in default queries. This means the system saves time and memory any place where trades are used, such as the Trading Manager browser, the EOD Simulation Results, Account Manager Postings, etc. Once a trade is matured all realized results will still be a part of the EOD simulation results for that deal.

2.5.17 Rolling the business and processing date


The final step of the EOD process is to roll the business and processing date to the next good business date. This will be automated through the following tasks: 1. STD_Date_Roll_Business 2. STD_Date_Roll_Processing Please, refer to 2.5.1for further details about system dates.

Confidential

Page 32 of 55

3. Automated EOD Process


The screen shot below shows an example of how the EOD will occur on an automated process via a workflow. The EOD workflow will be configured for Ita as soon as OLF receives approval of this document. This automated process will occur within the Service Manger under the Workflow Management Tab.
Identifies the actual process that will be taking place. The sequence identifies in numerical order when each process of the EOD process will be carried out.

The purpose of making sure that the individuals responsible for running EOD will become accustomed and able to identify an issues when running EOD manually so that when it is running in a workflow and it stops they know how to diagnose and fix the issue.

Confidential

Page 33 of 55

Note on Sequence Number:

Changing the sequence number of a job also changes the jobs position on the job list. Jobs run in the order of their sequence number, from lowest to highest. The next job will not run until the first job is complete. For example, if Job 1 has a sequence number of 10 and Job 2 has a sequence number of 20, Job 2 will not execute unless Job 1 completes the job. Jobs that have the same sequence number run at the same time. Tip: Use non-consecutive sequence numbers (e.g., 5 10 15 20 or 10 20 30 40). This enables you to insert new jobs in between existing jobs.

Confidential

Page 34 of 55

4. Technical Specification
4.1 Script Name: STD Amended Trade Listing

4.1.1 Processing
This is a Standard Script

4.1.2 Logic
The Amended Trade Listing shows all trades that have been amended within the specified date range. Today is defined as the Market Manager Current Date. The report will look for ab_tran_event records where the event_type = Amended Open and the event_date occurred within the specified date range.
Column Name Deal Num Tran Num Instrument Type Trade Date Amend Date Counterparty Portfolio Unit Ccy Position Ticker Cusip ISIN Trader Description Deal number Transaction number Instrument Type Date on which deal is traded Date on which deal was amended Legal External Entity of the deal Portfolio of the deal Unit of the deal (only in ENERGY report) (only in ENERGY report) (only in FINANCIAL report) (only in FINANCIAL report) (only in FINANCIAL report) Name of the trader. This is the internal contact personnel id. Database Table/Formula ab_tran.deal_tracking_num ab_tran.tran_num ab_tran.ins_type ab_tran.trade_date ab_tran_event.event_date ab_tran.external_lentity ab_tran.internal_portfolio parameter.unit ab_tran.currency ab_tran.position header.ticker header.cusip header.isin ab_tran.internal_contact

Confidential

Page 35 of 55

4.1.3 Report Example

4.1.4 Error Handling


None

4.1.5 Logging Requirements


Standard logging.

Confidential

Page 36 of 55

4.2

Script Name: STD Trades Done Today

4.2.1 Logic
The Trades Today Listing shows all trades entered today for specified business units, including back dated trades. Today is defined as the Market Manager Current Date. It will show trades at all transaction statuses (e.g. will show trades that were deleted and or cancelled). It will NOT show templates entered today. It will find trades with an input date equal to today. There is a separate report created for each business unit. If no parameter script is specified, by default it will run for all internal business units.
Column Name Deal Number Instr Type Trade Date Counterparty Position Unit Currency Portfolio Traded by Description Deal number Instrument Type Date on which the deal is traded Legal External Entity of the deal Position of the deal Unit of the deal Currency of the deal Internal portfolio of the deal Name of the trader. This is the internal contact personnel id.

Confidential

Page 37 of 55

4.2.2 Report Example

4.2.3 Error Handling


None

4.2.4 Logging Requirements


Standard logging.

Confidential

Page 38 of 55

4.3

Script Name: STD Deleted Trade Listing

4.3.1 Logic
The Deleted Trades Listing shows for specified internal business units, all trades that have been deleted within a specified date range. If no parameter script is specified, by default it will run for all internal business units for today.
Column Name Deal Num Tran Num Instrument Type Trade Date Delete Date Counterparty Portfolio Unit Ccy Position Ticker Cusip ISIN Trader Description Deal Number Transaction Number Instrument Type of the deal Date on which deal is traded Date on which deal is deleted Legal External Entity of the deal Internal portfolio of the deal Unit of the deal (only in ENERGY report) (only in ENERGY report) (only in FINANCIAL report) (only in FINANCIAL report) (only in FINANCIAL report) Name of the trader. This is the internal contact personnel id. Database Table/Formula ab_tran.deal_tracking_num ab_tran.tran_num ab_tran.ins_type ab_tran.trade_date ab_tran.last_update ab_tran.external_lentit ab_tran.internal_portfolio parameter.unit parameter.currency ab_tran.position header.ticker header.cusip header.isin ab_tran.internal_contact

Confidential

Page 39 of 55

4.3.2 Report Example

4.3.3 Error Handling


None

4.3.4 Logging Requirements


Standard logging.

Confidential

Page 40 of 55

4.4

Script Name: Back Dated Trade Listing

4.4.1 Logic
The Back Dated Trade Listing lists all backdated trades that have been input today or within a specified date range. A deal is considered backdated when the trade date is earlier than the input date. Today is defined as the Market Manager Current Date.
Column Name Deal Number Tran Number Instrument Type Trade Date Input Date Counterparty Portfolio Unit Ccy Position Ticker Cusip ISIN Trader Description Deal number Transaction number Instrument Type Date on which the deal was entered Date deal was entered External Legal Entity of the deal Portfolio of the deal Unit of the deal (ENERGY REPORT ONLY) (ENERGY REPORT ONLY) (FINANCIAL REPORT ONLY) (FINANCIAL REPORT ONLY) (FINANCIAL REPORT ONLY) Name of the trader Database Table/Formula ab_tran.deal_tracking_num ab_tran.tran_num ab_tran.ins_type ab_tran.trade_date ab_tran.input_date ab_tran.external_lentity ab_tran.internal_portfolio parameter.unit ab_tran.currency ab_tran.position header.ticker header.cusip header.isin ab_tran.internal_contact

Confidential

Page 41 of 55

4.4.2 Report Example

4.4.3 Error Handling


None

4.4.4 Logging Requirements


Standard logging.

Confidential

Page 42 of 55

4.5

Script Name: STD Missing Resets

4.5.1 Logic
The Missing Reset Report shows deals that are missing resets (fixings). This report is typically executed in the pre-EOD process to ensure that resets are fixed and that valid closing prices are applied. This report can be configured to run for amended, cancelled and/or validated trades. It can also be configured to run for the Market Manager Current Trading Date or the Market Manager Current Business Date. This script can create two reports, Missing Reset Energy or Missing Reset Finance. In addition to deals shown in the Missing Reset Energy report, the Missing Reset Finance report will also show deals that are missing resets in the profile_reset table. The respective columns for each report are indicated in the list of columns below. If one or more deals is found with a missing reset, this script will exit with a FAILED status. If NO deals with missing resets are found, this script will exit with a status of SUCCEEDED. The FAILED and SUCCEEDED statuses are useful when configuring the script (task) to run in a workflow, so that exception processing can be triggered if deals with missing resets are found.
Column Name Business Unit Projection Index Index Source Reset Date Deal Num Tran Num Tran Status Ins Number Ins Type Start Date End Date Book Ticker Cusip Projection Tenor Confidential Index Description Internal Business Unit Curve fixings are performed against Reference source of projection index Missing reset date Deal Number Transaction Number Transaction Status Instrument number of deal Instrument type of the deal Reset start date (RFIS date) (Energy report only) Reset end date (RFIE date) (Energy report only) Book of the deal Ticker of the instrument (Finance report only) Cusip of the instrument (Finance report only) Tenor of reset (Energy report only) Database Table/Formula ab_tran.internal_bunit param_reset_header.proj_index param_reset_header.ref_source reset.reset_date ab_tran.deal_tracking_num ab_tran.tran_num ab_tran.tran_status ab_tran.ins_num ab_tran.ins_type reset.start_date reset.end_date ab_tran.book header.ticker header.cusip param_reset_header.proj_index_tenor

Page 43 of 55

4.5.2 Report Example

4.5.3 Error Handling


None

4.5.4 Logging Requirements


Standard logging.

Confidential

Page 44 of 55

4.6

Script Name: STD EOD Summary P/L

4.6.1 Logic
The STD_EOD_Summary_PNL report compares the mark-to-market and P/L values for yesterday and today for each instrument. This report summarizes the changes in MTM detailed in the STD_EOD_PNL_Explained report. However the Total P/L shown in the summary report does not always equal the P/L in the STD_EOD_PNL_Explained report, especially in cases of new trades. Today is defined as the Market Manager Current Date. Yesterday is defined as the prior day with saved EOD simulation results. Results are obtained from saved EOD simulation results. One P/L report is created per each specified portfolio.
Column Name MTM Yest MTM Today Yest Pymts Total P/L Opening P/L New P/L MTD P/L YTD P/L Description Base MTM for yesterday Base MTM for today BASE_CFLOW_CURRENT_RESULT for yesterday BASE_UNREALIZED_PNL_RESULT BASE_UNREALIZED_PNL_RESULT for trades where trade date is today Total PNL - Opening PNL Base Unrealized PNL MTD result Base Unrealized PNL YTD result Scenario Results/Formula tran_results.BASE_PV_RESULT (yesterday) tran_results.BASE_PV_RESULT (today) tran_results.BASE_CFLOW_CURRENT_RESULT tran_results.BASE_UNREALIZED_PNL_RESULT tran_results.BASE_UNREALIZED_PNL_RESULT Total PNL - Opening PNL cum_results.BASE_UNREALIZED_PNL_MTD_RES ULT cum_results.BASE_UNREALIZED_PNL_YTD_RESU LT

Confidential

Page 45 of 55

4.6.2 Report Example


By Portfolio

Confidential

Page 46 of 55

By Counterparty

Confidential

Page 47 of 55

By Toolset

4.6.3 Error Handling


None

4.6.4 Logging Requirements


Standard logging.

Confidential

Page 48 of 55

4.7

Script Name: STD EOD PNL Explained

4.7.1 Logic
The End-of-Day Profit and Loss Explained Report explains changes in the unrealized profit/loss values (Unrealized PNL result) between the previous business day and the current day. There is one report generated for each portfolio. The first section of the report summarizes the results for the portfolio. The second section details the impact associated with changes to each curve in the portfolio.
Column Name Instrument Type P/L Description The change in the mark-to-market between today and the previous business day. Taken from the Unrealized P/L result. The sum of all columns except P/L Variance: Impact of Delta + Impact of Gamma + Impact of Vega + Theta + Impact of Fixings + MTM New Trades + Impact of Amendments/Buyouts/Cancel + FX Gain/Loss The amount of P/L that is not explained by adding the "explanation columns". (P/L - P/L Explained) Describes the P/L attributable to the change in Delta. If inheritance is set to Yes on the curve: Impact of Delta = YIELD_CURVE_RESULT/FX_RESULT If inheritance is set to No on the curve: Impact of Delta = OUTPUT_YIELD_CURVE_RESULT/FX_RESULT Impact of Gamma Describes the P/L attributable to the change in Gamma. Using the price yesterday as the basis, we find the price today to match each gridpoint. 1. For stationary gridpoints, we first look to see if a corresponding price (based on label) exists, if not, interpolate a price from todays curve using today as the basis for the date conversion.

P/L Explained

P/L Variance Impact of Delta

(called Yield Curve Impact in v50)

2. For rolling gridpoints, we interpolate a price from todays curve using yesterday as the date basis for the conversion of the label.

If inheritance is set to Yes on the curve: Impact of Gamma = GAMMA_YIELD_CURVE_RESULT/FX_RESULT

Confidential

Page 49 of 55

If inheritance is set to No on the curve: Impact of Gamma OUTPUT_GAMMA_YIELD_CURVE_RESULT/FX_RESULT Impact of Vega Theta =

Describes the P/L attributable to the change in Vega. The change in P/L that is explained by the time value of money. It measures how the deal's MTM has changed in one day. Based on the saved EOD COST_OF_CARRY_RESULT of the prior good business day for which the EOD simulation was run. P/L that is attributable to the setting of rates (resets) that were previously calculated as projections of future rates. The P/L is calculated with projected rates and is compared to the P/L following the rate fixing. The portion of the P/L that is due to new trade Mark-to-Market result. Determines new trades by looking for trades that exist in today's results but not yesterday's. P/L directly attributable to Mark-to-Market calculations affected by cancellations, amendments, buyouts or closeouts. The impact_of_closeout flag regulates whether or not to include the Impact of Closeout result in this column of the report. If base PNL results are generated, the calculation is Unrealized Base PNL - (Unrealized PNL * FX Rate)

Impact of Fixings

MTM New Trades

Impact of Amendments/Buyout/Cancel

FX Gain/Loss

Detailed for [Portfolio]


Projection Index Contract Month Instrument Type Impact of Delta Impact of Gamma Impact of Vega

Confidential

Page 50 of 55

4.7.2 Report Example

4.7.3 Error Handling


None

4.7.4 Logging Requirements


Standard logging.

Confidential

Page 51 of 55

4.8

Script Name: STD Matured Trade Listing

4.8.1 Logic
The Trades by Maturity Report lists validated trades by maturity. The maturity of a trade is based upon the event date of the close transaction event.
Column Name Description Database Table/Formula

Number of Trades by Maturity Trade_Details Maturity Buckets; Double click to view Trade Details Running_Total Number of active trades in maturity bucket. That is, number of trades maturing during or after this maturity bucket. Trade_Per_Period Number of active trades maturing in this maturity bucket. Start_Date_Sym ex: 0d, 1y End_Date_Sym Start_Date End_Date Trade_Details [Period] Trade_Num Start_Date_Sym End_Date_Sym Maturity_Date Internal_Bunit Portfolio_Id Ins_Type Toolset External_Bunit Column Name ex: 0d, 1y ex: 21-Jul-03 ex: 21-Jul-03

ab_tran_event_view sum(sum(trades_per_period))

sum(trades_per_period)

static value in script static value in script parsed from symbolic start date parsed from symbolic start date

Deal Number Symbolic Start Date Symbolic End Date Maturity Date of the deal Internal Business Unit of the deal Portfolio ID of the deal Instrument Type of the deal Toolset of the deal Counterparty of the deal Description

ab_tran_event_view.tran_num static value in script static value in script ab_tran_event_view.event_date ab_tran_event_view.internal_bunit ab_tran_event_view.portfolio_id ab_tran_event_view.ins_type ab_tran_event_view.toolset ab_tran_event_view.external_bunit Database Table/Formula

Confidential

Page 52 of 55

Start_Date End_Date

Formatted Start Date Formatted End Date

parsed from symbolic start date parsed from symbolic start date

4.8.2 Report Example

4.8.3 Error Handling


None

4.8.4 Logging Requirements


Standard logging.

Confidential

Page 53 of 55

5. Appendix A: List of EOD simulation Results


Simulation results are broken down into four different result types: o Transaction Results This refers to information relating to a specific deal(s). Mark-to-Market and NV / PV are example of transaction results. o Cumulative Results Include information building from prior days results. Examples included Day over day change, Month to Date (MTD), Quarter to Date (QTD), Year to Date (YTD), and Life to Date (LTD) results. The cumulative results provide a means of tracking the changes in P&L over the life of a deal. Cumulative results will have a MTD, QTD, YTD or LTD suffix. o Leg Level Results Generated on a delivery period basis are included in the leg-level results category. Examples include all results with a by leg suffix. o General Results These results are more sophisticated results and calculate multiple columns of data that do not necessarily classify as other categories of results. All Greek Related results are general results as are all Monte Carlo related results. For more information on simulation results consult your OLF user guide.

Confidential

Page 54 of 55

5.1

Bank of Paraguay EOD Simulation List


Base Unrealized P&L YTD Convexity Current Cash Current Fixed Rate Current Float Rate Current Notional Result Current Position Current Rate Daily Accrued Interest Daily Accrued Interest MTM Delta Delta By Leg Result Delta by Trans Delta Contract FV Result Delta Contract PV Result Fee By Leg Fee PV By Leg Future Known Cash Future Known Cash by Deal Fwd Premium FX Gamma Gamma By Leg Result Gamma by Trans Gamma Contract PV Results Historical Cash Impact of Amendments Impact of Buyout Impact of Cancellations Impact of Closeout Impact of Resets Index Effective Rate Results index output Index Rates Mod. Duration MTM MTM Detail NV By Leg Result NV Total By Leg Result Payment By Leg Payment Date By Leg Period Accrued Interest Thru Period Accrued Interest To PNL Detail PNL Detail MTD PNL Detail YTD PNL Explained PNL Summary Price By Leg Result Price Current By Leg Price Future By Leg Price Prior By Leg PV By Leg Result PV Total By Leg Result PV w/o Resets Realized P&L Realized P&L Realized P&L LTD Realized P&L MTD Realized P&L YTD Realized PNL By Leg Remaining Size By Leg Theta Total Interest Tran Gpt Delta Tran Gpt Delta By Leg Tran Gpt Delta By Side Transactions Unrealized P&L Unrealized P&L By Leg Unrealized P&L LTD Unrealized P&L MTD Unrealized P&L YTD Vega By Leg Result Vol By Leg Result Volume Current By Leg Volume Future By Leg Volume Prior By Leg

Accrued / MTM By Leg Accrued FWD Premium Accrued Interest Accrued Interest D + 1 Accrued Interest LTD Accrued Interest MTD Accrued Interest YTD Base Accrued Fwd Premium Base accrued Interest Base Accrued Interest LTD Base Accrued Interest MTD Base Accrued Interest YTD Base Current Cash Base Current Physical Equiv Base Daily Accrued Interest Base Fwd Premium Base Historic Cash Base MTM Base PNL Explained Base Realized P&L Base Realized P&L LTD Base Realized P&L MTD Base Realized P&L YTD Base Unrealized P&L Base Unrealized P&L LTD Base Unrealized P&L MTD

Confidential

Page 55 of 55

Anda mungkin juga menyukai