Symphony has long been committed to an open technological approach. A recent, and significant, extension of this approach is the decision to adopt the FDC3 protocol.
Prior to this commitment, our CIO Dietmar Fauser was selected to serve on the FINOS Board where he helps to guide the future direction of the standard. Symphony has thus been working with the leading Desktop Integration Platforms (DIPs), our customers, and key partners to define high priority workflows to execute.
What’s the impact for our community? By promoting open standards and APIs, we strive to provide our clients and partners with the flexibility and choice to create a connected ecosystem of applications that best suit their needs. DIPs provide the connective tissue so that applications built by different technology providers can easily exchange information in the context of a workflow. And because in most cases, at some point in the chain workflows need human collaboration, Symphony plays a critical role in this ecosystem.
Desktop Integration Platforms (DIPs) are client-side integration solutions that facilitate more efficient workflows for financial professionals who navigate between many desktop applications on a daily basis.
From a functional point of view, DIP integrations provide many benefits, such as:
As explained in a previous publication, Symphony considers DIP integration as a key workflow enabler and is actively working with the FINOS FDC3 working group to standardize DIP integration APIs across the industry.
Symphony considers DIP integration as a key workflow enabler and is actively working with the FINOS FDC3 working group to standardize DIP integration APIs across the industry.
Even though DIP providers aim to offer flexibility to connect to their platforms, a few technical challenges need to be addressed to integrate an application like Symphony.
The first challenge is that Symphony is not a customer-specific solution, but a universal platform designed to work under different configurations. Consequently, Symphony must support all DIP providers. In addition, the Symphony DIP integration has to be as lightweight and flexible as possible. In other words, it should be possible to enable the integration through a simple configuration change and should not require complex software updates or dedicated software versions. Finally, we want to keep our client software modular and avoid unnecessary code for customers that don’t use a DIP integration – i.e. the Symphony desktop client should not even download resources dedicated to DIP integration if such integration is not activated.
This is why Symphony has selected a technical solution based on optional sandboxed plugins transparently deployed upon configuration changes. These plugins will be developed and validated by Symphony. They will be hosted with the Symphony code base so their deployment will not require any IP whitelisting or network configuration changes.
Symphony has selected a technical solution based on optional sandboxed plugins transparently deployed upon configuration changes.
As security is one of Symphony’s core tenets, our approach to DIP integration must not introduce any risks in this area. DIP providers usually offer two integration mechanisms for applications based on web technologies like the Symphony client:
From a technical standpoint, the embedded mode is much simpler to implement and is probably the best option for applications that do not manage sensitive information. However, web applications running in DIP webviews do not run in the browser’s sandboxed environment, which means that code running in the DIP can technically access all data loaded in the webapp memory. Importantly, this would compromise Symphony’s security chain, such as messages and chat cryptographic keys, which is why embedded mode is not the default Symphony integration mechanism.
As previously mentioned, our integration solution is to rely on optional plugins (also known as adapters) that will allow communication with any DIP, while still running the Symphony client as a standalone process. A secondary benefit of this approach is that running as a standalone application also ensures better performance: the Symphony client can run in the background, enabling it to quickly react to any client-side events.
Security is one of Symphony’s core tenets, our approach to DIP integration must not introduce any risks in this area.
The DIP adapters are optional plugins that will extend the Symphony client capabilities and will be dynamically downloaded through activation switches in the Symphony Admin and Compliance Portal.
The goal of these plugins will be to open communication channels between the Symphony client and the DIP APIs.
Technically, they will be loaded as headless sandboxed iframes and downloaded from the Symphony resource servers along with the rest of the Symphony client code. As such, no specific changes will be required in the customer environment as the plugin code will be downloaded like any other Symphony resources. In addition, the adapter code will be managed by Symphony in partnership with the DIP providers.
From a communication standpoint, the plugins will provide a translation layer between the Symphony and the DIP APIs. As such they will have two connection points:
The goal of these plugins will be to open communication channels between the Symphony client and the DIP APIs.
The plugin logic will be simply to:
To make this possible, the Symphony client will expose a new TypeScript-compatible API that will come on top of the current client-side extension APIs. This new API will improve the developer experience. It will expose new services and events – like the capacity to submit messages, which is not offered today – and will also integrate a finer permissions management system to select which events or data can be shared with the DIP’s agent.
This new client API will also become available to future client-side extensions (also known as Symphony extension apps).
From the DIP perspective, the Symphony application is a new client that must provide proper authentication to connect to the DIP agent.
As Symphony’s objective is to support all DIP providers through a common set of APIs, we will move to an OpenID authentication model which is standard and provider-agnostic.
During the connection phase, the OpenID token will be passed to the DIP agent to authorize the secure WebSocket connection. The DIP agent will have to authorize the connection by validating the token expiration date as well as its claims and digital signature (this will be done with the Symphony public signing key that will be either provided to the DIP configuration or exposed through a public Symphony Back End service accessible to the DIP).
Once the connection is authorized, the DIP will have to generate a random session key that will be passed to any subsequent calls to the DIP internal APIs:
The first FDC3 integrations supported by the Symphony client will cover the following topics.
As input (i.e. messages received from the DIP agent):
In both cases, the Symphony client will display a confirmation dialog to let the end user fine-tune the chat creation (i.e. room name, member lists) and/or the chat messages.
As output (i.e. messages sent to the DIP agent):
Symphony is deeply committed to developing and improving its client-side DIP integration capabilities.
As explained, DIP adapters will come as native Symphony plugins that will be dynamically installed or removed through simple configuration changes. Adapter plugins will allow leveraging of all DIP capabilities, as there will be one adapter per DIP provider, which means both standard and proprietary APIs will be supported. This modular approach allows Symphony customers to choose any DIP provider to support standard FDC3 integration.
Our first beta version will be available in the first half of 2022 and is designed to be compatible with all current DIP providers.
The current digital environment provides organizations with a range of messaging solutions, each characterized by varying levels of security and compliance capabilities. This has become particularly prominent as people add messaging apps to their personal and professional workflows as a complement to e-mail.
Symphony’s Cloud9 has been awarded ‘Best Sell-Side Trading Communication System’ at WatersTechnology’s Sell-Side Technology Awards 2025.
In this interview we hear how Cloud9 differentiates itself with a modern, cloud-native approach to trader voice. It requires no on-premise infrastructure and functions primarily as a software application, aligning with broader cloud-based communication trends.
Cloud9’s flexible architecture empowers technology teams with robust deployment, while seamlessly supporting remote and mobile work. Michael Lynch also explains the plans for the mobile app and how it will extend voice beyond the desk to users on the go, offering 24/7 trading control.
Watch the interview to learn more.
Symphony’s leadership team have shared their expertise regarding the impact to the industry and offer valuable insights into how firms can collectively respond to information security threats. Here are 7 key insights from these conversations:
