Skip to main content

Introduction

Financial and enterprise users rarely work in a single application. They move between pricing tools, order entry, portfolio views, research, and CRM — copying identifiers, re-keying context, and switching windows. Interoperability is what removes that friction: connected applications share context and actions so the user stays in flow, makes fewer mistakes, and finishes tasks faster.

What FDC3 is​

FDC3 (Financial Desktop Connectivity and Collaboration Consortium) is an open FINOS standard for UI-level interoperability. It defines how applications on a desktop or in a browser discover each other, share context (for example an instrument or portfolio), raise intents (“show this chart for this symbol”), and link via channels — without each vendor building bespoke integrations pairwise.

UI control plane vs data plane​

Most integration effort in large organisations goes into the data plane — APIs, messaging, ETL, and services that move business data between systems (prices, orders, positions, reference data).

FDC3 addresses the UI control plane — how applications on the user's desktop or browser coordinate with each other:

PlaneWhat it connectsTypical examples
Data planeBack-end systems and servicesREST APIs, Kafka, FIX, data warehouses
UI control planeEnd-user applications in a workspaceContext share, intents, channels, app directory

These are complementary, not competing. A trade might flow through the data plane while the user experience is orchestrated through the UI control plane — select an instrument in one app and linked apps update instantly, without custom glue code for every app pair.

What Sail is​

FDC3 Sail is a standards-compliant FDC3 Desktop Agent — an implementation of FDC3 2.2 and FDC3 3.0 (For-The-Web / WCP + DACP) that runs in the browser. Concretely, it does:

  • Intent resolution — route intents between applications
  • Channel linking — connect applications via user and app channels
  • Directory search — discover and launch FDC3 applications via an app directory

FDC3 Sail implements the Desktop Agent and host wiring for the UI control plane above. Your FDC3 applications use the standard @finos/fdc3 library and getAgent() — the same API regardless of which Sail path you choose. Per connection, Sail negotiates the FDC3 wire version from the app's WCP hello (2.2 or 3.0) and routes DACP through the matching handler set.

Is it a good fit for you?​

FDC3 Sail is a good fit if you:

  • Need a browser FDC3 host aligned with FDC3 2.2 and/or 3.0 and For-The-Web
  • Want an open-source stack you can run, host, embed, or extend
  • Have (or plan) FDC3-compliant web applications that call fdc3.getAgent()
  • Prefer standards-based interoperability over one-off app-to-app integrations

Consider alternatives or additional work if you:

  • Only need back-end system integration with no linked UI (data plane only)
  • Require a mature vendor desktop with long-term support contracts today — evaluate Sail against your risk tolerance; the project is actively evolving with the standard
  • Need enterprise packaging out of the box (SSO, MDM distribution, hardened installers, multi-tenant ops) — that remains your integration work regardless of which FDC3 host you choose

Status​

FDC3 Sail is under active development and not yet ready for production use (see the root README). It implements FDC3 2.2 and 3.0 (DACP, WCP) and works with the standard @finos/fdc3 client library unchanged. Packaging Sail as an enterprise system — identity, deployment pipelines, operational monitoring, and IT policy — is a separate layer of work for your organisation.

What Sail grows into​

A single Desktop Agent is enough for a lot of hosts, but a real deployment usually needs more around it: pluggable persistence for workspaces and layouts, a lifecycle, and a place for host chrome to bind to instead of polling agent state. @finos/sail-platform composes the same Desktop Agent together with that scaffolding, growing Sail from a standalone engine into an interoperability platform — the layer that Sail's two example UIs are built on: sail-finance, a finance-specific shell, and sail-one, a domain-neutral one for more general use.

Most of that platform's intended business-readiness surface — telemetry, auth, entitlements, connectors — is [planned], not built yet. The composition itself (construct → launch → resolve → persist) is real today. See the Architecture Overview for exactly what's implemented versus planned.

Composite parts​

Package ownership, the two supported entry points, the host-contract surface, and the app-connection model all live in one place: the Architecture Overview. That page owns the single layering diagram for these docs — this introduction links to it rather than redrawing it.

How to consume it​

Where you go next depends on what you are building:

I want to…Go to
Add an existing web app to Sail or another FDC3 Desktop AgentAdd your app to Sail
Adopt or host Sail itself — compose the pieces yourself, deploy a shell, or check on a hosted versionHow to consume Sail
Contribute to or build Sail from sourceDevelopment Guide

Documentation policy​

The Docusaurus site (website/docs/) is the single source of truth for all documentation. npm README.md files in each package are brief summaries that link here.