Nick Kolba
CEO & Co-Founder @Connectifi
FDC3 (Financial Desktop Connectivity and Collaboration Consortium) is a standard for interoperability between applications that has been widely adopted in capital markets, with some of the world's largest financial institutions using it to drive their platforms and create application ecosystems.
I led the creation of FDC3 when I was the CTO at OpenFin - whose platform had a widely used interoperability message bus. While FDC3 was created as a response to the opportunities and challenges at OpenFin, the approach was informed by my own experiences building interoperability tech at other firms, as well as the examples of mobile intents systems.
FDC3 is now going on 7 years old, and its scope and adoption has grown considerably in that time. 2 years ago, I co-founded Connectifi - which has been focused on bringing FDC3 into a native cloud world and transform what interoperability can mean for application integrations going far beyond the financial desktop. It seems like a good time to take a step back and reflect on the history of how we got here.
Back in the mid-2000’s, what were then called ‘mashups’ enjoyed a brief explosion of creativity and popularity. iFrame portal apps like NetVibes provided inspiration, and technologies like Google gadgets and QEDWiki from IBM seemed to be ushering a new dawn of interoperability and low code nirvana. It was out of this heady primordial soup that the earliest forms of what would become FDC3 emerged.
In 2006, Reuters patented a technology called the Common Component Framework (CCF). This was a protocol for interoperability between different components, brokered by a container. While CCF was originally created with iFrames in mind, its real application quickly became integration between web based components and thick desktop containers.
There were some important lessons learned from CCF:
The creation of FDC3 was driven by the experience of seeing the same sub-optimal pattern over and over again in finance. Message buses, bespoke messages, and proprietary APIs force wheels to be constantly reinvented, instead of focusing on critical and high value problems around security, discoverability, and addressing critical business problems.
Here is an excerpt from a pre-FDC3 proposal for interopability standards:
Today, interop is achieved through bespoke agreements between Apps that intend to interact. Intention has to come from the App developers (of both Apps). Security in these systems is largely based on obscurity. Standards for interop will promote the following benefits:
- Robust security
- Plug and play of Apps into end user workflows
- Enabling App discoverability
- Enabling a plugin ecosystem providing services and capabilities to all Apps across an end-user’s desktop.
Early FDC3 proposals focused on standardizing identity through a cloud-based App Directory.
As FDC3 progressed, the focus of the standard shifted to APIs; these have been an important part of the story for developer adoption. It is important to note that (although thinking around implementation has certainly evolved) security and identity were part of the FDC3 story from the very beginning.
There were many challenges in getting FDC3 off the ground; coming up with a solution that would work was certainly part of it. But, what mattered far more was just getting enough key people to the table to agree on a few core principals, and then getting them to actually go out in the world and use it.
A north star for FDC3 at the beginning was simply paving the cow paths that everyone could agree on and being ruthless about doing nothing more than that. If you look at the 1.0 spec, it may seem like there are significant gaps in what is defined. More often than not, these gaps were intentional. Our goal wasn’t to create a comprehensive system describing all interoperability that everyone would ever want to do; it was to lay a foundation of things we could all agree on that would serve as a basis for future agreements.
A big part of the early FDC3 work was actually consensus building. We’d put out proposals, review them with stakeholders, adjust according to feedback, and keep iterating until we came to consensus. If we couldn’t get there, it meant there wasn’t a lowest common denominator to be found, and we simply wouldn’t do the thing. This kept the standard very honest and largely clear of proprietary bias. Another critical benefit was that it got people involved, cultivated a sense of ownership for everyone in the group, and forced the creators of the standard to spend time on outreach and communication, rather than just building a ‘standard’ behind closed doors.
In the end, this commitment to consensus building and finding the common ground helped ensure that the standard wouldn’t be DOA. Since stakeholders had been intimately involved with its creation and the standard was free of non-starters, organizations had every reason to use FDC3 and very few not to.
In 2018, FDC3 was contributed to FINOS by OpenFin as a fully open source project. This move was mutually pivotal and beneficial for both projects. Newly founded FINOS received its first truly community contribution (and one that is still a leading project today), and FDC3 found a home that would ensure its neutrality and open source status going forward.
Another key driver of adoption for FDC3 was evangelism by many players across the capital markets ecosystem. It is notable that these organizations were often competitors; whether they were banks or desktop container vendors, they found common ground in FDC3. The benefits of promoting FDC3 far outweighed the risks of trying to create a competing standard, driving even more adoption.
Looking to the future for FDC3, we hope to see far more investment in concrete use cases that define intent and context data mappings, and fuel the adoption of higher value workflows. As more is learned from real world implementations, we expect this learning to bubble back up into the standard as context and intent definitions that are durable and repeatable.
Also, a future-facing FDC3 will need to approach web and mobile as its primary environments. This will likely mean some re-thinking and streamlining of the standard, as well as new patterns of implementation. Alignment with mobile intents and the expansion of the intents system in iOS is something that the FDC3 community should be paying attention to closely.
Connectifi is constantly thinking about FDC3’s evolution as it grows. We’ve been first in browser, first in cloud, and first in iOS with FDC3, and this is just the beginning. If you want to learn more about what we’re doing with FDC3, interoperability, and integrations in general, we’d love to hear from you. Feel free to reach to us at info@connectifi.co.
%20(2).png)
