OK then if i must
I have to ask, do they take Visa in Zimbabe?
It seems an empty amount field is the culprit in the programming glitch that caused some 13,000 holders of prepaid Visa cards to receive warnings that their accounts were overdrawn by more than $23 quadrillion. At least, that's the theory advanced by several Register readers, who posit an 8-byte blank field was converted to …
Were the affected cards flagged to prevent them from being used after this erroneous transaction? As I understand things, if a credit card is used out of character then it is blocked until it can be confirmed that said activity was made by the card holder. If they weren't blocked this would imply that it is quite normal for these people to pre-load their cards with 23 quadrillion dollars so as not to carry small change with them.
Is very poor practice to freely convert an important value from one format to another and back and forth. This was recognized as poor practice, but common, among FORTRAN programmers 30 years ago.
Have often heard one of the driving forces keeping COBAL alive was a data type where data (money) was kept in BCD. Seems that was easier to understand for management types than fixed point binary integers.
This is common in program writen in COBOL , when you modified the structured of the fields on the record to make the record more big, so the binhex theory is correct, 0x20 in hex is equal to character 20 in ASCII (nothing) but when you display or print this character the result is 20, so if have 0x200x200x20 the result is 202020 and so on
It is more likely that the number was displayed incorrectly on the statement but never existed in the actual banking system. This would explain the lack of alarm bells being raised before the customers viewed their statements. It also explains how such an improbably large number existed, it wasn't in the bank's computer system rather it was generated by whatever software tool was being used to display the statement. The software being used to print statements for a small number of customers is also unlikely to have the vigorous testing that a system dealing with actual money has.
It was probably someone incorrectly merging a data set with a bank statement template, the sort of silly error that happens in offices all over the world every day. You can put the pitch forks down, well spotted but there is no need to burn any witches.
P.S. this is just speculation but I am normally right about these things.
As far as I can see it was me who suggested the rounding theory in my post "@Visa deserves glitchslapping? # By Anonymous Coward Posted Wednesday 15th July 2009 19:52 GMT".
Has anyone actually seen a repro of one of the affected statements yet, or are we still just relying on press wire stories for the figure, where it might easily have been rounded to a nice multiple-of-100? It would be informative to see if it actually was $23,148,855,308,184,500.00 or really $23,148,855,308,184,535.36 on the actual invoice.
What's good for the goose.... I hope all those given a penalty will return the favour by charging their own penalty to the banks concerned. Of course, it may well be that some people's costs to rectify the errors (time, telephone, postage) are significantly higher than the costs for the bank to send a standard letter....
To the couple of posters asking about this not being flagged as fraud or irregular activity, as others have mentioned, this amount almost certainly never existed in any financial system. It's just an error in the way the report was generated. Those fraud detection systems monitor transactions as they come in and look for certain patterns (a common one being several consecutive payments for a small amount - to check a "generated" number is actually an active card).
So no, VISA would not have flagged this up as fraud and blocked the card.
No the field that was incorrect was the one that took the account over the limit. This number would be formatted differently to indicate going over the limit. This is why only a small number of accounts showed the absurd number, and why it got through on the nod, as none of the accounts the person mapping the data to the template looked at were over the limit.
As for the not having to pay the "fine" if you phone up and complain the banks normally waver this as there is no law allowing a bank to reinforce a punitive fine anyway.
I take it that Noggin had never been to Turkey before they revalued the currency then? There was a surreal quality about handing over a 1 million note for a ten minute taxi ride and not expecting change.
Even a fairly modest hotel bill used to require at least two card payments as the PDQ processing systems wouldn't handle the numbers concerned in one swipe. I remember being pleasantly surprised when Mastercard implemented something internally that automagically vapourised the "duplicate" transactions.
Anon, 'cos I expect that a certain Turkish hotel was unpleasantly surprised.
"So the AC in the article asserts that it's QA's fault for not finding the bug, typical programmer, using QA as a safety net for shoddy code."
Well perhaps in your organisation developers invariably deliver 100% perfect code but in most organisations QA/Testing are indeed a safety net for the developer's (and analyst's) mistakes and they perform a vital function. It seems to me that the test cases performed were obviously not adequate to catch this mistake.
Who is this Anonymous Coward who posts such brilliant solutions?
Mind you, this same Anonymous Coward also posts a lot of flame bait, retarded posts and the such, so it's definitely a person with a multiple-personality disorder.
Black helicopters will be dispatched to find the true Anonymous Coward soon.
"So the AC in the article asserts that it's QA's fault for not finding the bug, typical programmer, using QA as a safety net for shoddy code."
Not all of us blame QA... but then again what should organizations expect when they expect code to be completed *yesterday*
True, QA should have picked up on the issue, but so should have the developer. Everyone seems so quick to point the finger at others nowadays. Some bugs just go unnoticed... look at VMWare some months ago when they left an date check statement in an update rendering entire virtualisation environments useless. Even the biggest development houses make mistakes.
Sorry might have got the wrong end of the stick so feel free to flame away. :-)
The main new around here was a cigarette purchase at a Mobil gas station
http://www.upi.com/Odd_News/2009/07/15/Man-baffled-by-23-quadrillion-overdraft/UPI-31881247688026/
I like this bit "The Bank of America referred questions about the issue to VISA, which recommended questions be addressed to the bank"