ELECTRONIC DATA PROCESSING IN BANKS 
By Ralph C. Boyer

 r

When banks moved into processing their deposit account work with computers, the majority went with using the MICR (Magnetic Ink Character Recognition) printing that we began printing on the bottom of the checks and deposits. For the first time customers were required to buy personalized checks with their names and their account numbers imprinted on their checks and deposit tickets.

          There were a lot of problems with pre-encoded items. For the customer service people in the banks there was the job of selling checks. Customers were accustomed to just asking for a pad of checks and that is what they got. Suddenly the bank was requiring customers to actually buy checks and regardless of how neat we tried to make it sound that the checks were personalized and errors were reduced, the idea of purchasing something that had always been free was traumatic for the majority of customers.

          There was also the change to something with which people were not accustomed. Customers went to the bank, took a deposit slip from the counter, completed it and made their deposit. A few smart guys went into some banks and put some of their personalized deposit tickets into the racks on the tables. Customers would unknowingly take one of the preprinted deposit slips, complete it and put their funds in someone else’s account.

          Word got out that a tiny pin hole through a MICR number on the check could delay posting for several day while the bank dealt with the check as an exception item. Frequently, it was not necessary for the customer to make the pinhole because MICR printing was so haphazard in the early stages that the result of the printing was not dependable.

          In the beginning, the overall rate of MICR rejection was well over 40%. It just did not go smoothly for a significant period of time.

AN ALTERNATIVE SOLUTION

          Valley National Bank of Arizona and City National Bank of New York chose a different approach to entering the electronic data processing of demand deposits and savings deposits. The high rate of MICR failure was causing untold customer relations  problems for banks. These two banks were known for their superior customer care and wanted to avoid the hassle other banks were experiencing. The solution was expensive but the banks felt justified in bearing the expense to preserve customer satisfaction.

          Each bank purchased specialized equipment from a Belgium company to use for processing checks and deposits without using the magnetic ink printed directly on checks. The system required only that the customer write his account number on the check or deposit slip. Valley National Bank was able to encourage the practice by providing each customer with a medallion in the form of the bank’s logo, which was a spread eagle on an octagonal background. The wings spanned beyond the background. On the medallion, the customer’s account number was imprinted. Customers were proud of those medallions and they became very conscientious about using the number of their items.

          All banks process their work through some kind of proof machine to make sure the debits equal the credits. A deposit ticket has to be supported by checks and cash in tickets equivalent to the amount being deposited. The process using the Belgian equipment began with such a process. When the items were entered into the proof machine function, each items was mechanically inserted into a plastic jacket. Across the face of the jacket was a magnetic tape strip, just like that to which a tape recorder can read and write. The accumulated jackets could be sorted magnetically in a similar manner as Hollerith cards had been sorted by mechanical data processing equipment.

          The internal items were sorted and separated from the external items, such as checks drawn on other banks, and captured for input into the computer system. After capture, the jackets were removed to other equipment called Unjacketers, where all the items were removed. The internal items were sent to the branches to be filed and the external items were sent with cash letters to correspondent banks or the Federal Reserve Bank for credit.

COMPUTERS

          General Electric built a building on the southwest corner of Thunderbird Road and I-17, where they started building computers. Valley National Bank always tried to do business at home so when it came time to get into electronic data processing, GE got the business. The first computer was designated the 210.

          I never programmed the 210 or it’s successor, the 415 but eventually learned a little about them. I believe they had their own programming language which was some form of assembly language. The word “byte” had not yet come into existence. General Electric computers were “word” machines.

          A word consisted of four characters. Efficient programmers strived to work in units of four to preserve precious memory. Commands such as “save” and “copy” could be very efficient. If you had to resort to a field like zip code, you lost the use of three quarters of a word. For example, 85303 use up two words with four characters (8530) in the first word, one (3) in the second word and the remaining characters of the second word lost. If it was possible to combine the state code with the zip code, efficiency could  be restored. For example again, AZ 85303 would use two words if combined. “AZ_8” would use the first word and “5303” would use the second word.

Computer Programming

          I ran into a friend named Ed one day. Ed had been working on a special project of some kind for a few months. The year was 1966.

