Read the article and learn about:
- What SimCorp’s Technology Labs work on
- How machine learning prototypes can help support the full trading lifecycle
- Why robotic process automation (RPA) can’t be used as a band aid to solve integration challenges
Technical Fellow, Vice President – Enterprise Architecture, SimCorp
Connect with Anders on LinkedIn
About the author
Anders looks after the enterprise architecture of SimCorp products. This includes cloud-first strategy and roadmaps for both product architecture and enterprise integration. Anders also initiated SimCorp’s machine learning efforts.
Machine learning and artificial intelligence (AI) will transform our lives in the decades to come. But machine learning also has a role in the more near term to address concrete problems users currently face on a daily basis. This article explores how SimCorp is looking to exploit these opportunities.
At SimCorp, we have set up a dedicated research function, SimCorp Technology Labs, to pursue our ambitions in the machine learning space as well as in high performance computing. Together with clients, we have developed a list of machine learning-based product ideas, which we are busy qualifying. The most promising ideas will be turned into prototypes and verified by our clients.
Robotic process automation and disparate systems
There has been a lot of talk about robotic process automation (RPA) in the last couple of years and often in connection with machine learning. The two can certainly be combined. But too often the good intentions based on acquiring shiny new toys are misplaced. RPA makes it easier to create automated workflows in an organization with poorly integrated systems. If on the other hand, you consider a platform like SimCorp Dimension, which is integrated across functional areas, you are better off using more of such a platform than using RPA as a band aid to solve integration challenges. That being said, there are use cases where RPA is the right tool, particularly around frequently changing client-facing tools.
When RPA and machine learning are mentioned together, it is typically about letting the machine learn to perform a poorly described series of manual tasks and thus automate the execution of the tasks. Imagine that a settlement break is raised by a post-trade processing system and demands manual intervention to resolve a data issue that prevents it from going through automatically. With enough data, you can train a machine learning component to identify the root causes. But we are not yet at a stage where the resolution is handled by a computer calling your counterparty to negotiate who got the nominal wrong. As a result, we are only automating the easy part of the process, i.e. the root cause analysis within the data you can see, not the external interaction. The human operator will still have to perform that part of the task and his or her day-to-day experience is not vastly different.
Machine learning’s potential with integrated software
Within the integrated system SimCorp Dimension, we offer both the underlying investment book of record and the portfolio and order management tools to support the full lifecycle of a trade. In other words, our integrated software solution has visibility of any post-trade effects resulting from specific choices made pre-trade. In one of our recent prototypes, we leverage that access to allow the system to tell the user creating the trade that with the current combination of key trade attributes like counterparties, instrument and currency, it is likely to fail straight-through processing. Ideally, the front office user is able and willing to take the big picture view and will gradually learn to listen to the guidance provided by the machine learning-based component system. The gain is to ultimately save manual processing downstream, which will fundamentally change processes and reduce overall costs.
Traditionally, traders are perhaps not overly concerned about post-trade processing costs. If that remains unchanged, the functionality can still be used very early in the post-trade processing. Here, the aim is to identify a set of settlement or matching breaks before they become known to the system via subsequent attempts to process the trades. If trades are processed continuously, this may not make much of a difference, but many settlement and matching processes are run in batches or at least when users aren’t around to investigate. This leads to processing delays and in the worst case you may miss a reporting deadline.
Attacking friction in otherwise automated processes by preventing an issue from appearing in the first place is a bit like the crimes detected and prevented before being committed in the science fiction movie Minority Report, if anybody remembers that one. But contrary to a Tom Cruise of the future, our everyday hero users can get their hands on this functionality today via our prototypes.
Note: The mentioned functionality is still in a prototype stage since we would like to get more feedback from hands-on users before we finalize this as product features.
If you’re interested, please don’t hesitate to reach out and hear how you might join the program. Connect with me on LinkedIn and we can start a dialogue.