British Government create Major Fraud Incident by using IT to save on human costs! 20+ million pounds lost.

Current benefit scam (Universal Credit) in the United Kingdom has yet again shown how any approval for money given out via online validation is risky. Since the money was provided quickly by the government, scammers jumped on the chance to coax personal information out of people and even to make up fake personal information so they could get access to the most money possible. Current estimates are that over 20 million pounds has been stolen by fraudsters.

To help gain people’s trust, scammers used social media heavily to sell the fraud. Scammers also did the online application so any warnings of what was being signed up for were not visible to the victims of the fraud.

If we look at the original honorable goal of the online application, it was to provide people with money until their benefits were reviewed / approved as the approval process was taking 5 weeks or more. Government thought it would be great to give people money (in a the form of a loan) that would be later paid for by the claimants benefits (if approved) or repaid by the claimant if not approved for benefits. This way, the claimant could avoid cash flow issues. Really, the problem was that the Government did not have enough staff to process the claims quicker. The IT solution along with the loan was a cheaper approach that was badly implemented.

What was completely missed by the IT department working for the British Government when setting up the solution was the implementing of all the rules that human employees would use to process an application. This was a complete failure on the part of the business analysts involved in this software development and has ended up costing the UK government millions.

Some of the functions a human employee would have done in processing the application:

  1. Is the applicant aware of what they are signing up for? – Scammers did the application on behalf of the applicant so the applicants never knew fully. Scammers also used social media to describe the money as coming from a grant and not a loan.
  2. Do I have confirmation that the applicant knows what they are signing up for? As the applicants were not on the web site, they never confirmed what was being done. Victims have found out after the case what was really done.
  3. Do I have some reliable proof that the claim is accurate? Scammers submitted whatever they wanted to state in the claim as the validation was done over the process of 5 weeks after the money had been sent.
  4. Does the applicant know the amount and fees (if any) associated with the claim? Scammers claimed a fee to fill in the application on behalf of the claimant but there were no fees in reality.
  5. Does the applicant know who is supposed to do the claim? Scammers jumped on the opportunity to do the claim as their was no biometric validation (as compared to being interviewed by the government employee) as it was done online.

Here are the functions that we should watch for in our projects that require special attention when we are providing money quickly based on online validation only:

  • We need to guarantee that the party receiving the money is who they say they are and they know exactly how much is their money. This could be done by ensuring they are using an already validated bank account. In this fraud, a lot of the victims actually received the money to their bank account but thought they were obligated to pay the scammers part of it as the scammers had completed the online application.
  • We need to guarantee that the applicant is the one completing the application online so that the applicants are aware of what they are doing. Any warning / informational messages associated with the claiming / providing of money as part of an online application, we have to be 100% sure that the party to receive the money (legally tied to the money) has seen them! A web page pop-up with click of “Yes” along with capturing of IP address is not enough to verify that the person who needed to see the warning / informational message actually saw them. We need to guarantee the person at the computer on the web site is the valid party involved. This is where biometric information or a chip style reader (as used in credit cards) for an identity card would come in handy. Some companies use validated phone numbers with text messaging to achieved this however if the phone number is hacked or changed by the scammer this does not work. With the current fraud, it is several weeks before the Government works out that the claimant never used the web site to complete the application and thus were not aware of what was being signed for.

In summary, the British Government got themselves into this position because they did not want to hire more staff to process claims quicker. It is the classic case of relying on Information Technology to speed up a process on the cheap without due considerations of the risks involved or the human functions being replaced by the computer. Whoever did the analysis and design of this payment solution was incompetent beyond belief.

The Data Lake – understanding the concept

June 8, 2019 by · Leave a Comment
Filed under: Business Analyst Skills, Data 

As data capture has grown so have some of the techniques of handling the data. For about 10 years now, the Data Lake has started to appear in the business world as part of the data capture concept.

Originally when I started out, data was distributed all over the place with business analysts having to ask for extracts from various departments to get an overall view of the company. It was time consuming.

Next came the large data warehouse accepting in data from all over the company to a central store. However it could take years to get that data into the data warehouse. At one place I worked, it was a minimum of 2 years to absorb data into the data warehouse. Delay in getting data in was caused by the need to model the data and understand it completely before it could be absorbed. Data modelers would have to work out if new tables were needed and BAs would have to justify the business cost of storing the data. Add onto this that existing reports would be expected to use the data from the data warehouse and these reports would all have to be rebuilt to use the new data structure.

As companies have evolved to produce even more data, the data warehouse wait time was increasing significantly. Waiting for centralized data however did not tie in well with corporate strategy of being able to know what is going on around the company. At this point the Data Lake concept came into being. The Data Lake is basically a collection point for all data from around a company in any type of data structure. Data does not need to be refined to end up in the Data Lake. Good and bad data is collected. Visually the Data Lake term represents departments that generate data as streams that feed the lake.

As the data collects in the Data Lake, eventually some of it will make its way into the enterprise data warehouse based on need and cost justification. By creating a Data Lake approach, it has created a one source of data for people in a company to access. Data scientists can look at what is being captured and see if any of it is of use to what they are trying to analyze.

Pros of Data Lake:

  • Centralized repository of company data which in theory makes it easier to find data.
  • Quick to capture data into as not refined in anyway.
  • Allows the data source departments to focus on supporting their applications / business and not on providing formal data extracts that have to be absorbed by a data warehouse or other team.
  • Don’t have to wait on departmental availability of resources to get access to another department’s data.

Cons of Data Lake:

  • Resources have to be hired to support the collection of data into the data lake and the sharing of it.
  • Failure to get good searchable metadata on the data being store in the Data lake would prevent the data from being discovered at a later date.
  • Resources associated with the original data generation are not part of the Data Lake team which means the personal knowledge on the Data Lake team is limited to non-existent. Data knowledge is totally reliant on the metadata captured at the time the data is stored.
  • Useful and not so useful data is captured as the focus is capturing data.
  • Dependent on cheap storage to justify the large storage costs and the resources to support the physical storage / networks etc.
  • Secure data should not end up in a Data Lake due to risk that it may be exposed.
  • Not for operational reporting where reports have to be generated in 24 hours or less of data being created.

In summary, the Data Lake concept is just a fancy way of saying centralized raw data store created from data provided via different departments in a company. A Data Warehouse can pull data from the Data Lake for storage in the Warehouse at a later date once the need for it to be stored formally has been identified.