The Challenge:
Front Arena is a position keeping system that is used by financial institutes to automatically process their trading in financial instruments. Trades in different products are entered by the Front office users into the system. Data is divided up and saved in multiple tables in a relational database. Based on this data the trades and positions are processed and reported by other departments like Operations, Accounting and Risk.
The trade entry is complicated with multiple data fields and high operational risk. Data entry errors lead to processing issues in the Back office and incorrect calculations. Finding and fixing these issues is challenging and ties up resources across different units. There is a possibility to write validation rules but this requires anticipating what the errors will be. In practice validation rules are written only if an error happens again and again.
Since every institution using Front Arena has its own individual processes there are few general validation rules that can be written. Obviously we need another approach to the problem starting from what is right instead of thinking about what can go wrong.
The Goal:
Within the Front Arena workflow controllers usually look at trade entries and raise issues with the traders. In an ideal world they would have enough time to do a thorough check of every relevant field. Unfortunately this is often not the case and many errors go unnoticed for an extended period of time.
The goal is therefore to facilitate the controlling of trade entries by highlighting trades that have data anomalies.
The Idea:
Sooner or later most trades with wrong data entry are identified and fixed. We can therefore extract a dataset of “clean” trades from the past and use machine learning techniques to teach an AI what the right data entry looks like. Then we can test new trades against the accumulated knowledge of the AI and find anomalies. These anomalies are then raised with Operations for further review. The AI sends the trade with fields that it deems wrong and even makes suggestions of what the right entries should be. It is like a very conscientious controller that checks each and every field much faster than any human can.
And being an AI it should also keep on learning. If an anomaly it has identified turns out to be a valid trade then it should know this the next time around.
The Solution:
Our proprietary tool the Plausibility Engine was developed with this kind of problem in mind. Its algorithms analyze of the clean data from the past and learn what trade entries were necessary in each situation that occurred. They recognize the recurring patterns and store them for future reference just as a human will. This is the initial learning process.
The Plausibility Engine then uses this knowledge in daily operations and applies it to new trades. If a trade is unusual it generates warnings and suggestions for the users who can the review the case and decide what to do. Finally if the trade is valid the Plausibility Engine can learn to accept a similar trade entry the next time. A short demonstration of this can be seen in the following video.
Integration with Front Arena
Within the system architecture of Front Arena the Plausibility Engine is a separate service running constantly as a socket server. The server listens for incoming validation requests, performs the validation and sends back the result to the client. The client is integrated within an ATS which is also a service listening for trades in the Front Arena database. So whenever a user saves a new trade or changes it, this triggers the ATS to send a validation request to the Plausibility Engine. It then gets the response and saves it in Front Arena. In case there is an issue it generates a warning out of it and presents it to the user.
Limitations:
As with any AI the Plausibility Engine only knows what is has learned from its data. Since every client uses Front Arena differently it needs to be calibrated with the data of this particular client. It has no general knowledge so even if a trade entry is valid it will reject it if it hasn’t seen it before. This can also be viewed as an additional benefit because it may be a good indicator for new products or features being entered in Front Arena. Maybe there is nothing wrong with the product but if it hasn’t been traded before it’s likely that there are no processes for it.
Transaction Reporting for new MM benchmarks
Background: The Libor manipulation scandal from 2012 revealed some cartel-like practices around setting the different LIBOR interest rates. This led to a drive in jurisdictions all over the world for a better regulation of...
ADFL Performance Boosting
The Challenge: Very often we find ourselves in a situation where we have to extend or improve an already existing solution. In this project the client has been utilizing a custom built solution for...
Detecting Wrong Trade Entries with the Plausibility Engine
The Challenge: Front Arena is a position keeping system that is used by financial institutes to automatically process their trading in financial instruments. Trades in different products are entered by the Front office users...