Sunday, January 26, 2014

PCGD, Technology, Design, and Paradigm Change

My lifelong fascination is with how technology allows us to solve the same old problem in a different way, and equally how chances are sometimes missed, and superior solutions get sidelined for all the wrong reasons. In the early seventies, I worked for a while at PCGD, or Postgiro, the Dutch postal payment service, and I studied their business model and their technology intensely, which set me up for other IT related roles later in life. In its day, it was considered one of the most advanced implementations of the IBM/360 architecture.

In those days the network was the postal service, and in my native Holland there was a complete parallel system of mailboxes, one blue mailbox for the PCGD, next to every red mailbox for the regular mail. The payments were done with an instruction to the PCGD that was filled out on a 50-column portion of an 80-column hollerith punch card, with the 30 column stub portion serving as your own record of the transaction. The speed was incredible. Holland is an area the size of Connecticut, Massachusetts and Rhode Island combined, and for the most part if you posted your payment in a timely fashion, your payment instruction would make it to the PCGD in one day, take one day for processing, meaning it was key punched and processed so that the money would be in the other party's account within typically 48 hours, and they would in turn receive notice a day later. The banks could never beat the efficiency, and so the entire adult population of Holland, some 10 million people, had an account with the Postgiro. Even today, there is nostalgia for the old advertising campaigns, one of which featured John Cleese: Giroblauw past bij jou! (Giro blue suits you!), and a book by that name is still available for fans of this venerable institution--the URL of the website www.blauw-bloed.nl (blue blood).

Banks could not compete in part because of the federated system, and it took them a long time to develop comparable efficiencies. PCGD was not a bank, but purely a payment service, a sort of automated postal money order. As the banks caught up, the speed advantage decreased, and the PCGD tried to compete by becoming increasingly like a bank. In the mania to privatize government services, the PCGD was first merged into the postal savings bank, and became more and more like a bank, until in 2008 it was taken over by ING.

What no one noticed in the process is that the system of the PCGD had certain innate advantages, which were lost in the shuffle, but they are more relevant today than they ever were. We live in the days of increasing scrutiny of monetary transactions, and regulations like KYC and AML, all of which are weak under a federated system, because a bank knows only one side of a transaction, where as the old model of the PCGD allows one to know both sides of a transaction. This system is superior by design.

There is another advantage, which could be powerful in today's world where the network is not the postal system, but the Internet. Remember how banking works, ever since the first time someone wrote a "check," or rather a "cheque," probably on the back of a napkin in a coffee shop or its equivalent in the Achaemenid empire. From the article on Wikipedia: "The drawer writes the various details including the monetary amount, date, and a payee on the cheque, and signs it, ordering their bank, known as the drawee, to pay that person or company the amount of money stated."

The very model presents security problems, which are today coming home to roost, because our payment systems have not really evolved, except in doing the same old stuff faster, and in more different forms... a check is an authorization for a 3rd party to withdraw money from my account at the bank. A credit card transaction or an ACH are no different. This very concept introduces a security problem, for the amount could be changed, the check duplicated and presented more than once, etc. etc. The crucial concept is that this is payment by pull: a third party PULLs the money from my account. The PCGD model had at least part of the solution, for it used payment by PUSH. Originally, the user gave the PCGD an instruction to pay x amount to the PCGD account of the counterparty in the transaction. This model per se limits the potential for fraud by the payee in the transaction, and the only issues are mistakes in transmission between the Payor and the PCGD, and to address that, there was elaborate quality control on the input end of the process. This is where I worked, and I got to know the system really well, and I was keenly aware at the time about the design superiority over the concept of writing checks. Recent events at Target and Nieman-Marcus are a fresh reminder of the downside of payment by pull.

All of our electronic systems, debit cards, credit cards, ACH, etc., tend to work on the same old model: authorizing another party to withdraw money from my account/accounts, and payment fraud is rampant, because the situation is unmanageable. What if we turned it around? With today's technology, payment by PUSH would be really powerful, if it were combined with adequate authentication of the payor. Namely, instead of an unlimited number of parties that might be authorized to withdraw money from an account, now only the owner of the account could issue payments. So we have reduced the security problem from an unlimited number of potential compromises to just one.

As a corollary to the security problems of the check model, there must necessarily be consumer protections that allow repudiation of a transaction. Checks can be stopped or reversed, ACH's can be challenged, and with credit cards there are chargebacks - all necessary protections because there are too many ways to compromise a given withdrawal. In other words, all of these modern payments are only really good after their respective protections expire. Checks are revocable for nine months, ACHs for up to 48 months depending on the jurisdiction, credit card charge backs are allowable up to 6 months, and sometimes longer. These protections are absolutely necessary, because of the design of the process, and as a result none of these payment methods can take the place of cash. The only alternative is Swift wire, but at a retail cost of some $30 per transaction it is practical only in exceptional circumstances. What if there were...? Stay tuned!