I'm researching the interdependencies of Banking systems for an article that I'm writing. It's my view that the biggest threat to the world financial system (which is totally dependent on computers) is the problem of imported data. Or rather the problem of imported corrupt data, which is correctly formatted and parsed and thus gets by the standard EDI checks and balances, but is inaccurate and thus the inaccurate data will be processed and further propagated throughout the financial system on rollover.

It is my view that, say for example Citigroup, after spending 900 + million dollars, declares itself compliant in late '99, will be exposing itself to contamination. How will Citigroup protect itself from the non-compliant banks that it interfaces with world-wide? Can a firewall be constructed that will weed out corrupt data? I really don't see how this can be done.

Similarly, bank isolation has been proposed. I don't see how this can work in practice.

Any thoughts on this subject would be greatly appreciated, whether you agree or disagree. Any direct experience of IDI and data interfaces mechanisms would be most helpful.

Thanks,

Andy

By the way the following statement was recently issued by Koskinen - I thought to myself, am I in an episode of the twilight zone? :)

"It's clear to the federal regulators, of all the industries in the United States, that the financial institutions are in the best shape."

Andy

Two digits. One mechanism. The smallest mistake.

"The conveniences and comforts of humanity in general will be linked up by one mechanism, which will produce comforts and conveniences beyond human imagination. But the smallest mistake will bring the whole mechanism to a certain collapse. In this way the end of the world will be brought about."

Pir-o-Murshid Inayat Khan, 1922 (Sufi Prophet)

Only if the imported data problem can be disproved or solved.

-- Andy (2000EOD@prodigy.net), January 18, 1999

Answers

This is an example from No Spam to get you thinking :)

Example -- Bank A sends Bank B a funds transfer with the following data:

Date: 2000-01-06 Time: 09:00:00 Type of transaction: Transfer checking-to-checking Source account: Bank A account number 123-456- 789 Destination account: Bank B account number 987-654-321 Amount: $5,435.43

Looks okay. All field data correctly formatted, all numeric fields within bounds. Date is in ISO format with four-digit year. Bank A account 123-456-789 had to have sufficient funds in order for the transfer software to send the transfer request.

Except --- What is not apparent in the transfer data is that Bank A account 123-456-789 was incorrectly credited on 2000-01-06 at 08:31:00 with interest in the amount of $5,555.55 instead of the correct amount, $5.55, because of a Y2k bug. Thus its available balance at 09:00:00 is $5,550.00 larger than it should be. At 08:00:00 the Bank A account's correct balance was $321.00, and at 08:59:59 its balance should have been $326.55, quite insufficient for a transfer of $5,435.43 out of it. But because of that not-yet- detected Y2k bug, that Bank A account's balance appeared to have been $5,876.55 at the time the transfer was requested, and thus was deemed to have had sufficient funds.

Oh, and the Bank A account owner wasn't trying to get away with ill- gotten gains -- she didn't yet know that her account balance was so high, and she was trying to transfer merely $5.43 (an automated request to pay a monthly bill). A Y2k bug related to the other Y2k bug caused her requested transfer amount to be changed from $5.43 to $5,435.43!

To recap the amounts:

Bank A account 123-456-789 balance as of 08:00:00 = $321.00 Correct interest amount to credit at 08:31:00 = $5.55 Correct account balance at 08:59:59 = $326.55 Correct transfer amount at 09:00:00 = $5.43 Correct account balance at 09:00:01 = $321.12

Actual (incorrect) interest amount credited at 08:31:00 = $5,555.55 Actual (incorrect) account balance at 08:59:59 = $5,876.55 Actual (incorrect) transfer amount at 09:00:00 = $5,435.43 Actual (incorrect) account balance at 09:00:01 = $441.12

Bank B account 987-654-321 is credited with $5,430.00 too much as a result of the Y2K bugs. Bank A account 123-456-789 winds up with $120.00 too much as a result of the Y2K bugs. In the given example, Bank A was not Y2K-compliant. Bank B was Y2K- compliant, but now has incorrect data not detectable by edit-checking of the transfer from Bank A.

