As Cobalt prepares to go live, its founders reflect on the difficulty for banks to innovate like they used to, why blockchain technology in its traditional format is ill-suited to processing FX transactions and why shared infrastructure is – finally – a reality.
The first thing that Andy Coyne and Adrian Patten, the co-founders of Cobalt, are keen to emphasise is that the system that they have built is very real and is already up and running. Currently, Cobalt has live transactions from 12 banks going through the system and is due to go into full production this year. They insist that “full production” whilst a technical reality is really only when the final paperwork and vendor risk management (VRM) documents get final sign-offs.
It’s hardly surprising that Coyne and Patten want to highlight that they have built a tangible product that is actually being used by financial institutions given that, for all the recent hype around fintech “disruption”, thus far there has been limited ability to act on it, particularly when it comes to infrastructure solutions.
There are a number of reasons why this disparity between the hype and the lack of real-world execution has occurred.
One is that, at a time when compliance with new regulations such as MiFID II has been dominating both financial and human resource at many banks and large financial institutions, implementing new fintech tools hasn’t necessarily been a major priority for many firms, with new projects simply getting put on the back burner or not finding the political or financial capital that they need to develop further. Another reason is that in many cases the benefits that these fintech tools can bring are deemed to be outweighed by the difficulty of implementing them to a complex large institution like a bank.
“This is why we’ve been very careful to make sure that people understand that we can save them money from day one, meaning this year,” says Coyne. “Because although people like to talk about the big picture, they actually have very short-term time horizons and so you have to be able to deliver cost savings in year one, and these have to be meaningful cost savings.”
But one possible reason why the fintech revolution predicted by many has struggled to build up any meaningful steam is because of all the hurdles that fintech firms have to clear in order to be adopted by established financial services firms.
Talking about VRM, Patten declares: “It’s going to be the death of the banks, it’s the thing that kills innovation.”
He continues: “The banks have multiple layers of legal and compliance and risk management, startups have to jump through a ridiculous number of hoops to get through this process. But the fact is that if the bank’s existing vendors tried to go through this process they wouldn’t be able to meet all the requirements, so the newer firms are held to a higher standard than the existing incumbents. This is why you see legacy providers that have monopolies in certain areas of the market.”
Patten argues that making it difficult to implement new vendor solutions will ultimately prove counter-productive for banks as there is an opportunity cost to their businesses as they fail to innovate or evolve with the technology available.
Reconciling the data
Although it may have been a time consuming process, it seems that Cobalt has managed to navigate the complex bureaucratic landscape of the modern banking system and so now the next step is that it needs to deliver on the cost savings that it says its system can provide. Right now, Coyne and Patten claim that the biggest banks spend between $500 million to $1 billion per year on FX operations, a figure that they say could be vastly reduced if these banks move away from their existing legacy infrastructure.
The problem starts, says Patten, with the initial data set that the banks get following an FX transaction. So if two banks conduct an FX transaction via a multibank platform, the platform will then send out a copy to bo
th the buyer and the seller, and then also to any risk management or processing systems that are being used by each of them. This instantly creates four copies of the trade that need to be reconciled.
On the surface this sounds like a simple enough task, but the reality is that there’s a whole range of differences that can exist between each copy of the transaction that makes reconciliation challenging.
For example, the identifier codes that each counterparty assigns to the
mselves and others is often different – JP Morgan might use “JPML” as its code, while another counterparty might still have the bank down as “CHML”, the old code for Chemical Bank London. Another problem is that different parties risk management systems run to varying lengths of decimal places, meaning that the trades won’t match up. Yet another issue is that in many cases, as banks have merged or acquired other businesses, they never retired any of the systems that these firms were using. As a result, Patten says that he knows of one bank that has more than 200 separate systems for FX post-trade processing.
He adds: “It really is this simple: legacy infrastructure is very expensive to run.”
Cobalt aims to solve this problem by picking up the different copies of the trade transaction and, using what Coyne and Patten term a “pre-ledger”, it checks the various market access rules, permitted product rules, currency, designation notices, credit limits, term limits, etc, associated with each party to check if the trade should be allowed to pass to the ledger. If on the pre-ledge it is determined that there is any discrepancy with any of these limitations, each counterparty is alerted and they can choose to amend, cancel or proceed with the trade.
If the trade proceeds, then the Cobalt system creates a single shared copy of the trade with all enrichment reference data, all of the financials and has a unique trade identifier (UTI), that each counterparty can see.
“Then everything else becomes really very easy,” says Coyne. “Novation netting, payment netting and multilateral compression, all these things become much easier because you have a prereconciled data set that no one can disagree with.”
The problem with blockchain…
Because the infrastructure for reconciling the different data sets is shared, it is vital that users of Cobalt’s system have confidence that the reconciled data cannot be changed, tampered with or hacked.
While the immutability of shared data is supposed to be one of the great benefits of blockchain technology, Coyne and Patten found that the solutions that were available in the market were not fit for purpose.
“There’s a few problems with blockchain,” says Patten. “One, it’s slow. Two, it’s expensive, and the whole point of Cobalt is to bring costs down. And three, the banks don’t agree on exactly what form the ledger should take, and you need consensus to make a blockchain work.”
Given that everything up until settlement in FX trading is ultimately a message rather than a transfer of financial value, Patten says that the proof of work and consensus models that underpin some blockchains, such as the Bitcoin Blockchain, is not necessary.
Instead, the Cobalt staff developed a data immutability service, which they call the Babylon Network. Unlike blockchain, which encrypts data, this uses a digest algorithm to encode the data coming in to create a unique hash value for each data set.
“The hash value is effectively a digital fingerprint of that data, which is posted onto a network of nodes that synchronise the information via a multicast network,” explains Patten.
It’s important to note that this means that the underlying data itself is not on the network, only this “digital fingerprint” of it. The client who sends the data to the Babylon Network then gets the receipt back from Cobalt and a message is sent out to the nodes. The message size is set at 256 bytes and the network has the ability to process 30 million messages per second.
“So if a bank comes to do a payment on that data, once they take all the transaction details that they need to put into their payment system, they re-hash it, send that hash record back to the first node – they can have their own node if they want – and then if the two match it means that the data hasn’t been altered,” says Patten.
He adds: “And what’s really cool is that if they don’t match, then the Babylon Network can identify where the discrepancy is, even though it doesn’t actually have the underlying data. So, for example, if someone’s changed the SSIs to make a payment to another bank that wasn’t on the transaction, the network can identify that something was changed between, say, byte numbers 15 to 25 and we can tell the bank where they need to go back and look. But the data itself is never on the network and we never have access to it.”
The point here is that this data immutability service is, according to Coyne and Patten, secure, scalable and, because it’s mainly built using open source components, highly cost effective. It’s worth pointing out here that although Cobalt developed and utilises this data immutability service, the two are distinct and separate. Whereas the Babylon Network can be applied to any data set, and therefore has a variety use cases, Cobalt is a utility shared infrastructure that is specifically focused on foreign exchange.
Shared infrastructure: heard it all before?
This might all sound well and good, but the fact is that potential value of shared infrastructure has been talked about for some time while, once again, there has been little tangible evidence of the implementation of it in FX.
Various market participants and vendors have been making the case for shared infrastructure for years – arguing that essentially anything that isn’t a revenuegenerating centre or a differentiating service is a cost on businesses – and this cost could in many areas be significantly reduced by implementing shared infrastructure that can leverage economies of scale and reduce infrastructure duplication.
This makes logical sense on paper, yet the only real example of shared infrastructure in the FX markets remains CLS, which was launched in 2002. Why has the industry been so reluctant to embrace shared infrastructure until now, and really, has anything changed in this regard?
“I asked myself this exact same question: why now? Because although the technology would have looked a little different, it could have been done before,” says Coyne.
He continues: “Two things have happened. The first is that all the blockchain hysteria did trigger a change. Even though the outcome of that isn’t going to be what people thought, it caused people to think more about the concept of moving to better, utility-like shared infrastructure and so opened a lot of doors for discussion. In addition to this, the profitability of the industry just isn’t what it used to be. The overheads for regulatory compliance are higher than they’ve ever been and keep growing, and so for the first time, people are starting to focus on the bottom line. When I started in the FX industry, traders got paid on revenue and firms have often struggled to understand the cost base of their businesses, but now firms are analysing this much more and they’re going back to the people who run the FX business to tell them that, on a net basis, they’re not as profitable as they thought they were. And it’s this cost pressure that is driving firms towards shared infrastructure.”
And finally, as a provider of shared infrastructure, both of the Cobalt founders stress the importance of remaining independent. Against a backdrop of derivatives exchanges buying OTC FX platforms with a view to offering pre- and post-trade services around those platforms to recreate the horizontal silo model that they’re used to operating, Coyne and Patten stress that they only view Cobalt as a viable proposition if it is independent.
“This business only operates by being independent, it cannot be tied to a venue or exchange. It doesn’t mean that other exchanges or venues won’t invest, because they will, but it will only be a relatively small amount because we are committed to staying independent,” insists Patten.