Ed had been a branch operations officer.  When I met him in the hall, he told me he was going to become a computer programmer. That intrigued me because I had wanted to be a computer programmer.  I started to take a class in programming at Arizona State University but it started out with wiring circuit boards, a dying practice, and I decided I could better utilize my time with something else. Ed said management had decided to choose three operations officers and train them to be computer programmers. The idea was that it was easier to teach bankers to be programmers,  than it was to teach programmers to be bankers.  He said another operations office, Tom, had been selected to take part in the program also but as far as he knew a third man had not been selected.  Off I went to the Personnel Department.

I found the usual guy I hassled about such things and told him I had talked to Ed and wanted to be the guy number three.  He showed his usual excitement and said they wanted operations officers. I said try it. He called them. They said that if I could pass the test they would consider me.

I went to the Customer Service Department where the newly trained programmers would work and they gave me the test. The test was a breeze. It was the kind of test where you had to reason out sequences. It was logic. When I was in the seventh and eighth grades we had to take the same kind of tests, among others. We were going from a school with 150 students to a school with 5,300 students. It was like going to a university and we were told that, at this early point in our lives, we had to decide what our life’s work would be. Sounded okay to us, but what did we know.

So they gave us a battery of tests. My results were mixed. I was told I had all the logic required to be an engineer but all the math skills required to be a professional chimpanzee.

Well, I was a lot better at math at this time, thanks to Albert Qually, a math professor at Arizona State.  That, along with the long time logic ability I possessed, I passed the test with flying colors and was soon informed that I had been selected to participate in this experiment.

PROGRAMMING SCHOOL

The IBM System/360 Model 30, had been ordered for my new department and was in the process of being installed. It was called a third generation computer and was designed by a second generation computer and beyond the understanding of mere mortals.  At least that is what they claimed.  Ed got delayed in starting but Tom and I went to IBM’s school. It wasn’t long before we were more than willing to accept the premise that this computer was beyond the understanding of mere mortals, and bankers as well.

A woman from Los Angeles came to Phoenix to hold classes for us. She tried, and not only did Tom and I have a hard time, but those who had past experience, had a hard time understanding.  We were in class for six weeks.  The first two weeks “taught” us basic computing for the 360.  The next two weeks “taught” us assembly language programming. The final two weeks “taught” us I/O – Input/ Output.  We didn’t feel like we had been taught anything, and if we were, we didn’t learn anything.  Our instructor was obviously frustrated. We agreed that the situation was hopeless.

We had been hinting to management that things weren’t going well but they kept saying, “Don’t worry about it”.  I did worry about it.

We went in the Monday following the completion of our training and I had a bad case of the dreads.  We were convinced we just weren’t going to be able to handle this work.

A COBOL SHOP

          There is a computer programming language called COBOL, which is an abbreviation for COmmon Business Oriented Language. Assembly Language, which we had been “exposed to” at school is more than difficult and just one level above “machine language” which is written by no one, except possibly second generation computers. At the time I became a programmer, some work had to be written in Assembly Language and we had a couple of experts that took care of that kind of work.  We were told that our department was a “COBOL shop”.  We were also told the department had Programmed Instruction manuals for us to use to learn IBM COBOL and the department also had some very experienced COBOL programmers that could help us.

THE COMPUTER – IBM SYSTEM/360

          Before we get into that, I need to describe our new computer.  It had huge metal boxes stuffed with electronics and that could fill a couple of good sized rooms.  We had one printer, very high speed.  We had five tape drives, four 7 track and one 9 track, virtually obsolete now, and slow.  We had two disk drives, a new creation.  It was essentially what we all have for hard drives in our computers now, only much larger and with much less capacity.  This very modern computer operated on a memory called “core” which was a network of tiny wires that crossed one another and had a little ring circling each crossing. Each “intersection” was either on or off, thus the computer operated on the “binary” principal. All our core printouts were in hexadecimal. A majority of this technology is completely obsolete now.  We had 13 CRTs, which is another name for the monitor you have on your computer.  CRTs were new in those days also. CRTs weren’t much use unless you had disk drives like I have mentioned that were also new. 

The CRTs were replacements for all those printouts I talked about when I mentioned the start up of the credit card program. With CRTs and disk drives, merchants could not call one number and the operator who answered could access any account and update it in “real time”.  Now!

