Workflow orchestration engine¶
| ID | MOD-062 |
| System | SD07 |
| Repo | bank-platform |
| Build status | Deployed |
| Deployed | Yes |
| Last commit | bbdfbac46a1b5cf6dc25b4c7cd428a8daa669d03 |
The workflow orchestration engine is the runtime that executes multi-step user journeys as defined sequences of steps, decisions, and integrations. It replaces hard-coded flow logic with a configurable graph of states, transitions, and actions — allowing onboarding, credit application, dispute, and trade finance workflows to be defined once and operated consistently across channels.
The engine calls into other modules (decisioning, KYC, validation, payment) at each step, handles retries and timeouts, and evaluates branching conditions using the output of each call. Customers see progress indicators and can resume interrupted journeys; operations staff can see the full journey state, identify where a customer is stuck, and intervene at any step.
Designed as a durable execution engine: every state transition is persisted before being acted on, ensuring no journey is lost to an infrastructure failure and no step is executed twice.
FR-295 / FR-740 scope split¶
FR-295 covers the Step Functions task-token approval pause/resume mechanism (durable approval, authorised approvers only). FR-740 covers workflow versioning at the execution layer (pinning in-flight executions to a specific workflow definition version). FR-740 is currently deferred; the workflow_version tag stamped on each state machine is a traceability marker only — there is no version comparison or in-flight execution pinning.
Module dependencies¶
Depends on¶
| Module | Title | Required? | Contract | Reason |
|---|---|---|---|---|
| MOD-043 | EventBridge domain event governance | Required | — | Workflow state transitions publish domain events via the EventBridge governance layer consumed by downstream modules. |
| MOD-104 | AWS shared infrastructure bootstrap | Required | — | AWS shared infrastructure provisioned by MOD-104 (EventBridge buses, S3, KMS, Kinesis, Cognito) is required before this module can be deployed. |
Required by¶
| Module | Title | As | Contract |
|---|---|---|---|
| MOD-055 | Onboarding fraud scoring engine | Hard dependency | — |
| MOD-063 | Notification orchestration | Hard dependency | — |
| MOD-064 | Operations work queue | Hard dependency | — |
| MOD-084 | Open banking data access — data recipient | Hard dependency | — |
| MOD-159 | Synthetic transaction engine | Optional enhancement | — |
| MOD-168 | Maker-checker enforcement engine | Optional enhancement | — |
Policies satisfied¶
(No policies assigned)
Capabilities satisfied¶
| Capability | Title | Mode | How |
|---|---|---|---|
| CAP-091 | Journey orchestration | AUTO |
Drives multi-step journeys (onboarding, loan application, dispute) through each defined stage without ad-hoc coupling between systems. |
| CAP-092 | Step state management | AUTO |
Persists step-level state so a journey can be paused and resumed — including after a timeout, failed check, or system restart. |
| CAP-093 | Dynamic journey branching | AUTO |
Evaluates decision outputs and routes the journey to the correct next step, including branching for refer, manual review, or alternate product. |
| CAP-090 | Multi-step approval workflows | GATE |
Receives bank.payments.approval_required events from MOD-021, orchestrates the multi-step approver chain (pending → first approval → second approval → released or expired), and emits bank.payments.approval_granted or bank.payments.approval_rejected when the chain resolves. |
Part of SD07 — Data Platform & Governance Infrastructure
Compiled 2026-05-22 from source/entities/modules/MOD-062.yaml