IQTrainwrecks.com

In a taste of the change of emphasis that is seeping through the global financial services industry, the Irish Financial Services Regulatory Authority is pursuing 24 cases of overcharging by banks and insurance companies, according to this morning’s Irish Independent

Of course, stories of financial services overcharging and other information quality disasters in that industry are not new to the IQTrainwrecks reader. Over the years we’ve covered them here, here, here, here, here , here, here, and here (to select just a few).

We’ve also covered the growing “hard touch” trend in Financial Services that is bringing a clear “cost of non-quality” to bear on banking/financial services processes (see this post from August of last year).

Why is this now an IQTrainwreck again?

• Regulators are adopting a tougher line with banks about overcharging/undercharging (a bit like the regulators did in my former industry – telecommunications).

The new chief of the Irish Financial Services regulator is concerned about the number of overcharging cases and recently said that:

It is clear from recent cases that change is needed in how firms handle charging and pricing issues.

• Financial services companies, facing into severe cutbacks in budgets and man power are potentially increasingly exposed to the risks of manual work arounds in processes simply stopping, end-user computing controls not being run,  and ultimately inaccuracies and errors creeping into the information they hold about the money they hold for or have loaned to customers.

As the regulatory focus shifts from ‘light touch’ to ‘velvet fist’, those financial services companies who invest in appropriate strategies for managing the quality of information in a culture of quality will be best placed to avoid regulatory penalties.

From The Register comes this wonderful example of the problems that can arise where data is used for unintended purposes, resulting in poor quality outcomes for all involved.

The NYPD have been regularly raiding the home of an elderly Brooklyn couple. They’ve been hit 50 times over the past 4 years, which might mark them out as leading crime kingpins but for the fact that their address has wound up included in police data used to test notification systems. The Reg tags this as “a glitch in one of the department’s computers”, but Information Quality trainwreck observers will immediately recognise that the problem isn’t with the technology but with the Information.

The trainwreck is compounded by two facts which emerge in the article:

1. NYPD believed that they had removed the couple’s address from the system back in 2007, but it appears to have not been the case (or perhaps it was restored from a backup)
2. The solution the NYPD have now implemented is to put a flag on the couple’s address advising officers NOT to respond to calls to that address.

The latter “solution” echoes many of the pitfalls information quality professionals encounter on a daily basis where a “quick fix” is put in to address a specific symptom which then triggers (as el Reg puts it) “the law of unintended consequences”.  To cut through implication and suggestion, let’s pose the question – what happens if there is an actual incident at this couple’s home which requires a police response?

What might the alternative approaches or solutions be to this?

(And are the NYPD in discussions with the Slovak Border police about the perils of using live data or live subjects for testing?)

Courtesy of Dataqualitypro.com on twitter comes this story about how Virgin Media in the UK have sent a letter to a customer prospect addressing them as “Mr Illegal Immigrant”.

Virgin Media have investigated the issue and state that it was an isolated incident arising from data purchased from a 3rd party. This suggests that Virgin Media might have issues with the quality control processes they apply to vetting data purchased from 3rd parties.

From an IQ Trainwrecks perspective, this ticks a lot of boxes as it has resulted in embarrassment for Virgin Media and hassle and trouble for the actual householder, a Mr Needham who told the Daily Telegraph that:

… he was offended by the letter: ”I was a bit shocked. I was taken aback. I have tried to ring up and complain and they have not really done anything about it.

”They kept passing me from pillar to post. They tried to say it was not their fault, it was somebody else. It is not good.” read more…

From today’s SUN tabloid newspaper in the UK comes this great story about how automated processes without adequate business rules and checks on information can cause embarrassment.

It seems that local government authorities in the UK have been fining themselves for parking offences and then suing themselves when the fines aren’t paid. Things have even gone as far as councils seeking awards of legal costs against themselves when they haven’t complied with their requests to themselves to pay themselves the fines that they imposed on themselves for parking their vehicles in places where they had decided people shouldn’t park.

It seems that none of them have yet tried to argue the defence that was put forward in Ferguson vs British Gas.

The lesson here is that when defining an objective in a process one should take the time to consider the various scenarios that might occur in that process and then ensure you have adequate checks and balances and controls to prevent embarrassing and costly errors from occurring.

Oh… and knowing that your customer is yourself is also a good idea.

A correspondent in the field, Nic Jefferis has sent in this story about how a “database glitch” has affected customers of the Egg on-line bank who have been trying to pay their bills using their NatWest debit cards.

The BBC describes the problem very succintly:

