End-Of-Day made simple: Mission impossible?

Imagine you come to work around 7 am to prepare for the trading day. You expect a set of reports around exposures, PNL, MTM, etc to give you your starting positions and to help you make decisions what to trade today. They are missing. Someone in IT explains the End-of-Day has failed and it is re-run as we speak.

You take a sip of coffee and wonder whether to shout to someone. Then you go back to Excel and start to recover what happened yesterday to make sure you don’t trade based on wrong positions.

Sounds familiar?
Well, End-of-Day, after all is a mythical monster, working and failing in mysterious ways. A lot of trading companies have fought to provide a stable, predictable, and performant EOD process for a while. Below are some thoughts on how to achieve it and what to look after.

EOD (End-of-Day) is a daily process. ETRM systems need certain processing to occur each day in order to correctly handle the captured trades. The EOD process consists of a series of operational functions that process the trades.
Normally, one would want as lean EOD process as possible or in the words of Antoine de Saint-Exupery: “Perfection is Achieved Not When There Is Nothing More to Add, But When There Is Nothing Left to Take Away”

The EOD process may be either fully automated or semi-automated with some jobs from the workflow requiring manual work. Full automation typically calls for custom solutions. Depending on whether the process is fully automated or not, the EOD workflow may be done entirely during the night or partly during the night and during the day (when manual work is required). A typical example of manual work that could be required is the “price upload” job. In cases of required manual work, usually a messaging task is created that sends a message to the responsible person to do the job. He then sends a message back if the task is done which triggers the next one in line.

In the best case scenario there would be a separate server for the EOD process. As it requires date rolling, this could be disruptive for business-as-usual processes during the day. Therefore, EOD timing should be taken into account in order not to hinder other processes in the system. The amount of time it takes for EOD to complete depends on the computing power, the complexity of the workflow (+amount of data calculated). Possible disruptions of the process should also be taken into account (failed jobs) and predefined if certain failures stop the whole EOD process.

The jobs comprising the EOD workflow could basically be started on two principles: time and event triggered. Normally, there is a chronological hierarchy of the tasks that need to be performed for EOD. The problem with scheduling tasks on a time principle is that they may not always finish on time due to various reasons. (If there is some manual work to be done for a task to be completed, users may not be able to perform it on time; price assessment agencies could fail to deliver prices on time, etc.) Normally time scheduled tasks in EOD will be only used when event triggered ones cannot be used or require too complex setup.

It is important to remember that the End-of-Day process is set to achieve the following basics:

• Prevent users from forgetting to perform their daily tasks by means of automation.
• Achieve automation by scheduling of tasks using a time or event trigger.
• Provide information that is requested by management on a daily basis (Position Reports and trade listings)
• Perform all tasks that are a prerequisite for successful use of Endur. (Data Maintenance, Price Fixing, Roll System Date, Data Upload)

Having this in mind, one should try to set up an EOD process as lean as possible that manages addressing all of the above in accordance to the specific organization`s needs.

Written by Maxim Yachev