Skip to content
Home » FinTech’s Foundations COBOL

FinTech’s Foundations COBOL

A very interesting article from the Wall Street Journal confirmed to me what I had always suspected, in terms of the technology all banking is still based on, COBOL (at least on the banking side of things).

The world of banking is very risk averse when it comes to technology. There are backups to all systems, multiple power sources every system must live up to “5 9’s” availability. This means the system is up 99.99999 % of the time. As the Canadian Feds found out changing out an old system and replacing it with new code and technology is problematic (aka Phoenix), thus most Banks are reluctant to do whole sale changes just to update technology. Old systems get replaced typically if they are broken, not if they are still working.

At the core of the banking system in terms of technology is a language older than me (and I am old). COBOL (COmmon Business-Oriented Language) was written in 1959 based on the works of Admiral Grace Hopper. I worked in it, at school and on the job as well (at school I used WATBOL), so I have a passing understanding of the language. It does, what it does, well.

FinTech continues to crow about it being new and exciting, and parts of it might be (the user interface is my guess), however the heavy lifting (i.e. account creation, asset moves, etc.,) is all still being done capably by COBOL.

A COBOL Punched Card

Fear and Loathing

Is it time to fear FinTech? You should be skeptical of all the claims, but if the system works (for you), that is the major decision point. If someone tells you how it is the future of banking, ask them about how they interface to the banking COBOL interface (see if they have an answer for you).

I am glad to see that old technology still keeps the world humming. Also, the finance world is so Risk Averse they won’t change to new technologies quickly either.

Some say COBOL programmers are like cicadas, they come back every 20 years or so.

EQ Bank

Feel Free to Comment

  1. First thing about the Phoenix debacle… You NEVER put in a new system and just run it and kill the old system. you run BOTH systems side by side, preferably for a full year or more to ensure that when Fred is supposed to get paid $2500 per month then dammit he gets paid the $2500 per month according to BOTH systems.
    One is constantly compared to the other to ensure that what Fred is supposed to get is what Fred is supposed to get. If there is a discrepancy, then you go through the system to find out why! The new system doe not go LIVE until the faults are worked out. This Phoenix thing was a complete screwup from day one with people not getting paid, or getting too much, or for the rare few just the right amount! Someone should have gotten fired over this at a high level, and many in the mid to lew levels in the company that owns the Phoenix software.

    1. I’d love to kibitz on this one, but since what you said is correct, no point. My understanding from my sources, no one was fired, no contracts cancelled, no consequences other than employees with no pay, double pay, wrong pay, and no yearly reports about pay or pension to employees.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this:
Verified by MonsterInsights