The future Y2K bug. Releasing in year 2016 at your business applications.

If you thought that the Y2K bug has come and gone, think again. It was just dormant, and it's slowly resurfacing. When will it strike you ask? Read further to find out...

Many regulated services industries, including the financial services sector, have a business application that captures their client information. Part of the regulations will require that one obtains documents for validations that the client says who he/she is. One of the government accepted document is the National Identity document.

Wait, so what is so special about the National Identity Document and how does it relate to the Y2K bug? Simple, every citizen of a country has a National Identity Number (NIN) and some of them contains the Date of Birth.

So far, I've seen the date of birth captured as YYMMDD or DDMMYY (DD is 2 digit date of month; MM is the 2 digit month of year, 01 being the first month & 12 being the last month; YY is a 2 digit year, excluding the century). 

Now, here's the kicker: Many applications determine the Date of Birth from the ID number alone: Why, you ask? Simple, validation purposes:

1. Based on the ID number, one can extract the date of birth and using computed algorithm, a precise age can be calculated.
2. A validation can be used by extracting the date of birth from the ID number and validate that the date of birth captured on the application matches.

The South African Identity Number (SAID), in this example, is captured in the following format: YYMMDDSSSSCAZ. The exact explanation can be found on the Wikipedia page. We're just interested on the date of Birth.

Now, let's break down the 2 items listed above. The valid scenario will be as follows: You were born on the 01 January 2000. You have just survived the Y2K bug doomsday clock and you've survived this cruel world to live to be 16 years old (in year 2016, obviously). The South African Home Affairs department has issued you a valid National Identity document. 2 years later, you've hit the big 18 and you're eligible for various things. One of those things is to apply for a bank account (Can you get it at age 16?) and apply for credit. Years past, you studied further, got a qualification, got engaged, married and you decide to take credit to build a family home for yourself.

For item 1, we extract the date of birth from your ID number. In this case the first 6 digits of your ID number is 000101. Now, here's the kicker: Many applications still prepend the century in front of the date, especially the 20th century, the 1900's. So, your date will be, essentially, 1900-01-01. In year 2016, this makes you 116 years old. The crisis here will be with the company business rules, particularly when determining your risk profile and affordability. Those aged over 85 years are considered high risk (because they've got a short life span and they're living on pension or government grant). Now you want a lump sum of credit from a credit service provider and they refuse you credit because you're 116 years or older (wait....what?).

You'll be asking me, where do they use such algorithm? Here's a scenario. Have you ever heard this type of message on an ad "SMS your name, ID number and <option> and we'll quote you for a list of <products> that <list benefits here>.". Many financial service providers provide a quick quote functionality, where an ID number is essential to calculate your age without the need of capturing your actual date of birth. Essentially, when you're quoted on something basically.

For item 2, we follow the same process as item 1. The difference is that the agent captured your actual date of birth as 2000-01-01. Now, you have an algorithm which states that, based on your ID number, your date of birth is 1900-01-01 and your actual date of birth is 2000-01-01. Now, if a comparison is done, this will fail as year 1900 is not equal to year 2000.

Essentially, you are an outlier, a generation that we not accounted for when they first developed the initial system. Why? Because no-one thought beyond the year 2000 when programming languages were first created. There are possibly a good chance to find a solution on the internet that follows item 1 and 2.

Why is this an issue?

Ok, you still think it's not an issue? Let me break it down for you:

Many enterprise applications that is currently running in major corporate organizations are very old. They still follow the paradigm "If it ain't broke, why fix it?". So, chances are, an old dinosaur programmer added the logic I've described above and you have a ticking time bomb.

Now, we move to newer technologies. Your organization asks that we won't our system to be on the web, on the cloud and on mobile platforms. Your old systems were not designed to be portable to the cloud, so what do you do? You write a system, each system for each platform. Your developers realize that your organization wants to be one of the first to launch the product on the market, to gain market share or eat the major share of the market share pie, and they've given you a strict deadline, 6 to 8 weeks (or 3 to 6 months) anyone? What do your developers do? They follow the DRY (Don't Repeat Yourself) principle and copy-paste code (with headphones on their ears to not listen to their micro-managers nagging every 5 minutes asking "Are you done?").

Now, 9 months turns to 18 months and, finally, your product is LIVE. You have a mobile app, a service oriented application, full of business logic and what do you know, it works like the old system. Problem is: Your testing team has NEVER tested the future scenario of year 2016 and beyond. The Y2K bug lurks in the shadows of 0's and 1's.

I know, I know, you're probably saying that I'm bluffing. I have seen this scenario recently, from 2 companies. In one of the company, this was done by a Senior Software Architect! 

So now, how do we fix it?

There are 2 options:

1. Use the actual date of birth field to calculate the client's age. This will mean capturing the client's actual date of birth including the century of the client's year of birth. What I'm saying, capture the date of birth as 2000-01-01 and not 00-01-01.
2. If you still think that ID number date and age validation is sufficient, add another field that will indicate which year of century the client was born from. This will be essential as the same dilemma will exist around every millennium (wait, I'll be dead by then, so why should I care?).

I know, application maintenance cost is expensive but one cannot escape it. I hope you take heed to this warning. This bug is definitely in many applications running today. Thank your parents, kids, for introducing this bug. When they'll retire with their millions, you'll be screaming that you want to bank with Steve from Beep Bank. I hope they are using better date of birth validation.