Break the bank!

greenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread

I got my monthly statement from my bank yesterday. Along with it there was a small pamphlet on Y2K (they called it Year 2000) in which the bank claims all its systems are Year 2000 compliant. This is a small rural bank with maybe five branches and probably not a lot of code to correct, so they may be right, although we won't really know for sure until 2000 gets here.

What I wonder about is what happens to the clean data in my bank's computers the first time (and the second and the third) it imports incorrect data from a non-compliant bank (garbage in, garbage out)? If my bank accepts bad data as good, it will corrupt its own good data and send new and increased bad data out to other banks. Yet if my bank insists on keeping its financial virginity and simply disconnects from all other banks (the only way to avoid bad data), we no longer have a banking system. Any ideas on this?

-- cody varian (cody@y2ksurvive.com), December 18, 1998

Answers

Yea, I got an idea....SCREW the bank, & get out of the banking system. They took my money for being a day late 8 years ago, & I haven't had a bank account since. Screw the banking system, the greedy, selfish S.O.B.'s

-- Randy (flembob@usa.net), December 19, 1998.

Cody - you are precisely correct. I worked in Banking and wrote a comprehensive piece on this exact problem of imported corrupt data. Check out the "VISA is toast" thread under "banking".

Firewalls are impractical as a solution. Isolation is impractical - Banks need to talk to each other.

">If company A is non-compliant and sends compliant company B >non- compliant data, then B will simply reject the non-compliant data. >This has worked for the last 40 years of data transfer between >computers, and I expect that it will remain in force until at least >1/1/2000 - or do you know of some reason why Visa (or any other >company) would start accepting "bad" data? > >This is the If company A is non-compliant and sends compliant company B non-compliant data, then B will simply reject the non-compliant data. This has worked for the last 40 years of data transfer between computers, and I expect that it will remain in force until at least 1/1/2000 - or do you know of some reason why Visa (or any other company) would start accepting "bad" data?

This is the misguided, unsupported Gary North idea of "corrupt" data spewing forth from computers on 1/1/2000, and "corrupting" computers that the data is transferred to. Anyone who has worked with communicating computers knows better and realizes that both the transferring and receiving machines have agreed on the data edit rules in advance, and I'm surprised that Andrew here feels otherwise. Anyone who has worked with >communicating computers knows better and realizes that both the >transferring and receiving machines have agreed on the data edit rules >in advance, and I'm surprised that Andrew here feels otherwise.

Hmm. I work with "communicating computers" and must say that Andrew is precisely right. Date-dependant calculations have nothing to do with data-interchange validations routines. What Andrew is pointing out is that non- complient programs will produce data that is wrongly calculated; these errors will spread magnitudianlly throughout the global financial system. Validation routines between data interchanges simply verify that the parameters are correct: not the calculations forming the data. This is the meaning of corrupt data: bad information, not bad parameters. Andrew (and Gary North) are precisely correct. You are espousing the "misguided, unsupported idea of "corrupt" data " equalling bad parameter transfers. That is incorrect and a straw dummy. Corrupt data = data correctly parametered yet wrongly calculated. Wrong calculations beget wrong calculations ad nauseum. Within 24 hours of the turnover, the Global Finacial System will either A)be completely corrupt B)be completely shut down so as to avoid A. The result is the same in either case; even if we don't go Milne, you are going to see a mess bigger than you can imagine. Alan Greenspan was entirely correct when he stated that 99% is not good enough. We will be nowhere close--not even in the ballpark. The engines have shutdown; the plane is falling--we simply haven't hit the ground yet. Scoff if you must; as a professional working with professionals, I know the score. It's going down. This is why at least 61% of IT professionals are pulling their money out before it hits--of course, in 10 or 11 months, that number will rise to 100%; but then, it will be to late. We know for a fact that that 50% of all businesses in this, the best prepared of countries, will not perform real-time testing. As a Programmer/Test Engineer, I can therefore assure you that at least 50% of all businesses in this, the best prepared of countries, are going to experience mission-critical failures, Gartners new optimistic spin not withstanding. Remediation sans testing is not remediation. The code will still be broken, just in new and unknown ways.

Got wheat?

Bryan"

-- Andy (2000EOD@prodigy.net), December 19, 1998.


From GN today on imported data:-

"There has been a standard myth, widely believed, that it takes two years for a large company to reach compliance. This myth is still believed as strongly as it was two years ago, or three. Meanwhile, no large company has made it -- not even those that began in 1995 or earlier. Social Security, which discovered the problem in 1989 and began repairing it in 1991, is still not compliant. Soon, soon, we are assured. And people still believe these assurances.

I have said since 1996 that most large systems cannot be fixed, and if a few of them do get fixed, they will be unfixed the day they import data from noncompliant computers, which will vastly outnumber them. I devoted a category to this on my site: Imported Data. I have not added many articles to this category lately. It's a topic that reporters discussed a year ago, but rarely today. It is the unsolvable problem of y2k, as I have said from the beginning. It has yet to be solved. It cannot be solved. A compliant firm has two choices: cease exchanging data with noncompliant firms, or else get corrupted again. Either y2k is re-imported, or else the organization pulls out of the industry. Then it goes bankrupt. The obvious example is your local bank. Because there is no solution to this problem, no one discusses it any longer. In 1997, they did."