How powerful was this computer?  Well the computer I’m working at right now is 4,000 times more powerful than that computer.  Put another way, that computer was .0000003% as powerful as my computer. The computer I’m working on now cost me about $850 total, after the infamous mail-in rebates.  That computer leased for $16,000 per month.  Mr. Watson, long time president of IBM, once said, “There may be a need in the world for two, maybe three, computers.”  I have four in this house now and one is in the garage, unused. Just putting things in perspective.

SIDELIGHT

          At the time we were installing and using CRTs, Arizona Bank, across the street, was introducing their customers to audio response. This technology is now so prevalent that we think nothing of calling the bank and having a voice read out balance to us. It wasn’t always so. Arizona Bank’s programmers struggled mightily getting that technology to work in 1967.

SUPPORT

          At this time the 360 was so new and with two banks, across the street from one another, heavily involved in experimenting with new ideas and technology, we had no shortage of IBM personnel hanging around, helping us and learning for themselves. The 360 was so advanced for its time that there were a great number of mysteries to be explored and solved. We got a lot of bad information from IBM but we all learned together.

PROGRAMMED INSTRUCTION

          I thought programmed instruction was pretty neat. The manuals were like the kind of workbooks we have all used in school.  I used a piece of paper as I worked my way through the book.  It started very basic.  There was a lesson of one short paragraph and the answer to a question at the end.  I used the paper to cover the answer while I read the material. Then I read the question and checked to see if I got the right answer. Working independently, Tom and I worked our way through the first volume of the manual.  I was getting it.  Tom wasn’t.  I had spent several years of analysis type work.  Tom had been an operations officer doing more generalist work.  We were both good in our background but this was completely foreign to Tom.

          COBOL is a little like English.  You identify something as A and something as B and a third thing as C. Then you can say, “Add A to B, resulting in C”. There was a large list of “reserved” words.  These words, such as “add”, “to” and “resulting in”, had specific meanings to the “compiler” program so the words would be converted to machine language.  You had to be selective how you used the reserved words or your program would not compile and would not work. Tom somehow got the idea that being reserved words, they could not be used at all.

PROGRAMMING

          At the conclusion of Volume One of the manual, we were told it was time to get to work.  We could do Volume Two on our own, as time permitted, but there was work to do and we needed to jump in and get our feet wet. 

After all, we had some excellent tutors available to us. The computer had very limited ability, although we didn’t know it at the time, so everything had to be programmed in small segments.  Tom and I were each assigned a segment of whatever it was that needed to be programmed at the time.

          I drew my flowchart, which is what computer programmers did in those days, and should do now days but don’t, and went over it with my supervisor. He made some suggestions and I did it again. He liked the revision.  That accomplished, I started coding.  Coding is the actual step by step work the computer is to do.  Using the flowchart as my guide, I coded the segment.  When I didn’t know how to proceed, I would go to Sue, a splendid COBOL programmer and teacher. She is the reason I was able to learn to do the job. When she, my supervisor and I were satisfied with my coding, the coding sheets were taken to the keypunch department and punched into Hollerith cards. 

Those were commonly called IBM cards and even my spell checker never heard of Hollerith. Mr. Hollerith invented them and for size decided to make them the same size as United States Currency.  If you could find one of those cards today and compare it to the currency you have in your pocket, you would find the card much larger. That is because the card was invented so long ago, none of us ever carried bills that size. At some point they decided to make them smaller.  I guess so they wouldn’t stick out of our wallets.

The program segment was punched and run through the compiler and it worked.  I received congratulations all around and began to feel maybe I could handle this job.  I knew I still had a long way to go because I had needed a lot of help.

Poor Tom. On the other hand, Tom needed a lot of help with his flow charts and eventually came up with something workable.  But then … when he tried to code without using any reserved words … the old timers couldn’t contain themselves. They would read his coding aloud and howl. Tom was always a good sport and could laugh at himself, and he put on a good show. No Brit ever had a better “stiff upper lip”, but Tom was really made to feel bad. We had become good friends and I felt badly for him.  When not around him though, even as a novice, I couldn’t help but lose control of myself when I read his attempt at coding. I don’t remember at what time he went back to being an operations officer but he didn’t stay around long. 

