U.S. Treasury tests a new payment mechanism, The

Journal of Information Systems Education, Fall 2003 by Gelinas, Ulric J Jr, Gogan, Janis L, Wade, Chuck

ABSTRACT

This case presents a set of technical issues confronting the United States Treasury eCheck Pilot Project team in January 2000. The team, which included representatives from the U.S. Treasury, the Federal Reserve Bank of Boston, Fleet Boston, Bank of America, and several hardware and software vendors, was testing a new Internet-based payment mechanism (eCheck). The system had already been tested for a year and a half with the participation of the two commercial banks (Fleet Boston, Bank of America), but this portion of the pilot was now coming to an end. During the first phase of the project, several key design choices had been made, including the use of smart cards to hold digital certificates, and specification of the information flows among the participants (payer, payee, payer bank, payee bank). Now, the system would need to be modified so that the U.S. Treasury could continue to make eCheck payments to a few defense contractors, with the help of the Federal Reserve Bank of Boston. Two new designs are presented for evaluation.

Keywords: eCheck, Internet, payment mechanisms, systems design, emerging technologies

1. INTRODUCTION

In January 2000, the United States Treasury eCheck Pilot Project team was planning the next phase of this test of a new electronic payment mechanism, which involved participation from the Treasury's Financial Management Service, the U.S. Department of Defense Finance and Accounting Services Division, the Federal Reserve Bank of Boston, and a few Defense suppliers. An earlier phase of the project had also involved two commercial banks, Fleet Boston and Bank of America, but this next phase would not include commercial banks. Thus it was necessary to redesign the payment flows. One solution had been suggested by Frank Jaffe, the outgoing manager of the eCheck Pilot Test. Another solution was suggested by Mike Versace, from the Federal Reserve Bank.

Participants on the eCheck team-especially the representative from the U.S. Treasury Financial Management Service and Mike Versace from the Fed-needed to decide which of these two approaches to take.

2. eCHECK PROJECT BACKGROUND

eCheck was one of several projects initiated by the Financial Services Technology Consortium (FSTC), which consisted of financial institutions, hardware and software firms, governmental agencies and others. The eCheck project, begun in spring 1994, was aimed at developing a new electronic payment mechanism for use in Internet commerce and other contexts. A Proof-of-Concept demonstration was held in 1995, and in 1996 a decision was made to conduct a pilot test at the United States Treasury (the decision was not announced until fall 1997, after all parties signed project contracts). Much work was then done to flesh out the detailed specifications for ensuring secure transactions before the first eCheck was cut on June 30, 1998.

This case describes the evolution of the eCheck design and technical specifications through winter 2000. A companion case (Gogan, Gelinas and Rao, 2003) addresses strategic and project management issues.

3. PROJECT PARTICIPANTS

The pilot project was officially announced on October 7, 1997. Participants (listed in Exhibit 1) had expected that the pilot test would involve 50 vendors, run for one year, and process up to 1,000 checks and $1 million per day. But before payments could be made, several important design issues had to be resolved. The next three sections of the case discuss each of these design challenges.

4. SMART CARD DESIGN: A TOKEN CHOICE?

Early on, security experts on the eCheck design team (such as Milt Anderson, a cryptography expert from Bellcore, Ken Goldman, a security researcher at IBM, Doug Kozlay, a founder of Information Resources Engineering (IRE), and Chuck Wade, a specialist in PKI services at BBN) urged the use of a separate "token" for storing cryptographic private keys (a "security token" is a simple hardware device, such as a smart card, key fob or small keypad, that is used in conjunction with another hardware device). A user would need to insert a specially designed card or device into a reader on their computer, before an eCheck could be digitally signed and sent on to the payee. Milt Anderson explained:

"In two-factor authentication, the user must have something-a token-and know something-a password. If I leave my laptop PC at the airport, I'll have plenty to worry about, but my eCheck account will be safe. If my eCheck smart card falls into the wrong hands, that's okay as long as the thief doesn't know my password. If I carelessly reveal my password, then the thief must obtain my smart card, which imposes one more security hurdle for the bad guys to surmount."

Some participants questioned the choice to store security keys on smart cards. Frank Jaffe, who represented Bank Boston and also served as overall eCheck project manager, argued in favor of a simpler approach:

"Not all computers have PCMCIA slots, and I'm no longer convinced a token is necessary, from a business perspective. Another approach: store the key for the user's digital signature in an encrypted file on their hard drive... This is not quite as secure as a smart card, but ... it's good enough. Most firms use firewalls to prevent unauthorized penetration. There is always a trade-off between perfect security and usability. Since it's fairly unlikely that bad guys can obtain digital signature keys on a large scale, it's more practical to establish just-in-case corrective procedures for the unlikely event keys are compromised."