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.
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.
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.
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.
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.
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.
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.
Each layer has its own job, its own SLA, and its own tools:
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.
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.
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.
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 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 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.
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.
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.
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.
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.
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.
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.
Consider a cross-border payment that fails sanctions screening:
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.
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.
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.
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.
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.
The Industrial IoT Landscape Q4 2026 maps vendors and open source from edge to cloud…
Telecom has more orchestration standards than any other industry, and the maturity stops at the…
Jev by TypeSafe AI returns a calibrated probability instead of text. In a workflow that…
Jev by TypeSafe AI returns typed decisions with calibrated probabilities in a few hundred milliseconds.…
System One models such as Jev by TypeSafe AI answer typed questions with calibrated probabilities…
A working Python cron job moved to Kestra, the open source workflow orchestration platform, without…