******************************************************************* On the Main Categories Page of this site, the following has been posted for two years: "I maintain that the y2k problem is systemic. It cannot be fixed. The interconnections are too many. A noncompliant computer will spread bad data and re-corrupt a compliant computer. They cannot all be fixed. There is no agreed-upon standard for even the placement of the century date. Either the noncompliant computers will re-corrupt the compliant ones, or else the compliant ones must cease all contact with noncompliant ones, thereby shutting down entire systems, most notably the banking system." I am still waiting for anyone, on any site, to respond to this. *********************************************************************

Response 

A noncompliant computer will not re-corrupt a compliant one. First of all, it should be obvious that data will not modify code. Only humans or code (including viruses perhaps) can modify code. If Bad Bank A sends valid, but corrupt, data to Good Bank B, then what you end up with are data records in some database at Good Bank B which are incorrect in some way. But they are not going to modify other, non-corrupt, data records that may have come in from Good Banks C, D and E. And they certainly wont make Good Bank Bs program logic suddenly re-corrupt. Software and data simply do not interact in that fashion.

However, we still have those aberrant data records sitting in the database. What effects WILL they have? Well, it all depends on the actual nature of the transaction that they represent. A hypothetical example 

Bank Italia Unremediata, having ignored Y2K until November of 1999, crosses into the new millenium with a noncompliant loan program (among other problems). This program calculates P&I which is due to be paid to Citibank, N.A. on 1/4/00, and instead of the correct payment of $80,000 it comes up with $140,000. A wire transaction is created, and $140,000 is sent to Citibank. What does Citibank end up with? A transaction in some database for $140,000, which does NOT re-corrupt anything - it just sits there - AND an actual $140,000 credit in its account at the Federal Reserve. What does Bank Italia end up with? The same thing, except a debit of $140,000 in its reserve account, which is $60,000 too much. The end result? Perhaps Citibank reconciles the error by verifying the amount received against a separate database record indicating the amount expected, and informs Bank Italia. If not, then Bank Italia will most likely notice the error when it performs some sort of reconciliation, or perhaps simply because they end up with an overdraft in their cash account. At which point they have a panic attack and go into emergency repair mode. Ultimately, correcting transactions are created and transmitted to properly balance out the books for both banks with respect to the original bad transaction. The corrupt data will actually sit in the databases forever, infecting and harming no one.

Is it necessary for Bank A to cease all contact with Bank B in this type of scenario? No, it is only necessary that the error be identified and corrected at some point, so that all obligations are settled accurately in the end. At no point is there a contagion of bad data spreading beyond these two banks nor is there any re-corrupting of compliant systems. Invalid data records get created, transmitted and stored, and correcting records later get created, transmitted and stored.

Most financial transactions are largely point-to-point, between Bank A and Bank B, with perhaps one or two intermediaries like a central bank or clearing institution involved also. But the corrupt data record does not pass from one place to the next in an endless sequence, infecting everything along the way.

The possible meltdown argument that CAN be made is that so many systems will still be unremediated in so many banks that there simply wont be the time and resources to fix everything in a timely fashion, and that everything will eventually collapse in an unreconciled mess. If you believe that, then so be it. But please, stop telling us that Y2K is systemic in such a way as to imply that a few pieces of bad data will propagate wildly and collapse the entire banking system. The system is not that fragile. If it was, it would have collapsed a long time ago. The argument that the interconnections are too many does not float, simply because no given entity or interconnection represents a global failure point. Lots of failures can occur, and the system will still survive. Yes, there is a critical mass of failures which would result in dire straits for the banking system, but that is an entirely separate argument from this its systemic, it cant be fixed assertion. And arguing whether that critical mass will occur simply goes back to how you read the tea leaves, and generally results in dueling news clips and overhyped anecdotes.

But if someone can describe to me a real world financial transaction flow where a piece of bad data from an unremediated bank could propagate through the entire financial system like some sort of virus, and actually do damage along the way, then I would be very interested in seeing it.

-- Polly (skippy@innermongolia.com), May 11, 1999

Answers

Polly, It seems you and I have had this discussion before. The regulars on the forum are aware that I am neither a programmer nor a banker, so the only knowledge I have of this matter is from y2k reading.

With all that said, I describe the risk factors exactly as you have, but since I cannot "read tea leaves" at all, I remain concerned about the banking system.

My concern primarliy relates to the number of problems to be encountered (which we all can agree is unknown), then amount of time it takes the system to recognize a problem with data which is correctly formatted but erroneous in date or amount, the amount of manhours necessary to fix the problem and the amount of men and time available to work on the fix.

Others who ventured here have conceded that a sufficient number of problems could create a Gordian knot of data that could cripple the system. Do you concede that theoretical possibility?

-- Puddintame (achillesg@hotmail.com), May 11, 1999.

Bullshit. I've worked in EDI for 12 years, and when you start handing out bad files, you are stopped in your tracks until you fix the problem.

