The Camunda 7 Fork That Financial Services Built — And Why It Changes Everything for AI Governance

Camunda 7 Community Edition is dead.

The repository is archived. No security patches. No PRs accepted. If you are running Camunda 7 CE in production at a regulated institution, you are running unsupported software. Today.

Camunda 7 Enterprise Edition gets a reprieve — extended through April 2030 — but the final feature release (7.24) shipped in October 2025. The clock is ticking.

And the migration path that Camunda is offering? Camunda 8 is not an upgrade. It is a reimplementation. Different engine (Zeebe), different API, different data model, different licensing. Third-party analysts are blunt: “Trying to do a technical migration is a recipe for disaster.” Small projects take 2–3 months. Large ones take 6–12 months or more. And Camunda 8 has no open-source variant.

So what happens when 2,600+ companies — many of them in financial services, where BPM engines underpin loan origination, KYC/AML, trade processing, and regulatory reporting — face a forced migration to a proprietary platform?

The same thing that happened with Terraform, Redis, and Elasticsearch.

The industry forks.

The Fork Financial Services Built

In October 2025, at the Open Source in Finance Forum in New York, FINOS announced Fluxnova: a fork of the last Apache 2.0-licensed version of Camunda 7, hosted under Linux Foundation governance.

The founding contributors tell the story: Fidelity Investments. NatWest Group. Deutsche Bank. Capital One. BMO.

These are not hobbyist contributors. These are Tier 1 financial institutions that decided, collectively, that they would not outsource control of their compliance infrastructure to a single vendor. FINOS Executive Director Gabriele Columbro called it “the first time financial institutions exercise their right to fork to collaboratively chart their future under open governance.”

Existing BPMN and DMN models created for Camunda 7 work with Fluxnova with minimal modification. A migration utility automates much of the transition. No reimplementation. No architecture change. No new licensing cost.

The pattern is now unmistakable:

Every time a critical open-source tool moves to a proprietary model, the ecosystem responds.

Why This Is Existential for Regulated Industries

Here is the part most people miss: in regulated industries, process orchestration engines are not just tooling. They are the compliance substrate.

A BPM engine like Camunda 7 touches the audit trail. Regulators — OSFI, OCC, FCA, ECB — do not just want to know what happened. They want to know how the process was defined, who approved the workflow, when it executed, and why it made the decisions it did. The orchestration engine is the system of record for all of that.

It is embedded in change management. Every modification to a production workflow goes through change advisory boards, model risk review, and often regulator notification. A forced migration is not a software upgrade — it is hundreds of individual change tickets, each requiring re-testing, re-validation, and re-approval.

And as agentic AI enters production, the orchestration engine is becoming the governance boundary — the system that decides whether an AI agent can execute a trade, approve a loan, or release a drug batch. If that layer is controlled by a single vendor who can change terms unilaterally, the institution has outsourced its regulatory posture to a third party.

That is precisely what OSFI’s B-10 guidance on third-party risk, the EU’s DORA regulation, and the OCC’s critical service provider framework are designed to prevent.

The vendor lock-in question is not theoretical. It is existential.

The Missing Piece: Who Governs the Agents?

Fluxnova solves the orchestration independence problem. But it opens a new question that nobody has answered yet.

Fluxnova’s own roadmap explicitly targets agentic AI orchestration — AI agents running inside BPMN workflows, making decisions, taking actions. FINOS positions Fluxnova as “the control plane to manage how AI agents interact with your core systems.”

But a control plane without governance is a liability. If an AI agent operates within a Fluxnova workflow — approving a transaction, classifying a regulatory filing, routing a customer complaint — who governs that agent? Who enforces the policy boundaries? Who captures the evidence trail that satisfies the examiner?

The FINOS AI Governance Framework (AIGF v2.0), co-authored by Goldman Sachs, Morgan Stanley, Citi, RBC, BMO, and Bank of America, defines 25 risks across operational, security, and regulatory dimensions. Five of those risks — multi-agent trust boundaries, agent action authorization, MCP supply chain compromise, agent state poisoning, credential harvesting — are new in v2.0 and target agentic architectures specifically.

This is where orchestration and governance converge. The institutions forking Camunda 7 into Fluxnova are the same institutions co-authoring the AI governance framework. They need both halves of the equation: an open-source orchestration engine they control, and a governance layer that enforces controls at runtime — not just in policy documents.

The Convergence Point

At iTmethods, we have been building at this intersection.

Forge, our AI Governance and Modern DevOps platform, provides managed infrastructure for regulated enterprises — SOC 2 certified, multi-deployment (on-prem, private cloud, hybrid), with 24/7 operational support. Forge already runs managed platforms for financial services, defense, and life sciences customers.

Reign, our Enterprise AI Governance platform, maps to all 25 FINOS AIGF risks with 15+ preventative controls. The AI Gateway enforces policy at the model access layer. The Evidence Engine captures audit-ready decision trails. The Agentic Hub governs multi-agent trust boundaries.

Managed Fluxnova on Forge, with Reign governance integrated, delivers the governed orchestration stack: open-source BPM with zero licensing cost, enterprise-grade infrastructure, and AIGF-compliant AI governance — all vertically integrated.

No other vendor offers this combination. Managed orchestration. Managed governance. For regulated enterprise.

The Question for Every Camunda 7 Shop

If you are running Camunda 7 in production at a regulated institution, you have three options:

The question is not whether to adopt the fork. The question is whether you want to run it yourself — or have it managed and governed.

We are building the managed Fluxnova offering for financial services. If you are running Camunda 7 and evaluating your options, I would welcome the conversation.

Paul Goldman is the CEO of iTmethods, where his team helps regulated enterprises build and govern AI-native infrastructure. This article is part of “The New Stack” series on building AI-native organizations.

Previously: The Platform Engineering Pivot · Self-Hosted AI Agents Are Here. The Governance Isn’t. · The AI-Native Stack: What It Actually Looks Like