In today’s business world, Enterprise Iron is engaged in multiple client conversations about system modernization, and updating of systems to take full advantage of modern technology platforms. What has brought us to this point? Let’s look back at the history of our industry in this area of technology.
The year was 1984, and a young man had just graduated from college. He sought a place to put his new degree to work and landed at a small recordkeeping shop. This company had recently acquired another with a system and was currently consolidating the operations of the two firms.
Section 401(k) of the IRS code was only a few years old, and the first 401(k) plan had been in existence for about four years. In that brief period, the concept of a pretax savings vehicle had already started to catch on as almost half of all large companies had begun to offer these plans.¹
It was an exciting time to be a part of a revolution in the retirement plans industry as a change was suddenly everywhere. This small outsourced recordkeeper realized there was a market for licensing their system so that plan providers could offer a broad array of their services. This company grew to become one of the dominant players in our industry through visionary leadership, and the Omni platform was born.
Through the years, there have been other systems, most notably the TRAC system owned by SS&C (formerly DST). TRAC was initially built as an accommodation for mutual fund clients who wanted to offer retirement plans. Around 2007, DST decided that this retirement business could be a winner and seriously invested in the team and technology. The origins of the DST system, upon which TRAC was built, date back to the late ’60s. Many updates were applied to the system before TRAC was “spun off” to create a retirement-specific platform, but still…
Why does this matter?
So why all this talk about 1984 and the late ’60s in 2021? Interestingly, the financial services industry has been slow to modernize the core, back-end accounting and recordkeeping systems that process trillions of dollars of activity every day. COBOL and other “out of date” languages like Assembler (BAL) are still utilized – because they work! Even in 2021, they are efficient and secure processing engines because our business is large-scale. Payroll processes that can include millions of participant updates nightly require large, efficient engines to meet the trading windows required for our plans.
Census data updates, conversion of plans from one provider to another, and tax form processing at year-end stress our systems. The Legacy languages have been effective for decades, and companies are slow to change something that works efficiently. The adage of “If it ain’t broke, don’t fix it” is never truer than with today’s financial services firms. There are remnants of these antiquated systems that are still in use to some degree in some of the major recordkeepers across our industry.
A study performed by Reuters during the height of the pandemic found that 43% of all banking systems are COBOL-based, and a staggering 95% of all ATM swipes rely on COBOL code to varying degrees.² Given these facts, why have we not seen a technology disrupter create a modern platform to compete with these major players? Our industry has seen multiple firms enter the market with promise, but most either focus on a particular market or have flamed out trying to become relevant. The retirement business is one of great complexity, and continually changing regulatory requirements, that need scale to be profitable. Simply put, it’s just hard to break into this market. However, we are encouraged by some of what we are seeing in our industry today.
What approaches are firms taking?
At its core, COBOL is still relatively secure. However, there are several reasons why firms are looking at modernization. First, the supply of knowledgeable COBOL developers is dwindling as colleges and universities no longer teach the language. COBOL also runs largely on big mainframe systems that are incredibly costly to maintain.³
For years, many firms have taken the approach of not touching the core engines but have sought to minimize the impact on end-users by creating ancillary technologies that provide a buffer. As well-intentioned as these approaches may be, we created vulnerabilities that can be exploited by others who have nefarious plans and desires. This approach usually requires additional databases that can often become out of sync, resulting in incorrect calculations and reporting. What of the security of those databases? One only needs to scroll through their favorite financial news website on any given day to hear of another data hack and security breach.
What’s next?
Today, firms are starting to “rip off the bandage” and migrate their COBOL-based core applications to modern technology platforms. This promises to be an endeavor that is as expensive, complex, and risky as the Y2K transformation. Recently, both FIS (Omni) and SS&C (TRAC) have announced major initiatives to modernize their platforms. This involves bringing forward large, COBOL-based, mainframe systems into current technologies.
There are multiple approaches to COBOL modernization being employed by firms today. These approaches have their benefits and downsides. The first approach is a manual, line-by-line conversion. An army of consultants can migrate COBOL code to modern technology, such as Java or Python, but it can be costly and resource-intensive.
This approach often results in Java code that remains structured like the procedural COBOL code it replaces and does not take advantage of the features of the newer technology platforms. The second approach to address these concerns is to use a conversion tool to automate some portion of the code. Typically, these automation tools fall short of a complete translation but can get the code much closer to being fully translated. However, in many such cases, the translation tool creates a vendor lock-in requiring an ongoing license (and associated excessive fees) to use the vendor’s APIs or platform to use, manage, or enhance the resulting translated code. In addition, every translated COBOL statement in this model becomes an API call, which is not a preferred methodology.
For more information on Enterprise Iron’s approach to modernization, please contact us to discuss our services.
>>> You might ask whatever happened to our young 1984 college graduate… he has spent 37 years in the retirement industry helping clients transform their recordkeeping environments and now gets to work with clients who are going through their modernization journeys.
¹401(k) Basics: When It Was Invented and How It Works | Northwestern Mutual ²COBOL blues, www.thomsonreuters.com ³COBOL Modernization, www.resqsoft.com