I've actually had to troubleshoot our customer's bad files and suggest the fix.

And word gets out fast, too. How long can Bank d'Italia Unremediata stay afloat with nobody settling their funds? A week?

-- Lisa (lisa@work.now), May 11, 1999.

Polly,

An official at Intel seems to think otherwise...

http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=000nwo

-- Kevin (mixesmusic@worldnet.att.net), May 11, 1999.

This is pure whistling in the dark. It starts out with a straw man argument, blowing a trivial mis-statement "bad data will corrupt computers" out of proportion and making a great ceremony of knocking it down (of COURSE North doesn't imply that the logic will be corrupted - he clearly means the *information* will be corrupted).

Then Polly waves his magic wand and makes the sum total of Y2k-caused errors into "a few pieces of bad data." How many trillion dollars have been spent so far to avoid generating these "few pieces"?

If the system is not fragile enough to collapse (it DID collapse within living memory, junior) then why are banks furiously launching their PR campaign to keep depositors calm and uninformed? Why is the FED printing money (too little, too late) as fast as it can? How many pennies on the dollar are insured by the FDIC?

Polly indeed. As in "parrot."

Dano

-- Dano (bookem@blacksand.srf), May 11, 1999.

Great response, Dano. Just for the benefit of any newbies, though, let it be very plainly emphasized: "corrupt" as used here means "wrong information". So, if a non-Y2K compliant computer system mis-calcuates and generates bad (corrupt) data and passes it to a Y2K compliant computer system (note that this potentially has NOTHING to do with date formats!), then whatever further use of the bad data takes place (which may be passed to more systems) is going to be wrong (corrupt).

-- King of Spain (madrid@aol.com), May 11, 1999.

To add a bit to what King of Spain has said -- errors of this type happen now. Undoubtedly they will happen at a greater rate next year. The critical issue is, to what degree will the functionality of the banking system be reduced by this increased error rate?

Related questions are: (1) To what degree will current remediation efforts reduce this rate?; (2) What actions can (and might) the banks and/or government take if the error rate rises above manageable levels?; (3) How rapidly can the error rate be reduced to a level that permits full bank functionality?; (4) To what degree (if any) might loss of public confidence in banks complicate the task of fixing code bugs?; (5) What legal ramifications might be caused by an unmanageable error rate?

North's position comes out of his own personal crystal ball. To counter it to his satisfaction, you must convince him that your crystal ball is superior. Good luck.

-- Flint (flintc@mindspring.com), May 11, 1999.

But if someone can describe to me a real world financial transaction flow where a piece of bad data from an unremediated bank could propagate through the entire financial system like some sort of virus, and actually do damage along the way, then I would be very interested in seeing it.

Definitely looking in the wrong place here. Been trying to get an answer to that for awhile now.

BTW, Dano, nice redirection. The "collapse" within living memory obviously had nothing to do with electronic transactions. Neither does the printing of money, or the PR campaign.

Pretty typical. Can't address the post, so let's try sliding the question around.

-- Hoffmeister (hoff_meister@my-dejanews.com), May 11, 1999.

Hoff, don't you understand the concept of ANALOGY, of EXAMPLE? If you did, then you would see that Dano did a superb on-target treatment!

North's crystal ball is bleak, it only sees the "worst case scenario". Even with the passing of corrupt data -- which will indeed skyrocket come Y2K -- it may be that no real damage will occur. NOBODY KNOWS. Personally, I like to play it safe. Can you say, "All the money out of my account, in cash please"? Can you say, "Lump sum payment on my 401k, the taxes and penalties be damned"??

-- King of Spain (madrid@aol.com), May 11, 1999.

No, King, don't see it.

The post was directed at the oft-repeated notion of bad data "systemically" propagating through the banking system, causing its collapse.

No doubt, the idea of "panic" is probably a greater concern. But that was not the point of the original post.

-- Hoffmeister (hoff_meister@my-dejanews.com), May 11, 1999.

With regards to the statement made that:

"If Bad Bank A sends valid, but corrupt, data to Good Bank B, then what you end up with are data records in some database at Good Bank B which are incorrect in some way. But they are not going to modify other, non-corrupt, data records that may have come in from Good Banks C, D and E."

I would beg to differ with the statement that a few corrupted data records always remain isolated and do not impact on other records in a database. In the IS department where I work we experienced just this kind of problem about seven years ago. It involved a code bug that resulted in two orderbase records becoming corrupted on our database. These two messed up orders, during nightly processing, caused massive linking errors which, in addition to corrupting our entire order base, also resulted in a massively corrupted order fulfulment feed. This bad feed messed up 500 orders down through our entire logistics supply chain affecting systems and databases at six other plant & warehousing sites. Only part of this mess could be fixed by system fixes and re-processing. The bulk of recovery involved much manual effort over a period of two months by a number of our business and IS people. In addition, an estimated $5 million in cancelled orders was attributed to delivery delays stemming from this disaster.

All these headaches resulted from just two corrupted order records created by a single obsure program bug. Ripple-effects from corrupted data can extend far and wide. Being burned once makes me shudder to think what the impacts of multiple serious Y2K data corruptions could be.

-- Some Programmer Comments (arxyz@magma.ca), May 11, 1999.

Hoff, let me again try to clarify. I mean play it safe BECAUSE of the POTENTIAL for bad data to spread, to infect, to cause big problems, etc. It had nothing to do with panic, though obviously if people could ever understand what the risks are with Y2K and banking, you bet you would see some panic.

I know that the bad data spread problem has yet to be proven to your satisfaction. I doubt if it ever will be. I am sure not going to wait until it is.

-- King of Spain (madrid@aol.com), May 11, 1999.

I too went through a few nightmarish weeks when an obscure bug blew out some links. Sure can corrupt a lot of data in a hurry when that happens. Much worse than simply storing incorrect values with valid formats.

I wonder how likely it is that y2k fixes might introduce errors of this type? Would it be worse for expansion than windowing?

-- Flint (flintc@mindspring.com), May 11, 1999.

Flint: It is the contention of Ivan Mingham, an expert (30+ years) mainframe programmer (Infomagic) that the modified code itself will have enough bugs when put into production to collapse the whole nine yards. Period. You won't even have to worry about y2k processing errors, and Hoff and Andy's notorious "bad data".

-- a (a@a.a), May 11, 1999.

This doesn't address the initial question, but it seems appropriate here, having to do with Y2K disclosure policies of the banking community.

A flyer from an investment advisor (not Gary North!) turned up in today's mail. The pitch was to Y2K-proof your financial situation, starting with bank accounts. This adviser had asked "14,000 banks, S&L's and insurers, Will you be ready for Y2K?" The flyer quotes from a few letters he says he received in reply:

1) from Raymond Natter, Acting Chief Counsel, Comptroller of the Currency: "National banks may not respond to requests by private companies for the institutions' Year 2000 ratings assigned by the Occ. We are advising national banks that, regardless of their Year 2000 ratings, they should not give responses to such requests or to other questions that could have the effect of disclosing a bank's assigned rating..."