Ed never did become a programmer. They always had something else they needed for him to do.  Also after the situation with Tom, I understood they decided against continuing with their initial plan.  After hearing what happened with Tom, I think Ed decided he didn’t really want to pursue the programming thing either.  I don’t think he would have liked it but I think he could have done it.

PAYROLL

I liked programming.  It was a contest all the time.  The programmer against the computer.  It was like a wild horse I was trying to tame and I was never sure who was going to get tamed and who was going to get trampled. I had some good “cowboys” to help me though.

The bank decided to write a universal payroll system that could be used for the bank’s payroll, and that we could sell as a payroll service to customers. I was assigned to the project.  We worked together and had planning meetings and tried to design the payroll system.  We had an accomplished leader and were making progress.  We had a new data processing manager who was a go-getter and we were really up for the project.

          It isn’t easy to design a universal payroll.  We had to take into account that many different companies had many different kinds of income paid to their officers and employees: hourly, overtime, double time, sometimes more, bonuses, commissions, etc.  They had many different kinds of deductions besides income taxes and FICA taxes. There were insurance deductions for life, disability, health and accident. There were deductions for union dues, profit sharing plans, pensions, etc.

          To make the payroll work for the bank and for all the possible customers we had to take into consideration every possibility.  We thought we were doing a pretty good job of designing the system, when the bottom dropped out.

          There are always politics involved with everything.  General Electric had a plant in Phoenix that manufactured computers. Up until we took delivery of the IBM computer all of the banks internal work was done using GE computers, strictly because they were locally manufactured. The whole configuration of the GE computer was different from the IBM computer. It seemed to me that trying to deal with the GE way of programming would be very frustrating but those who had only experienced those restrictions didn’t know the difference.

          Well, the political powers that were, decided the payroll had to be done using the GE computers. None of us were GE programmers, although we had been “threatened” that we would probably have to change, so we had no way to take the work we had done and convert it to the different way.  The nature of politics is that the GE programmers weren’t going to even accept our concepts. To add to our morale problem, the decision wasn’t made overnight.  We were told it might happen early on.  At some point, we were told to stop work on the project.  Now we had six or eight project managers and programmers sitting idle. Rumors sprang up both ways – we were going ahead, we were losing the project. Morale got lower and lower.

          Finally the decision was made and the project was taken away from us. A couple of other, smaller projects came along.  We were supposed to be a customer service department so that was the direction we took.  One project was given to me and it ended up making me a pretty good programmer.  I was able to learn a great deal in a very short time.

