BPM for financial services

The first design decision in a financial services BPM build is which data classes the engine will carry. Onboarding, KYC and loan processes move identity documents, beneficial ownership declarations, sanctions and watchlist screening results, credit bureau inputs and payment account data through process variables and task forms. Each class needs its own rule on what may be stored in a variable, who can read it, and how long it lives. Ask the process owner and the compliance lead to classify every variable in the BPMN model before any task form is built, and treat a variable without a classification as a defect.

Process variables and history tables are not scratch space. Once an engine records who approved a loan, which screening result was attached, and when a task was claimed, those rows become records that an examiner or auditor may ask to see. The history tables therefore need the same retention and access controls as the system of record. Personal data should be limited to references: store a case identifier, a document reference in the core system or document store, and a screening result code, rather than copying passport numbers, full bureau reports or account numbers into variables. Flowable's configuration docs list H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server as supported database types, and the choice affects retention, backup, point-in-time recovery and who holds database credentials. Confirm with your database team whether the engine schema will sit in the same backup and encryption scope as the core banking data, and confirm the retention period for history with your records officer.

Integration points set the boundaries of that data. Core banking provides account and product data, CRM provides customer contact records, credit bureau services return scores and reports, and sanctions or identity verification services return match results. For each interface, document which fields the process reads, which it writes, and which calls leave your network. Confirm in writing with each provider where data is processed and stored, because contracts for ICT services that support critical functions must state those locations under DORA Article 30(2). Map each integration to a named service account with minimal rights, and log each call with its request reference so a screening decision can be traced back to the exact response it relied on.

To prove which rule version decided a case, the decision record must point to an exact, immutable version of both the process definition and the DMN decision table, and the audit history must show who approved each change. In a Flowable or Camunda deployment, the process instance stores the process definition key and version it started on, and each decision task stores the decision table key and version it evaluated. A reviewer should be able to take a loan or onboarding case, read its history, and rerun the same inputs against the recorded versions. Confirm with your engine vendor and your own test environment exactly which history tables and fields your chosen version writes, and whether decision inputs and outputs are captured in history or must be logged separately.

Four-eyes control belongs on rule changes as well as on case approvals. Require that a rule author cannot also approve and deploy the same DMN table, and that the approver's identity, the diff against the prior version, and the test results are stored with the deployment. Keep reviewer identity in the history itself, not only in a ticketing system, so that an auditor can see that the person who approved a credit policy change is a different named user from the person who edited it. Map those identities to your directory service so that leavers and role changes are traceable. Ask your partner how the identity service is wired to your identity provider, because the Flowable docs describe replacing the identity service to integrate with an external store.

Where an AI model contributes to a decision, such as a document classification or a risk summary feeding a DMN table, the logging obligations go beyond the BPM history. Article 12(1) of the EU AI Act requires high-risk AI systems to technically allow automatic recording of events over the system's lifetime, and Article 19(1) requires providers to keep those logs for at least six months unless other law provides otherwise. Whether your use is high-risk, and which retention period your own regulators require, is a question for your legal and compliance teams. Capture the model identifier, prompt and output references, and the rule version that consumed the output in one correlated record, and plan retention accordingly.

Start with four-eyes and segregation of duties. Ask the partner to show, in the actual BPMN model, where the second approver is enforced: which user task carries the approval, how the engine blocks the initiator from approving their own case, and how the approver group is resolved from your identity system rather than typed into the model. Ask them to demonstrate a failing test where the same identity attempts both steps. Then ask how DMN decision tables are tested before a rule change goes live: who signs off the table, which regression cases are replayed against the new version, and how the decision version that ruled on each case is recorded in history. A vague answer about testing is a warning sign for eligibility and pricing rules.

Ask how running instances are handled when a process version changes. Long-running loan or onboarding cases can span months, so ask for the migration approach, who approves it, how it is rehearsed on a copy of production data, and how stalled instances are detected afterward. On licensing, ask for written confirmation of which engine and license terms apply to production, since the Camunda 8 source code license permits only non-production use without a commercial license, while Flowable is Apache-2.0. Ask for the license position in writing from the partner and the vendor, not from a sales conversation.

For ITGC and engine change control, ask how the partner documents approval and testing of BPMN and DMN deployments and of the engine itself, and how that evidence maps to the program development, program change and access control areas named in SEC Release 33-8810. Ask how task users authenticate: whether MFA is enforced at the identity provider for everyone who can access a task, and how any exception would be approved in writing by the Qualified Individual under 16 CFR 314.4(c)(5) where that rule applies. Finally, for DORA, ask which contract terms they will document: the location of services and data under Article 30(2), data return on termination, and a tested exit strategy and transition plan under Article 28(8). Confirm these in the contract and in the register of information under Article 28(3) before work starts.