Commerzbank, Germany's second largest retail bank, has spent the last three years quietly converting one of the messiest jobs in retail banking into something that looks almost boring on a system diagram. The job is customer onboarding. The tool is Camunda 8. The result is a modular orchestration pattern that the bank now reuses across small business and private customer segments, with the reuse curve doing most of the heavy lifting on cost and speed.
Sebastian Kreuzer, Product Owner for Digital Onboarding in the Accounts and Deposits cluster, put the starting point bluntly: "Three years ago, we didn't have an onboarding process for small business customers." Work moved through email threads, document handoffs, and ad hoc validations. KYC was a separate workstream. Product activation for accounts, cards, and digital banking required yet more manual steps. The customer felt every seam.
The Camunda swap that broke the legacy queue
The decision Commerzbank made was the one most large banks defer for another budget cycle: stop trying to replace the underlying systems and instead orchestrate them. Camunda 8 was selected as the process engine because it could coordinate calls into core banking, KYC providers, identity verification, card issuance, and the digital banking stack without forcing any of those systems to change shape. The queue of manual handoffs that used to define onboarding got replaced by a BPMN model that the bank can read, version, and instrument.
That choice matters because the legacy pattern at most European retail banks looks the same. A request lands in a workflow tool, jumps to a ticketing system, then to a mainframe screen, then to a compliance review, then back to a relationship manager. Each hop is a queue. Each queue is a SLA risk. Camunda's role at Commerzbank was to absorb those hops into a single executable process, with the human tasks made explicit rather than implicit.
How the product-owner team rebuilt the workflow library
The rebuild was not run as a classic IT project. Kreuzer's team operates as a product organisation, with end to end ownership of the onboarding journey and dedicated engineers attached to each component. The library they assembled now includes personal onboarding, customer number creation, KYC validation, identity verification, product creation, error handling, rejection flows, and reminder processes. Each one ships as a discrete sub process with its own owner, its own backlog, and its own test harness.
The first delivery, small business onboarding, was workshop heavy. Process modellers, compliance leads, core banking engineers, and the product owner sat through the joint sessions that any serious BPMN rollout demands. The payoff arrived on the second delivery. When the team turned to private customer onboarding, most of the library transferred directly. Contract artifacts and a small set of customer specific validations had to change. The rest was composition work. A multi year build for one segment became a much shorter delivery for the next, which is the reuse curve that justifies the orchestration investment in the first place.
What the orchestration layer actually replaced
It is worth being precise about what came out of production. Email driven case routing between branch staff and operations was retired for the in scope segments. A patchwork of manual KYC checks was consolidated behind a single orchestrated call pattern. Product activation steps that used to require operations staff clicking through three or four screens are now triggered by the engine on completion of upstream tasks. Status visibility, which used to live in spreadsheets and inboxes, now lives in Camunda's operational view.
None of this required a core banking replacement. That is the architectural lesson worth lifting out. Peers like ING, BBVA, and BNP Paribas have spent the last decade learning that orchestration first beats core first when the goal is faster customer journeys. Deutsche Bank and Santander have published similar patterns around their own BPMN and case management investments. The Commerzbank account simply makes the modular sub process discipline more concrete than most.
The monitoring trap that came with modularity
Modular orchestration is not free of trade offs. Kreuzer's team has been candid that incident tracing gets harder when a failure surfaces at the end of a long chain of sub processes. A rejection that lands in the reminder flow may have originated in a KYC validation three steps upstream. The blast radius is small because each component is isolated. The diagnostic path is longer because the engineer has to walk back through the composition.
The mitigation, predictably, is observability. Correlation IDs across sub processes, end to end traces stitched into the operational dashboard, and clear ownership of each component so that the on call rotation knows who to wake. Banks moving down this path should budget for the observability work at the same time as the BPMN work, not after the first production incident makes the case for them.
For broader context on how enterprise software vendors are repositioning around orchestrated, agent driven workflows, see our earlier coverage of SAP's autonomous enterprise reset and the PenFed Agentforce partnership in US banking.
The build-vs-buy call CTOs face on enterprise BPM in 2026
Here is where we land on the operator question. The Commerzbank case is a clean argument for Camunda 8 in a regulated European bank, but the build versus buy call on enterprise BPM is not settled by one reference. We think the honest comparison set for 2026 is Camunda 8, Temporal, and AWS Step Functions, with a long tail of legacy IBM and Pega estates still in the mix.
Camunda 8 wins when the orchestration has to be readable by non engineers, when BPMN is already a regulatory and audit artifact, and when human tasks sit inside the same flow as system calls. That describes most retail and commercial banking journeys. Temporal wins when the workload is engineer owned end to end, when the flows are code first, and when durable execution semantics matter more than visual modelling. That describes a lot of fintech and platform backends. Step Functions wins when the estate is already deep into AWS, the volumes are spiky, and the team wants serverless billing rather than a managed cluster. None of these is wrong. They are different shapes.
On vendor lock in math, we keep coming back to the same arithmetic. Camunda's BPMN models are portable in theory and sticky in practice once the connector library, the Operate tooling, and the Zeebe cluster sizing are tuned to a workload. Temporal's durable execution model is portable in code but reshapes how engineers write the workflows in the first place. Step Functions is the most locked in by definition, with the lowest operational tax. The realistic switching cost on any of them, two years in, is measured in quarters of engineering, not weeks.
Three questions we would put to any mid market bank weighing this call. First, is the regulator going to want to read your process or your code, because that answer narrows the field immediately. Second, do you have a product owner model that can sustain a sub process library across multiple segments, or will the second delivery look as expensive as the first because the components were never owned. Third, what is the observability budget, and does it land in the same sprint as the BPMN build, because the monitoring trap Commerzbank flagged is the one that bites every modular orchestration program.
The closer has teeth. Banks that treat onboarding as a workflow project will keep shipping faster screens on top of the same operational mess. Banks that treat it as an orchestration program, with a product owner, a sub process library, and an observability bill, will get the reuse curve Commerzbank is now riding. The blueprint is on the table. The CTOs who ignore it in 2026 will be the ones explaining to their boards in 2028 why their cost to onboard is still measured in weeks while their competitors quote it in hours.
