Every large bank and fintech built its own glue at some point: a scheduler, a workflow engine, or a framework of scripts that connects the tools it already runs. Nothing on the market coordinated across those tools, so the most senior engineers wrote the connection themselves. Most of them still maintain it instead of building anything new.
The pattern looks the same everywhere. A fintech serving thousands of financial institutions recently retired exactly such an engine, and the business case was not a feature list. It was recaptured developer time, lower operational risk, and a faster cloud migration. Dozens of credentials were rotated by hand inside the old engine, regulated and non-regulated workloads shared infrastructure that should have been isolated, and heavy jobs competed with critical ones for the same on-premise capacity.
Workflow orchestration in financial services fragments into four disconnected silos, held together by that kind of code. This post shows what unified orchestration looks like in a bank: the four silos, the tools inside each one, and the flows that cross all four, from the overnight settlement chain to instant payments and AI agents.
The Four Orchestration Silos in Financial Services
Orchestration in a bank happens in four categories, and each one grew its own stack over decades, with its own tools, its own team, and its own operating model. Unified orchestration means one control plane for data, infrastructure, applications, and business processes, with agentic AI governed inside the same plane.
The cost sits in the glue between them, and in the fact that no one sees an end-to-end flow across all four.
Data Orchestration: Fraud Detection, Risk, and Regulatory Reporting Pipelines
Payment streams, market data, and change data capture from core banking feed fraud models, risk calculations, and the data warehouse or lakehouse. Data engineering teams orchestrate these pipelines with schedulers built for that job. A typical flow: CDC from the core banking database into the lakehouse, transformation, then a risk aggregation job that must complete before the morning risk report reaches the trading desk and the regulator.
Infrastructure Orchestration: Mainframe Job Chains, Enterprise Schedulers, and Cloud Migration
The infrastructure heartland of banking is the mainframe and the enterprise job schedulers around it. Nightly job chains provision resources, run backups, move files to clearing houses, and trigger COBOL programs in a strict sequence. Next to this legacy world, cloud landing zones brought their own automation stack. Most banks now operate both, connected by scripts nobody wants to own.
Application Orchestration: Coordinating Core Banking, Payment Engines, and KYC Systems
Core banking platforms, payment engines, and KYC and AML systems each expose APIs and events. Application teams coordinate multi-step operations across them: open an account, call the KYC provider, run the screening checks, create the ledger entries, notify the customer. Failures must be retried or compensated without leaving half-finished state in a system of record.
Business Process Orchestration: Loan Approvals, AML Cases, and Payment Exceptions
Loan approvals, AML case handling, and payment exception management are processes with people in them. An analyst reviews a flagged transaction. A credit officer approves an exposure. These flows have deadlines, escalations, and audit requirements, and they historically live in BPM suites or case management tools.
Where Workflow Orchestration Fits in the Banking Latency Spectrum
The first thing to get right is which paths a workflow engine may enter. Two paths run through every bank, and for both the answer is never. Both are engineered as real-time systems rather than as workflows.
The first is the trading path. Matching engines and market data feeds operate in microseconds on specialized, often proprietary technology. I wrote about this boundary years ago in the context of data streaming: Apache Kafka is NOT real real-time data streaming. The stock exchange example in that post shows a core engine with sub-15 microsecond latency requirements, with Kafka powering the analytics and distribution services around it. If even Kafka does not belong in that path, a workflow engine certainly does not.
The second boundary is newer: the instant payment execution path. Since October 2025, euro-area banks must send instant payments around the clock and credit the payee within ten seconds. Verification of Payee runs inside that flow, before the payer confirms. The end-to-end SLA is seconds, the fraud scoring inside it runs in milliseconds, and the whole path is engineered like a real-time system, not like a workflow.
Orchestration still has plenty to do on both rails. It just never sits inside the execution path. Instrument and reference data has to be loaded before the market opens, and trade capture and reconciliation run after the close. Liquidity transfers keep the instant payment account funded around the clock so that nothing fails for lack of funds at three in the morning. Failover drills run on a schedule. All of that is coordination around the rail on a timescale of seconds to hours, which is exactly where an orchestrator belongs.
The Three Latency Layers in a Bank
Each layer has its own job, its own SLA, and its own tools:
- Critical real-time (microseconds to a hard seconds-level SLA): matching engines, payment authorization and execution rails. Specialized technology. Not data streaming, not APIs, not workflow orchestration.
- Streaming and APIs (milliseconds): event distribution and fraud scoring with Apache Kafka and Apache Flink, CDC, request-response calls to KYC providers and payment engines. Fast data movement between systems, event-driven and synchronous.
- Orchestration (seconds to days): everything that coordinates work across systems and people. Pipelines, job chains, retries, approvals, escalations, calendars.
These are three different jobs, not three speeds of the same job. The tool follows the job, and the fast paths stay closed to the slower ones.
One Orchestrator Per Silo: Airflow, Control-M, Temporal, and Camunda
The orchestration market served each silo very well, which is how the fragmentation happened. Each category has a strong incumbent, and each is the right choice for a real set of problems.
One clarification first, because the terms get mixed constantly. Orchestration is not an integration style, and it is not tied to one. Banks integrate systems through APIs (open banking, KYC providers, payment engines), through files (clearing house handoffs, host-to-host transfers, regulatory submissions), through events and streaming (Kafka, Flink, CDC), and through the request-response middleware of the ESB and iPaaS era. A workflow orchestrator coordinates across all of these styles in the same flow: call an API, wait for a file, consume an event, trigger a batch job. Data streaming platforms move and process events in real time, but they do not schedule jobs, manage dependencies, or route work to humans. I mapped the full tooling space in the Data Integration Landscape, and the practical takeaway for this article is simple: an orchestrator that only speaks one integration style is just another silo.
Apache Airflow: Data Pipeline Orchestration for Analytics and Risk
Airflow dominates data pipeline orchestration, and for Python-centric data teams it is a reasonable default. In banking it typically runs the analytical workloads: end-of-day risk aggregation, regulatory reporting pipelines, feature pipelines for fraud models. Its limits appear at the edges of that scope. DAGs defined in Python create a bottleneck when engineers outside the data team need to contribute, event-driven triggering was bolted on late, and coordinating anything beyond data pipelines (infrastructure tasks, application calls, human steps) works against the grain of the tool. If your problem is purely data pipelines owned by one Python team, Airflow remains a fine choice.
Control-M and AutoSys: The Batch Backbone of Core Banking
Enterprise job schedulers run the overnight core of banking: settlement chains, general ledger updates, regulatory extracts, mainframe job nets. They are reliable, battle-tested, and expensive, and they were designed for a world with a batch window. The next section covers why that world is ending. If your workloads are stable mainframe job chains with no cloud ambition, these schedulers keep doing their job.
Temporal: Durable Execution Inside Payment and Banking Services
Temporal earned real respect in payment engineering, and for good reason. It gives developers durable execution: long-running, stateful code that survives crashes and retries safely, which is exactly what a payment service or an account opening service needs internally. Temporal orchestrates code inside an application boundary. It is not built to be the control plane across data pipelines, infrastructure jobs, and business processes, and teams that stretch it that far end up writing the glue themselves. For engineering teams building resilient services, Temporal is often the right tool inside that service.
Camunda: BPMN Automation for Loan Origination and Case Management
Camunda owns the business process category in many banks, with BPMN models for loan origination, case management, and order handling. It is strong where the process itself is the product and business analysts co-own the model. It is not a data pipeline tool and not an infrastructure orchestrator, and using it as one produces the same mismatch in the other direction. For human-centric, model-driven process automation, Camunda is a legitimate standard.
Beyond These Four Tools: Starting Unified Inside One Category
Airflow, Control-M, Temporal, and Camunda are the names that come up often in banking conversations. They are not the whole market. Data teams also run Dagster, Prefect, or the pipeline services of their cloud provider. Enterprise scheduling has Broadcom Automic, IBM Workload Automation, Redwood, and Stonebranch next to BMC. Durable execution has AWS Step Functions, Orkes Conductor, and Restate. The business process side has Appian, Pega, SAP Build, and ServiceNow, plus open-source engines such as Flowable.
The four-silo argument does not require a bank to start with all four. A team that only needs data pipelines today can still pick a platform built for all four, as long as it does not pay for that breadth up front. Four properties decide whether it does. Flow definitions that any team can read and change, not one team’s programming language. Schedules and event triggers in the same engine from the first flow, so a nightly pipeline can go event-driven later without a migration. A footprint small enough to run self-hosted without a dedicated operations team. And independence from the cloud provider, the mainframe vendor, and the BPM suite, so the platform outlives any of them. A platform with those four properties costs a single team nothing extra on day one. When the second category shows up, and in a bank it always does, it plugs into a control plane that is already running instead of into new glue code. The next section shows what that looks like.
Unified Orchestration: One Control Plane Above the Silos
Airflow, Control-M, Temporal, and Camunda each earn their place, and none of them is the problem. The problem sits in the seams between them, where a flow leaves one tool and arrives in another through code somebody wrote once and now maintains forever. The flows that matter most in a bank cross all four. A payment exception touches data pipelines, application APIs, batch jobs, and a human analyst before it is resolved. No silo owner has ever been accountable for that flow end to end.
Unified orchestration platforms address this gap. Kestra is the one I know from the inside, as Global Field CTO since 2026, and I wrote separately about why this category is worth the move. It meets the four properties above: flows are declared in YAML that any team can read and change, schedules and event triggers run in one engine, the runtime is a lightweight self-hosted service, and the core is open source. What makes it unified is the task reach on top of that. One flow can run a data pipeline step, provision infrastructure, call an application API, hand a file to a clearing house, and wait for a human approval, in one definition and one audit trail.
Unified orchestration does not replace Temporal inside a payment service. It does not re-model every BPMN diagram either. It adds one control plane above the silos. The incumbents keep doing what they are good at underneath, where they already earn their place.
What Unified Orchestration Looks Like Inside a Bank
The architecture argument only counts if it survives contact with what a bank actually runs. Three places decide that: batch workloads, payment exceptions, and regulated deployment.
Batch Workloads: Settlement and Payments Without a Batch Window
Conference talks cover streaming and AI. Nobody presents their overnight batch landscape, yet it is where much of banking actually runs: settlement chains, ledger updates, clearing files, and the regulatory submissions that leave the bank as files because the regulator ingests files. Two independent regulatory shifts are now squeezing this world at the same time.
The first is T+1 settlement. The EU, UK, and Switzerland move to T+1 on 11 October 2027, following North America in 2024. The first regulatory milestone lands much earlier. From 7 December 2026, allocations and confirmations have to be completed on trade date, and ESMA has told firms that 2026 is the year to finish the build. Market-wide testing windows run across 2027. Post-trade chains that comfortably fit a T+2 night now have to clear in a fraction of that window. Banks are rebuilding those job chains right now. Anyone modernizing a settlement chain in 2026 should ask whether rebuilding it inside a 1990s scheduler is the right target architecture.
The second shift already happened: instant payments removed the night entirely for payments operations. Since euro-area banks must receive and send instant payments around the clock, there is no quiet window left for maintenance jobs, reconciliation runs, or ledger updates that assumed the payment systems sleep. Sanctions screening changed shape with it. Ten seconds leaves no room to screen each transaction, so the regulation moved the check to the customer level. Banks screen their own payment service users at least daily, and again immediately after any change to the EU lists. A daily job that also has to fire on every list update is an orchestration workload by any definition. The batch window did not shrink. For payments, it is gone.
Mainframe Modernization and Scheduler Migration
The mainframe itself is not the problem, and it is not going away. As I described in Mainframe Integration with Data Streaming, modern mainframe generations are built for decades more of mission-critical work, and data streaming with Kafka and CDC tools moves mainframe data into the real-time world without touching the COBOL logic. But streaming solves data movement, not job coordination.
The dependency graph of a settlement night, the calendars, the reruns, the file handoffs to clearing houses, and the operator interventions are an orchestration problem. A modernization strategy needs both layers, and the Strangler Fig pattern applies to scheduler migration the same way it applies to application migration: move job chains incrementally to a modern orchestrator while the legacy scheduler keeps running what it still owns.
Payment Exceptions: One End-to-End Flow in the ISO 20022 Era
The ISO 20022 migration passed its hardest milestone. Swift ended the MT coexistence period for cross-border payment instructions on 22 November 2025. Adoption stood at roughly 97 percent after the cutover weekend. Nearly all cross-border instructions now travel as structured, data-rich messages. The industry conversation has moved from migration to exploitation: what do you do with structured data end to end? Exceptions and investigations are next in line. From November 2026, every institution has to be able to receive camt.110 investigation requests through Swift Case Management, and the move completes in November 2027. Payment exception workflows are being rebuilt across the industry right now, which makes this the flow to walk through.
A Cross-Border Sanctions Hit, Step by Step
Consider a cross-border payment that fails sanctions screening:
- Detection (data): the screening system flags the payment. An event lands in the stream, and a pipeline enriches the case with customer and transaction context from the lakehouse.
- Case creation (application): the orchestrator calls the case management API, creates the investigation with the structured ISO 20022 message attached, and assigns it based on rules.
- Human review (business process): an analyst reviews the case. This step is not optional: a human decision on a sanctions hit is a regulatory requirement. The workflow waits, escalates on deadline, and records who decided what and when.
- Repair and resubmission (application and infrastructure): after approval, the orchestrator repairs the message, resubmits the payment, and monitors the confirmation.
- Confirmation and audit (data and infrastructure): ledger confirmation flows back, the case closes, and every step lands in the audit trail with full lineage.
No single-silo orchestrator covers this flow end to end. The glue code that banks wrote to connect these steps is what the fintech from the opening story finally retired.
Regulated Deployment: DORA, Multi-Tenancy, and Auditability
In banking, compliance and supervision shape the orchestration platform decision before any feature comparison starts. Six requirements come up in nearly every evaluation, and each one is anchored in a regulation or an operational reality rather than a preference.
Where the Platform Runs and Who Can Access It
- Self-hosted and air-gapped deployment. Regulated institutions run the platform inside their own perimeter, often with no outbound connectivity at all. A vendor that requires SaaS or phone-home telemetry is out of the evaluation before it starts.
- Logical tenant isolation. PCI and non-PCI workloads, or different business units and clients, must be compartmentalized. Without logical multi-tenancy, banks end up deploying dozens of physical instances, one per tenant or team, purely out of necessity, and then paying the operational cost of maintaining them all. Compliance drives the isolation requirement; economics drives the consolidation.
- Fine-grained access control and compute isolation. SSO and role-based permissions down to the level of who can execute which flow are the gate compliance teams enforce before any platform expands beyond the first team. The same granularity applies to compute: one team’s heavy workloads must not starve another team’s critical jobs, which means isolated worker pools with their own scaling rules rather than one shared queue.
- Workflows as code, with tests. Banks treat orchestration flows like any other production software: version control, CI/CD, and unit tests before deployment. The inability to test a workflow change before it hits production is an operational risk no bank accepts at scale, and it is a common reason teams outgrow their first orchestration setup.
- Secrets from an external vault. Dozens of credentials living inside an orchestrator, rotated by hand, is an audit finding waiting to happen. The platform must pull credentials dynamically from the enterprise secret manager, so rotation happens in one place.
- Lineage and a live asset inventory. Risk data aggregation sits in the ECB’s supervisory priorities for 2026 to 2028, backed by targeted on-site inspections and an escalation path for banks that leave findings open. The Basel Committee named data lineage and traceability as a remaining gap at the start of 2026. An orchestrator that knows every resource its workflows touch makes audit evidence a query instead of a manual search. Hybrid execution belongs here too: core systems stay on-premise for years while migrations run, so heavy workloads must burst to the cloud without a second orchestration stack and without losing the audit trail.
DORA and the Register of Information
DORA sharpens all of this. The regulation has applied since January 2025 and supervisory tolerance is over. Banks filed their first Register of Information covering ICT third-party arrangements in 2025, and the second cycle closed in 2026 under far closer scrutiny. Incomplete registers, missing subcontractor chains, and contracts without the mandated clauses are the findings that come back most often.
The practical consequence for orchestration: the platform is itself an ICT third party in that register. Banks will pass DORA obligations down to it, from exit strategies to incident support. Vendors serving this market answer these requirements in their enterprise offerings. Any serious evaluation should test them with the compliance team in the room from day one.
Agentic AI in Banking: Governed Across All Four Categories
Banks are past the chatbot phase. The agent use cases with real traction in financial services are operational: a fraud triage agent that scores and summarizes a flagged transaction before the analyst opens the case, or an AML agent that extracts structured facts from case narratives and matches conditions across accounts. These agents produce drafts and recommendations that feed the workflows described above.
The governance requirement follows directly. An agent step is a workflow step, and it needs the same operational rigor as any other: inspectable runs, the ability to replay from a specific input to understand a decision, alerting when behavior drifts, and a human approval as a first-class step before anything consequential happens. In AML and sanctions contexts, that approval is not a best practice. It is the law.
Governance also extends to the platform’s own AI features. Banks routinely require the ability to restrict or disable functions that call external LLM APIs, down to specific user roles, because data leaving the perimeter is a compliance event regardless of which feature sends it. An orchestration platform for this industry needs feature-level controls for its AI capabilities, not just for its workflows.
This is why agentic AI is not a fifth orchestration silo. An agent that touches payments data, calls application APIs, and hands work to an analyst crosses all four categories like every other flow, and it must be governed by the same control plane. Bolting a separate agent platform next to four existing orchestration silos creates the next generation of glue code, this time with a non-deterministic component inside it.
The Trinity of Modern Data Architecture in Financial Services
Unified orchestration is not a pillar of its own. It sits inside process intelligence. The Trinity of Modern Data Architecture has three layers: process intelligence, data integration, and trusted agentic AI.
Process intelligence covers three capabilities: Process Mining shows how a process actually runs. Orchestration executes and governs what happens next. A decision gate keeps automation and agents inside auditable boundaries. Workflow orchestration is the execution core of that layer, and the Process Intelligence Landscape maps the vendors across both halves, from the miners to the orchestrators.
Event-driven integration moves payment and core banking events in real time. Event streaming with Apache Kafka and Change Data Capture (CDC) from databases move data off the mainframe without touching the COBOL logic. From there it feeds microservices for cloud-native operational workloads, and the lakehouse, where the analytical and regulatory truth lands. Process intelligence coordinates and governs the work around those events, from the settlement chain to the sanctions case. Trusted agentic AI acts inside the boundaries that layer sets. A fraud triage agent is only as good as the data beneath it and the gate above it.
To follow this work across data integration, workflow orchestration, process intelligence, and trusted agentic AI, subscribe to the newsletter and connect on LinkedIn.