Now if this type of transaction at Bank B runs into serious numbers in terms of quantity of transactions, bank B is in serious trouble. It will process inaccurate data and fire off this data to umpteen other different financial entities, which will all be facing exactly the same problem, at the same time, world-wide.

Result = cross-contamination/infection.

Result = Meltdown. Grid-lock. Deadly embrace. No more Banks.

Anyone see any fault in the above logic and/or the whole scenario???

--

-- Andy (2000EOD@prodigy.net), January 18, 1999.

Andy,

There's a section on the Federal Reserve's Y2K site called "How Computers are Used in a Bank." It's at...

http://www.bog.frb.fed.us/y2k/howcompu.htm

The Federal Reserve's Y2K site is at...

http://www.bog.frb.fed.us/y2k/

The FFIEC's Y2K site is at...

http://www.ffiec.gov/y2k/

Hope this helps.

-- Kevin (mixesmusic@worldnet.att.net), January 18, 1999.

Andy,

There's also the Bank Administration Institute Y2K site:

http://www.bai.org/y2k/

-- Kevin (mixesmusic@worldnet.att.net), January 18, 1999.

Excellent - thanks Kevin - I'll check then out.

-- Andy (2000EOD@prodigy.net), January 18, 1999.

In case anyone is interested, this all came about after ANZ Bank in Australia announced that they were compliant.

I posted to the csy2k group that I thought this was not truthfull, that no bank on earth is compliant yet in the strictest sense.

[snippet]

From Andy

>Tell me, Bradley, how said bank will process correctly formatted and >parametered yet still corrupt inaccurate data??? > >This corrupt data will have been caused by Date Arithmetic and other >unremediated bugs. > ...

From Bradley

Sorry, but three question marks do not make up for sloppy thinking. Please construct an entirely hypothetical transaction originating at the Bank of Potsylvania (which is unremediated) which somehow causes ANZ Bank to do the wrong thing. You will not be able to. [end snippet]

I want to get my facts straight before responding as there are some very blinkered programmers eager to rip my piece to shreds.

-- Andy (2000EOD@prodigy.net), January 18, 1999.

Full details:-

"The ANZ bank yesterday became one of the first major financial institutions in the world to announce the completion of its internal Y2K computer bug program."

Notice the word "internal" above.

How will said bank process correctly formatted and parametered yet still corrupt inaccurate data???

This corrupt data will have been caused by Date Arithmetic and other unremediated bugs.

Will it reject it? No.

Will it process it? yes.

What will be the effect of processing corrupt data? The perpetuation of bad data, with further corruption along the way.

This bank is not compliant.

No bank is compliant unless the problem I outlined above is solved.

Further details:-

"However, the bank has still some way to go to reach compliance as it has yet to replace and test all of its non-compliant third-party provided software, some of which is dependent on the promises of vendors to deliver compliant versions in time for the date rollover. "

"Westpac's manager of Y2K business integration at Westpac, Mr Andy McPhee, said third-party applications, which ANZ had yet to completely test, made up a major portion of software systems at banks and inter-bank testing was fundamental to a bank's Y2K project. "We're in essentially the same position as ANZ -- we have some outstanding issues related to third-party providers and most of us have key parts of our business provided by third-party vendors."

-- Andy (2000EOD@prodigy.net), January 18, 1999.

Andy,

Thank you for the compliment of using my example. :-)

I wish to add some information, because my example was constructed simply to show how incorrect data could slip past edit checks. In the larger context of propogation of bad data, there are other factors to consider.

>"The ANZ bank yesterday became one of the first major financial institutions in the world to announce the completion of its internal Y2K computer bug program."

>Notice the word "internal" above.

Yes, and notice that my constructed example states, "Bank B was Y2K- compliant", without qualifying the compliance as _internal_.