2) from Lori A. Champion, Esq., Gorham Savings Bank: "We are under no regulatory or legal obligation... to provide any such Year 2000 compliance information... we will seek all legal recourse against you."

3) from W. Curtis Stitt, Superintendent, Ohio Department of Commerce: "You are advised that you cannot reveal the (Y2K) regulatory rating should you somehow become aware of the rating."

4) from K. Gary Reynolds, President, Centralia Savings Bank: "Be advised that any survey results compiled by your company... will result in dire consequences."

Is he making this up?

-- Tom Carey (tomcarey@mindspring.com), May 11, 1999.

NO< He's NOT making it up. There is a thread down below that quotes the relevant regs.

Chuck

-- chuck, a Night Driver (rienzoo@en.com), May 11, 1999.

Flint -

I think your last two questions may actually turn out to be the most critical ones. Especially considering some of the six week programming wonders I saw turned out around here last fall/winter - several temp agencies appeared to have their own 'you can learn COBOL in 60 days or less' schools going (those seem to have disappeared in the last couple of months, though).

The ironic part of all of this, is that the polly arguments concerning 'self-fulfilling prophecies' may actually be partially true WRT errors being introduced due to attempts to fix y2k noncompliant code. And of course it's too late to stop those attempting the fixes at this point.

Arlin

-- Arlin H. Adams (ahadams@ix.netcom.com), May 11, 1999.

Lisa - You're right of course, when you discover a problem with financial data you lock the doors and fix it immediately. I was only attempting to present one scenario where corrupt data was passed around without causing a collapse. And I think it's a valid scenario of a sort that happens every day. And no one has yet demonstrated to me that Y2K errors will be qualitatively different from errors that occur today. In fact, I think that Y2K errors will be more blatant for the most part, and easier to spot. My quarrel is with North's rhetoric that paints the financial system as some sort of delicate crystalline web that will shatter into a million pieces the first time some bank transmits a bad number. A non-technical newbie who reads his stuff is likely to conclude that if one bank anywhere has unremediated systems then we are doomed. That's nonsense.

'Some Programmer Comments' -

Just out of curiousity, was the corrupt database on a mainframe system, or was it in a c/s environment? Also, were the records corrupted by an internal process, or did they come in from the outside?

-- Polly (skippy@innermongolia.com), May 12, 1999.

Well, 'a', Ivan's record speaks for itself.

Tell me, why haven't we crashed yet? If I had to guess, well over half the systems being repaired or replaced for Y2k are already back into production.

So, when will this "critical mass" be reached? I'm sure there have been plenty of errors, but they've been fixed, with I'm sure a few exceptions. They aren't accumulating. If I remember, Ivan predicted critical mass around July. Is that still his prediction? Or has that been sliding along.

-- Hoffmeister (hoff_meister@my-dejanews.com), May 12, 1999.