The first month or two at Pacific Fidelity felt like an echo of Great American Life. There was the familiar SBC time-sharing terminal, and a similar library of actuarial publications. Mr. Eisenberg set me up with a userid and a password and asked me to write a few small BASIC programs. While I was at it I took a look around and was surprised to find a large pile of old programs that hadn't been used in at least two years. I mentioned this to my boss. "Is that a problem?" Well, you're paying to keep a bunch of useless junk on-line at SBC. How much are we spending on the service? "Oh, about $1,000 a month." Let me clean it up, and I'll cut your bill by 85%, I said. And I did. During the whole time I worked there, PFLIC's bill for SBC's services never again reached $150 per month. And nobody ever missed the old programs I had deleted.
Pacific Fidelity differed from GALIC in one important respect. They had an in-house S/370-135, and a programming staff. They were running '62 CFO under autocoder emulation, but they were in the process of converting to "CFO+", which was Cybertek's version of CFO II, an IBM rewrite of '62 CFO in S/360 assembly language. Mr. Eisenberg wanted me to help install and test the actuarial portions of the new system, so it wasn't long before I had several new friends who worked for Cybertek. Obie Martin and Dale Yoemans were particularly helpful. "If you're going to work on CFO+ you'll need to know Assembler," they said. So I got a couple of reference books and plunged in.
The life insurance industry was in a state of ferment in 1974. The newly formed FASB had recently released Generally Accepted Accounting Principles for life insurance and annuity contracts. Stock companies were in a rush to produce new financial statements that complied with GAAP. Regulatory changes were in the air, including agitation for relaxed valuation and nonforfeiture standards, proposals for a new mortality table (to replace the 1958 CSO table), and pressure to allow the marketing of a new breed of "variable" policies. On top of all that, the accounting profession was in an uproar about the still-emerging scandal at Equity Funding Corp.
Now Pacific Fidelity had just developed a new GAAP reporting system, but the auditors (Peat Marwick) were not happy with it, mainly because of a lack of documentation. One of my first assignments was to fill that hole. The rate tape that PFLIC was using to compute GAAP reserves had been created by a Cybertek employee named George Napoles. George had completed the first five actuarial exams before pursuing a programming career. He was in great demand, and had very little time for me. When I pressed him for the necessary documentation he gave me a few sheets of paper with plan codes, interest rates, schedules of lapse and mortality rates, and some summarized expense assumptions. He couldn't supply the source program that had been used to generate the rate tape, and he didn't have any actuarial formulas written down in a single document -- just some disconnected notes from a couple of late-night brainstorming sessions.
I showed Steve Eisenberg what I had. "Can you re-create the rate tape?" he asked. I think so. As long as George gave me the assumptions he actually used, it shouldn't be too hard. "How long will it take?" Oh, about two weeks, if all goes well. Steve stared at me in amazement. "In two weeks? The consulting actuaries said six months." Well, I'm not certain yet. Check back in a week.
In point of fact, my two-week estimate was just about right. It took a day to get the PL/I compiler operational at PFLIC, a day to design the GAAP reserve calculation program, three or four days to get it coded, keypunched, and debugged, and about a week to run the factors for the various plans of life insurance and merge them all into one rate tape. I spot-checked factors as all this was going on, and was reasonably well satisfied that there were no major discrepancies between the factors I had produced and the factors George had calculated. I wrote out the actuarial formulas long-hand, and Steve took care of getting them all typed up nice and pretty.
At this point I got a rude introduction to the realities of public accountancy. I figured we could just rerun the last quarterly valuation of PFLIC's business using the new rate tape, and as long as it produced substantially the same numbers, we'd be good to go. Tom Snow, the lead CPA from Peat Marwick, didn't see it that way. He insisted that we had to compare each factor on the new rate tape to the corresponding factor on the old rate tape. Moreover, he wasn't going to allow anybody from PFLIC to write the comparison program. He was going to write it himself. He called in a couple of "specialists" from PM&M's New York office, and they installed a package called Auditronics on PFLIC's SYSRES disk. He spent two days coding his program, and reserved a Sunday afternoon in the data center to run it.
Tom came to my office on Monday morning, a sneer of contempt curling his lip. "Come look at this," he commanded. I followed him to his office. There were six boxes of computer printouts piled on the floor. "These are all the differences between the two rate tapes," he said. "I guess you'll have to start over." There must be some mistake, I told him. Do you mind if I look at part of your output? And may I get a copy of the program you used? OK, he said. Here you go.
I dumped the first three or four records from the rate tape and started comparing them to the numbers on Tom's report. It quickly became obvious that his program had compared every record on the first input file to the very first record on the second input file. I thought about telling him this right away, but decided to look through his "program" first. It took a little while to make sense of it. Auditronics was a report generator package, sort of like RPG. Fortunately for me, it functioned as a COBOL pre-compiler: the Auditronics front end generated COBOL source code, which then passed through the COBOL compiler to produce an object program. I found the error in the COBOL program in about 15 minutes, then studied the Auditronics input for an hour or so to figure out how that worked. Once I had identified Tom's error, I took the whole mess back to him and explained what he had done. He was unconvinced, but said he would make the indicated correction and run his program again.
The next time I saw Tom he looked fairly contrite. "So how did it go?" I inquired. You were right he replied, glumly. When I reran the corrected program it found about two dozen discrepancies. Out of 250,000 factors. And the biggest discrepancy was 2 cents. I'm sorry. "Hey, we all make mistakes," I told him. "The important thing is to learn something each time we do."
The next few months flew by in a whirlwind of activity. I skipped taking Part V in May, even though I had been studying the material. I would be better prepared in November. And I was. In November I passed Part V of the actuarial exams and became an Associate member of the Society of Actuaries. In the meantime I was very busy learning Assembly Language, and reading the IBM manual "Principles of Operation" (affectionately known as the "POPS" manual by programmers world wide).
People who say that Assembler is a low-level language haven't been exposed to the full power of the IBM Macro Assembler. Yes, it's possible to write programs at the machine language level. And that can be quite time-consuming, at least in the initial stages of program development. But the conditional assembly features built in to support "MACRO" instructions are very powerful. An innovative assembler programmer can develop his own "high level language" (consisting of subroutines and some well-designed macro instructions) to deal with particular aspects of his work that come up regularly, and with time and patience he can learn to outperform the COBOL and FORTRAN compilers by a wide margin.
At this point in my career I was still wet behind the ears when it came to Assembler. I spent a lot of time reading other people's programs, especially the programs that ran every day as part of CFO+. One day I was looking through one of the accounting programs when I ran across an odd subroutine: it was used to convert a decimal number to its binary equivalent. I showed this to Obie Martin. Why not use the CVB (Convert to Binary) instruction, I asked. Why write an entire subroutine when one or two machine instructions wll do? Obie laughed. Then he explained how CFO II had been written in the first place. IBM wasn't willing to reinvent the wheel. They already had the '62 CFO code. So they built a language translator to convert 1401 AutoCoder to S/360 Assembler, then hired a bunch of code monkeys to polish up the resulting code so it didn't look quite so clunky, and had some rudimentary comments embedded in it. There had been no "CVB" equivalent in Autocoder. The language translator faithfully converted the input program, and none of the code monkeys knew enough about system architecture to recognize what that subroutine was actually doing.
My old Chevy II bit the dust late in 1974. I bought a brand new Chevy Vega hatchback to replace it. I borrowed money to buy that car; a first for me. I had also moved away from 417 Ocean Front Walk, first to 53 Sunset Ave (right on the Pacific Coast Highway in north Venice), and then to a place on Washington Boulevard, on the north side of Marina del Rey. I shared both these latter apartments with roommates. I remember that the rent in Marina del Rey ran $375 per month. There were a few months that Glenn Abel, my roommate, didn't have his share of the rent. I had always been pretty thrifty -- I was saving money hand over fist. So I was always able to help Glenn out with his cash flow problems when necessary.
I was part of the conversion team at PFLIC. We were still running '62 CFO, but were planning to go live with CFO+ sometime in 1975. In December of 1974 Tom Snow approached me with a request. "As part of our audit, we need to send letters to about 500 policyholders to verify that they actually have an insurance policy with Pacific Fidelity," he began, a little nervously. "We've looked at the '62 CFO record layout, and there's no way we can use Auditronics to get the policyholder's address out of the Y trailer. Heck, there's no way we can even read a '62 CFO record into Auditronics' memory space. It will only handle fixed-length fixed format records." Well, that sounds like a problem, Tom. What do you want me to do? Teach you Assembler? "No. I would like you to create an extracted version of the policy master file, in a fixed-length format." I talked to Steve Eisenberg to get the green light, then sat down with Tom to design the record layout he needed. It took me about a week to create his file; a lot of that time was spent in keypunch, punching my code into 80-column cards.
One of the main things I learned while writing the program for Tom was how to use the EX (Execute) instruction. I needed to perform a variable-length move, to extract the variable-length name field (for instance) into the fixed-length name field in the output record. Obie Martin kindly taught me about "EX". I was really starting to enjoy ALC! Anyway, Tom sent his letters out, and the actuarial department settled into the year-end routine: reviewing the valuation runs, correcting the inevitable errors, setting up the various exhibits for the Annual Statement, and filing the year-end financial reports with the many states in which we did business.
About the end of February, just before the Annual Statement work was finished, I sauntered over to Tom Snow's office. "Hi, Tom," I began, cheerily. "I just want to let you know that the file I gave you -- the one with all the names and addresses in it -- really wasn't the entire policy master file. I left all the phony policies out, since you didn't care about those guys anyway. Have a nice day." And I turned to leave. "Wait!" he cried, a tremor in his voice. "Did you really leave some policies off the tape you made for me?" "Of course not," I said. "I'm an honest guy. The point is, I could have left some policies off that tape, and you would be none the wiser. You auditors need to up your game substantially if you're really going to verify that a company isn't using its computers to perpetrate some sort of fraud. 'Auditronics' isn't ever going to cut the mustard." (The last time I had anything to do with auditors, this problem still persisted. The CPAs seem to have a real hard time keeping up with technology.)
I liked the people at Pacific Fidelity, but one thing about the place really bothered me: no one seemed to care if the company made money, or not. For example, when we prepared the annual statement for 1974, I was told to prepare the active and disabled life reserves for the waiver of premium benefit. The company had a fairly large ($½ million) reserve for disabled lives, and was taking a very small reinsurance credit against it. I called my opposite number at Occidental Life (PFLIC's primary reinsurer) and asked him if they had set up a reserve for PFLIC's disabled lives. He lowered his voice conspiritorially: "In fact, we've got a $100,000 claim reserve set up. You guys haven't submitted a claim in the last ten years." I did a little more digging, to figure out why this had happened, then alerted the reinsurance department. They had to do a bit of work, but were eventually able to recover nearly $80,000 from Occidental, on claims that were up to ten years old. I got kudos for finding the money, but was left wondering how such a thing could happen. Sloppy procedures and pervasive laziness was all I could figure. I asked my boss about it. He explained that PFL was controlled by a very wealthy family that also owned Richardson-Merrell, which marketed Vicks Cough Drops, among other products. They didn't really care whether PFLIC was profitable or not; it was basically an income tax dodge which allowed them (somehow) to cut their taxes on the rest of their business empire.
In the early days of GAAP accounting for life insurance, people weren't entirely certain what "conservative" assumptions really were, nor how often actuarial valuation factors (i.e., the rate tape) should be revised. For instance, the lapse rate on new business written, especially the first year lapse rate, is a critical factor in evaluating the profitability of new business. An important consideration in setting up "Deferred Acquisition Charges" (also called DAC, a peculiar sort of asset required by GAAP rules) is whether or not these charges can be recovered from future premium revenues. To be conservative in this part of the calculation is to use a lapse rate assumption a bit higher than one actually expects. But the survivorship factor (1.0 less the lapse rate, very nearly) appears in the denominator of the valuation factor for the DAC at the end of the first policy year. So if actual lapses are less than assumed lapses, at the end of one year the valuation formula produces (1 - actual lapses) * Actual DAC / (1-assumed lapses), which will be larger than the actual DAC, and will cause the profit reported in the first policy year to be too high. So the "conservative" lapse rate produces an anomalous profit, which isn't really conservative from the income statement point of view.
A very large portion of PFLIC's new business was being written on a "deposit term" product for which the first year lapse rate was absolutely atrocious (roughly 40%). The auditors were concerned that Deferred Acquisition Costs might not be recoverable on this plan, so they demanded that the company produce a lapse rate study. As usual, I stepped into the breech. The programming department had already begged off on developing such a report; they were too busy working on the pending conversion to CFO+. The transaction files produced by the daily cycle were effectively unusable; because of sloppy procedures in the new business area, policies were often purged and reissued five or six times before they were finally OK. So I cooked up a method to produce the needed lapse study solely from policy master files from successive quarter-ends. (A policy would not drop off the master file for at least 90 days after it had lapsed, to allow for automatic reinstatements on late premiums.)
At about this same time my boss, Steve Eisenberg, took a job in Atlanta, Georgia. Steve was a Southern boy, and the chance to return to the Heart of Dixie was irresistible. I was growing weary of the perpetual summer and never-ending traffic jams that define life in Los Angeles. So early in August I went to Denver, Colorado to interview with United American Life. They offered me a job, and I accepted their offer on the spot. I also lined up a one-bedroom apartment on Capitol Hill, and paid the rent through the end of September before flying back to LA.
Now that Steve was gone, I was reporting directly to Walter Elcock, the president of Pacific Fidelity. I walked into Walter's office one fine Monday morning with the lapse report in my hand. "Walter, I have good news and bad news," I announced. "The good news is that I've finished the lapse study the auditors requested. The bad news is that I quit." Walter puffed on his cigar. "I had high hopes for you, my boy. Stick with us. I'll triple your salary." "Now I know that I have to quit," I said. And I went on to explain why.
"This company is full of people wearing golden handcuffs," I said. "Pacific Fidelity Life isn't exactly a bad company. But because of the ownership structure, nobody really cares whether we make money or not. The result is a sort of dry rot. People know there's no real chance of advancement here, in the long run, because this company is going nowhere. But most of the employees are being paid more than they're worth on the open market. They'd have to take a pay cut to get another job. And most of them won't do that. I don't want to end up stuck in a rut. So good-bye." I turned and walked out. And that's the last time I ever spoke with Walter Elcock.