Varun Dudeja: How transaction consistency defines Southeast Asia’s payment modernisation

Payment infrastructure across Asia Pacific is expanding rapidly across multiple rails. Real-time domestic schemes, global card networks, account-to-account transfers, and cross-border systems are increasingly expected to operate in parallel, often within the same customer journey.

For many banks and fintechs, the first phase of payment modernisation focused on connectivity and customer-facing speed. APIs, faster payments, and new rails improved how transactions are initiated and routed. As volumes increase, the harder challenge is no longer access to rails, but whether transactions remain consistent once they move across fragmented systems.

In this editorial interview, Varun Dudeja, Vice President for Southeast Asia at Pismo, outlines where multi-rail environments begin to break down, and why the next phase of payment modernisation in APAC will depend less on connectivity and more on how transaction state is managed end-to-end.

Transaction consistency breaks before routing does

As banks and fintechs expand across cards, account-to-account systems, wallets, and cross-border rails, the industry often treats connectivity as the primary milestone. Yet operational failures tend to appear after a transaction has already been routed. In practice, why does transaction consistency break before routing does, and what does that reveal about how institutions are managing balances, authorisation, and settlement across fragmented systems?

Varun Dudeja: The most underestimated point of complexity in multi-rail environments is how transaction state is managed as it moves across rails. Many banks successfully connect cards, account-to-account transfers, wallets, and cross-border systems, but continue to manage balances, authorisation, clearing, and settlement logic in silos. The first thing that breaks is not routing; it is transaction consistency.

This shows up when institutions cannot maintain a single, real-time view of a customer’s balance and transaction status across rails. Failures surface quickly as delayed refunds, broken reversals, duplicated debits, or customers seeing one balance while downstream systems reflect another. Each rail updates state differently, often asynchronously, and most legacy cores were never designed to resolve these differences in real time.

As volumes increase and products span multiple rails, batch reconciliation and after-the-fact corrections stop scaling. At that point, operational risk and customer dissatisfaction can increase significantly.

Reconciliation still exposes structural fragmentation

Reconciliation, liquidity, and data consistency are often cited as key friction points in modern payment environments. Even with infrastructure upgrades and faster rails, reconciliation remains difficult to stabilise. Why does this persist, and what does it indicate about how transaction data is managed across systems?

Varun Dudeja: Reconciliation is often one of the more challenging areas to stabilise, even as institutions modernise their infrastructure. The reason is that reconciliation exposes a deeper structural issue: whether systems share a consistent view of transaction state across the lifecycle. When that view is fragmented, reconciliation becomes complex regardless of how it is ultimately performed—by the platform, the bank, or downstream functions.

In multi-rail environments, each rail produces its own representation of a transaction, often with different timestamps, lifecycle events, and settlement rules. Infrastructure modernisation improves connectivity and speed, but it does not automatically resolve the fact that transaction state may still be created and updated in multiple places. Many institutions, therefore, continue to rely on batch reconciliation layered on top of real-time flows, introducing timing gaps and operational friction. Modernising infrastructure is more than just using new programming languages. It means rethinking processes.

Liquidity management is evolving as treasuries adapt to faster settlement, and data consistency is improving with standardisation efforts. Reconciliation, however, sits across both. It requires balances, postings, and customer-facing positions to remain aligned at all times—not just at reporting cutoffs.

Institutions that make sustained progress focus less on who performs reconciliation and more on establishing a single source of transactional truth. When authorisation, posting, and settlement are anchored to a shared, real-time ledger, reconciliation becomes a validation exercise rather than a repair process. Without that foundation, reconciliation remains difficult even after significant modernisation.

Orchestration increases flexibility, but not always control

Many institutions introduce orchestration layers to manage multiple payment rails more efficiently. These systems improve routing decisions and flexibility, but they do not always translate into stronger operational control. What trade-offs typically emerge when orchestration is layered on top of fragmented systems?

Varun Dudeja: The key trade-off emerges when orchestration is treated as a routing abstraction without a shared transactional core. Orchestration delivers flexibility by dynamically selecting rails based on cost, speed, or geography, but when underlying systems maintain their own balances and state, that flexibility comes at the expense of control.

Practically, this reduces operational clarity. Transactions may be routed intelligently, yet their state is updated inconsistently across systems, making exceptions harder to trace and controls harder to enforce. Orchestration determines where a transaction goes, but not reliably how its state is maintained end-to-end—this is where resilience begins to erode.

