April 2013

Implementing the logic behind trade enrichment

April 14, 2013 // 0 Comments

Now, the age old question of where to add this logic in the trade execution and booking IT landscape. Even the Romans had problems with it. enrich the trade data in the middle ware enrich the trade data in the trade execution system before sending use the trade capture interface adapter on the receiving ETRM system I know that enriching data on the middle ware upsets quite a lot of IT-architects, where the rule commonly is that no business logic will ever be implemented on the middleware. One way around this rule that could work is having a data-enrichment system, a server/service that sits in the chain of the functional steps before booking the deal into the ETRM system. Such a system could work out the start and enddate of a prompt deal and slap them onto the trade before sending it further down the line towards the ETRM system. This option adds quite a lot of complexity to the functional interfaces and possibly even a lot of work to maintain that particular “enrichment” server or service. This would be my least preffered option. Enriching the trade with start and end dates on the execution system is a nice idea, but mostly these systems dont allow a whole lot of customization. You would still end up with a lot of custom code that takes the output of the trade capture interface, transforms and enriches the data before sending it onwards to ETRM systems. This solution is a nice one if there is a permanent programmer available that can adjust logic in the trade capture code in a limited amount of time. Enriching the data on the ETRM side raises a different question, and that is whether or not the ETRM systems will accept the information at all if it is not complete. This could be handled by the incoming interface and doing the enrichment and transformation at that side, but still requires a lot of coding. This perspective only lokos at the challenge from a technical side; what might be even more challenging is to get the auditors to agree on the process, and proof them that the implemented process is a right way of doing things. All said and done, the rule that seems most elegant is to store trades in the ETRM system in exactly the same format as they arrive on the trade capture system. (but.. here we go already .. You would still need a trade enrichment system to create or adjust some information that is not captured, but can be derived from the captured information)