The quiet way financial institutions are modernizing payments right now

Article

Payments modernization is rarely framed as an operational problem. It’s usually discussed in terms of rails, reach and customer experience: faster payments, broader payment options, lower transaction costs, new payment methods.

That’s understandable. Revenue growth, AI innovation, cloud agility and customer experience dominate modernization conversations because they’re visible to boards and clients. But inside most financial institutions, the systems coordinating settlement, cutoffs, retries and reporting were designed long before real-time expectations became standard.

We’ve seen this pattern before. During cloud migrations and earlier digital transformation cycles, front-end capability advanced quickly while the operational foundation evolved more cautiously. Payments modernization is now encountering the same imbalance.

In many institutions, particularly large banks and card issuers, the orchestration model was built 25 or 35 years ago for batch windows and predictable cycles. It still works, but layering real-time controls, in-line fraud scoring and API-driven flows onto a clock-driven coordination model introduces complexity that accumulates.

For CIOs, CTOs and enterprise architects, this creates a growing tension. Legacy workload automation and batch orchestration remain deeply embedded in revenue flows, reporting cycles, regulatory controls and settlement processes. Touch them carelessly, and you risk disruption. Ignore them, and modernization efforts stall under their own weight.

The biggest risk in payments modernization today isn’t moving too slowly. It’s assuming the orchestration model you’ve relied on for decades will keep working while everything around it changes.

How modernization unfolds in the industry

Payments modernization rarely arrives as a single, declared program. It unfolds through a series of cautious, tightly scoped decisions, each designed to limit operational and regulatory risk.

• A new payment rail is introduced, requiring ISO 20022 translation, prefunding and intraday liquidity controls
• A real-time fraud check or anti-money laundering (AML) engine is deployed to score transactions in-line in milliseconds rather than overnight
• An API gateway is implemented to expose payment initiation, status and routing to fintech partners or corporate clients

Each change is reviewed carefully, implemented incrementally and monitored closely. Individually, these decisions make sense. Collectively, they change how payments move through the organization. And what often goes unexamined is the execution layer coordinating that work. 

Legacy systems remain in place because they’re stable, familiar and deeply intertwined with settlement, reconciliation, governance and reporting. Modernization rarely centers on replacement. It progresses through selective isolation of functions and the introduction of new capabilities at the edges of the system. The architecture that emerges is layered, as each addition addresses a defined requirement. 

New payment rails change the rules of execution

What’s surfacing now isn’t confusion about how new payment rails work. It’s a growing mismatch between those rails and the execution models many financial institutions still rely on to run them.

Instant payment rails like FedNow and Real-Time Payments (RTP) remove timing buffers that legacy batch coordination quietly depended on. When funds move immediately from the issuing bank to the recipient’s bank, recovery paths narrow and accountability shifts upstream into the orchestration layer itself.

At the same time, payments workflows are becoming more asynchronous and distributed. Tokenization introduces lifecycle events that don’t align neatly with batch windows. Open banking APIs and embedded payments extend payment journeys across third-party providers, payment processors, fintech platforms and institutional counterparties. Cross-border payments introduce dynamic routing, intermediaries and real-time compliance checks across payment networks like SWIFT, SEPA and card rails.

Legacy orchestration models were designed for stability in predictable environments. New payment workloads demand adaptability across hybrid ones.

The “new workload” strategy

A more pragmatic approach is emerging. Instead of forcing legacy workloads into modern patterns, leading teams are deploying modern orchestration only where it’s required:

• New payment rails and faster payments services
• New customer-facing payment options
• New API-driven and data-intensive payment flows

Existing batch workloads — ACH payments, recurring payments, settlement cycles, reporting — continue running where they are. They’re stable, governed and understood. They don’t need reinvention to support innovation elsewhere. Modernization expands outward from new payment capabilities, rather than backward into stable legacy flows.

What qualifies as a “new payment workload”?

Not every payment flow is created equal. Across banks, card networks and payment platforms, the workloads that demand modern orchestration share one trait: they can’t wait.

Examples include:

• Real-time payments and instant settlement
• Token lifecycle management
• API-driven payment initiation and partner ecosystem orchestration
• In-line fraud and risk decisioning tied to live transaction events
• Cross-border payments with dynamic routing and compliance logic

