The banking railroad of innovation: Follow the river

I'm a big fan of the old movie classics. The TMC channel was a loyal companion during my graduate school days at the University of Illinois, offering a comforting black and white backdrop to frequent all-day programming sessions, and today I frequently call on TMC to get me through my daily hour-long treadmill sessions.

This weekend TMC offered up Jimmy Stewart as railroad detective Grant McLaine in 1957's Night Passage. A classic Western, McLaine was fired in disgrace over a railroad robbery carried out by his estranged brother, only to be offered a second chance to prove his loyalty to the railroad by being the courier for a large cash payroll being sent to the workers at the rail head.

Grant's companion during the critical train ride to the rail head was young Joey. Riding with Grant on a flatbed car as the train twisted and turned through the Rocky Mountains, Joey asked Grant how the railroad builders knew the best route through the harsh terrain. This question gives Jimmy Stewart the rare opportunity to showcase his singing and accordion-playing skills as he responds by singing a song called "Follow The River". The song ends with the chorus:

"Follow the river,
Wherever you may be,
Follow the river back to me."

Just as the railroad builders used the river to guide the design and layout of the early railroads, bankers have used technology to guide how banking services are designed and built. In an interesting bit of historical irony, the first use of machine-based bank processing was being rolled out by the Bank of America just as Night Passage was hitting the movie theaters.

The system was called ERMA (Electronic Recording Method of Accounting), a machine-driven approach to electronically reading checks and processing the bank's accounts. ERMA was co-developed by Bank of America and the Stanford Research Institute, launched in 1958, and was able to process 50,000 accounts per day. While ERMA's initial capacity was small by today's standards, in those days, it represented an outlandish number in comparison with 10,000 accounts per monththat BOA estimated it could process using existing paper-based manual methods.

ERMA ushered in the era of Big Iron in banking (a term also used to describe railroad locomotives), as improvements in the speed and capacity of what we today call the mainframe computer facilitated the rapid growth of the large banks during the 1960s and 70s. Mainframe computers running programs powered by Rear Admiral Grace Hopper's newly developed Common Business Oriented Language (COBOL) became the river that banks followed when planning and building new banking systems like Electronic Payments (EFT), Electronic Tellers (ATM), and others to meet emerging customer demands.

Mainframe computers are interesting from operational processing perspective in that data (specifically customer accounts and daily transaction data) takes a while to load, but once loaded accounts can be processed at a lightning-fast rate. While ERMA could process only 50,000 accounts in a day, modern mainframes can process millions of accounts in a matter of a few hours. COBOL itself as a programming language was scorned nearly from Day One by the computer science cognoscentias a crude and unstructured way to build an enterprise system.

In 1975, a respected Dutch computer scientist named Edsger Dijkstra made the famous comment that: "With respect to COBOL you can really do only one of two things: fight the disease or pretend that it does not exist, " before concluding, "the use of COBOL cripples the mind; its teaching should therefore be regarded as a criminal offense." Despite the withering criticism from academia, mainframe vendors and banks moved forward on the basis that the systems simply worked. Throughput is the key to understanding how high-volume banking systems and today's railroad system works.

A case in point is the Canadian National railroad's purchase in 2007 of the Elgin, Joliet & Eastern Line (EJE) to facilitate its rail connection of parts east and west through Chicago. While the distrance from Gary, Indiana to Waukegan, Illinois is only 70 miles by car, CN now connects these points using EJE's 198 miles of track. This makes no apparent sense until you consider that CN is now able to route cross-country trains around the busy hub of Chicago, where previously CN endured a variety of operational restrictions and traffic jams arising from the many at-grade crossings through the congested urban core. To CN, routing traffic around Chicago rather than through Chicago resulted in more throughput and fewer train delays, more than compensating for the additional mileage.

And so it has gone for the banking processing. The use of oft-criticized COBOL and the unique operating characteristics of mainframe computers was tolerated as there were no other alternatives for banks requiring reliable processing at very high scale. That is, until recently.

Just as the river in Night Passage twisted and turned through the Rockies, the path of technological progress has twisted in an unexpected way to many bankers, as cloud services are now challenging the hegemony of mainframe-based banking systems. While a top of the line mainframe computer can be purchased with more than a 100 lightning fast processors, a bank can "rent" thousands, even tens of thousands, processors for 10 minutes, 10 days, or 10 years. Using software that is tuned to manage the distributed processing of bank accounts across thousands of virtual machines, banks can now meet and exceed the enormous throughput of their mainframe computers at a fraction of the cost.

The king of mainframe computing, IBM, clearly understands and has responded to the changing role of the mainframe in banking. During the 50th Anniversary celebration of the mainframe in 2014, IBM rolled out its new vision of the mainframe as an uber-sized cloud server, allowing for the hosting of several thousand virtual machines at one time. Last summer, IBM upped the ante with the annoucement of IBM LinuxONE Emperor, a z13-based server allowing for up to 8,000 virtual machines to be hosted on a single machine.

While banks have experimented with cloud services to varying degrees, most of the innovation has taken place at the channel services level, with new online and (particularly) mobile banking applications getting a technology refresh through the unique benefits of cloud services. While each bank will need to build its own business case for the gradual porting of COBOL-based account processing systems to modern programming languges that are "cloud-ready", it is clear that cloud-based account processing will allow the level of agility in product development that is increasingly called for as channel and payment systems continue to evolve.

Cloud-backed innovation in back office systems has been slow to develop, with many banks citing security and the fear of regulatory issues as inhibitors to adoption. As the recent two-part Celent report Banking in the Cloud: Between Rogues and Regulators establishes, regulators in fact do not have any objections to banks hosting their banking services in the cloud, provided that banks follow the same standard of care (including encryption, access controls, data masking, etc.) that they manage for in their own data center.

In time, I expect that the banking railroad will continue to follow the river of innovation that is now leading us directly into the age of cloud services. The proven yet inflexible COBOL-based systems that have served the industry reliably for 50 years will be replaced with agile and cloud ready account processing platforms that will over time both reduce costs and the drive service quality improvements that banks will need to compete and survive in the increasingly competitive world of financial services.