LAND CONTRACTS

          A customer of the bank was selling land.  There eventually was a scam and scandal regarding these land sales but it had not surfaced at the time.

          The customer contacted the bank and was interested in the possibility that maybe a computer could be used to keep track of the contracts he carried when he sold the land.  I think he took 10% down and carried the remainder on an installment basis. Usually our salesmen went out and promised the world for a very little price, because they had no idea of what it took to provide the service they agreed to provide.  This time the salesman came to the department for advice. Management decided I should go with the salesman to the customer.  I went.  We talked and I told him what we could do. He decided to do it. It was supposed to be simple.

          When the contract was signed, we were informed.  My manager, Dave, and I sat down and started working out the details.  I flowcharted the system, in the usual small increments.  I flowcharted each increment so we could see that the increments would function properly.  Dave and I went over all this work and he approved it, after making corrections he knew were necessary.  Dave was great to work with. (He also introduced me to the term “gut-bomb” in describing Jack-In-The-Box hamburgers. There was often a late night visit there for dinner when we had no other choice.) 

          I don’t remember what else was going on but I had to do the project pretty much by myself.  The customer was, of course, in a hurry, wanting it done yesterday. He hadn’t really believed me when I had told him how long it would take.  I hadn’t understood either and didn’t give us enough time anyway.  I did the job and made a lot of novice mistakes.  Some were unbelievable.  Something else that was unbelievable was Dave’s patience. I finally got all the segments coded and keypunched.  Time was running out so Dave and I decided to work Saturday compiling and debugging my little system.  The program took about one and a half boxes of IBM cards. The cards had to be read into the computer with a card reader and the compiler program run. The compiler program would provide a list of errors, called syntax errors.  Sometimes I could mess the coding up so badly the compiler couldn’t even figure out what kind of errors I had made. That’s when Dave was at his best.

          Our office was in the Arizona Title Building Annex. The same building now houses the City of Phoenix Personnel Department.  The computer was in the basement. We showed up for work on Saturday and took our “deck” of cards to the basement.  We loaded them on the card reader and pushed all the right buttons.  The reader started to read, got about halfway through the deck, and stopped.  Those computers generated a lot of heat and had built in sensors that made the peripherals stop when they got too hot. The card reader had gotten too hot and stopped.  We noticed the room was getting too warm for us too. Usually the temperature and humidity were very carefully controlled. Not so that day. There was something wrong with the building’s cooling system.

          We called the building office and got a recording. We were told to leave a message and that someone would be back to us within the hour. The machine cooled down in the meantime but it is impossible to tell what was the last card read and what should be next. We weren’t even sure if we could pick up where we left off anyway.  So we reloaded the deck and tried again. It stopped again. More than an hour had passed, so we called again. Same message to us, same message to them and the same results.  We tried all day. We would fan the machine while it tried to read, thinking maybe we could fool it.  The room got hotter and hotter and our deck stopped sooner and sooner. Finally we had to give up and just wait until Monday.

          On Monday, we finally got the card deck read and got a list of errors.  Dave helped me correct them and we got a good compilation.  We ran test data to see if the system did what we wanted it to do. Dave helped me get that right. I felt that I had really messed up but Dave assured me it wasn’t all that bad. I would like to have done it over but that was impossible.

          When we got it where we wanted it, I went to the client with the user manual and input forms.  Our data processing manager required us to write a user manual before we started anything, revising after our flow charts were done, revise it again after coding was done and then revise a final time after testing was done. Our user manuals were good. I trained the employees that were to use the system and we worked out delivery of raw data to us and delivery of reports to them. All went well for about a month, then the client decided it wasn’t quite fancy enough and demanded more. It was already a financial loser but clients with big bank accounts have a way of getting their way.  I’m sure he got his way, for a time. 

          The client and others with whom he was associated were soon indicted for land fraud.  They were using pictures of nice land with forests, and selling worthless land that was all desert. They were selling land with no hope of water, no expectation of utilities and totally uninhabitable. Most of the land was sold sight unseen to ignorant people from the east who had hopes of retiring in Arizona. Those who did eventually come to see their land realized they had been sold worthless land.

There was one other problem with the deals. They really did sell the land -- over and over again. I don’t know the final outcome.  I was long gone by then.

Meantime, I was off on another project.

ON LINE TYPEWRITERS

          Tellers were not on line with the computers as they are now. The bank began to work on moving that direction.  On-line involved “telecommunications”. Telecommunications with CRTs or any other device was not supported with “high level” languages, like COBOL.  It is now.  When this project came up the only way to handle telecommunications was by writing programs in the dreaded assembly language. I became an assembly language programmer.

          This was more experimental than an expectation of reality.  Anything the tellers might have reason to access was on the GE computers at the time.  The handwriting was on the wall though and management was hinting that our allegiance was about to change from GE to something more customer friendly.  I think they knew GE was going to sell and their computer would cease to exist. Both eventualities became reality in a short time. General Electric sold to Honeywell not long afterward.

          Anyway, IBM had a device that was sort of an IBM typewriter, with wires attached. Management decided to write a system that would allow tellers to use the typewriters to enter a request for a balance and the response would be typed back to the machine. 

This was not a lot different than the way computer operators exercised control of the computer, which was done through typing on a typewriter type keyboard built into the console of the machine.  The computer operator did not have a screen to look at as we do today.

          I was assigned a segment to write in assembly language.  Dave and Rich, our real assembly language expert, who had done all the CRT work, were running this show.  See how forgiving Dave was.  Anyhow, I set out to write my segment and got it accomplished.  It would go nowhere without the other segments so it was assembled, as opposed to compiled as high level languages were, and there were only a couple of errors. I was proud of that because they could be, and were, easily corrected.

          A few months after I had left programming and moved on to other things, I visited the programmers with whom I had worked on the teleprocessing project. They said my module was the only module that worked the first time. I was very proud of that.