These flows run on live signals, not schedules. Recovery has to be automatic and context-aware, because there’s no safe pause button in the middle of a real-time payment.

The foundation for disciplined modernization

Modernizing forward only works if your orchestration layer evolves alongside those new workloads. Payment rails, fraud engines and APIs introduce speed and distribution, and orchestration determines whether you can safely gain speed without losing control. If your logic remains tied to clock-driven execution, your new capabilities will just inherit old constraints. Deliberate, modern orchestration helps them operate in real time without destabilizing your existing systems.

Why this reduces risk instead of increasing it

The instinctive fear is understandable: introducing new orchestration alongside legacy systems feels like adding complexity. In practice, it does the opposite.

Running modern orchestration in parallel:

• Avoids disruption to revenue-generating payment systems
• Eliminates forced migration of fragile legacy logic
• Creates a clear separation between systems of record and systems of innovation

Instead of turning every change into a platform-wide event, you contain the impact to the new flow. A FedNow exception doesn’t have to spill into ACH payments, and a routing issue doesn’t necessitate a war room just to understand what broke.

Just as importantly, this containment model prevents modernization costs from compounding, so there are fewer emergency fixes, one-off integrations and expensive upgrade projects designed solely to keep the lights on. 

Hybrid orchestration isn’t a compromise

Payments modernization will remain hybrid for the foreseeable future. Cloud-native payment platforms, SaaS services, on-premises systems and external payment networks will continue to coexist.

Chasing a perfectly unified architecture is a distraction; what matters is whether the work moves cleanly across boundaries — cloud to on-premises, internal systems to payment processors, batch to event-driven paths — without creating new failure points.

Modern orchestration becomes the connective tissue across cloud, SaaS and on-premises environments, aligning payment instruction flows, routing decisions and downstream processing without forcing everything into a single model. This is how organizations escape orchestration technical debt without risking operational stability.

Over time, this approach changes the economics of modernization by shrinking upgrade cycles, lowering operational overhead and freeing capacity for new initiatives instead of constant maintenance.

A quieter form of transformation and why it works

The most effective payments modernization programs rarely announce themselves loudly. They don’t arrive as sweeping transformation initiatives or architectural resets. Instead, they introduce new capabilities deliberately, with clear operational boundaries and a strong bias toward stability.

This approach aligns with how regulated financial institutions actually manage risk. Change is evaluated in context, scoped tightly and introduced where it delivers clear value without increasing operational exposure. 

“Boring” is often the point. It means exceptions are handled predictably, and investigations start with answers instead of guesswork. Teams can explain what happened in a payment flow without reconstructing the story after the fact. It also means audits and regulatory reviews are routine rather than disruptive, because the execution trail is clear and defensible from the start.

Change the cost curve of modernization

When new payment capabilities are introduced without reworking what already runs, modernization stops drawing from the same operational budget year after year. In that environment, digital transformation becomes more cost-effective by design. Your teams can spend less time maintaining orchestration debt and more time delivering new value.

Explore how modern orchestration supports new payment workloads without disrupting legacy operations or allowing excess costs to accumulate.

Confidence theater: When “closed” isn’t actually closed

Article

The curtain rises at the end of the accounting period. Dashboards light up. The close checklist is fully checked. Key performance indicators (KPIs) show green across the board. To leadership and other stakeholders, the financial close process looks complete, controlled and ready for strategic decisions.

But backstage, the performance is still running.

What many CFOs are presented with is confidence theater: a polished view of progress that suggests finality without proving that the work behind the scenes is finished. In finance, that gap matters. Because when visibility replaces execution proof, financial statements can look settled while the general ledger is still changing.

Dashboards create confidence, not certainty

Dashboards are designed to present progress, not verify completion. They summarize workflow steps, timelines and metrics that imply the financial close process has reached its final scene. For accounting and finance teams under pressure, this presentation is reassuring. For executives, it signals stability.

The problem is that dashboards rarely confirm whether financial transactions have actually landed in the accounting system. Progress indicators show that tasks were reviewed or approved, not that journal entries were posted and reflected in the trial balance, balance sheet, income statement or cash flow statement.

This is where risk creeps in. Leadership believes results are stable, while accruals, reclassifications and other adjustments are still being created post-close. The finance and accounting teams may still be reconciling accounts, updating templates in spreadsheets or correcting discrepancies across subledgers.

