Interoperability types

A blog based on the paper, “The Myth of Easy Interoperability”

Have you ever been sad that you can’t play Super Mario on a Playstation?[1]  Me too.  Or disappointed at Christmas after receiving a $20 gift card from grandma at one retailer when you would have preferred it at another store?

Can you imagine, then, being unable to settle Bermudan Swaptions or other exotic OTC interest rate derivatives on your favorite blockchain platform?  These are the problems of interoperability.

Interoperability within the distributed ledger technology (DLT) space is a complex issue that affects the industry’s value proposition.  Technically incompatible solutions across asset classes could undermine the fundamental promise of DLT platforms – to facilitate seamless interaction between many assets across different counterparties and geographies.

Interoperability in financial services

Interoperability is the ability of different systems to work with each other. In computer systems, it involves the exchange and use of information.  Discussions about interoperability in the DLT space covers three types of interactions:

  1. DLT platforms with legacy systems (integration)
  2. between different DLT platforms (Fabric-Corda)
  3. different ledgers on the same platform, (e.g. different CordApps)

The solution to the first type of interoperability will be needed to drive adoption for banks. The second requires industry-wide focus groups and deep interaction with technical teams across various platforms and products.  For the third, each platform’s own team is working to ensure that different applications within a given platform’s ecosystem can interact with each other when necessary.  From a technical standpoint, the third type of interoperability is easier than the second.

Could DLT re-create digital islands?

Using different APIs to link and try to connect different DLT products across assets is possible but would be architecturally intensive and complex. Third-party bridging is also possible but such an approach could provoke breaks, credit and operational risks, and re-introduce many of the problems with centralized infrastructure that DLT seeks to resolve.

Take this example: Corporate bonds are issued on a given platform. Participants decide that a cash contract is needed for delivery-versus payment and coupon payments. This can either be built on the same platform, or a different one. Making a new platform could would be adding a new layer of technical complexity for both the cash contract and the corporate bond.

If this precedent expands to other asset classes, the resulting technical complexity has the potential to expand across the DLT ecosystem, potentially resulting in a large permutation of APIs.  The worst case would be different technically incompatible solutions across each asset class, resulting in delineation and dozens of siloed solutions.


While there are a wide variety of DLT-based applications on the market, the current market has a limited number of global platforms that host them.  Continuing to build ecosystems within a manageable number (2-3) of underlying platforms would allow the technology to address historical IT fragmentations while retaining a competitive platform environment.  A manageable number of platforms would reduce integration complexity.  Further, industry-wide focus groups and collaborative projects on standards can help with interoperability between platforms.

[1] Melissa Schilling, Technological Leapfrogging: Lessons from the U.S. Video Game Console Industry.