“The problem is that the Egg website does not recognise Natwest Visa Debit cards as being legitimate cards.”

The root cause seems to stem from the fact that key base data used by Egg’s on-line bank, the valid set of Bank Identification Numbers, appears to to not include NatWest Visa debit cards as they are only being rolled out at the moment to replace the existing Maestro Debit card facility currently in use at NatWest.

And at this point the second common component of IQTrainwrecks raises its head – who is responsible for the data.

Egg get their data from Experian. As soon as the problem arose, Egg contacted Experian to get a solution.  Natwest state that they were “aware of this problem and raised it with Egg at the outset” and were waiting for Egg to sort out the problem in their systems.

Somewhere in the process for maintaining BIN master data something has gone awry which has affected the ability of NatWest customers to pay bills using their new Visa debit cards. As the problem appears to be in the underlying base data, it is possible that there are impacts wider afield than just Egg’s payment systems.

As a source quoted in the BBC report says, this should be a straightforward process and an error like this would be highly unusual. But as we know here at IQTrainwrecks, it is often the simple errors that can have the biggest knock on impacts in downstream systems and processes resulting in loss, damage, injury, or frustration.

IT media sources are reporting that reports of the demise of the Y2k bug may have been premature. (see also here)

Systems affected included Spam control software and other security software from a leading vendor, network equipment from leading vendors as well as credit card payment systems in Germany and Australia, as well as (it seems) Windows Mobile. The bug was tweeted heavily on Twitter.

The effect of this bug seems to have been to catapult messages forward in time by a few years, resulting in credit card terminals rejecting cards as they failed date validation checks (the card expiry date was in the past apparently), valid emails being flagged as spam (because the message was date stamped in the future), and SMS messages appearing to come from the future.

The potential knock-on impacts of this error don’t bear thinking about. In the immediate term we have:

• Embarrassment for credit card wielding shoppers who found themselves unable to pay for purchases or meals.
• Missed emails due to them being flagged incorrectly as SPAM (although this has been fixed).
• SMS confusion.

But, in this automated world where processes are triggered by business rules based on facts and information there are potentially other impacts:

• Discovery of emails or SMS messages in criminal or civil litigation (will the lawyers think of looking in the future? Can the evidence be verified if it appears to be from the future?)
• electronic transfer of data or funds based on rules
• Calculation of interest payments or penalties based on date rules

The root cause of this problem appears to have been assumptions about dates, and the thought in 1999 that 2010 was sufficiently far in the future that (one must assume) everyone assumed that a better fix for the rules being applied would be developed by then.

The Irish and International media have been busy the past few days covering the story of the horrendously botched security test by Slovakian Border Police which resulted in 90 grams of high explosive RDX finding its way to Dublin from Bratislava in the backpack of an unsuspecting Slovakian electrician who was travelling back to Ireland after Christmas at home. This lead to a street in Dublin City Centre being closed this past Tuesday, with homes and businesses evacuated, while police and Army bomb experts raided the innocent electrician’s home to secure the explosives.

A full timeline for the story can be found here.

This is a tale which has a number of classic elements of an IQTrainwreck about it. read more…

Poor geographic data gives rubbish results.  Recently I read in Railways Africa:

“Electronic files of Southern California’s rail system can be downloaded from the Federal Railroad Administration’s website,” the Los Angeles Times says, “but are riddled with errors, placing hundreds of rail crossings at points far from any railroad tracks. Many are shown in the Pacific Ocean.

Source: LEVEL CROSSINGS IN THE PACIFIC OCEAN Published 2009-10-02

The article goes on to report that level crossing (aka grade crossings in the USA) accidents are porly recorded, and a number of known accidents do not appear in the database.

In the state of New South Wales, careful analysis of level crossing data found that where trains involved in level crossing accidents were not exceeding 120 km/h (75 MPH), derailment and loss of life to those on the train was avoided, and led to the max speed limit reduced from 160 to 120 km/h. So you would think that accurate rail accident statistics are vital in saving life.

But lest you think that southern Californian railway companies are the only culprit here, see the New South Wales Government shows a water monitoring site OURIMBAH CREEK UPSTREAM OF WEIR about 10 km offshore…

How do you plan to monitor fresh water in a river 10 km into the Pacific Ocean?

Two different NSW Government web offerings for the same location reveal a data quality problem:
1. The HITS site shows longitude 151.771 degrees East
2. The Real Time data sites shows longitude = 151.344 degrees East. This location makes more sense:

So in this case we can probably assume that the offshore coordinates are wrong. But when we find two differing sources of data, how do we determine which is accurate?

