30 Million German Bank Cards Almost Fixed

2010 Date Problem Still Exists For Cards Used Outside of Germany

1 min read
30 Million German Bank Cards Almost Fixed

As I mentioned a few days ago, some 2010 date problems hit various electronic systems and devices in different parts of the world on New Years Day. One Risk Factor reader noted that Germany likely experienced the greatest date-related problem because software in a security microchip used in 30 million German bank cards was unable to recognize the date 2010.

As a result, bank card holders weren't able to use their cash cards or credit cards at automated teller machines and point-of-sale terminals from the 1st until the 8th of January 2010.

The German banks whose cards were affected have been trying to reprogram them on-the-fly whenever their customers attempt to use their cards again, say at an ATM machine. However, there are still reports that while the software fix seems to be working for the cards when they are used in Germany, the fix doesn't guarantee that the cards will work outside the country.

The Wall Street Journalreported that at least one bank, Commerzbank AG, has decided to replace any customer's card that won't work outside of Germany.

According to this story in DW-World.de, "The blame for the card malfunctions has been placed on the French manufacturer of the cards, Gemalto. In Paris, the CGT trade union said the company had overworked the staff at its factory in Filderstadt, Germany. It also claimed that staff at a software development center near Marseilles had also been told to cut costs."

There is no word on how long it will be before all the cards are fixed or replaced.

The Conversation (0)

Why Functional Programming Should Be the Future of Software Development

It’s hard to learn, but your code will produce fewer nasty surprises

11 min read
A plate of spaghetti made from code
Shira Inbar

You’d expectthe longest and most costly phase in the lifecycle of a software product to be the initial development of the system, when all those great features are first imagined and then created. In fact, the hardest part comes later, during the maintenance phase. That’s when programmers pay the price for the shortcuts they took during development.

So why did they take shortcuts? Maybe they didn’t realize that they were cutting any corners. Only when their code was deployed and exercised by a lot of users did its hidden flaws come to light. And maybe the developers were rushed. Time-to-market pressures would almost guarantee that their software will contain more bugs than it would otherwise.

Keep Reading ↓Show less