Speed–governance tradeoffs also emerge. Modular, API-driven designs accelerate launches, but without a shared ledger, risk controls and data consistency are enforced unevenly across rails, leading to operational fragility.

Institutions that strike the balance treat orchestration as a coordination layer anchored to a single transactional system. Routing remains flexible, while authorisation, posting, and balance management are enforced centrally, enabling innovation and resilience to scale together in APAC’s multi-rail environments.

Selective modernisation is not the same as operational readiness

Across APAC, many institutions have already adopted APIs, real-time payment capabilities, and cloud-based infrastructure as part of broader payment modernisation efforts. Yet these upgrades do not always produce the same operational outcome. Some organisations become faster and more resilient as they add new rails, while others continue to struggle with fragmented controls, inconsistent balances, and heavy reconciliation burdens underneath. What separates institutions that are genuinely ready for multi-rail operations from those that have modernised only parts of their stack, such as Buut (a cloud-native fintech) and Citi (a large-scale global bank)?

Varun Dudeja: The real separator is not the presence of modern components, but whether institutions have aligned their infrastructure and operating models around a consistent, end-to-end transaction lifecycle. Organisations that are genuinely ready for multi-rail operations ensure that authorisation, posting, and balances are updated consistently across rails, with clear ownership and visibility as transactions move through the system.

Many organisations modernise selectively. They may add API gateways, enable real-time rails, or move parts of the stack to the cloud, while transaction state and balances remain spread across multiple systems. That is where execution begins to diverge.

The Buut implementation reflects how a modular, cloud-native environment reduces dependence on monolithic core changes. The shift is not just architectural. Product teams can move faster because new capabilities can be introduced through modular services rather than through heavier core rework. In this case, the debit card was launched in 10 weeks.

Citi points to a different operational challenge. Its modernisation work on corporate demand deposit accounts is less about launch speed and more about supporting always-on payment services at scale. The issue there is maintaining accuracy, consistency, and resilience across geographies and regulatory environments while reducing dependence on batch-era operating assumptions.

A key differentiator is how transaction data is governed. More mature institutions treat transaction state as a shared operational asset rather than a rail-specific artefact. This enables consistent controls, clearer accountability, and faster exception resolution. Others continue to rely on downstream reconciliation to bridge gaps between systems.

Cross-border scale is still constrained by institutional alignment

Cross-border real-time payment connectivity is advancing through standards such as ISO 20022 and API integration. However, scaling interoperability across markets remains uneven. What are the main constraints today, and where does progress tend to stall?

Varun Dudeja: Interoperability constraints span technical, operational, and institutional dimensions, but institutional alignment is often the most difficult to address. Technically, progress has been made through standards such as ISO 20022 and API based integration, yet implementation remains uneven across markets.

Operationally, differences in settlement models, liquidity approaches, dispute handling, and definitions of payment finality complicate real-time cross-border flows. These mismatches create friction even when the underlying technology is capable.

The largest constraint is institutional. Cross-border connectivity requires coordination among central banks, regulators, and payment system operators. FX controls, compliance requirements, and data localisation policies can slow or constrain integration.

In APAC, early bilateral and regional linkages demonstrate what is possible, but scaling across more jurisdictions introduces exponential complexity. Interoperability is ultimately a multi-stakeholder challenge, not simply a technical one.

Connectivity scaled first—control determines who can sustain it

Payment infrastructure across APAC has expanded faster in routing, access, and speed than in the systems governing transaction state underneath. Institutions have added rails and reduced latency, but many still rely on fragmented balances, posting, and settlement logic once transactions begin moving across those systems.

This is where the next constraint sits. More rails increase flexibility, but they also increase the number of systems updating a transaction. When balances, authorisation, and settlement are still managed in silos, maintaining consistency becomes harder at scale. The failures that surface—delayed refunds, duplicated debits, mismatched balances—are not isolated issues. They reflect fragmented transaction control.

Reconciliation and orchestration are often used to manage this complexity, but neither resolves it at the source. Reconciliation becomes more complex because it compensates for inconsistencies in transaction state. Orchestration improves routing decisions but does not enforce end-to-end transaction recording and updating. Both approaches adapt around fragmentation rather than removing it.

The more meaningful distinction is not between legacy and modern infrastructure, but between fragmented and unified transaction control. Institutions that treat transaction state as a shared operational layer are better placed to scale across rails without turning growth into operational friction. Those who continue to manage it within individual systems will keep pushing complexity downstream.