Skip to content

Built-In Obsolescence in Legacy Payment Processing

built in obsolescence
Click Play to LISTEN

As I noted in a previous blog post, the legacy payments processing systems currently used by many financial institutions (FIs) are notoriously slow, inflexible, and out of sync with today’s market needs. The underlying technology was built decades ago and never designed for contemporary market realities.

This fact was highlighted recently in a post in Chris Skinner’s blog, which stated that most of the systems presently used by FIs “are written in programming language that no one knows anymore.” Specifically, Skinner pointed to an article revealing that 43 percent of US banks’ core systems are written in an old programming language called COBOL.

60-Year-Old COBOL Prevalent in Financial Systems

As background, COBOL (which stands for Common Business-Oriented Language) was developed nearly 60 years ago and has been gradually replaced by newer, more versatile languages such as Java, C, and Python. Despite the fact that few universities still offer COBOL courses, the language remains crucial to businesses around the world because it underpins powerful systems that were built in the 70s or 80s and never fully replaced.

COBOL plays a particularly critical role in the financial industry, where an estimated $3 trillion in daily commerce flows through COBOL systems. The language supports deposit accounts, check-clearing services, card networks, ATMs, mortgage servicing, loan ledgers, and other services.

Also, given the industry’s aggressive push into digital banking and mobile payments with apps and other new tools written in modern languages, there needs to be seamless interaction with these old, underlying systems.

If You Break It, Who Will Come?

Here’s the problem: if changes need to be made to get a new product or feature to market quickly, or if something goes wrong (and with older payment processing systems, maintenance is always an issue), there are fewer and fewer people in the workforce who know how to fix these systems.

Because COBOL was written so long ago, the population of banking technology professionals fluent in it is dwindling as more of them retire. Inevitably, a generation of COBOL experts will be gone. This fact must certainly be unsettling for FIs, especially with a Computerworld survey revealing that 71% of businesses will rely on COBOL at least through 2023.

Dependency on legacy card processing technology poses a real risk to FIs fighting to win in a rapidly changing market defined by increasing competition and high expectations of current and prospective customers.

Agile Payments Processing is the Answer

The issue has not gone unnoticed by payments executives.

According to the Bank Innovation Readiness Index survey findings released last month, 70 percent of FIs with a flexible IT infrastructure said that their recent innovations were extremely successful, which was more than twice the average. And in an i2c survey conducted with the advisory firm Celent, 41 percent of payments executives felt constrained by their legacy processor to create and deliver differentiated products.

Issuers are faced with a choice: either manage your business to the constraints of outdated legacy payments platforms and sacrifice time-to-market and the ability to roll out products that meet customers’ expectations, or turn to a better, modern payments processing technology that gives them the tools to respond to changing market needs and deliver their payments roadmap vision.

This solution is what lies at the heart of i2c‘s vision for the payments industry. Our Agile Processing platform eliminates the reliance on outmoded technologies – and the coding and maintenance required. Issuers gain a flexible, reliable platform that allows them to quickly design, test, and scale innovative payments features and offerings unique to their business.

Visit our Resource Kit to learn more about i2c’s Agile Processing platform.

Want to learn more about i2c?

Enhance credit decision-making and drive strategic initiatives with i2c.

Contact Us