Why Flowable fits financial services process work
Head of operations and CISO teams at banks and payment firms carrying loan or account opening backlogs can run those processes on Flowable's open source engines inside their own infrastructure. Flowable's BPMN, CMMN and DMN engines are licensed under Apache 2.0, so the process logic, decision rules and audit history stay in environments the firm controls, including its cloud accounts, data centers or air-gapped networks. The engines are Java components with Java and REST APIs, so they can sit behind the systems a lender or onboarding team already uses. Three things change in practice. Credit and risk criteria move out of application code and into DMN decision tables that compliance and credit teams can read, version and test. Approvals move out of email and spreadsheets into BPMN user tasks whose assignees and sequence the engine enforces, which is where four-eyes controls get implemented and checked. Execution history becomes evidence: the engine records which decision version ran and who completed each task, and you decide how long that history is retained and who can read it. Confirm with your own compliance team exactly which fields and events your regulators expect before you design the history model.
Open source scope needs a clear boundary. The Flowable open source engines provide the execution, decision and case capabilities, along with a community forum. Flowable's commercial products, including Flowable Work, Engage, Orchestrate and Design, are built on the same engines and add low-code modeling, visual debugging, security controls, monitoring and governance. Those products are a separate licensing and support decision, and this page does not assume you will buy them. Professional services and partner support are also offered separately, so ask which delivery model fits your team before the build starts. Before committing, the firm should check three items: the Flowable version it will standardize on (the Flowable open source page and the engine release notes list the current line), the database platform its security team has approved, and the identity source that will drive approver roles. Each of these shapes the audit story, so settle them in the design phase rather than after go-live.
Which regulatory requirements shape a Flowable build
This table maps the regulatory requirements most often raised in financial services Flowable projects to what each one means for process design, data location, access and history. Read each row as a question to answer with your compliance and risk teams before the design is fixed. DeployOpen prepares systems, controls and evidence for assessments, but auditors and certification bodies issue the attestations.
| Requirement and source | What it asks for | Build consequence for Flowable |
|---|---|---|
| DORA Article 28(3) and 28(8): ICT register and exit planning (Regulation (EU) 2022/2554) | A register of all ICT contractual arrangements, and documented, tested exit strategies for services supporting critical or important functions | Record Flowable and its database, hosting and integration providers in the register. Keep BPMN, CMMN and DMN models in a format you can export and re-run, and test a restore onto another environment. |
| DORA Article 30(2): contract terms on location and data return (Regulation (EU) 2022/2554) | Contracts state where services run and data is processed, give advance notice of changes, and cover data return on insolvency or termination | Decide the hosting region for the Flowable database, the async executor nodes and history tables before go-live. Confirm with your provider and legal team that contract terms match where engines and backups actually run. |
| SEC Release 33-8810: IT general control areas (SEC guidance, SOX Section 404) | Program development, program changes, computer operations and access to programs and data are areas management may consider, depending on each company's facts | Route deployment of process and decision definitions through a controlled change pipeline with approvals. Separate who can publish a DMN table from who can run cases, and keep deployment logs for each version. |
| FTC Safeguards Rule, 16 CFR 314.4(c)(5): multi-factor authentication | Non-bank institutions under FTC jurisdiction require MFA for any individual accessing any information system, unless the Qualified Individual approves an equivalent control in writing | Place Flowable Modeler, admin consoles and REST APIs behind your identity provider with MFA enforced. Identity is delegated to your own service, so confirm how task assignment and group membership are sourced. |
| PCI DSS v4.0.1 scope (PCI SSC) | Applies to entities that store, process or transmit cardholder data, or could affect the security of that data environment | Keep card numbers and sensitive authentication data out of process variables, history and logs. If a process touches the cardholder data environment, include its engines, databases and integrations in scope and document the boundary. |
| Swift Customer Security Controls Framework v2026 (Swift CSP) | 32 controls, 26 mandatory and 6 advisory, assessed independently and attested annually for Swift users | Where payment messages are triggered from workflows, map the Swift-connected components and their access paths. Confirm with Swift and your assessor which controls apply to the Flowable hosts and integration layer. |
| SOX Section 404 and PCAOB AS 2201 (15 U.S.C. 7262) | Management assesses internal control over financial reporting each year, with auditor attestation for applicable filers | Where a process produces financial records, define the controls it performs, such as approvals and reconciliations, and keep evidence of their operation. Confirm with your auditor which controls rely on the workflow engine. |
| DeployOpen role and limits | DeployOpen prepares systems, controls and evidence for assessments | DeployOpen does not issue audit reports, attestations or certifications. Ask your independent auditor, assessor or certification body to confirm which controls meet each requirement. |
Loan, account opening and payment processes modeled in Flowable
Loan origination is usually a BPMN process for the fixed path (application intake, document checks, decision, offer, signature) with a CMMN case around the parts that vary, such as income verification or collateral review, where the next step depends on what the file contains. *Illustrative example:* a personal loan application enters a BPMN process, and a DMN decision table combines applicant score band, debt-to-income ratio and product limits to return approve, refer or decline. Referrals create a human task that routes to a credit officer.
- Decision calls: a credit decision table and a separate risk rule table are called from a business rule task, with their versions recorded on the process instance.
- Four-eyes approval: a second approver task is placed after any override of the decision output, and the engine must block the first approver from completing it.
- Events to record: application submitted, each decision input and output, referral reason, override, approver identity and timestamp, and offer acceptance.
- Timers: a document-expiry timer reopens the case if the applicant does not respond, and the timer event is logged.
- Model separation: keep the decision logic in DMN so credit policy changes do not require a change to the process diagram.
Check with your credit risk and model governance teams which decisions must be reproducible years later, and confirm how your audit team wants overrides evidenced before you finalize the decision table design.
Account opening combines a fixed sequence (identity capture, screening, account creation) with conditional branches that depend on customer risk. A BPMN process handles the main path, and a CMMN case or subprocess handles enhanced due diligence, where tasks are added or skipped as information arrives. *Illustrative example:* a retail applicant with a mismatched address triggers an additional verification task, and a timer escalates the case to a compliance analyst if the task is not completed within the internal service window.
- Customer risk rating: a DMN table maps screening results, country exposure and product type to a risk tier, which then selects the due diligence path.
- Human KYC tasks: analysts review screening matches, with the outcome and rationale stored as process variables or history.
- Four-eyes approval: high-risk onboarding and exceptions to standard checks need a second reviewer who did not perform the first review.
- Events to record: each screening call and result, risk tier assigned, analyst actions, escalation timers, and account activation.
- External calls: screening and identity services are called through service tasks or an external worker, with request and response references logged.
Confirm with your compliance function which records must be kept, for how long and in which system, and whether screening vendor responses may be stored in process variables under your data protection rules.
Payment exception handling is well suited to CMMN because exceptions arrive unpredictably and need different handling each time: a rejected payment, a suspected duplicate, a sanctions alert or a beneficiary name mismatch. A case holds the exception, with stages for investigation, repair and release, and sentries that move the case when a condition is met. *Illustrative example:* a payment flagged by a screening result enters a case in which a hold milestone is reached only after an analyst records a decision.
- Case structure: each exception is a case instance, with plan items for investigation, customer contact and resubmission, and milestones marking release or return.
- Decision calls: a DMN table decides the queue, priority and whether dual approval is needed based on amount, currency and exception type.
- Four-eyes approval: release of a held payment above your internal threshold requires a second approver, enforced by the application and not only by the UI.
- Events to record: case creation, each sentry trigger, plan item transitions, hold and release decisions, and the user who performed each action.
- Integration: payment rails and core systems are reached through messaging or service calls, and failed calls raise job failures that appear in operations monitoring.
Check with your payment operations and fraud teams which exception types must stop a payment, and confirm whether the core or payments platform already holds the authoritative transaction state.
Engine modules, settings and integrations that matter for banks
A bank's Flowable deployment is shaped by a small set of engine and platform choices made early. Each card below names one component, the decision it forces, and what to confirm with the vendor or in your own environment before the design is fixed.
BPMN, CMMN and DMN engines
Decide which engines a loan or account opening application actually needs. BPMN runs the executable process, CMMN handles case work where the sequence of tasks depends on events and documents, and DMN holds credit and risk rules as decision tables. Keep rule logic in DMN where compliance teams must read it, and confirm with DeployOpen and Flowable which engine versions your chosen Java baseline supports before you commit to a version.
Async executor and cross-node locking
The async executor runs timers and asynchronous jobs from a thread pool, and nodes coordinate through lock owners and lock expiration times stored in the database. For a bank running several nodes, decide the thread pool size and lock expiry per environment, then test what happens when a node is killed mid-job. Confirm lock recovery timing under your database and load profile.
Identity service and directory integration
Flowable's default identity model is not your staff directory. Decide whether to implement the identity service interface against your corporate directory or use the LDAP reference implementation as a starting point. Four-eyes approvals depend on this mapping being correct, so confirm group membership sources, separation of duties rules, and who owns the mapping logic with your identity team.
Database choice from the supported list
Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server. Banks usually choose the database their DBA and backup teams already run and can audit. Confirm version support for your chosen database with Flowable, check the MySQL timestamp precision note if MySQL is in scope, and plan backup and point-in-time recovery for the process and history tables that form your audit record.
Spring Boot starters and actuator monitoring
Spring Boot starters let teams add the full engine set, REST, or individual process, CMMN and DMN engines as needed. The actuator endpoint at /actuator/flowable exposes running process information for monitoring. Decide which endpoints reach operations dashboards, restrict them to internal networks, and confirm the Spring Boot baseline with Flowable before choosing starters, since version 8.0.0 requires Spring Boot 4.
Core banking and message broker integration
Flowable process steps call core banking systems and receive events from brokers, so the integration pattern determines how failures are retried and recorded. Decide whether service calls run synchronously in a delegate or through asynchronous jobs and messaging, and who owns idempotency keys. Confirm the integration points with your core banking vendor and broker team before the design is final.
How four-eyes approvals and audit history are built
Segregation of duties is enforced by your application, not by the Flowable engine. Flowable's BPMN and CMMN engines execute tasks and record who acted, but the engine leaves authorization checks to the application. That means the build has to define who can claim, complete and approve each human task, and then check those rules on every call that touches a task, whether it comes from a form, the REST API or a custom delegate. For a loan or account opening flow, the design should state that the person who prepared a case cannot also approve it, that approvers must hold the right group or role, and that a task claimed by one user cannot be completed by another. Write these rules as tests against the REST API and the engine, because a control that exists only in a diagram will not survive an audit.
Audit history depends on settings you must confirm, not assume. Flowable records process and task history, and the reconstruction a compliance team needs (who approved what, which rule version was live, and what data the decision used) comes from combining that history with process definition versions and the events your application writes. Before go-live, confirm the history level and retention settings in your configuration, how long finished instances and variables are kept, and whether your database backups cover the history tables for the period your regulator expects. Process versioning matters here too: a case started under version 1 of a credit policy must still be explainable after version 2 is deployed, so retain old deployments and link each decision to the DMN or BPMN version that produced it. Confirm the exact configuration keys and retention behavior against the Flowable configuration documentation for the version you deploy.
Keep sensitive data out of process variables. Process variables are copied into history, so anything you store there becomes long-lived and widely readable. Account numbers, national identifiers, full card data and credit bureau payloads should stay in your core system or a vault, with the process holding only a reference ID, a decision outcome and a hash or masked value where an auditor needs a link. Define this as a design rule with a review step for every new variable and a test that scans deployed definitions for prohibited names. Where card data could enter the flow, the PCI DSS scope analysis should happen before the process is built, since variables and history tables then sit inside that scope. Have your security and compliance owners sign off the variable list as part of the design, not after the first release.
Rollout phases for a regulated Flowable deployment
The sequence moves a Flowable deployment from control mapping to a monitored production rollout, with each phase producing evidence that the firm's risk, security and audit functions can review before the next phase begins.
Map controls and scope the first process
The team maps the firm's obligations to the Flowable work: which processes touch customer money, credit decisions or regulated reporting, which IT general control areas those processes depend on, and which third-party arrangements the Flowable deployment creates. Risk, compliance and internal audit should agree the scope in writing, including the first product line and the exit and data return expectations for any hosting provider. The output is a control map and a scoped statement of work that names who approves each control. Ask your DeployOpen contact to confirm the scope against your own register of ICT contracts before design starts.
Build the deployment pipeline in your infrastructure
DeployOpen sets up the Flowable engines, database, identity integration and deployment pipeline inside your cloud accounts, data centers or private network, using the database types and runtime your architecture team has approved. Process and decision definitions move through version-controlled pipelines with separate environments and recorded approvals for each promotion. The output is a working non-production environment, a documented promotion path to production, and a runbook for who can deploy. Your platform team must supply the hosting, network segments, secrets store and database service that the engines will use.
Build processes and decisions with test evidence
Engineers model the BPMN processes, CMMN cases and DMN decision tables for the first product line, then add delegates and integrations to your core systems. Each decision table is tested against agreed cases, including boundary values and the rejected outcomes that credit or risk teams specify, and the test results are stored with the release. Business owners sign off on the rule logic before deployment. The output is a tested build, a traceability matrix from each control to the test that covers it, and signed rule specifications. Your credit, risk and operations teams must supply the rules and the expected outcomes.
Review security and access before pilot
The security team reviews authentication, authorization checks, administrative access, scripting and XML handling, secrets management and logging of engine and API activity. Four-eyes approval steps are tested so that the initiator cannot also approve, and privileged accounts are restricted and logged. Findings are tracked to closure with an owner and a date. The output is a signed access review, a list of accepted risks with written approvals, and test records for the approval controls. Your identity team must supply the directory integration and the role model that the review checks against.
Run a pilot on one product line
The first product line runs on Flowable with limited volume and documented fallback procedures, so operations staff can handle exceptions and the team can compare engine results with the existing process. Monitoring covers failed jobs, stuck instances, decision outcomes and approval timing. Issues found in the pilot go back through the build and review phases. The output is a pilot report that records incidents, control exceptions, the decisions made about them, and whether the product line should proceed. Operations leads must supply the volume limits and the people who handle exceptions.
Roll out to production with monitoring
The production rollout expands in steps that the risk owner approves, with monitoring dashboards, alert routing and on-call responsibility in place before each step. Backups and restore tests are run against the production database, and the history and audit data retention settings are confirmed with compliance. The output is a production go-live record, a monitored operating baseline, and a schedule of recurring evidence such as access reviews, restore tests and change records. Ask your DeployOpen contact to confirm which of these recurring activities sit in a support retainer and which stay with your team.
Compliance considerations and the evidence Flowable can supply
Financial regulators and assessors test whether controls operated, not whether a tool was installed. Flowable's deployment history, process and decision versions, and audit data can support several of these controls, but each card below separates what the engine can show from what your firm must still run, approve and document. Auditors, assessors and regulators decide conformity.
DORA register and exit planning
DORA expects a register of information on ICT contractual arrangements and documented, tested exit strategies for services that support critical or important functions. Flowable is open-source software you run yourself, so the arrangement to record is usually your contract with the infrastructure, support or implementation provider. The engine can show which process and decision definitions run in production, but it cannot write your exit plan. Confirm with counsel and your DORA function how to classify the dependency, and keep the export and migration steps for your process definitions and history tested.
ICFR change and access controls
Where workflows support financial reporting, auditors look at IT general controls over program changes and access to programs and data. Deployment pipelines, version-controlled BPMN and DMN files, and deployment records in Flowable give a traceable change history for process definitions. Your firm still owns the approval of each change, segregation between developers and approvers, and periodic access reviews of who can deploy or edit models. Confirm which workflows feed reported figures before deciding the control scope.
FTC MFA for engine interfaces
For non-bank financial institutions under FTC jurisdiction, the Safeguards Rule requires multi-factor authentication for any individual accessing an information system, unless the Qualified Individual approves an equivalent control in writing. Flowable's REST application, Spring Boot actuator endpoints and modeling tools need authentication in front of them, and the engine does not provide MFA itself. Your identity provider or gateway enforces it, and the approval record is yours. Check every administrative and API path, not only the user-facing task list.
PCI DSS scope for card workflows
A workflow touches PCI DSS scope when it stores, processes or transmits cardholder data, or could affect the security of the cardholder data environment. Flowable process variables are a common place for card data to leak in by accident, so keep primary account numbers out of variables, history and logs. The engine can help by minimizing variables and tokenizing references, but the scoping decision, network segmentation and the assessment belong to your Qualified Security Assessor or self-assessment process. Assessors issue the Report on Compliance or the Attestation of Compliance, not DeployOpen or Flowable.
GDPR and NIS2 data handling
Loan and account workflows hold personal data, so GDPR questions about purpose, retention and erasure apply to process variables, history tables and audit records. Flowable history retention settings determine how long these records live, and the retention rules must match your lawful basis and retention schedule. NIS2 may apply to some financial entities and their critical suppliers, and it affects incident reporting and supplier security. Confirm with your data protection officer which fields belong in history and how erasure works on the database backups that hold them.
What banks and payment firms ask before hiring a Flowable partner
What drives the cost of a loan or account opening build on Flowable?
The main cost drivers are the number of process paths, how many decision rules must be modeled and tested, and how many systems the workflow must call. A loan origination flow with several products, document checks, credit bureau calls and core banking updates costs more than a single approval path. Expect one-time costs for process and decision design, integration build, identity setup, testing and deployment into your environment, plus recurring costs for support, upgrades and rule changes. Ask any partner for a quote built from a written scope that lists process variants, decision tables, integration endpoints, test environments and handover deliverables. DeployOpen works on fixed-scope engagements agreed in writing before work starts, and does not publish a price list.
How long does a Flowable loan or account opening build take?
Duration depends on how many products and jurisdictions the first release covers, how stable the credit and onboarding rules are, how many core systems must be integrated, and how quickly your compliance and risk teams review decisions. Limit the first release to one product and one channel, then add variants once the audit trail and decision evidence have passed review. Ask for a timeline in the written scope that separates discovery, modeling, integration, testing, security review and production readiness, and that names which of those depend on your staff. No fixed duration applies to every bank, so treat any single number from a vendor as a claim to verify against your own scope.
What must our bank provide to a Flowable implementation partner?
The partner needs named people with authority over each part of the work, not just access to documents. Provide the following:
- Process owners who approve the BPMN flows for onboarding, lending and payments exceptions
- Rule owners from credit risk and compliance who sign off DMN decision tables and their versions
- Test data that mirrors real product types, with masked or synthetic customer records approved by your data protection office
- Identity contacts who manage the directory, roles, and the four-eyes approval groups the engine will use
- Infrastructure and security contacts for the hosting environment, database, secrets and network access
Agree these contacts and decision rights in the written scope before build starts, because delays in approvals are a common source of schedule slip.
Can an internal team build a Flowable loan process without a partner?
Yes, a capable internal team can build Flowable processes, because the engines are open source under Apache 2.0 and embed in Java applications through Spring or servlet containers. The harder question is capacity and continuity: the team must cover BPMN and DMN modeling, Java delegates, integrations, identity, security hardening, backups, upgrades and evidence for auditors, and it must keep doing so after the first release. Assess your team against that full list, including who will own the code after go-live and how many people can respond to a failed job at night. A partner can cover part of the work under a fixed scope, such as design, integration or hardening, while your staff keep ownership of rules and day-two operations.
How does Flowable 8.0.0 and its Spring Boot 4 baseline affect planning?
Flowable 8.0.0 was released on February 27, 2026, according to the Flowable 8.0.0 release notes on GitHub. Its release notes describe an upgrade to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3, Jackson 3 as the default JSON library with a Jackson 2 compatibility layer, and removal of JUnit 3 and 4 support. If your application runs on Spring Boot 3, plan the framework upgrade as a separate workstream before or alongside the Flowable upgrade, and budget test time for serialization changes in REST payloads and process variables. Check your existing custom delegates, test suites and any libraries that depend on Jackson 2 or JUnit 4. Ask a partner to name the baseline they will build on and to show how the upgrade risk is handled in the written scope.
Does DeployOpen issue compliance certifications for our Flowable system?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors, assessors and certification bodies perform those assessments. For a payment firm, the relevant assessment under PCI DSS is carried out by a Qualified Security Assessor or through a Self-Assessment Questionnaire, each with its own Attestation of Compliance, and the assessor decides the outcome. Ask your assessor early which Flowable history, access logs and approval records they expect, and confirm with them which controls fall in scope. DeployOpen's role is to build and document those controls so your assessor can test them.
Which compliance regimes should a Flowable scope cover in financial services?
The answer depends on your entity type, geography and whether you handle cardholder data. Payment firms and merchants should check PCI DSS scope, and EU financial entities should review DORA, which has applied since 17 January 2025 according to the regulation's Articles 2 and 64. DORA Article 28(3) requires a register of information on ICT contractual arrangements, and Article 30(2) requires contracts to state where data is processed. Listed US issuers should review how SOX Section 404 treats IT general controls over access, program changes and computer operations. Confirm applicability with your legal and compliance teams before the scope is written, because each regime sets different evidence expectations.
What to ask a Flowable partner before signing a fixed-scope agreement
A fixed-scope agreement for a financial services build should name each process and case by its model identifier, list every decision table with its hit policy and the input data it reads, and enumerate each integration with its direction, protocol and owning system. Ask for the environments in writing too: which ones exist (development, test, pre-production, production), who provisions them, and which ones hold real customer or account data. Then ask for the evidence deliverables, such as deployment records, test reports, configuration baselines and the history retention settings, and for acceptance tests tied to each named process. A scope that says "loan origination, delivered" without these details gives you nothing to accept against.
Ask where every component runs and where data is stored, processed and backed up, including any log, history or support access path that could carry personal or account data out of your infrastructure. Your contract and your DORA register of ICT arrangements will need that location statement, so get it in writing before work starts. Ask who holds the BPMN, CMMN and DMN files, the Java delegates and the deployment scripts at handover, in which repository, under which license, and whether your team can rebuild the system without the partner. Then settle upgrade responsibility: which party applies engine patches and major versions, who tests them, and who pays for regression testing after a Spring or Java baseline change. Confirm the support options, response expectations and escalation contacts as written terms, and confirm which items are included in the fixed fee and which are priced separately. Where the answer depends on your own environment or your auditor's expectations, ask for it in writing rather than assuming it.
How DeployOpen works on this
DeployOpen plans, implements, customizes, hardens, documents and supports Flowable engines inside the bank's or payment firm's own cloud accounts, data centers or air-gapped networks. Work starts with a written, fixed scope that names the processes, decisions, integrations and evidence the build must produce.
How we scope
- Map the loan, account opening or payment processes and the decision points that need DMN tables.
- Agree in writing which integrations, identity sources and history retention settings are in scope.
- Confirm with your compliance and audit teams which evidence the build must produce before work starts.
How we build
- Model BPMN approvals with four-eyes controls and CMMN cases where exceptions need flexible handling.
- Implement custom delegates, identity services and audit history inside your controlled infrastructure.
- Test process paths, decision tables and access checks, and document results for your control owners.
How we hand over
- Deliver deployment pipelines, runbooks, configuration records and architecture documentation to your team.
- Walk your operations and security staff through monitoring, failed job handling and version rollout.
- Provide control mapping notes that your internal and external auditors can review and test themselves.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the build.
- Plan Flowable version upgrades and their effect on Spring, Java and database baselines with your team.
- Confirm response expectations and maintenance windows in the written agreement before go-live.