-- Andy (2000EOD@prodigy.net), December 19, 1998.


Am I missing something here? The following publicly-traded companies are registered as Y2K-compliant or soon-to-be compliant. Now, if what you are saying is correct and data can be corrupted from non- compliant entities such as vendors, CPA firms, banks and any other entity that does business with these companies by computer interaction then these companies have remediated on a mirror system and although they are claiming compliance, they haven't done real time testing because it would crash them, and cannot use their y2k compliant mirror system until their respective vendors, banks, CPA firms etc are all compliant as well. Please dissect and tell me where I am wrong.

Albertsons Inc ABS BORDERS GROUP INC BGP Hibbett Sporting Goods Inc HIBB Lands End Inc LE NOODLE KIDOODLE INC NKID NORDSTROM INC NOBE Oshmans Sporting Goods Inc OSH Paper Warehouse Inc PWHS SHOE CARNIVAL INC SCVL WAL MART STORES INC WMT

-- Goldi (goldilucks@yahoo.com), December 19, 1998.


Everyone says they're going to be compliant soon...say, in the next 18 months or so(!). Here's what companies claimed in their latest SEC 10-Q filings:

http://www.flybyday.com/y2k/

-- Kevin (mixesmusic@worldnet.att.net), December 19, 1998.



Goldi: If one firm's computer system is generating substantial amounts of bad data because of y2k or anything else, and that data is configured properly so that other systems accept the parameters but do not realize that the data itself is incorrect, then the other systems will import that bad data and begin making calculations based on corrupt data.

This is my understanding. Am I right, everybody?

Then, since billions of data tranfers occur daily among the world's computers, this bad data is made still more corrupt by the changes made to it by the second system's computers, and then reintroduced into the global data stream to other computers. All this happens in the blink of an eye; it will not take long at all for the entire global system to be totally corrupt. In the case of banking, it will shut down the entire system because no bank will be able to have confidence that its information is correct.

Given the fact that so many systems will not be compliant by 2000, how can this scenario possibly be avoided? Personally, I'm keeping my Doom And Gloom hat on until I'm proven wrong.

-- cody varian (cody@y2ksurvive.com), December 19, 1998.


Cody,

Your understanding on this is the same as mine. Some bad data will be rejected because of unusual parameters, but some won't. I can see an attempt to cut non-compliant banks and businesses out of the system, but I couldn't make any suggestions on how to do that. Banks being closed and their customers being absorbed by other "compliant" banks?

Maybe the whole financial system will be shut down late December 1999, and then be brought back up bit by bit, section by section in January of 2000.

Whatever happens, it'll be a mess--a MAJOR mess.

-- Kevin (mixesmusic@worldnet.att.net), December 19, 1998.


Cody varian;

Keep your hat on.

You are absolutely correct, y2k or cyber-terrorism. It works the same regardless.

It all gets "more gooder" don't it?

S.O.B.

-- sweetolebob (La) (buffgun@hotmail.com), December 19, 1998.


Goldi, Cody's comments above hit the heart of the problem. For example, the Canadians have 8 major banks and they are *claiming* compliance. I've heard rumbles that they may isolate themselves as a group of 8, and that any other international transactions would go through some sort of firewall or be screened for accuracy. I don't see any practical way that this can be done in a realtine environment. How many banks does the USA have? Are they all going to do the same thing? Don't thinks so, totally impractical. Then all non- USA banks? Transaction A comes from a small bank in Yokohama, via Tokyo, via land lines to Singapore, uplink to satellite,down to New York, to issuing Bank in New England, response goes back the other way. Now physically you have a bunch of switches at which the original "good" data can be corrupted, not to mention communications problems come rollover. Now if firewalls are introduced along the way how is the data going to be checked - manually. New England teller phones Yokohama (phones working?), ooops, wrong time zone, no answer. Next day, fax sent, language problems. You get my drift, the whole situations is ridiculous and it is preposterous to ay that work- arounds can be instituted. Banking cannot go manual - if imported data is not 100% correct at *ALL* times banking is a dead duck.

Or am I missing something?

-- Andy (2000EOD@prodigy.net), December 19, 1998.


http:// deseretnews.com/dn/view/0,1249,30001761,00.html?

British banks warned of Y2K computer crooks
Scripps Howard News Service

LONDON  British banks are being targeted by crooked computer consultants making millions of dollars from bill-padding for work on preparation for the European single currency and year 2000 date-change, accountants Arthur Andersen have warned.

In one case, $10 million worth of work was invoiced at nearly $33 million.

Making matters worse are the waves of mergers, cost-cutting and layoffs, causing senior staff to worry more about their jobs than preventing fraud. In extreme cases, employees with access to budgets have worked hand-in-glove with outside consultants, splitting the proceeds of the swindle.

Those fleecing the banks are not the well-known consultancy firms but ad hoc teams put together to bid for work on the date change and the euro. Those with someone "on the inside" are best-placed to defraud the banks, and  to add insult to injury  the work they do is often substandard.

-----------------------------------------------------------
xxxxxxx xxxxxxx xxxxxxx xxxxxxx

-- Leska (allaha@earthlink.net), December 19, 1998.



Moderation questions? read the FAQ