THAT WAS A FLAW IN THE EXAMPLE. Had I had a larger picture in mind when constructing the example, I might have realized my omission. But I didn't. There's a lesson there. (But give me a break - it was just a simple example, not the real world.)

So I hereby declare that my example intended, and be extended to specify, that Bank B be _internally_ Y2k-compliant, with no claim as to Y2k-status of its connections to the rest of the world.

>What will be the effect of processing corrupt data? The perpetuation of bad data, with further corruption along the way.

It is important to recognize that the computer industry has had to devise various sorts of error corrections ever since the infamous moth-in-the-circuitry which inspired the slang "bug" to refer to computer errors.

But Y2k-remediators need to consider whether existing error-correction measures are adequate for Y2k-caused errors. In some cases, they may. In others, Y2k may overwhelm the capacities of current safeguards.

The electronic funds transfer systems have types of transactions specifically designed to make corrections. In the example given, whenever Bank A discovers the errors it could send Bank B a correction for the $5,430.00 excess in the 2000-01-06 09:00:00 transaction.

_However_, this will take _a certain amount of time_ (how long will it take Bank A to discover its mistake?), time in which the incorrect data may indeed be propogated.

The banking system takes certain measures to allow corrections to catch up with the transactions to which they apply, precisely to avert bad-data propogation. (E.g., banks hold funds from deposits of out-of-state checks longer than those from in-state checks before they're made available for withdrawal, allowing for the longer average time for a correction from out-of-state to reach them.)

A few key questions in discussing propogation of Y2k-related errors through the banking system:

Will the existing correction measures adequately handle an expectedly increased load? Perhaps the system handling 1,000 corrections per day now will collapse when confronted with 100,000 corrections per day.

Are measures being implemented to take care of anticipated new types of Y2k-related foulups?

What is the capability of banks to detect Y2k-related errors?

In the example, if Bank A detects its Y2k bugs within a few hours, it has a good chance of being able to send a correction to Bank B before Bank B propogates the error. If the correction reaches Bank B before settlement time on the same day, there might not be any noticeable consequence of the error.

But if Bank A's bugs go unnoticed for many days, the chances for the corrupt data to infect other banks increases dramatically.

So the time scale for detection and correction is crucial.

>This bank is not compliant.

Here I prefer to say that the bank is _internally_ compliant, but that that isn't the whole story.

>No bank is compliant unless the problem I outlined above is solved.

Here I prefer to say that compliancy is not enough to guarantee absence of Y2k problems.

Rather than use "compliant" in such a general way as to inevitably lead to the conclusion that no entity can ever be "compliant" because there will always be some Y2k bugs somewhere, I recommend that we all recognize that achieving internal compliance is a great step for almost any entity. Each needs to work on itself as well as its connections to others.

Let's just use "compliant" in an orderly fashion, and always specify the scope of that compliancy. Interconnectedness and external dependencies are other parts of the Y2k picture, not synonymous with compliance.

>"However, the bank has still some way to go to reach compliance as it has yet to replace and test all of its non-compliant third-party provided software, some of which is dependent on the promises of vendors to deliver compliant versions in time for the date rollover."

So the bank's internally-developed software may be compliant, which is a significant achievement, but they acknowledge that isn't the only piece of the puzzle.

According to my view, the bank could legitimately claim that its internally-developed software is compliant (if that's what it's saying), but not that the bank as a whole is internally compliant, as long as any of the rest of the software they use is not compliant.

-- No Spam Please (anon@ymous.com), January 19, 1999.

No Spam,

I really want to thank you for letting me use your example. There is a discussion going on now at c.s.y2k, all concerning your example. Please feel free to participate.

At the moment I am taking a lot of flack - but the discussion is certainly a valuable exercise.

The points you raised above are all excellent, and I would have to agree with most, if not all of them.

The thread is at comp.softeare.year-2000

and called "To Hoff Meister, Bradley KS and Don Scott".

It's been going on for a couple of days now.

Thanks again no spam.

-- Andy (2000EOD@prodigy.net), January 19, 1999.