The RISKS Digest
Volume 1 Issue 31

Thursday, 19th December 1985

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…


oEnough on passwords? Pharmacy systems
Elizabeth Willey
o Risks re computer-compared prescriptions
Brint Cooper
o Oops
Marty Moore
o $32 Billion Overdraft Resulted From Snafu
Washington Post

Enough on passwords? Pharmacy systems

Mon 16 Dec 85 18:00:52-EST
To: risks@SRI-CSL.ARPA

Could that discussion [on passwords] go over to SECURITY@RUTGERS (mail to
SECURITY-REQUEST@RUTGERS to join)?  Passwords have been discussed there
        [It could.  We have made the point that passwords are frequently
         misused.  But everyone has an opinion on them, so it is only
         natural that there are lots of contributions on that subject!  
         Actually, I rejected two messages on the subject for this issue,
         both of which would have required me to add caveats on the 
         soundness of those messages.  But there are still risks in relying 
         on passwords that are worth including here.  PGN]

About the pharmacy systems:  people are essentially lazy.  They will
certainly become dependent on a computer program that tells them conflicts
and stop noticing the conflicts themselves! Unless you formatted the program

         ["Sorry.  I did not know the answer, but I did not want to admit it

Re: Risks re computer-compared prescriptions

Brint Cooper <abc@BRL.ARPA>
Mon, 16 Dec 85 20:52:56 EST
Risks of putting prescriptions "on-line" must be compared to the risks
of NOT putting them on-line;i.e., to the risks of doing things as they
now are done.  It is tempting to compare them to the risks of doing
things as we wish they were done, but this is unrealistic.

Now let's consider Dave Platt's well-founded concerns, keeping in mind
that it is ALREADY the responsibility of the pharmacist to protect the
patient/consumer from harmful drug interactions and the like:

    The database of drug conflicts comes from wherever it now comes
from.  Package inserts (or the PDR) contain some of this information;
this is mandated by law.  Even if the automated database is less
complete than the present human-maintained database, an automated system
is much more likely to consult every relevant item.  A human can forget!

    Information beyond drug-drug interactions should be included if this
is within the responsibility of the pharmacist.  Otherwise, it should not be
unless the medical and pharmaceutical professions consciously decide
otherwise.  Programmers should not redefine the practice of the professions
of others.

    Clearly, the first step is a non-intelligent database system.
The example of an asthmatic taking another med containing sulphites
should be covered by the database on medicine-medicine interactions.

    Regarding degrees of responsibility, if the sources of
information in the database are the same as at present, and if the
pharmacist is using the database as a "decision aid," then I don't see
how anyone's responsibility has been changed by a change in
recordkeeping systems.

>    -  Will doctors, pharmacists, and/or consumers begin to depend
> on the correct functioning systems such as this, at the expense of
> studying the issues involved themselves?
    My problem with this question is that it assumes that doctors,
pharmacists, and consumers presently study the issues involved.  To the
extent that an automated system provides a professional with free time,
it will enable him/her to spend more time studying.  But an automated
system is not necessarily good or bad for anyone's habits!

    Sure!  People may come to rely on an automated Physician's Desk
Reference (tm), but many people take their pharmacist's word as gospel
right now.  And too many pharmacists spend so much time as business
managers selling cosmetics, stationary, motor oil, jewelry, books, and
flowers that their "expertise" is anything but.  At least a
well-functioning database doesn't "forget" what it has learned.



"MARTIN J. MOORE" <mooremj@eglin-vax>
0 0 00:00:00 CDT
To: "risks" <risks@sri-csl>

[I have abridged Marty's message.  He pointed out that I did not complete
the editing of RISKS-1.30, leaving the banner line as
    RISKS-LIST: RISKS-FORUM Digest  Thursday, 13 Dec 1985  Volume 1 : Issue 29
instead of 
    RISKS-LIST: RISKS-FORUM Digest  Monday, 16 Dec 1985  Volume 1 : Issue 30
He also noted that "the table of contents seems to be rather skimpy this
issue."  (I left it out.)  "I guess even RISKS is not immune to glitches!"
(But it was a HUMAN error, not a computer-related error!)  On the
other hand, nobody complained that Friday the 13th fell on Thursday in
RISKS-1.29, for those of you who remember Pogo.  PGN]

   [By the way, William Daul reported getting as many as 10 copies of
    RISKS-1.29.  Another forum to which I belong recently had an issue where
    the system crashed repeatedly during mailing, and some users got as many
    as six copies, others getting none.  I hope there is a way for the
    network people to fix this problem.  PGN]

$32 Billion Overdraft

Al Friend <friend@nrl-csr >
Wed, 18 Dec 85 15:47:45 est
From: Al Friend - SPAWAR
To: Risks Forum

  Here is an interesting article out of the Washington Post.  It seems that 
there is a very real potential for financial disaster lurking in the 
electronic banking jungle:

[Washington Post, 13 December 1985, p. D7]

Computer Snarled N.Y. Bank
$32 Billion Overdraft Resulted From Snafu
By John M. Berry, Washington Post Staff Writer

  The Bank of New York, the nation's 18th largest, had a brief $32 billion 
overdraft on its cash account at the New York Federal Reserve Bank when a 
computer failure last month snarled thousands of government securities 
transactions, a congressional committee was told yesterday.
  By the end of the day, the overdraft had been reduced to $24 billion, and 
the bank actually had to borrow that amount from the New York Fed — pledging 
all of its assets — in order to balance its accounts overnight. 
  Aside from the unprecedented scale of the borrowing, and the spillover 
effects on the government securities market, the incident intensified concern 
at the Federal Reserve over the vulnerability of the nation's financial 
payments system to a technological glitch that could have disastrous 
  Federal Reserve Chairman Paul A. Volcker and New York Fed President 
E. Gerald Corrigan went before a House Banking subcommittee yesterday to 
describe how the computer failure occurred and how the Fed and the bank 
dealt with the crisis it caused. 
  On Wednesday, Nov. 20, transactions involving more than 32,000 different 
government securities issues poured into the Bank of New York, one of the 
largest processors of such deals on behalf of others.
  The bank's computer system was supposed to be able to cope with up to 
36,000 issues, but a programming glitch developed and, unknown to anyone,
the computer began to "corrupt" the transactions and make it impossible 
for the bank to keep them straight.
  Because of the computer system breakdown, the bank could not instruct 
New York Fed where to send the securities arriving at the Fed on behalf of 
the bank's clients, and therefore could not get paid for them.  The New 
York Fed was automatically taking money out of the Bank of New York's cash 
account to pay the sellers for the incoming securities, all of which are 
represented simply by computer records, rather than the familiar paper 
bonds still used by most corporations. 
  By Thursday evening, as hundreds of employes at a host of banks and 
government securities dealers tried to sort out the problems caused by the 
failure of the intricate and largely automatic network handling these 
transactions, the bank had a $32 billion overdraft on its cash account at the 
New York Federal Reserve Bank. 
  The bank's computer specialists finally came up with a "patch" for its 
 computer program — a process described yesterday by its chairman, 
J. Carter Bacot, as the electronic equivalent of patching a tire — that 
allowed it to begin to clear some of the backlog.  But just after midnight, 
the patch failed too, after the overdraft had been whittled down to about 
$24 billion. 
  The Fed kept both its nationwide wires for securities and cash transactions 
open in the early hours of Friday morning.  When the patch failed, the Bank 
of New York was still able to borrow $700 million from other banks.  The rest 
was covered by a $23.6 billion loan from the New York Fed.  As collateral, 
the bank pledged all its domestic assets and all its customers' securities 
it was allowed to use for such purposes.  Altogether, the collateral was 
worth #36 billion, according to the Fed.
  The drama was not over.  Around 5 a.m. Friday, the bank finally completed 
reconstruction of its customers' transactions from Wednesday.  By 10 a.m., 
it had done the same for the Thursday deals.  But, meanwhile, the rest of the 
government securities industry had begun its Friday activities, and securities 
and an overdraft were piling up again in the Bank of New York's account at the 
New York Fed. 
  "Faced with this situation," New York Fed President Corrigan told the 
banking subcommittee, "at about 11:30 a.m., we temporarily stopped accepting 
securities transfers for the account of Bank of New York in an attempt to 
stabilize the situation somewhat and to see whether it was practical to 
prevent further increases in the overdraft without causing excessive 
disruption in the market more generally. . . . 
  "Operationally, this meant that holders of government securities who had 
contracts to deliver those securities . . . to the Bank of New York for
one of its customers [in return for payment] were temporarily unable to make 
delivery under those contracts," Corrigan said. 
  The stoppage lasted only for about 90 minutes that afternoon, and news of it 
did not spread widely for nearly an hour.  Yet that disruption at the clearing 
bank was enough, Corrigan said, to make some market participants unwilling to 
trade securities among themselves.  "Perhaps most importantly, there was also 
some evidence that investors were beginning to seek to break trades and 
financing transactions with dealers serviced by the Bank of New York." 
  Shortly after noon, the Bank of New York was able to begin handling the 
Friday transactions that had been piling up, and the Fed was again able to 
accept securities destined for the bank.  By that point the bank was operating 
with a computer system that had undergone a major overhaul in less than 24 
  The crisis was over, but its final bill is still mounting. 
  The Bank of New York was out of pocket about $5 million, an amount equal to 
about 7 percent of its earnings in the first nine months of this year, to pay 
interest on the money it had to borrow that Thursday.
  It is still negotiating with many of the parties who may have sustained 
losses in transactions that were not completed on time.  Such negotiations are 
common, said an official of one major securities dealer, because a few 
transactions are always going awry.  This time it was thousands. 
  Some customers walked away in better shape.  "Indeed, those individuals and 
intistutions who bought securities in question received a windfall in that 
they received interest for a day [on the securities], but did not incur any 
cost of financing," Corrigan noted. 
  But any loss or gain in dollars, even with millions of dollars at stake, is 
not the real issue.  What worries both Federal Reserve officials and 
participants in the government securities market is the potential for a 
failure of the system. 
  On the average day, about $200 billion worth of government securities 
transactions take place involving about 27,000 separate transactions, Corrigan 
said.  Some days the totals are far larger. 
  "Like it or not," Volcker told the subcommittee, "computers and their 
software systems — with the possibility of mechanical or human failure — 
are an integral part of the payments mechanism.  The scale and speed of 
transactions permit no other approach. 
  "In the last analysis, no mechanical system can be entirely 'fail-safe' 
and also be commercially viable," he said.  "The costs would simply be too 
high, and the money and Treasury securities markets could not operate at the 
present level of efficiency."
  The Fed chairman pointed out that, in this case, the Fed was available to 
lend the $23.6 billion, on good collateral. "The effects in this instance 
were of unprecedented magnitude, measured by the amount of the overnight 
loan," he said.  "But the effects in terms of market performance and risk 
were well contained. . . .  I believe it would be wrong to overdramatize this 
  Corrigan in his more detailed testimony sounded more notes of concern.  "I 
believe our actions were prudent, disciplined and appropriate.  In saying 
this, I should also confess that in some respects we were a bit lucky," he 
  Part of the luck was that the bank was able to get its computer going again 
as soon as it did.  Another part, Corrigan said, was that Thursday was not an 
especially heavy day for securities transactions. 
  One government securities trader summed up the situation this way. 
  "We're all afraid something will go bump and send the market into a tailspin. 
. . .  The Fed is working night and day to figure out what it can do.  The 
banks are working night and day.  But the amount of [trading] in financial 
markets is so large that we feel this is the No. 1 financial problem of the 
next few months.  Banks have to be able to make settlements with each other." 

Please report problems with the web pages to the maintainer