Inaccurate location data can cost utilities big money. And in the case of inaccurate level crossing locations, it can cost lives.

The Irish Sunday Independent reports this past weekend that the Irish State Broadcaster RTE is facing legal action from its erstwhile privately owned competitor TV3  arising from what are described as “significant and egregious” errors in the listings published for TV3’s programmes over the Christmas period in the RTE owned listing’s magazine “The RTE Guide”. The errors affect listings over the core Christmas period and also the time of one movie which is due to be broadcast tonight at 9pm but which is listed incorrectly in the Guide.

In a wonderful example which highlights the potential downstream cost and revenue implications of poor quality information, TV3 says the error is so serious that it could have a fundamental impact on its Christmas viewing figures.

And, in TV-land, viewing figures translate into hard-to-come-by-in-a-recession advertising revenues.

TV3 have asked for RTE to pulp all copies of the RTE Guide still in shops and to replace them with reprints which show the correct listings. Failing this, they have asked RTE to give prime-time advertising coverage on TV and radio to TV3 programmes over the Festive Season, which would have the effect of reducing the prime-time advertising slots which RTE would have already sold over Christmas, hitting RTE’s revenue streams as well.

RTE, for their part, blame a 3rd party supplier for the errors.

Of course, this writer’s thoughts are with the ultimate information consumers here… the viewing public. If my house as a teenager was anything to go by, the RTE Guide will have been used as the basis for negotiations about who gets to see TV ‘live’ versus programming the video recorder.

A while ago, Daragh O Brien wrote on his blog about the likely rise in Information Quality litigation, particularly as studies have shown that people become more litigious during a recession. This looks like one of those cases and it seems 2010 will be an interesting year for Information Quality management principles in Ireland.

A little later than we had planned, IQTrainwrecks.com is proud to publish the December edition of the IAIDQ’s Blog Carnival for Information Quality, a retrospective on blog posts that appeared in November.

[Edit: We'd actually missed one submission when we posted this. A horrendous oversight given the importance of the discussion. Apologies to Dylan Jones and the team at DataqualityPro.com for the boo boo]

Dylan Jones of DataQualityPro.com opens proceedings with an excellent and thought provoking debate about the nature of information quality and the role of Data Cleansing in a data driven business. The comments on this post are as interesting as the questions posed.

Then we had a short and sweet post from Dalton Cervo where he extolled the need for your information quality and data governance initiatives to be more than just a grab-bag of buzzwords but actually to be planned and executed with the understanding that each is a part in a machine that makes your business great and is capable of reacting and adapting to change.  My experience echoes Dalton’s very wise example that if the problem in in one process, the fix might need to be in that process and a number of other supporting processes.

I suppose, just like any other ‘manufacturing’ process, if the components of your machinery aren’t working in unison as they should, then the product will be defective and your machinery will eventually break.

(For those of you who don’t know Dalton, he’s  the Customer Data Quality Lead at Sun Microsystems, part of Customer Data Steward and a member of the Customer Data Governance team responsible for defining policies and procedures governing the oversight of master customer data.)

Next up is Charles Blyth. Charles is a veteran of the BI and MDM world from the business perspective. His blog post addressed the need to get Data Governance (and by extension, responsibility for information quality) back to the front-line:

Front line Data Governance is about driving data ownership back into the business, getting every resource at every data touch-point to ‘own’ the data. Get the people involved!

At this time of year when every magazine, TV station and pundit is producing their lists of things that happened in 2009 or will happen in 2010, Henrik Liliendahl Sørensen shares with us his 55 reasons to improve Data Quality. Each of these on their own is the seed for a business case (how many duplicate Christmas cards did you get from your suppliers this year?) and should form the basis of Information Quality New Year’s resolutions in companies around the world.

Jim Harris has also been busy in November with a range of posts on his own blog and on the Dataflux Community of Experts blog. At this time of year when a festive gent up living around the frozen North Pole (no… not Henrik, I’m talking about Santa Claus) is making lists and checking them twice, it is only appropriate that we’d pick Jim’s great post on Customer Incognita, where he talks about the challenges of defining the simplest fact most businesses need to know. Now… how would he handle “Naughty” and “Nice” as attribute definitions?.

Finally, Daragh O Brien shared some thoughts on how you need to keep your customer in mind when making changes in processes or technology so that you don’t wind up causing problems downstream and creating IQTrainwrecks in the process.

The look back on December will appear in January. Thanks to everyone who has written such thought provoking and stimulating posts on Information Quality in 2009. It’s hard to believe that there wasn’t this community of writers in existence this time last year.