Destroying The Village In Order To Save It--A Banking Report : LUSENET : TimeBomb 2000 (Y2000) : One Thread

I may have mentioned this before but it's just a single response of mine buried deep in the archives so here it is as a topic to consider. A couple of weeks ago I met with the branch manager of a bank in which I have an account, on some non-Y2K related business. After completing the business I casually asked about the bank's Y2K compliance. The manager replied that the bank felt there would be no problems with the bank's systems, that much work had been done and the systems were checking out pretty well.

I then asked what the bank planned to do about other bank's systems that may not be compliant. Specifically I asked how the bank would protect its ostensibly compliant systems from corrupt incoming data from other systems. He said that incoming data can be blocked out to protect the integrity of a system. I replied that if you block all questionable data, you destroy the overall interconnected system and essentially destroy the banking system. How can this be dealt with?

I received a blank look for a second or two as he processed this query and saw a bunch of Error messages on the personal computer system in his head. His answer was that he knew of no way to deal with this, that any widespread data blocking would destroy the system it was intended to save ("We had to destroy the village in order to save it, Corporal.").

"Then what is the answer?" I asked.

"There isn't any that I know of," said the banker.

You can guess what I did when I left his office.

-- cody varian (, September 06, 1999


no,tell us...what did you do?

-- zoobie (, September 06, 1999.


I agree with you that the non-compliant systems, whether or not they are mission-critical, will corrupt the compliant ones. This is one reason why the happy-face crowd are such a bunch of phonies.

-- Mr. Adequate (, September 06, 1999.

zoobie, what do you think I did? I was in my bank and had just been told by the bank manager that the banking system was mortally threatened (not his words but 2 + 2 = 4) by Y2K. It's only about 40 feet from his office to the tellers. What would you do?

-- cody (, September 06, 1999.

well,I never have any money,so I'd probably get arrested for vagrancy...

-- zoobie (, September 06, 1999.

Thanks for the reminders guys,

I'm developing a new srategy for maybe making some money out of this fiasco IF the systems stay up - however I, and so have the BIS in Switzerland, have come to the conclusion that the system will hose/impload.

The only way out I can see is to convert any money you may have accumulated into precious metals, guns, ammo and other assets.

Essentially I'm buying gold calls into 2000 as if the systems do stay up there will be so much chaos the gold will skyrocket. Also keeping some small units of gold shares for the same reason. Essentially I see this as dead, lost money, BUT... just in case...

-- Andy (, September 06, 1999.


Wow!!! Just started my morning paper route!

Thats right---go ahead and laugh---My thoughts have been that if things stay up and there is some semblance of order. The first J.O.Bs. to go will be everything but the basics.

I thought maybe applying at The grocery stores, but did not want my neighbors asking questions.

My Business partners at the office think I'm comical!!

N.Y.Times by the way! Gawd its dark in the morning ZZZZZZZZZZ

-- David Butts (, September 06, 1999.


For you, placing more bets (on gold going up) by buying gold calls is not a new strategy. You are simply adding another tactic to your already existing strategy. :-)


-- Jerry B (, September 06, 1999.

I'd like to hear more about a scenario where incoming data "corrupts" a compliant system making it concompliant.

In my IT work, I've never seen anthing like that.

In passing data from one application to another, the corruption would be the date field (or compliant fields that house calculations from the other system and has bad data due to the other system's errors).

Garbage in, garbage out, sure. But data like that would not 'corrupt' the target system and make the other "good" data corrupt nor would it make the target system noncompliant.

Remember, banking systems have predictive logic built in, so they have been looking into this Y2k stuff for a while. When you sign a 30 year mortgage, the bank want to predict what it's books will look like in the future (hello: financial calculations in the future).

They have been scared sh*tless about lawsuits and thusly assumed the wise thing to do is to be quiet (things you say WILL be held against you in a court of law).

I'm leaving my money in my bank. Anybody looked at the trend in gold prices lately? Chart it out. Remember when gold used to trade at over $200/oz?^GOX&d=2y

-- JAW (, September 06, 1999.


Bank A calculates an interest payment incorrectly due to Y2K remediation problems. The resulting interest calculation is passed to Bank B where it is in ERROR but WITHIN valid error checking parms. Bank B adds incorrect interest payment(s) and passes result to lets say a mortgage broker group account. Said account is accumulating via correct and incorrect (aka "corrupt") deposits from multiple banks. Now the mortgage broker account is just one of several owned en masse by Bank C which moves the funds to international Bank D...

Get it?

-- RDH (, September 06, 1999.

There is going to be one hell of a magic show at 4 am around JS12! "What the H***?" How did THAT happen?

If you haven't been there, don't bother responding.


-- br14 (br14@bout.done), September 07, 1999.

JAW: You miss the point. It's not that the data from a non-compliant computer will make a compliant computer's operating system non-compliant; no one is saying that. What can (and will) happen is that incorrect data from a non-compliant computer that is correctly formatted will be accepted and processed by the compliant computer and then transmitted to other systems, building error upon error. It's the data that is corrupt, not the computer hardware or software.

-- cody (, September 07, 1999.

Moderation questions? read the FAQ