The upcoming FDC3 3.0 release is one of the most significant updates we've made in years. While previous releases focused on expanding interoperability, FDC3 3.0 focuses on four themes that have become increasingly important:

• Security
• Observability
• Cross-Firm Interoperability
• Modern usage scenarios

In other words: how do you trust what you're receiving, understand where it came from, and operate FDC3 in a world increasingly dominated by web applications, APIs and AI agents?

A Zero-Trust Architecture Example

To help visualise how these four themes mesh together, let's consider zero-trust architecture: regulated financial firms increasingly operate under zero-trust principles. No component in the architecture is implicitly trusted, and every data access must be justified and auditable.

Consider a common scenario in banking operations: a customer calls in, and the VoIP or chat system identifies the customer and broadcasts their details to the desktop. A CRM retrieves their profile. A transaction viewer pulls up recent activity. An account system displays balances. Each of these applications is now holding sensitive customer data — and regulators want to know why each application was allowed to access it.

Increasingly, regulators expect firms to be able to demonstrate the provenance of sensitive information and prove how it moved through a workflow. Applications must prove (to an auditor, months after the fact) that they received the customer identifier from an authorised source (the VoIP system that had connected the agent to the customer), at a specific time, as part of a specific interaction.

For particularly sensitive data — say, a customer's full account details or transaction history — only the intended recipient, holding the correct private key, should be able to read it. The principle of least privilege applies: the routing infrastructure should see only encrypted blobs, while the actual data is accessible only to the application with a legitimate need to view it.

A Cross-Firm Example

While zero-trust architecture is redefining the security principles inside the firm, there is increasing need for secure interoperability between firms, where a user's desktop may contain applications from many different vendors, each connected to different data sources and potentially competing with one another.

The cross-firm use case — where applications from competing organisations coexist on the same desktop — remains the more commonly cited motivation for FDC3 security features. And many of the same requirements apply - confidentiality, integrity, authenticity, and nonrepudiation.

New FDC3 Building Blocks - 1. Metadata

FDC3 3.0 introduces standardised metadata throughout the platform. This effectively gives FDC3 workflows a distributed audit trail.

Applications can now provide and receive metadata alongside contexts and intent messages, including source information, timestamps and trace identifiers.

Instead of simply observing a context arrive, applications can understand the chain of events that led to it.

For developers, this makes debugging easier. For architects, it improves visibility, and for auditors and compliance teams, it provides much-needed provenance:

• Where did this come from?
• When was it created?
• Which workflow generated it?
• Is it related to a previous action?

New FDC3 Building Blocks - 2. Security

The headline feature of FDC3 3.0 is undoubtedly the new Security & Identity capability.

Historically, FDC3 has relied on the Desktop Agent as a trusted intermediary. Applications could exchange contexts and raise intents, but there was no standard way to cryptographically prove who originated a message, verify that it hadn't been modified, or securely exchange sensitive information.

Moreover, applications running in the same desktop had to implicitly trust each other. This is a problem for use-cases where several applications are competing with each other. For example, two competing applications might be providing prices to the user - it would be no good if one of the applications could obtain the other's price information and use it for unfair advantage.

So FDC3 3.0 introduces experimental Security & Identity support, including:

• Signed contexts
• Encrypted payloads
• Secure key exchange
• Standardised user identity exchange
• Anti-replay protection

Importantly, this happens without requiring trust in the Desktop Agent itself. Applications can sign and verify messages directly, enabling end-to-end trust between participants, based on existing, trusted open standards such as JOSE/JWT/JWE/JWS.

This opens the door to use cases that have traditionally been difficult to justify in regulated environments:

• Cross-organisational workflows
• Sensitive client information
• Trusted automation
• Agent-to-agent communication
• Audit and compliance requirements

And as AI becomes increasingly involved in business workflows, knowing who said what and whether you can trust itstops being a nice-to-have and becomes fundamental infrastructure.

New FDC3 Building Blocks - 3. FDC3 Language Interoperability

Modern workflows no longer consist solely of desktop applications. Instead, they increasingly include:

• Backend services
• Automation pipelines
• Agent frameworks
• Event processors
• Cloud-native platforms

Historically, JavaScript and TypeScript have been the primary implementation languages for FDC3 and other language support has been left up to vendors to provide themselves. However, since version 2.2, FDC3 has had its own protocol, opening the door to proper cross-language support for whoever wants to implement it.

So now FDC3 3.0 introduces Go, C# and Java language bindings and desktop agent vendors have a simple way to provide agnostic support via the common protocol.

FDC3 is no longer solely a browser standard. With standard language bindings and a common wire protocol, interoperability can now extend naturally into backend systems, cloud services and automation platforms.

Why This Matters

Looking across the release, a clear pattern emerges.

Earlier versions of FDC3 focused on helping applications communicate. FDC3 3.0 focuses on helping them communicate safely, transparently, industry-wide and at scale.

We're no longer building isolated desktop applications: we're building ecosystems of applications, services, workflows. Those ecosystems need interoperability, trust, security, auditing, provenance and non-repudiation. FDC3 3.0 is a significant step towards providing all of this.

And perhaps most importantly, it lays foundations for the next generation of interoperable financial workflows—where humans, applications and AI systems can collaborate securely using the same open standard.

To Learn More

• Read the FDC3 Security & Identity specifications and consider how they could support zero-trust and cross-firm workflows within your organisation.
• Explore FDC3-Sail, the community reference implementation, to see these concepts in action and begin experimenting with secure interoperability patterns.
• Experiment with the new metadata capabilities and think about how provenance and observability could improve your existing workflows.
• Join the FINOS FDC3 community, attend some of our meetings and help shape the future direction of the standard.

Author: Rob Moffat, FINOS, Chief Architect