Process Orchestration
Process Orchestration is currently available as a Non-Production Preview (NPP) feature, available to a limited number of customers. You should not process production data with NPP features. To request access, contact your Mambu Customer Success Manager. For more information, see Mambu Release Cycle — Feature Release Status.
What is Process Orchestration?
Process Orchestration lets you define, deploy, and run multi-step business workflows that coordinate Mambu's Core Banking Engine (CBE) with external systems — all within a single, audited, governance-controlled runtime.
Workflows are written as BPMN 2.0 files: an open, vendor-neutral standard supported by a wide ecosystem of modelling tools. A workflow can call external APIs, wait for callbacks from third-party services, assign tasks to human approvers, evaluate decision rules, and write results back to Mambu — chained into a single traceable execution.
Every process definition passes through a maker-checker approval before it can run, and every execution produces a persistent audit trail. This makes Process Orchestration suitable for regulated workflows where accountability and traceability are requirements, not nice-to-haves.
The problem it solves
Modern banking products rarely live inside a single system. A loan origination flow touches a CRM, an identity verification vendor, a credit bureau, a document store, and the core banking ledger. A collections process might involve automated outreach, a human review step, and a final write-off transaction in Mambu.
Without an orchestration layer, this coordination logic ends up scattered across multiple services, each maintaining its own retry logic, error handling, and state. When something goes wrong mid-flow, it is difficult to know which step failed, what data was in flight, and what needs to be rolled back.
Process Orchestration addresses this by giving you a single place to define the flow, a single runtime to execute it, and a single audit log to inspect it.
A practical example: KYC-gated account opening
Consider an account opening flow for a new client. The business requirement is:
- Receive the client's details from a mobile app
- Submit them to a KYC vendor for identity verification
- Wait for the vendor's decision — which may take seconds or minutes
- If approved: create the client record and open a deposit account in Mambu
- If rejected: notify the originating system with the rejection reason
- Throughout: log every step and make the outcome auditable
Without orchestration, each of these steps requires custom integration code, retry logic, and state management spread across multiple services. With Process Orchestration, the entire flow is a single BPMN file:
The BPMN file is the single source of truth for the flow. It is version-controlled, peer-reviewed through the maker-checker approval process, and every execution is recorded step by step.
Architecture
The BPMN engine
Process Orchestration runs a BPMN 2.0 engine inside Mambu's infrastructure. Each tenant has its own isolated engine instance backed by that tenant's database, so process state and history never cross tenant boundaries.
The engine is responsible for:
- Persisting execution state and variable history to the database
- Executing service tasks (HTTP calls, variable assignments, JSON construction)
- Evaluating gateway conditions and routing execution
- Managing timers, message waits, and human task assignments
- Producing a step-by-step audit log of every execution
Resources
| Resource | Purpose |
|---|---|
| Destinations | Named, authenticated HTTP connections to external systems. Credentials are stored server-side. BPMN tasks reference a destination by its logical externalId, so the same process definition works across environments by swapping destination URLs. |
| Process Definitions | BPMN 2.0 XML files that encode the workflow logic. Each definition goes through maker-checker approval before it can execute. Multiple versions can coexist; the engine always uses the latest CURRENT version. |
| Process Instances | A running or completed execution of a definition. Execution state, variables, and activity history are persisted and queryable. |
BPMN standard
Process Orchestration uses the BPMN 2.0 standard (Business Process Model and Notation), defined by the Object Management Group. BPMN is widely adopted in enterprise software and is supported by many visual modelling tools, including Camunda Modeler and Eclipse BPMN2 Modeler.
Mambu extends BPMN with a small set of custom task types and attributes under the xmlns:mbu="http://mambu.com/bpmn" namespace — for example, mbu:type="call-destination" to make an authenticated HTTP call, or mbu:assignedUser to route a human task to a specific Mambu user. Standard BPMN elements (gateways, sequence flows, boundary events, timer events) work as defined by the specification.
Maker-checker governance
Every resource — destinations and process definitions — must pass through a maker-checker approval before it becomes active. A single user cannot create and approve their own workflow.
DRAFT → PENDING_APPROVAL → APPROVED → CURRENT
└→ REJECTED
Once approved, a definition enters CURRENT status and is available for execution. If a change is needed, a new version is staged and goes through the same approval cycle.
What you can build
| Use case | Pattern |
|---|---|
| Sync external data into Mambu (exchange rates, reference data) | Periodic or triggered process calls an external API and writes the result to the CBE |
| KYC / AML / identity verification | Process calls the vendor, parks on a message wait, resumes when the vendor delivers a callback |
| Long-running loan origination or onboarding | Async process coordinates document collection, credit scoring, and account creation over hours or days |
| Human approval workflows | Process assigns a task to a Mambu user; execution resumes when they approve or reject in the Tasks inbox |
| Compensating transactions (saga pattern) | Boundary events and compensation handlers roll back completed steps if a later step fails |
| Scheduled batch operations | Timer start events trigger a process on a cron schedule |
Limitations (NPP)
- Only the External Orchestration pattern is supported. Lifecycle-hook-triggered orchestration (Core Extensions) and API Composition are not yet available.
- Process definitions must be valid BPMN 2.0 XML. Visual modelling tool support is not yet bundled — use any BPMN 2.0 editor and upload the XML file.
- Concurrent process instances per tenant are subject to platform capacity limits; contact your Customer Success Manager for guidance on high-volume use cases.
Where to go next
To implement Process Orchestration:
- Getting Started — prerequisites, maker-checker walkthrough, and a complete quickstart tutorial
- BPMN Authoring — full reference for all supported BPMN elements, task types, and expression language
- Worked Examples — four complete patterns: sync HTTP, async fire-and-forget, inbound callback, and human approval loop
API reference:
- Process Orchestration API Overview — all API categories and endpoint index
- Destinations API
- Process Instances API
- Process Tasks API