IBM partner sets out phased route for bank card core modernisation

Srini Bala, partner and industry leader at IBM, has argued that tier-one banks should avoid wholesale replacements of legacy credit and debit card platforms and instead move functions in stages to modular, cloud-native services. In an external opinion published by Finextra, Bala said the approach could reduce the operational risk, latency and cost pressures tied to decades-old mainframe-based card systems.

Bala described card platforms as both a major revenue component for global retail banks and a constraint on product development. He said many payment operations still depend on older software packages with proprietary data structures and tightly linked functions, including account ledgers, fees and rewards.

That structure, according to Bala, can make it difficult for banks to introduce products such as variable credit limits, point-of-sale buy-now-pay-later features and more tailored rewards. Banks often add middleware around older platforms to support newer services, he said, but those layers can add maintenance burden, processing delay and operating risk.

Bala said a full migration to a new card core can also create problems for large institutions, including long implementation schedules, budget pressure and downtime risk. He presented the Strangler Fig application pattern as an alternative, in which a bank places new technology around the old core and redirects selected activity to modern services over time.

How the phased model works

Under the model described by Bala, the first step is to insert an API gateway or routing layer between payment networks such as Visa and Mastercard and the existing card core. That layer can receive authorisation requests and allow fraud screening or ledger checks to run in parallel systems without immediate changes to the core platform.

The next step is to separate functions that require faster product change but do not control the main balance ledger. Bala identified rewards and loyalty as a common early candidate for migration to a cloud microservice, followed by fee calculation and billing functions.

The final phase involves running a new ledger alongside the existing one. Bala said banks can place new card products or selected customer groups, such as digital-only portfolios, on the modern ledger first, while moving existing accounts in smaller batches to limit exposure.

Latency remains a constraint

Bala also warned that distributed systems create a technical issue for card payments: network latency. Payment authorisations must be completed within tight double-digit millisecond windows, he said. A design that requires several consecutive API calls across databases to assess account status, fraud risk and available balance can cause a transaction to time out.

To address that, Bala said banks should use asynchronous, event-based architectures, distributed caching and event streaming tools such as Apache Kafka. In the design he outlined, transaction data including balances and risk profiles is copied to fast in-memory data grids close to the network edge.

When an authorisation request arrives, the edge system can make a decision using the cached information and then publish the transaction event to update the system of record. Bala said this lets banks preserve low-latency decisioning while moving selected processing away from monolithic card cores.

Finextra identified the piece as external author content and said it was published without editing and represented the author’s views.

This story draws on original reporting from Finextra Research.