BPM is the spine of regulated software.

Why workflow engines outlive frontends.

The problem with code-as-process

Most financial applications are built as state machines disguised as application code. A customer's KYC status is stored as an enum in a database. The state transitions are implemented as conditional logic in API handlers. The business rules are buried in if-else chains that no one can read without context.

This works until the regulator asks: 'show me every case that was in a pending-review state on March 12, and show me who reviewed each one and what they decided.' At that point, you discover that your application code does not have a process model — it has a data model, and the process is implicit in the code path.

What a BPM engine gives you

A Business Process Management engine makes the process explicit. Each workflow is a named, versioned artefact with defined states, transitions, actors, timers, and escalation paths. Every state change is an event. The event log is the audit trail. The process definition is the source of truth for what should happen; the event log is the source of truth for what did happen.

In Coreal, the BPM engine runs 38 active processes: onboarding, KYC step-up, card issuance, withdrawal approval, AML case management, dispute handling. Each process has its own SLA (the onboarding p95 is 38 seconds; the manual AML review SLA is under 4 hours). Each process has its own metrics, its own dashboard in the operator workspace, its own runbook.

Why BPM outlives frontends

We have rebuilt the customer-facing UI for Coreal-powered products three times. The underlying BPM processes have been revised, but never rebuilt from scratch. The reason is that the process definitions capture regulatory requirements that do not change when the UI does. The UI changes because user expectations change. The process changes because the regulator changes the requirements. These are on different timescales, and they should be in different systems.