On August 18 I wrote an article in response to Joe Firestone, the author of an EBook titled “Austerity, Greece’s Debt Crisis and the Theft of Democracy” that had a chapter on the IT problems of a Grexit, which addressed earlier articles I had written.
Yesterday someone brought my attention to a follow-up on his blog (http://neweconomicperspectives.org/2015/08/on-the-it-problem-of-grexit-a-reply.html) that once again tries to strike a balance between Australian economist Billy Mitchell’s blithe assurance that the IT problems are minimal and my own insistence that it will be at least a three year effort to modify the systems. This will be a brief response to Firestone’s latest.
Firestone maintains that he is only for studying and evaluating some approaches. He also favors a phased implementation, something that is put forward concisely in a comment he made under his article:
- The mainframe application is undoubtedly very complex so there is a good possibility that Louis is right and the mainframe conversion to Drachma processing cannot be accomplished in the short time necessary for Grexit
- So, if we want to support a Grexit that may be necessary in the short term, then we must find a way to get around the need to convert the mainframe application in the short-term
- The two possibilities I suggest in my book deserve discussion as possible ways to avoid immediate conversion of the mainframe application and to have to deal with the complexities of the interaction between humans and the mainframe inherent in the operation of the application in the real world
This assumes that you can hold off converting “the mainframe application” for the future but that’s not the way that banking systems are put together as if they were Lego toys made up of discrete modules that can be assembled in phases.
Think of it this way. When you open a checking account, you sit at the desk of some bank officer who begins entering your information into a computer, starting with name, address, social security number, etc. He or she then issues you a temporary ATM card that can be used immediately for deposits and withdrawals.
In the ensuing months, customers might take out a credit card from the bank and afterwards a mortgage and/or an auto loan. And each month they expect a statement that will have an accurate record of their transactions, both debits and credits. I am sure everybody is accustomed to this unless they are used to keeping cash under a mattress.
The implicit assumption (bordering on explicit) in both Mitchell and Firestone’s presentation of the problem is that such a “phase” is essential to moving to a drachma. I can certainly understand why someone might think in those terms because that is generally how we relate to a bank—as a customer. I should add that the applications that handle such relationships are generally referred to as belonging to the “front office”.
Unfortunately, most “back office” operations must be converted on the very day that you implement a new front office based on a drachma since they are designed to support the managers and clerks who are invisible to the customer but critical to bank operations.
For example, the accounting department of a bank is fed data aggregated on a daily basis from various sources in order to populate a General Ledger, which is the source of profit and loss statements and other essential reports for treasurers, auditors and the like. Your deposits and withdrawals are lumped together with those of other customers and end up in buckets identified by a unique General Ledger Account Number, one of which might reflect Mortgages. Needless to say, knowing how much is owed to the bank in this category is essential to a bank based on the 2008 financial crisis.
So if the accounting software is still denominated in euros, what are you supposed to do? Use these for a couple of years until the next phase kicks in?
This does not begin to address the problem of being able to rely on accounting systems once they are converted to handle the drachma. Banks have historical data that is used to generate reports that reflect financial trends. Since 2003, data has been captured as euro-denominated. If you want to study how the mortgage business has been faring over a ten-year period, you need to write conversion software to update computer files going back to the day Greece switched from the drachma to the euro. You also need to make sure that all back-office applications are checked for hard-coded tests for a euro amount, as I have pointed out a number of times.
I know that most of my readers and those who have seen my posts on Naked Capitalism care little about the financial analysis conducted by bank officers in order to make business decisions but as long as Greece remains capitalist, that is the name of the game. This is not a problem limited to banks. It applies as well to insurance companies, brokerage houses, manufacturers, and any other large-scale capitalist enterprise.
Now it is entirely possible that at some point Greece might elect the candidates of the new Popular Unity party that is a leftwing split from Syriza and that is committed to a Grexit, at least if you take them at their word. They may consider the conversion to a drachma to be cost-justified even if it entails the wrenching IT modifications needed to make it work. While I am obviously sympathetic to resisting austerity, I cannot help but wonder if the answer lies solely in the type of currency used. I plan to write a series of articles about Greece that deals with the economic problems in general and hope that by that time the IT questions will no longer need to be discussed since in the final analysis they are secondary to the political ones.