An example was when a CFO of a SaaS organization presented “100% closed” results to lenders and the board. The dashboards showed a clean close period. Days later, late intercompany reclassifications moved revenue between business units. Fixed assets depreciation was corrected. Variances emerged between prior period assumptions and actuals. Financial reporting still needed to be revised.

The numbers changed because execution never stopped, and that meant what leadership saw wasn’t a close. It was a preview. Without execution confirmation, visibility becomes performance, and decision-making confidence disappears.

“Done” does not mean posted

Most close management systems define “done” as task completion. A reviewer signs off. A close checklist item turns green. But none of that guarantees ledger impact.

Journal creation, approval and posting remain decoupled from close status in many automation tools. A journal can be approved yet still sit outside the general ledger. Accounts payable adjustments, receivable corrections or bank statement accruals may exist only in Excel files or email threads. Until posting occurs, account balances are provisional.

This matters because material activity stays invisible until it becomes a problem. The accounting process looks complete even as manual processes continue behind the curtain. Data entry errors, unresolved discrepancies and missing financial data surface late, usually after executives believe the close period is locked.

With the CFO of the SaaS organization, additional journal entries hit the ERP five days after the apparent month-end close process. Revenue recognition was updated. Liabilities tied to credit cards and bank accounts shifted. The accounting records had diverged from what leadership had already reviewed, which forced explanations and revisions that undermined trust in reported results. Because if journals weren’t posted, the close simply wasn’t defensible.

False confidence becomes an audit and credibility risk

Clean dashboards can hide operational instability. They smooth over bottlenecks, time-consuming reconciliations and unresolved issues that sit outside the reporting process.

Auditors don’t review dashboards. They follow execution. Late adjustments appear during audit walkthroughs, not executive reviews. Auditors trace financial transactions through subledgers, trial balance movements and period-end postings. That is where post-close activity is exposed.

The downstream effects are predictable with audit delays, process bottlenecks, extended year-end close cycles and, in some cases, revenue restatements. Accounting and finance teams are pulled into firefighting mode because they’re answering why variances exist and why accounting records changed after reporting.

In the CFO example for the SaaS organization, revenue had to be reexplained once the journal entries finally aligned with the general ledger. Forecasting assumptions were questioned. Strategic decisions made earlier had to be revisited. What looked efficient became a credibility issue. What leadership saw as a fast, efficient close turned out to be a delay waiting to surface. What felt like efficiency in real time became exposure under audit.

Real close control requires execution-level proof

True close control is not about workflow progress. It’s about verified journal execution.

Execution-level proof means knowing that journals are created, validated and posted based on business logic and data readiness instead of human memory. This is where orchestration changes the model.

Orchestration ties automation, ERP data, subledgers and financial transactions into one coordinated flow. When prerequisites are met, journals post automatically. When data changes, adjustments are recalculated. Visibility reflects what is actually in the ledger, not what is assumed to be finished.

Finance Automation by Redwood applies this orchestration approach across the financial close process, from journal entries and account reconciliation to intercompany activity, accruals, provisions and reclassifications. Dashboards show only posted, final results. The accounting system becomes the source of truth, not a presentation layer.

In the CFO of the SaaS organization example, leadership would never have seen provisional numbers with a record-to-report (R2R) orchestration platform like Finance Automation. Dashboards would have only included posted balances from the general ledger. Financial position, metrics and financial health would align with reality. Informed decision-making would be grounded in execution instead of performance optics. With Finance Automation’s orchestration, the CFO would not have relied solely on task progress. They would have relied on proof. And that’s the shift: real close control comes from knowing what’s finished, not what’s still in progress.

End the performance. Lead with proof.

CFOs should question dashboards that cannot confirm ledger reality. Task completion does not equal financial completion. A close checklist does not guarantee that period-end numbers are final.

Traditional automation software and tools focus on tracking work. Finance Automation focuses on executing it. By orchestrating journals, reconciliations and postings directly within the ERP, Finance Automation delivers verified, final execution that supports confident financial reporting.

The theater ends when the numbers stop moving.

Take the automation maturity assessment to see what’s really happening backstage in your close and whether your financial close process is built on performance or proof.

Redwood Insights Premium and more observability updates for RunMyJobs: Elevating context and confidence

Article

As enterprise automation grows more distributed and more business-critical, visibility needs to keep pace. Workflows now span SAP landscapes, cloud platforms, legacy systems and third-party services. Execution data is abundant, but without context, it becomes harder to answer the questions that matter most: Where are risks emerging? What’s slowing us down? How does automation performance connect to business outcomes?

Redwood Software began addressing this challenge last year with the introduction of Redwood Insights, bringing observability directly into RunMyJobs by Redwood through standardized dashboards and operational analytics. That foundation gave teams clearer visibility into automation health and compliance without relying on disconnected tools.

RunMyJobs 2026.1 builds on that momentum with a broad set of observability-focused updates across the platform. This update expands how automation data is surfaced, shared and trusted, combining default insights, deeper analytics, tighter ecosystem integration and strengthened security. Together, these enhancements give teams a clearer context across their automation environments and greater confidence as automation becomes more central to daily operations.

Democratizing automation intelligence

At the center of RunMyJobs 2026.1 is Redwood Insights Premium, an expansion of the analytics and observability capabilities already available to RunMyJobs customers.

Redwood Insights Premium is designed for organizations that need deeper analysis and longer historical context as automation becomes more central to their operations. It extends observability beyond platform administrators to the business and domain teams that rely on automation outcomes.

Key capabilities include:

• A no-code dashboard designer that allows IT to create role-specific dashboards for different teams
• Extensive visibility into workflow health, execution patterns and emerging trends
• 15 months of historical data retention, expanding the existing analytics window for trend analysis, capacity planning and ROI conversations

IT teams can curate views for different teams and control access, while stakeholders gain self-service access to insights in their own context. This reduces reporting overhead and removes the “IT-as-translator” bottleneck without sacrificing consistency.

Unified transparency across SAP and the broader ecosystem

RunMyJobs has long supported integration across enterprise environments. In 2026.1, that integration extends more deeply into observability workflows.

For SAP-centric organizations, the out-of-the-box SAP Cloud ALM connector brings RunMyJobs execution data directly into SAP’s native Job and Automation Monitoring. Automation health becomes part of the same operational view SAP teams already use, improving coordination and reducing mean time to resolution (MTTR).

At the same time, RunMyJobs continues to integrate with leading observability platforms such as Splunk, Dynatrace, New Relic and AppDynamics. These integrations strengthen full-stack correlation, allowing teams to connect automation behavior with application and infrastructure performance using tools already in place.

Enhanced security and trusted AI, built in

In 2026.1, RunMyJobs’ security and governance foundations are further strengthened.

New capabilities include automated malicious file detection for all UI uploads with full audit logging, along with enterprise-grade moderation applied to all Redwood RangerAI interactions. These controls allow teams to benefit from AI-assisted troubleshooting and scripting while maintaining strict governance boundaries.

Support for Java 25 ensures the platform continues to align with the latest long-term support runtime for performance and security.

Modern deployment: Cloud Gateway

As automation environments become more distributed, reliable connectivity becomes essential. Observability and execution depend on consistent communication across cloud, hybrid and on-premises infrastructure.

The updated Cloud Gateway in RunMyJobs 2026.1 improves how the platform connects to these environments. It supports multiple active gateways at the same time, enabling higher throughput and load distribution across gateways. Intelligent routing allows traffic to be segmented by network or domain, while automated failover ensures continuity if a gateway becomes unavailable.

Together, these enhancements strengthen availability and performance across complex network topologies. Observability and execution data remain reliable even as infrastructure becomes more segmented and automation spans multiple environments.

Velocity through usability

Alongside these enhancements, RunMyJobs 2026.1 includes hundreds of usability and performance refinements. These changes focus on reducing friction in daily operations rather than introducing new workflows that teams need to learn.

Improvements across navigation, responsiveness and issue detection help users move faster and identify potential problems earlier. Routine interactions require fewer steps. Signals that once required manual investigation are surfaced more clearly within existing views.

Together, these updates extend RunMyJobs’ observability capabilities into a broader, more actionable intelligence layer. Automation becomes easier to understand, easier to manage and easier to optimize over time.

Already a Redwood customer? Review all the features released in 2026.1.

Ready to democratize your data? Request a demo of RunMyJobs, including Redwood Insights Premium, and see how tailored observability changes how your teams work.

Why clarity, not coverage, defines modern observability

Article

Imagine standing in a control room filled with screens. Every system reports green, and every dashboard is populated. The view feels complete. Then, a critical business process misses its deadline.

The data was there. The warning signs weren’t obvious. By the time the impact surfaced, the moment to intervene had already passed.

This is a familiar tension for many enterprise leaders. Visibility exists, but understanding doesn’t always follow. Monitoring tools confirm that systems are running, but they rarely explain how automation behaves under pressure and how delays ripple across dependencies or where risk is quietly accumulating.

The single pane of glass was an important step forward. It brought fragmented information into a shared view and reduced blind spots. What it doesn’t consistently provide is depth: the ability to move from status to meaning without manual interpretation.

That gap becomes clear the moment questions turn from “Is it running?” to “Can we rely on it?”

When insight depends on translation, risk increases

Most enterprises already collect enormous amounts of operational data. Automation platforms generate execution logs and performance metrics. And applications and infrastructure emit their own signals. So on paper, nothing is missing. But in practice, insight is scattered.

Understanding what’s happening across critical workflows often requires translation. IT teams pull data from multiple monitoring tools, correlate timelines and explain what technical behavior means for business outcomes. Leaders then depend on these explanations to assess risk, prioritize action and answer questions they know are coming.

This model is fragile. It slows decision-making and quietly extends mean time to resolution (MTTR), even when teams are working as fast as they can. By the time an issue is fully understood, the opportunity to intervene early has often passed, turning what could have been a minor disruption into a larger operational event.

Observability reduces that dependency. Correlating automation data and presenting it with context, it allows different audiences to access the insight they need without waiting for interpretation.

Why consolidation alone doesn’t create clarity

The promise of a single pane of glass is powerful when the goal is shared visibility into a specific domain — one platform, one set of processes, one operational context. It creates a common reference point and a shared understanding of what’s healthy and what’s not.

The challenge emerges when that same approach is stretched to cover the entire enterprise. A single view can only show so much. When automation spans applications, infrastructure, data pipelines and business services, compressing everything into one window often flattens the story instead of explaining it. 

Over time, this leads to dashboard fatigue, especially when green statuses can mask issues that matter deeply to specific teams. Different roles need different windows into the landscape:

• Process owners need to understand whether end-to-end workflows will complete on time 
• SAP teams need to see how automation execution affects business services and applications
• Platform teams need to connect workflow behavior to application performance and infrastructure health

Effective observability builds on the single-pane-of-glass approach with more of a panoramic view, where multiple, connected panes together reveal the full landscape. Each pane provides the right context for the person looking through it, while still drawing from the same underlying source of truth.

Context changes how problems are handled

Monitoring answers a narrow question: did something happen?

Observability answers a more useful one: why did it happen?

With cross-domain, correlated, up-to-date data, teams can see how workflows behave as part of the enterprise ecosystem, how dependencies influence response times and where delays originate — insight that directly shortens MTTR by narrowing focus to the point of failure instead of the symptom. 

The real impact shows up in consistency. Fewer surprises reach leadership. More importantly, service-level agreements (SLAs) stop feeling like commitments you hope to meet and start becoming outcomes you can actively manage. Ultimately, the organization spends less energy reacting and more time improving how critical processes perform.

So, the control room still exists, but it stops being a wall of indicators. It becomes a place where cause and effect are visible.

Resilience requires a longer memory

Operational resilience isn’t built in a single incident. It’s built over cycles.

Short-term monitoring captures what happened today, while observability preserves history and makes it actionable. With extended data retention, leadership teams can look across quarters instead of weeks. They can compare peak-period performance year over year, identify recurring bottlenecks and understand how changes in architecture or volume affect outcomes.

This longer view supports better planning and more credible conversations with the board. It also simplifies governance and audit preparation. Instead of assembling evidence manually, you can rely on a consistent execution history that reflects how systems actually operate.

A 15-month narrative, rather than the two- or three-month one many teams work with today, creates continuity. It allows leaders to explain not only what changed, but why it changed — and how those decisions improved reliability, protected SLAs during peak periods and strengthened the return on automation investments in the long run.

A more sustainable role for IT

When observability is done well, something subtle but important changes inside the organization.

IT teams stop being the place everyone goes for explanations. They’re no longer stuck translating technical signals into business impact after the fact. Instead, they set the conditions for shared understanding. The right information is available earlier, in context and in language that different teams can actually use.

That shift frees technical managers to focus on improving how systems perform rather than defending why something failed. It also changes how leaders engage. Conversations become less about status and more about trade-offs, priorities and what to improve next. Visibility no longer depends on deep technical detail or last-minute briefings.

This is why observability can’t be reduced to “better dashboards.” The real value is confidence: 

✅ Confidence that the systems carrying real business risk are understood

✅ Confidence that issues will surface early 

✅ Confidence that decisions are grounded in reality, not assumptions

Continue exploring observability

As automation continues to scale via Service Orchestration and Automation Platforms (SOAPs), the ability to understand, anticipate and explain performance becomes a strategic advantage. To learn more about how modern observability supports resilient, data-driven operations, explore Redwood’s approach to enterprise observability.

The automation talent shift: Building teams that thrive in the SOAP era

Article

After years of working with SAP customers, partners and internal teams, one thing has become clear to me: automation has outgrown its roots as a technical initiative tucked inside IT. Today, automation is the connective tissue of modern digital infrastructure and, increasingly, of the teams that run it.

What doesn’t get talked about enough is that this shift isn’t primarily about tools. It’s about us as humans.

That’s why I find the 2025 Gartner® Magic Quadrant™ for Service Orchestration and Automation Platforms (SOAPs) so relevant as both a technology lens and a talent and operating-model conversation.

SOAPs aren’t simply better schedulers. They orchestrate end-to-end business services with precision, context and intelligence. And when an organization adopts one, it doesn’t just modernize its automation stack, but reshapes how teams work together, learn and create value.

From my perspective, this isn’t a skills gap problem. It’s about how roles are naturally evolving. With the right guidance, encouragement and space to grow, people can thrive in change rather than just adapting to it.

The shift from task execution to service ownership

SOAPs dramatically expand the surface area that automation touches. We’ve moved from “run this job” to “run this entire business service — with events, conditions, dependencies and real consequences.” 

That evolution changes the nature of the work. You’re no longer optimizing isolated workflows inside a single system. You’re orchestrating processes that span ERP, SaaS applications, cloud platforms and external services. That requires broader thinking and deeper collaboration. The work itself becomes more strategic.

People are still central, but they’re now enabling resilience, business agility and real-time orchestration, not just maintaining automation.

What high-performing automation teams think differently about

The first real shift has to happen in how teams think about automation. Over time, I’ve seen successful teams move from:

• “Automate the task” → “Orchestrate the service”
• Siloed responsibility → Shared, cross-functional enablement
• Versioned scripts → Reusable templates and modular components
• Maintenance thinking → Platform thinking
• Support role → Strategic enabler
  

This mindset shift is subtle, but it changes everything from design decisions to how people collaborate across SAP and non-SAP landscapes.

How automation responsibilities are being redistributed

As SOAPs reshape operational models, new roles naturally emerge. Many organizations already have the talent; they just haven’t named or empowered these roles yet.

Some patterns I’m seeing more often:

• Process architect/Orchestration designer: Connects workflows across business services, APIs and cloud-based environments
• Automation data translator: Bridges operational logic with analytics, logs and business context
• Workflow monitoring and exception manager: Manages signals, dependencies and upstream/downstream impact
• Adoption lead or Change champion: Drives orchestration consistency across business ops, IT operations and development teams
• Automation culture steward: Shapes shared norms around reusable assets, platform thinking and feedback loops

Revisiting how automation work is distributed can unlock capacity you didn’t realize you had.

The conditions that make orchestration stick

Technology expands what’s possible. Culture determines what actually sticks. As automation spans more of the business, shared ownership becomes essential.

That starts with a shared vocabulary. If one team calls it “dependency mapping” and another says “event chaining,” you’ll end up with silos — not orchestration.

It continues with a learning loop that goes beyond training. People and teams need space to experiment, compare patterns and refine their instincts. As a leader, your job isn’t to prescribe every step but to create the conditions for repeatable learning that scales naturally.

And all of the above depend on clear ownership. Without visible leaders accountable for process optimization, templates and tooling standards, automation efforts remain reactive.

How to help your team thrive

If SOAPs unlock new levels of human potential, your team’s job is to take that and run. The environment you create — and the initiatives you choose to prioritize — will bring the shift to life.

At a minimum, I’d focus on the following.

1. Build capability with intention

Capability building can’t be accidental. It should be purposeful. Help teams build fluency in event-driven automation, API integration, cloud orchestration and monitoring patterns. Give legacy automation specialists room to evolve into orchestration designers or platform operators.

The goal isn’t to turn everyone into a developer. But everyone should understand how services fit together and how dependencies behave. You’ll be designing for resilience when your teams understand the “why” behind SOAP-driven workflows.

2. Create a structure that supports orchestration

Orchestration doesn’t thrive without structure. Establish an automation Center of Excellence as a guide for standard workflow patterns, exception handling and reuse. Make ownership explicit for templates, connectors and observability.

Most importantly, bring your practitioners into governance conversations. That’s how you remove friction between process design and automation design.

3. Equip teams with tools that let them excel

People do their best work when technology reduces complexity instead of adding to it. Choose platforms that make dependencies visible and support both low-code and advanced design approaches. Each persona should be able to contribute at their level.

I often ask one simple question: Will this tool make it easier for my team to design, understand and maintain end-to-end processes? If the answer is yes, the value shows up quickly.

4. Avoid the usual traps

Automation stalls when it’s treated as an IT-only scripting exercise, when adoption is an afterthought or when success is measured by output instead of outcomes. You can avoid these traps by formalizing enablement, designing for orchestration — not tasks — and tying KPIs to reliability and business impact.

Your people = your differentiator

SOAPs raise expectations for how work flows across the enterprise. But it’s your people who turn those expectations into outcomes.

When you make space for teams to think bigger about how data, work and ideas move across the business, you unlock something far more powerful than automation alone.

If you’re building that kind of culture, it helps to understand where the market is headed. The 2025 Gartner® Magic Quadrant™ for SOAPs report offers a grounded view of the Leaders and orchestration capabilities shaping the next chapter of enterprise automation — and the teams that will thrive in it.

Payments modernization depends on orchestration — not just the core

Article

There’s a particular kind of risk that only exists in systems that “work.” It’s not the flashy kind, or the kind that triggers emergency funding or board-level interventions. This is a quieter risk, embedded deep in the background of day-to-day operations. 

It’s the infrastructure everyone depends on, but almost no one revisits, because it hasn’t failed loudly enough.

Banks have spent years modernizing what customers can see: digital experiences, mobile apps, real-time payment rails, cloud-native cores. Those investments were necessary. In many cases, they were overdue. And on paper, they delivered exactly what executives asked for.

So, why does it still feel harder than it should be to move money safely, quickly and predictably?

When “good enough” stops being defensible

Most enterprise architects and IT operations leaders know this feeling well. The environment works. Payments clear, and fraud is caught. Reconciliation eventually balances. When something breaks, teams step in, fix it and move on. The system absorbs stress, and people compensate. And because the compensation works, the underlying issue stays invisible.

But “good enough” becomes much harder to defend when three pressures converge at once:

1. Payments volumes accelerate
2. Time-to-decision collapses
3. Accountability increases

That convergence is happening now, and it’s visible to regulators and customers.

Real-time rails like FedNow and real-time payments (RTP) aren’t just faster versions of existing processes. They eliminate the buffer zones — overnight windows, batch retries, manual intervention points — that legacy schedulers took advantage of for decades. At the same time, regulatory scrutiny and customer expectations have converged around one assumption: you know exactly where a payment is, why it failed and what you’re doing about it.

That assumption exposes a structural weakness many banks and financial institutions have learned to work around — but not fix.

The invisible complexity behind every transaction

A modern payment doesn’t move through a straight line. It fans out across fraud detection, compliance checks, routing decisions, settlement systems, reconciliation workflows, notification services and reporting pipelines. Many of those components have been modernized individually. Few have been modernized together.

Orchestration fills the gap.

Many teams still rely on a combination of legacy schedulers, custom scripts and tribal knowledge. It’s not elegant, but it’s familiar. And familiarity is powerful, especially when budgets are tight and priorities are visible elsewhere.

The problem is that technical debt compounds fast, and it’s sticky.

Outages that weren’t supposed to matter

In May 2025, a major outage at Fiserv disrupted payment services across multiple United States banks and credit unions. Zelle transfers stalled, and online banking features and ACH processing were affected. For customers, the experience was confusing. And for banks, it was clarifying. It was a failure of coordination, not innovation.

Similar stories have played out across industries. 

• Airlines grounded by systems that couldn’t reconcile real-time data flows: Hundreds of flights were canceled in 2022 when key IT systems went offline, revealing how critical poorly coordinated back-end layers can be.
• Cloud providers experiencing cascading outages because dependency logic behaved differently under load: A major AWS outage in 2025 rippled across global services when internal automation triggers weren’t sufficiently orchestrated, showing how even modern platforms can fail without resilient control layers. 

In each case, the visible platform was modern, but the control layer beneath it was not. These incidents are foreshocks, signaling the risk of a greater problem in the near future. They indicate architectural lag — that the desire for execution speed outpaced application and data orchestration maturity.

The operational resilience question no one wants to ask

Over the past several years, operational resilience has stopped being something IT teams manage behind the scenes and started becoming something boards are directly accountable for. Regulators now expect banks to demonstrate not just recovery plans but clear tolerance for disruption, while customers and markets punish even short-lived outages with lost trust. As a result, resilience is now a governance issue.

Here’s the uncomfortable question many organizations avoid: If a critical payment flow failed right now, could you trace its path end to end quickly enough to meet your obligations without assembling a war room?

Not in theory. Not eventually. But immediately, in real time.

Could you see which system made the last decision, which dependency stalled and which downstream processes were affected? Or would your teams jump between dashboards, logs and scripts to reconstruct the story after the fact?

If the answer feels uncertain, don’t blame capability. The failure is architectural. Operational resilience is proven in the moment of impact: when systems strain, dependencies collide and decisions must be made immediately. It depends on understanding how work actually flows and how systems behave together under stress, so breaks can be proactively identified and addressed in real time, not explained after the fact.

Why this matters now

For years, banks could afford to defer this problem. Latency masked fragility, and lots of manual effort absorbed uncertainty. Institutional knowledge filled the gaps, but that tolerance is disappearing.

Real-time payments have reduced recovery windows to seconds. AI-driven fraud models are introducing asynchronous decision points. And each new payment method and provider increases the number of routing paths. Customers, retail and corporate alike expect transparency when something goes wrong. In that environment, orchestration is a strategic capability rather than background plumbing.

Orchestration as the control plane

Being successful at modern payments orchestration means establishing a control plane that understands how payment flows behave across systems.

That includes:

• Event-driven execution instead of clock-based scheduling
• Dependency awareness that prevents cascade failures
• End-to-end visibility across payment journeys
• Governance and auditability built into execution, not layered on afterward

When orchestration evolves, your ecosystem behaves differently. Failures isolate instead of spread, and recovery is not some heroic moment. You regain your margins quicker than you would’ve thought possible in the worst-of-the-worst scenarios.

Modernizing your orchestration approach is also going to prepare your organization for executing on the AI use cases you’ll need to keep up in tomorrow’s financial services world. Learn how.

The risk (and opportunity) of waiting

The greatest risk in payments modernization today isn’t choosing the wrong platform. It’s assuming the operational foundation will keep holding. Most organizations don’t modernize orchestration because something breaks. They do it because the cost of not knowing what’s happening in their payment flows —and not being able to change them quickly — eventually exceeds the cost of change itself. When competitors can launch new payment experiences in weeks and you’re stuck doing it in quarters, the limitation isn’t strategy but orchestration.

Payments modernization is already a recognized growth lever. What’s often missed is where that growth actually comes from. It doesn’t come from new payment types alone, but from the ability to operationalize, deploy and scale them into production quickly and reliably. That capability lives in the underlying application and data pipeline orchestration. When plumbing is rigid, modernization becomes cosmetic rather than transformational.

This is why payments modernization succeeds or fails long before a new rail or service goes live. Real-time processing and richer payment data enable request-to-pay, embedded finance, merchant insights and cross-border optimization. None of these are possible without orchestration that can adapt payment flows quickly, route intelligently across providers and expose consistent data across the ecosystem. Modernization creates growth only when the plumbing underneath is built to move.

The banks that act now won’t be the ones chasing outages but the ones making payments boring again. And in financial services, boring is often the highest compliment. Find out more about how to modernize your payments processes.