Markets Open
Global Markets
S&P 500 7,521.2 ▲ +0.2% DOW 52,384.11 ▲ +0.3% NASDAQ 25,839.64 ▲ +0.0% RUSSELL 2K 2,970 ▼ -0.6% VIX 16.91 ▼ -0.8% GOLD 4,165.5 ▲ +2.3% CRUDE OIL 86.2 ▲ +1.5% EUR/USD 1.14 ▼ -0.0% BTC 65,987 ▼ -1.0% ETH 1,943.17 ▲ +0.7%
Fintech

Banks urged to add intelligence to B2B payment routing

Infosys product manager Sunny Bhat says routing alone cannot address failed payments, legacy fragmentation and last-mile delays in B2B transfers.

Rafael Ortiz

By Rafael Ortiz · Fintech Correspondent

· 3 min read

Banks need to move beyond rail selection in B2B payment orchestration if they want to cut failed transfers and network rejections, according to Sunny Bhat, senior manager for product management at Infosys. In a Finextra opinion piece, Bhat said SWIFT data indicates the domestic “last mile” after a cross-border payment reaches the beneficiary bank can account for around 80% of total processing time.

The argument reflects a broader shift in bank payment technology as instant payments and ISO 20022 change the volume, speed and structure of data carried through payment systems. Bhat said orchestration that only identifies the lowest-cost, fastest or most suitable payment rail has become too narrow for modern B2B flows.

Routing solves only one layer of the process

Payment orchestration first developed around routing and failover: choosing a network based on factors such as the receiving bank’s relationships, cost or expected arrival time. That approach helped banks improve delivery choices, but Bhat said payments can still fail after validation and route selection have been completed.

He distinguished B2B payment orchestration from merchant payment orchestration. In card and checkout environments, orchestration is mainly concerned with payment service provider routing, retries and authorisation performance. B2B payments face additional steps before an instruction reaches a network, including scheme and bank validations, alias resolution, fraud and anti-money laundering checks, and reachability tests for intermediaries.

Receiving banks must also perform due diligence before accepting funds, while local regulation, market practice, scheme rules and data requirements can affect whether a payment completes. Bhat said these checks have to take place within service-level agreements set by payment schemes to avoid cancellations or reversals.

Legacy systems remain a constraint

Bhat identified fragmentation across bank technology as a central barrier. He said banks have accumulated multiple technology stacks, gateways and payment hubs through successive programmes, creating inconsistencies across channels, engines, data, operations and schemes.

That fragmentation can mean that a payment with the same underlying intent and data is handled through different validations, failure points and controls. Bhat cited a Payments Dive report on a Federal Reserve update that said around 1,800 financial institutions had joined the FedNow network, while many remained “receive-only”. He said the example showed that connecting to a new payment rail differs from building full sending capability, which requires additional interactions and validations.

Rule-based processing is another weakness, according to Bhat. Payment hubs often use fixed rules to determine what happens in specific scenarios. When the same scenario repeats, the same outcome can recur, including the same failure. Operations teams then have to address cases in repair queues.

Bhat said no bank can document every possible payment scenario, and limited rule libraries or incomplete data can push exceptions into manual investigation. Incorrect manual repair can add risk, while repeated failures can damage corporate customer experience when earlier errors reappear in later transactions.

Intelligence proposed before execution

Bhat said the next phase of B2B payment orchestration should place intelligence before the execution layer. In his view, orchestration systems should identify data gaps, check data quality and run pre-validations before instructions reach downstream engines that may be constrained by legacy architecture.

He said richer decisioning could use payment history, corridor performance, beneficiary validation requirements, service-level data, scheme performance at peak times and low-trust data signals. Feedback loops could help banks learn from prior failures and support recommendations or controlled updates where automation is permitted.

Bhat also said orchestration services could check customer limits and bank liquidity in real time before payment release. Where settlement funds or thresholds are constrained, he said systems could throttle payments to reduce settlement-failure risk.

Governance remains necessary, Bhat added, because any added or changed data field can affect processing, investigations and payment outcomes. He said banks should set policies based on the risk profile of orchestration recommendations and reserve human intervention for cases requiring judgment.

This story draws on original reporting from Finextra Research.

More from Fintech

All Fintech →