About Us | Search | FAQ | Contact Us
Reducing operational risk and operating costs through Straight Through Processing
Many firms are seeking to adopt a Straight Through Processing (STP) solution to manage their financial transaction processing. According to a recent Tower Group Study, the primary driver for increased IT spending post Y2K will be STP solutions. Firms seek to implement STP for primarily two reasons - the reduction of operating costs and the reduction of operational risk. But what exactly is Straight Through Processing? While there is a lot of discussion, a definition is rarely given. Therefore, let us begin our examination by defining STP as:
Use of a single system to process or control all elements of the work-flow of a financial transaction, including what is commonly known as the Front, Middle, and Back office, and General Ledger.
The definition of cost reduction seems obvious, but operational risk is less so. Therefore, the next concept we must define is operational risk:
Operational risk is the risk that is inherent in the actual processing of financial transactions, and can include risks caused by deliberate actions, non-deliberate actions, or by errors/gaps in trading systems.
With these definitions in place, how does STP help to reduce operational risk while also reducing cost? Let's start this analysis with a consideration of how the absence of STP can create conditions in which operational risk is difficult or impossible to control.
Multi System Operations
Multiple systems also give rise to the possibility for deliberate P&L arbitrage. With two systems making different valuation assumptions, it is possible to create fictitious P&L by creating synthetic positions. Consider the case of a FX Options desk hedging with FX Forwards. Most option pricing models present value options. However, some FX forward trading systems forward value P&L. The trader can arbitrage this difference in valuation, and create fictions P&L by creating a series of implied forwards (using two options) in the option system, perfectly offset by a real forward. While this position should be matched, the difference in pricing between the two systems allows the trader to create fictitious profits.
Another problem can occur when one system prices more products than the other. A front office application may value an interest rate swap, but the legacy back office may be unable to value the swap as a single product. Oftentimes, the solution is a band aid approach whereby a vanilla swap is represented as a strip of time deposits or as a bond and a floating rate note. By representing the transaction in two separate pieces, an important control feature is lost, and as such it will be more difficult to reconcile the positions between systems.
Efficiencies Through the Use of One System Versus Multiple Systems
Event management can also either complicate the interface issue or, if an interface for events does not exist, require redundant event processing. For example, an interest rate swap fixing must be done in both the front and back office in order to produce correct valuations and risk measures. Either a complex interface must be created to feed this fixing from one side to the other, or the fixing must be done in both locations. The issue is compounded even further if you consider the actions that need to be taken to undo an erroneous fixing.
A final issue to consider is the cost of maintaining multiple systems. Multiple systems imply both multiple vendors and perhaps even multiple hardware platforms. By combining systems and platforms, IT costs savings can be achieved. Perhaps even larger savings can result from the ability to manage static data in only one location. Multiple systems mean redundant static data maintenance. The addition of a single counter party or currency, which would only need to be defined once via a true STP solution, would have to be defined seven times for a desk using seven systems. This also leads to the need to reconcile static data between systems, another task eliminated via the use of a STP solution.
Given the problems with multiple systems, a STP solution can be effective in both reducing operational risk and costs. To be effective, a STP solution must:
n Cover all products handled by an existing desk
n Be a truly integrated solution not requiring additional interfaces
n Price products in a consistent way in all phases of processing (front, back, ledger)
nMaintain static data in a central location Opportunities available via STP
Having explored the problems that arise from multiple systems, let us next ask "Does the use of STP offer any advantages other than the elimination of multiple systems?" The answer is yes.
First consider a typical operational flow for a transaction. The work-flow for even a simple financial transaction tends to be quite complex. An effective STP solution will allow the user to monitor the flow at various points to prevent problems such as missed trades or unverified positions. A STP solution should allow the user to create a STP monitor, that is a screen or report that shows the processing status of any and all transactions. This screen or report shows trades that have been accepted into the back office, the verification status, the payment status, etc. The STP monitor screen or report permits the user to:
n Quickly spot trouble areas, including fictitious and hidden trades
n Ensure that all trades and events are processed
n Track verification and integrity of data
nTrack work-flow failures which may indicate other problems
The status screen or report described above promotes efficiency as problems are quickly identified. Creating a more efficient work-flow can be extended to the concept of exception processing.
One of the main benefits of STP is that an automated processing environment can be implemented, which in turn leads to substantial time and cost savings. With the introduction of 'exception criteria', the automated STP environment can become even more useful, allowing for operations time to be spent researching and examining those financial transactions that match the defined criteria.
Exception criteria definition lets the user, for example, flag trades from a particular trader or counter party, trades of a certain size, or even trades outside a preset tolerance level. The incorporation of exception criteria can make for the more intelligent use of time by better directing examinations of certain trades.
Exception criteria must be flexible and easy to modify so that new conditions can be easily integrated into the criteria set. A sample list of exception criteria is shown in. The exception criteria should fit into any part of the work-flow process.
A STP solution will also allow for the automated processing of all transactions not meeting the exception criteria, which subsequently streamlines operations. Any transaction that does meet the exception criteria can be flagged for further analysis, resulting in better use of staff time. A STP system can offer the user new tools for controlling operational risk and costs. An effective STP solution will provide:
n A work-flow monitor screen or report
n Automated work flow processing
n Flexible exception criteria definition
nThe ability to place exception criteria in various points in the work-flow
|Home | About Us | Search | FAQ | Contact Us|