BPM in European Banking 2026: DORA, MaRisk, and the Audit Trail Problem
BPM in European Banking 2026: DORA, MaRisk, and the Audit Trail Problem
For Heads of Operations, Heads of Process Excellence, and Heads of Risk at European banks: why the BPM layer is the integration spine that DORA, MaRisk, DNB guidelines, FCA Operational Resilience, and BCBS 239 collectively now require.
The EU Digital Operational Resilience Act (DORA) — Regulation (EU) 2022/2554 — has been directly applicable across all EU Member States since 17 January 2025. 2026 is the first supervisory cycle in which DORA enforcement is expected to bite. The European Central Bank has integrated DORA compliance into the Supervisory Review and Evaluation Process (SREP). National competent authorities across the EEA are running DORA-themed questionnaires. Penalties can reach 2% of annual turnover and are applied cumulatively across DORA's articles, meaning institutions exposed on multiple pillars face parallel enforcement actions.
For European banks, the practical problem is not the framework. The framework has been read, scoped, and accommodated on slide decks for two years. The practical problem is the architecture underneath it.
Most European bank BPM estates were built before DORA. The process catalogue lives in one tool, often ARIS. The runtime is split across SAP banking workflows, core banking platforms (Temenos, Mambu, Avaloq, FIS), custom Java, ServiceNow for IT workflow, and a layer of RPA bots holding the legacy connections together. Each of DORA's five pillars — ICT risk management, incident reporting, resilience testing, third-party risk, information sharing — depends on a unified audit trail across that stack.
Most banks do not have one.
The five DORA pillars and where they create BPM requirements
DORA's regulatory architecture is unified, but the operational requirements it places on European banks are pillar-specific.
The first pillar — ICT risk management — requires a documented, board-approved framework for identifying, managing, and reporting ICT-related risks. The BPM requirement underneath: a process model that traces where ICT systems support which business processes, with documented risk assessments at the process level. Without this, the risk register is theoretical.
The second pillar — incident reporting — sets strict timelines for reporting major ICT-related incidents to the competent authority. The BPM requirement: a process state model that detects when a banking process has been disrupted (transaction failure, settlement delay, customer-facing outage) and triggers the regulatory reporting workflow. The clock starts on detection, not on board awareness.
The third pillar — digital operational resilience testing, including threat-led penetration testing (TLPT) — requires regular, evidence-based testing of operational resilience. The BPM requirement: process-level test scaffolding that can simulate disruption against the actual process flow and produce repeatable, auditable test outcomes.
The fourth pillar — ICT third-party risk management — extends DORA's reach to the bank's ICT suppliers, including any provider designated as a critical third-party provider (CTPP). The BPM requirement: process lineage that traces which third-party systems sit inside which bank processes, so third-party disruption is traceable to the operational impact it causes.
The fifth pillar — information sharing — establishes a regulatory framework for banks to share threat and incident information with each other and with regulators. The BPM requirement is lighter here but operationally real: the bank needs to know what processes were affected before it can describe the incident to regulators or peers.
The cumulative requirement across all five pillars is one thing: an end-to-end audit trail across the bank's operational processes that traces what runs where, who touched it, when it broke, and what the impact was.
The audit trail problem
The reason most European banks struggle with this is architectural, not regulatory.
In a typical European bank's BPM estate, the BPMN process catalogue is owned by the process governance team, often in ARIS. The catalogue describes how the bank says its processes run. The runtime — what actually executes — runs across multiple platforms: SAP banking workflows handle parts of the operational stack, the core banking platform handles transactional flow, ServiceNow handles internal service requests, custom Java handles bespoke logic, RPA bots fill the gaps where legacy systems lack APIs, and a layer of email-and-spreadsheet processes covers the exceptions nobody designed for.
Each runtime layer produces its own logs. The logs do not compose into an end-to-end audit trail without significant integration work. When a process instance breaks — a payment fails, a customer onboarding stalls, a sanctions check is delayed — the bank has to reconstruct the trace across the runtime layers manually.
For DORA, this is not sufficient. The expectation is that the process state, the system events, and the audit log compose automatically, in real time, across the entire path of a business process.
The regulatory stack: DORA + MaRisk + DNB + FCA + BCBS 239
DORA is the European baseline. National regulators sit on top.
MaRisk — the minimum requirements for risk management published by the German Federal Financial Supervisory Authority (BaFin) — predates DORA but overlaps with it on ICT risk management and process governance. German banks operating under MaRisk have process-level audit requirements that DORA reinforces.
DNB guidelines — issued by De Nederlandsche Bank for Dutch banks — similarly expect documented end-to-end process governance, with particular emphasis on outsourcing risk and operational continuity.
FCA Operational Resilience — the UK Financial Conduct Authority's framework for resilience of important business services — applies to UK banks and overlaps in intent with DORA, even after Brexit. UK banks operating in EU markets need to meet both.
BCBS 239 — the Basel Committee on Banking Supervision's principles for effective risk data aggregation and risk reporting — sits above the EU framework as a global Basel requirement. For systemically important banks, BCBS 239 has been a process audit driver since 2013, and DORA does not replace it.
The cumulative effect: a Tier 1 European bank operating in multiple jurisdictions is now operating under DORA plus the national framework plus BCBS 239 plus sector-specific frameworks. The audit trail expectation across all frameworks is broadly the same: end-to-end, process-level, real-time, immutable.
BPM as the integration spine
The architectural pattern that meets the cumulative regulatory expectation is consistent across European banks that have rebuilt their process platform for the post-DORA environment.
BPMN 2.0 process models live in the modeling system of record — for most European banks, this is ARIS, sometimes Signavio, occasionally BIC Platform or a vendor-specific tool like SAP Signavio for SAP-heavy estates. The catalogue is the source of truth for how processes run.
A BPM engine executes the process models. Where the bank already runs Camunda 7 in production, the runtime stays on Camunda 7. Where the bank is moving to Camunda 8, the runtime is on Camunda 8. Where the bank wants a maintained Camunda v7-compatible engine with an open AI-powered platform layer, Concordia BPM is one of the available options. The engine choice is platform-neutral; the requirement is that the engine runs the BPMN faithfully and produces a complete, immutable execution log.
The engine orchestrates across the bank's operational systems: SAP banking and core banking platforms (Temenos, Mambu, Avaloq) via APIs where available, ServiceNow for IT workflow, custom Java for bespoke logic, and RPA bots where legacy systems require UI-level automation. The orchestration layer is what produces the single audit trail across these runtimes.
Process mining — Celonis, SAP Signavio Process Intelligence, IBM Process Mining — sits in front of the architecture as the discovery layer, identifying which processes are most exposed to DORA scrutiny, where the variants and exceptions live, and where the audit trail is currently broken.
This pattern is not novel. It is the pattern most European banks are now building toward — through multi-year programs that depend on architectural design, not on platform feature lists.
Vendor-neutral platform considerations for banking
The right BPM platform for a bank depends on the existing stack, not on the analyst rankings.
For banks with mature ARIS estates and significant Camunda 7 production runtime, the realistic 2026 architecture is to keep ARIS as the modeling system of record, keep the Camunda 7 engine running, and add the orchestration and AI layer on top. Where DNA's Concordia BPM fits is for the engine layer — a maintained Camunda v7-compatible engine that runs the same BPMN models, on a Java/Angular/PostgreSQL stack with transparent licensing.
For SAP-heavy banks, SAP Signavio is often the modeling tool of choice, with the bank's SAP banking workflows providing the operational runtime. The orchestration layer choice depends on the integration commitment to the SAP estate.
For banks that have committed to Camunda 8 as the runtime, Camunda 8.9 (released April 2026) now provides agentic orchestration support, making it the natural choice for AI-augmented banking processes — provided the v8 migration is in scope.
For banks running ServiceNow as the operational workflow tool, the BPM orchestration sometimes sits inside ServiceNow itself, with BPMN models translated into ServiceNow flows.
No single platform fits every bank. The right answer depends on where the bank sits today.
How DNA approaches European banking BPM
DNA's discovery-first methodology is calibrated for the European banking environment. The discovery phase produces three outputs that the rest of the engagement is anchored on: a documented process catalogue with regulatory exposure mapped per process, an audit trail gap analysis against DORA plus the national framework plus BCBS 239, and a platform recommendation that takes the bank's existing investment as the starting point.
DNA operates across ARIS, Camunda, ServiceNOW, SAP Signavio, and Microsoft Power Platform — and is also the developer of Concordia BPM for the maintained-v7 path. The recommendation depends on the bank, not on the platform.
DNA's verified European enterprise client list includes NEXI in financial services. 75% of DNA's enterprise engagements last 5 or more years, reflecting the multi-year nature of the regulatory-driven process work the European banking sector is now undertaking.
Book a meeting → https://www.dnaconsulting.io/contact
About DNA Automation Consulting
DNA Automation Consulting is an EU-based BPM consultancy specialising in process discovery, BPMN design, and automation delivery for enterprise clients in banking, insurance, energy, telecom, and manufacturing. 75% of client engagements last five years or more.
Founded by Ante Gudelj and Nikola Dlaka. Clients include Proximus, Equinor, Merck, and NEXI.
Frequently asked questions
For Heads of Operations, Heads of Process Excellence, and Heads of Risk at European banks: why the BPM layer is the integration spine that DORA, MaRisk, DNB guidelines, FCA Operational Resilience, and BCBS 239 collectively now require.
The EU Digital Operational Resilience Act (DORA) — Regulation (EU) 2022/2554 — has been directly applicable across all EU Member States since 17 January 2025. 2026 is the first supervisory cycle in which DORA enforcement is expected to bite. The European Central Bank has integrated DORA compliance into the Supervisory Review and Evaluation Process (SREP). National competent authorities across the EEA are running DORA-themed questionnaires. Penalties can reach 2% of annual turnover and are applied cumulatively across DORA's articles, meaning institutions exposed on multiple pillars face parallel enforcement actions.
For European banks, the practical problem is not the framework. The framework has been read, scoped, and accommodated on slide decks for two years. The practical problem is the architecture underneath it.
Most European bank BPM estates were built before DORA. The process catalogue lives in one tool, often ARIS. The runtime is split across SAP banking workflows, core banking platforms (Temenos, Mambu, Avaloq, FIS), custom Java, ServiceNow for IT workflow, and a layer of RPA bots holding the legacy connections together. Each of DORA's five pillars — ICT risk management, incident reporting, resilience testing, third-party risk, information sharing — depends on a unified audit trail across that stack.
Most banks do not have one.
The five DORA pillars and where they create BPM requirements
DORA's regulatory architecture is unified, but the operational requirements it places on European banks are pillar-specific.
The first pillar — ICT risk management — requires a documented, board-approved framework for identifying, managing, and reporting ICT-related risks. The BPM requirement underneath: a process model that traces where ICT systems support which business processes, with documented risk assessments at the process level. Without this, the risk register is theoretical.
The second pillar — incident reporting — sets strict timelines for reporting major ICT-related incidents to the competent authority. The BPM requirement: a process state model that detects when a banking process has been disrupted (transaction failure, settlement delay, customer-facing outage) and triggers the regulatory reporting workflow. The clock starts on detection, not on board awareness.
The third pillar — digital operational resilience testing, including threat-led penetration testing (TLPT) — requires regular, evidence-based testing of operational resilience. The BPM requirement: process-level test scaffolding that can simulate disruption against the actual process flow and produce repeatable, auditable test outcomes.
The fourth pillar — ICT third-party risk management — extends DORA's reach to the bank's ICT suppliers, including any provider designated as a critical third-party provider (CTPP). The BPM requirement: process lineage that traces which third-party systems sit inside which bank processes, so third-party disruption is traceable to the operational impact it causes.
The fifth pillar — information sharing — establishes a regulatory framework for banks to share threat and incident information with each other and with regulators. The BPM requirement is lighter here but operationally real: the bank needs to know what processes were affected before it can describe the incident to regulators or peers.
The cumulative requirement across all five pillars is one thing: an end-to-end audit trail across the bank's operational processes that traces what runs where, who touched it, when it broke, and what the impact was.
The audit trail problem
The reason most European banks struggle with this is architectural, not regulatory.
In a typical European bank's BPM estate, the BPMN process catalogue is owned by the process governance team, often in ARIS. The catalogue describes how the bank says its processes run. The runtime — what actually executes — runs across multiple platforms: SAP banking workflows handle parts of the operational stack, the core banking platform handles transactional flow, ServiceNow handles internal service requests, custom Java handles bespoke logic, RPA bots fill the gaps where legacy systems lack APIs, and a layer of email-and-spreadsheet processes covers the exceptions nobody designed for.
Each runtime layer produces its own logs. The logs do not compose into an end-to-end audit trail without significant integration work. When a process instance breaks — a payment fails, a customer onboarding stalls, a sanctions check is delayed — the bank has to reconstruct the trace across the runtime layers manually.
For DORA, this is not sufficient. The expectation is that the process state, the system events, and the audit log compose automatically, in real time, across the entire path of a business process.
The regulatory stack: DORA + MaRisk + DNB + FCA + BCBS 239
DORA is the European baseline. National regulators sit on top.
MaRisk — the minimum requirements for risk management published by the German Federal Financial Supervisory Authority (BaFin) — predates DORA but overlaps with it on ICT risk management and process governance. German banks operating under MaRisk have process-level audit requirements that DORA reinforces.
DNB guidelines — issued by De Nederlandsche Bank for Dutch banks — similarly expect documented end-to-end process governance, with particular emphasis on outsourcing risk and operational continuity.
FCA Operational Resilience — the UK Financial Conduct Authority's framework for resilience of important business services — applies to UK banks and overlaps in intent with DORA, even after Brexit. UK banks operating in EU markets need to meet both.
BCBS 239 — the Basel Committee on Banking Supervision's principles for effective risk data aggregation and risk reporting — sits above the EU framework as a global Basel requirement. For systemically important banks, BCBS 239 has been a process audit driver since 2013, and DORA does not replace it.
The cumulative effect: a Tier 1 European bank operating in multiple jurisdictions is now operating under DORA plus the national framework plus BCBS 239 plus sector-specific frameworks. The audit trail expectation across all frameworks is broadly the same: end-to-end, process-level, real-time, immutable.
BPM as the integration spine
The architectural pattern that meets the cumulative regulatory expectation is consistent across European banks that have rebuilt their process platform for the post-DORA environment.
BPMN 2.0 process models live in the modeling system of record — for most European banks, this is ARIS, sometimes Signavio, occasionally BIC Platform or a vendor-specific tool like SAP Signavio for SAP-heavy estates. The catalogue is the source of truth for how processes run.
A BPM engine executes the process models. Where the bank already runs Camunda 7 in production, the runtime stays on Camunda 7. Where the bank is moving to Camunda 8, the runtime is on Camunda 8. Where the bank wants a maintained Camunda v7-compatible engine with an open AI-powered platform layer, Concordia BPM is one of the available options. The engine choice is platform-neutral; the requirement is that the engine runs the BPMN faithfully and produces a complete, immutable execution log.
The engine orchestrates across the bank's operational systems: SAP banking and core banking platforms (Temenos, Mambu, Avaloq) via APIs where available, ServiceNow for IT workflow, custom Java for bespoke logic, and RPA bots where legacy systems require UI-level automation. The orchestration layer is what produces the single audit trail across these runtimes.
Process mining — Celonis, SAP Signavio Process Intelligence, IBM Process Mining — sits in front of the architecture as the discovery layer, identifying which processes are most exposed to DORA scrutiny, where the variants and exceptions live, and where the audit trail is currently broken.
This pattern is not novel. It is the pattern most European banks are now building toward — through multi-year programs that depend on architectural design, not on platform feature lists.
Vendor-neutral platform considerations for banking
The right BPM platform for a bank depends on the existing stack, not on the analyst rankings.
For banks with mature ARIS estates and significant Camunda 7 production runtime, the realistic 2026 architecture is to keep ARIS as the modeling system of record, keep the Camunda 7 engine running, and add the orchestration and AI layer on top. Where DNA's Concordia BPM fits is for the engine layer — a maintained Camunda v7-compatible engine that runs the same BPMN models, on a Java/Angular/PostgreSQL stack with transparent licensing.
For SAP-heavy banks, SAP Signavio is often the modeling tool of choice, with the bank's SAP banking workflows providing the operational runtime. The orchestration layer choice depends on the integration commitment to the SAP estate.
For banks that have committed to Camunda 8 as the runtime, Camunda 8.9 (released April 2026) now provides agentic orchestration support, making it the natural choice for AI-augmented banking processes — provided the v8 migration is in scope.
For banks running ServiceNow as the operational workflow tool, the BPM orchestration sometimes sits inside ServiceNow itself, with BPMN models translated into ServiceNow flows.
No single platform fits every bank. The right answer depends on where the bank sits today.
How DNA approaches European banking BPM
DNA's discovery-first methodology is calibrated for the European banking environment. The discovery phase produces three outputs that the rest of the engagement is anchored on: a documented process catalogue with regulatory exposure mapped per process, an audit trail gap analysis against DORA plus the national framework plus BCBS 239, and a platform recommendation that takes the bank's existing investment as the starting point.
DNA operates across ARIS, Camunda, ServiceNOW, SAP Signavio, and Microsoft Power Platform — and is also the developer of Concordia BPM for the maintained-v7 path. The recommendation depends on the bank, not on the platform.
DNA's verified European enterprise client list includes NEXI in financial services. 75% of DNA's enterprise engagements last 5 or more years, reflecting the multi-year nature of the regulatory-driven process work the European banking sector is now undertaking.
Book a meeting → https://www.dnaconsulting.io/contact
About DNA Automation Consulting
DNA Automation Consulting is an EU-based BPM consultancy specialising in process discovery, BPMN design, and automation delivery for enterprise clients in banking, insurance, energy, telecom, and manufacturing. 75% of client engagements last five years or more.
Founded by Ante Gudelj and Nikola Dlaka. Clients include Proximus, Equinor, Merck, and NEXI.
Frequently asked questions
What is DORA and when did it come into force?
The Digital Operational Resilience Act (DORA), officially Regulation (EU) 2022/2554, is an EU regulation that establishes a unified framework for digital operational resilience across financial entities in the European Union. It has been directly applicable across all EU Member States since 17 January 2025. As a regulation rather than a directive, DORA does not require national transposition — it applies directly. The first supervisory cycle in which enforcement is expected to bite is 2026.
What does DORA require from European banks?
DORA requires European banks (and other in-scope financial entities) to meet obligations across five pillars: ICT risk management, ICT-related incident reporting, digital operational resilience testing, ICT third-party risk management, and information sharing. Cumulatively, these pillars require a documented, end-to-end audit trail across the bank's operational processes — covering what runs where, who touched it, when it broke, and what the operational impact was. Penalties can reach 2% of annual turnover and are applied cumulatively across DORA's articles.
How does DORA relate to MaRisk, DNB guidelines, FCA Operational Resilience, and BCBS 239?
DORA is the European baseline. National frameworks sit on top: MaRisk (Germany, BaFin), DNB guidelines (Netherlands), FCA Operational Resilience (UK). BCBS 239 is a global Basel framework for risk data aggregation that predates DORA and continues to apply for systemically important banks. A Tier 1 European bank operating in multiple jurisdictions typically operates under all of these frameworks simultaneously. The audit trail expectations broadly align — end-to-end, process-level, real-time, immutable — but each framework has its own scope and penalty regime.
Why is the audit trail a problem for European banks?
Most European bank BPM estates were built before DORA. The BPMN process catalogue typically lives in one tool (often ARIS). The runtime is split across SAP banking workflows, core banking platforms (Temenos, Mambu, Avaloq, FIS), custom Java, ServiceNow, RPA bots, and email-and-spreadsheet exception handling. Each runtime layer produces its own logs. The logs do not compose into an end-to-end audit trail without significant integration work. DORA's expectation is that the process state, the system events, and the audit log compose automatically in real time across the entire path of a process — which most banks cannot currently produce.
What BPM platforms work for European banking?
The right BPM platform for a bank depends on the existing stack. ARIS dominates the modeling layer in European banking. Signavio and BIC Platform are also common modeling tools, particularly in SAP-heavy estates. The engine layer varies: Camunda 7 is heavily deployed in production, Camunda 8 is the v8 path for committed migrators, Concordia BPM is the maintained Camunda v7-compatible engine with an open AI-powered platform layer. SAP banking workflows handle the SAP-native parts of the stack. ServiceNow handles IT-adjacent workflow. The platform conversation comes after the discovery work, not before.
How does DNA approach BPM in European banking?
DNA's discovery-first methodology starts with the process catalogue, the regulatory exposure per process, and the audit trail gap analysis. The deliverables from discovery anchor the platform recommendation — keeping the existing investment (ARIS modeling, Camunda 7 runtime, SAP banking workflows) where it earns its keep, and adding the orchestration and audit layer where it is missing. DNA operates across ARIS, Camunda, ServiceNOW, SAP Signavio, and Microsoft Power Platform, and is also the developer of Concordia BPM for enterprises on the maintained-v7 path. NEXI is named among DNA's European enterprise clients in financial services.
What is DORA and when did it come into force?
The Digital Operational Resilience Act (DORA), officially Regulation (EU) 2022/2554, is an EU regulation that establishes a unified framework for digital operational resilience across financial entities in the European Union. It has been directly applicable across all EU Member States since 17 January 2025. As a regulation rather than a directive, DORA does not require national transposition — it applies directly. The first supervisory cycle in which enforcement is expected to bite is 2026.
What does DORA require from European banks?
DORA requires European banks (and other in-scope financial entities) to meet obligations across five pillars: ICT risk management, ICT-related incident reporting, digital operational resilience testing, ICT third-party risk management, and information sharing. Cumulatively, these pillars require a documented, end-to-end audit trail across the bank's operational processes — covering what runs where, who touched it, when it broke, and what the operational impact was. Penalties can reach 2% of annual turnover and are applied cumulatively across DORA's articles.
How does DORA relate to MaRisk, DNB guidelines, FCA Operational Resilience, and BCBS 239?
DORA is the European baseline. National frameworks sit on top: MaRisk (Germany, BaFin), DNB guidelines (Netherlands), FCA Operational Resilience (UK). BCBS 239 is a global Basel framework for risk data aggregation that predates DORA and continues to apply for systemically important banks. A Tier 1 European bank operating in multiple jurisdictions typically operates under all of these frameworks simultaneously. The audit trail expectations broadly align — end-to-end, process-level, real-time, immutable — but each framework has its own scope and penalty regime.
Why is the audit trail a problem for European banks?
Most European bank BPM estates were built before DORA. The BPMN process catalogue typically lives in one tool (often ARIS). The runtime is split across SAP banking workflows, core banking platforms (Temenos, Mambu, Avaloq, FIS), custom Java, ServiceNow, RPA bots, and email-and-spreadsheet exception handling. Each runtime layer produces its own logs. The logs do not compose into an end-to-end audit trail without significant integration work. DORA's expectation is that the process state, the system events, and the audit log compose automatically in real time across the entire path of a process — which most banks cannot currently produce.
What BPM platforms work for European banking?
The right BPM platform for a bank depends on the existing stack. ARIS dominates the modeling layer in European banking. Signavio and BIC Platform are also common modeling tools, particularly in SAP-heavy estates. The engine layer varies: Camunda 7 is heavily deployed in production, Camunda 8 is the v8 path for committed migrators, Concordia BPM is the maintained Camunda v7-compatible engine with an open AI-powered platform layer. SAP banking workflows handle the SAP-native parts of the stack. ServiceNow handles IT-adjacent workflow. The platform conversation comes after the discovery work, not before.
How does DNA approach BPM in European banking?
DNA's discovery-first methodology starts with the process catalogue, the regulatory exposure per process, and the audit trail gap analysis. The deliverables from discovery anchor the platform recommendation — keeping the existing investment (ARIS modeling, Camunda 7 runtime, SAP banking workflows) where it earns its keep, and adding the orchestration and audit layer where it is missing. DNA operates across ARIS, Camunda, ServiceNOW, SAP Signavio, and Microsoft Power Platform, and is also the developer of Concordia BPM for enterprises on the maintained-v7 path. NEXI is named among DNA's European enterprise clients in financial services.
What is DORA and when did it come into force?
The Digital Operational Resilience Act (DORA), officially Regulation (EU) 2022/2554, is an EU regulation that establishes a unified framework for digital operational resilience across financial entities in the European Union. It has been directly applicable across all EU Member States since 17 January 2025. As a regulation rather than a directive, DORA does not require national transposition — it applies directly. The first supervisory cycle in which enforcement is expected to bite is 2026.
What does DORA require from European banks?
DORA requires European banks (and other in-scope financial entities) to meet obligations across five pillars: ICT risk management, ICT-related incident reporting, digital operational resilience testing, ICT third-party risk management, and information sharing. Cumulatively, these pillars require a documented, end-to-end audit trail across the bank's operational processes — covering what runs where, who touched it, when it broke, and what the operational impact was. Penalties can reach 2% of annual turnover and are applied cumulatively across DORA's articles.
How does DORA relate to MaRisk, DNB guidelines, FCA Operational Resilience, and BCBS 239?
DORA is the European baseline. National frameworks sit on top: MaRisk (Germany, BaFin), DNB guidelines (Netherlands), FCA Operational Resilience (UK). BCBS 239 is a global Basel framework for risk data aggregation that predates DORA and continues to apply for systemically important banks. A Tier 1 European bank operating in multiple jurisdictions typically operates under all of these frameworks simultaneously. The audit trail expectations broadly align — end-to-end, process-level, real-time, immutable — but each framework has its own scope and penalty regime.
Why is the audit trail a problem for European banks?
Most European bank BPM estates were built before DORA. The BPMN process catalogue typically lives in one tool (often ARIS). The runtime is split across SAP banking workflows, core banking platforms (Temenos, Mambu, Avaloq, FIS), custom Java, ServiceNow, RPA bots, and email-and-spreadsheet exception handling. Each runtime layer produces its own logs. The logs do not compose into an end-to-end audit trail without significant integration work. DORA's expectation is that the process state, the system events, and the audit log compose automatically in real time across the entire path of a process — which most banks cannot currently produce.
What BPM platforms work for European banking?
The right BPM platform for a bank depends on the existing stack. ARIS dominates the modeling layer in European banking. Signavio and BIC Platform are also common modeling tools, particularly in SAP-heavy estates. The engine layer varies: Camunda 7 is heavily deployed in production, Camunda 8 is the v8 path for committed migrators, Concordia BPM is the maintained Camunda v7-compatible engine with an open AI-powered platform layer. SAP banking workflows handle the SAP-native parts of the stack. ServiceNow handles IT-adjacent workflow. The platform conversation comes after the discovery work, not before.
How does DNA approach BPM in European banking?
DNA's discovery-first methodology starts with the process catalogue, the regulatory exposure per process, and the audit trail gap analysis. The deliverables from discovery anchor the platform recommendation — keeping the existing investment (ARIS modeling, Camunda 7 runtime, SAP banking workflows) where it earns its keep, and adding the orchestration and audit layer where it is missing. DNA operates across ARIS, Camunda, ServiceNOW, SAP Signavio, and Microsoft Power Platform, and is also the developer of Concordia BPM for enterprises on the maintained-v7 path. NEXI is named among DNA's European enterprise clients in financial services.
Written by:
Ante Gudelj
Managing Partner
Share with friends: