This isn’t the first time we’ve built a clearing service. In fact, some of our most experienced team members, such as Mohammed Arshad, a highly accomplished Clear Street engineer, have been coding clearing from the very beginning, bringing nearly half a century of skills to our endeavor. Mo codes the posting rules for our clearing engine. He also guides the design and development of the core clearing system. In this Clear Street Q&A, we talk with Mo about how he moved clearing from COBOL to the cloud — and from independent service to monolithic ones and then back again. Mo lays out how the industry has benefited (and learned) from each stage of innovation, and how Clear Street’s combination of microservices and messaging will revolutionize fintech.
What was the earliest clearing system you helped build?
The original version we had was written in COBOL. This was a traditional clearing system in the late 80s, very similar to what the big banks use. The companies that have been on the street for the longest time built their systems at around the same time, a little bit earlier than I was building my first version. These were all based on mainframes and were built with a closed mindset: a siloed set of functions that was very narrow in its scope.
For example, we had one system that did trade capture, and that’s all it did. It didn’t understand anything about what that trade meant downstream, or what had happened previously in the process. This one system got trades, it stored them, and it made them available downstream. That’s all it did. The settlement engine was a totally independent piece that would then use the data that the trading book guy had built, eventually via databases, but at first just using flat files.
The next part of the clearing process was what we call the matching piece of clearing: matching the trades against what was known on the street. Traditionally this was called purchase and sales. The P&S team would have their own system, usually written by a different team than the team that wrote the trade capture, meaning the two systems didn’t always see eye to eye. You ended up needing what was called a reconciliation. The trade capture system would say, “Hey, I got a hundred trades today in our systems alone.” The P&S system would reply, “I got 99.” There was always this additional work that you would have to do to make sure that all the pieces within the process were all talking together and not dropping things along the way.
Keep reading on our blog:
www.clearstreet.io/insights/how-microservices-are-revolutionizing-trading-a-q-a-with-mohammed-arshad
