Call Validate - ID Checking

Introduction

In January of this year seven benefit assessors across three separate London councils took advantage of their roles to commit over £1m in benefit fraud.

Using false identity documents and bank accounts they had access to, they took advantage of the roles they had to achieve staggering levels of fraud and extrapolate funds from the public purse when it can least afford it. This being reported just one year after a similar fraud happening across London in Harrow

Cases like these are the reason why benefit applications have laborious verification processes in place that actually slow the administration process down for everyone. In 2011, Risk Based Verification (RBV) became mainstream with the publication of the S11 Circular. RBV recognises that there are specific combinations of variables on claims that means some claims do not need the full amount of evidence the old school Verification Framework suggested. In fact 55%+ of claims actually fall into the low risk category meaning only proof of ID is required. This led to IEG4 building RBV integration into both its eClaim and eChanges (for Housing Benefit / Council Tax Support) products.

However, to get to the pinnacle of evidence verification we considered how we could automate this even further. This led us to realise that if we could:

1. Confirm Identity in real time

2. Validate the bank account details a person provides are not just valid but that they relate to that person claiming

We could remove all evidence requirements from those in the low risk category and simultaneously prevent the types of fraud happening in the two articles previously. Working with the London Borough of Lambeth and TransUnion, IEG4 has integrated its online benefit claim service with CallValidate to achieve precisely this.

Now when a benefit claimant makes an application their identity is checked in real time and evidence required dynamically updated. If they have indicated they want the money paid to themselves and the bank details they have provided do not relate to them, it will actually prevent submission. By leveraging real time web service calls powered by smart credit reference agency functions, we have ensured fraud is removed is prevented intelligently and the many get their applications processed quicker.

Like with the introduction of Risk Based Verification, IEG4 is the first online service provider to integrate to CallValidate into an online form. This release covers the introduction of this functionality into the eClaim (for Housing Benefit/Council Tax Support/Discount).

Functionality

The bulk of the functionality provided in this additional (necessarily chargeable) module is under the hood but at the highest level the functionality is:

1. The ability to send details of both the claimant AND a partner if there is one to the CallValidate service in real time to:

   1. confirm the claimant/partner's identity

   2. confirm the bank account they have provided is valid and relates to them

2. Dynamically hide the evidence requirement for ID for the claimant/partner where the person passes the ID Check in Call Validate. I.e. proof of id might be required for the partner if they failed the check but the claimant passed. This means that if a person is low risk it is technically possible to have the scenario where no evidence is required to make a decision on the claim - assuming their NINO is confirmed and evidenced in CIS.

3. Prevent progression through the form if the person has provided bank details that are invalid/do not relate to them and they want the money to be paid to themselves.

This is a visual and clear addition that does not exist without this functionality. So if a person provides spurious data for the bank account they wish the benefit to be paid to i.e. incorrect and importantly not their bank account they will be presented with the following in the nav menu:

And this at the foot of the the actual 'Paying Benefit' page:

4) The ability to surface the details of the checks done/outcomes on the PDF officers see in document management

This is probably the most visual element of this functionality in that it illustrates the outcome of the checks. There are three high level categories of response and these are that:

1. a) the identity was confirmed. SeeIdentity Result - Yes

This is the high level information returned from the CallValidate check. The details shown on the PDF can be customised by you and can show any of the data provided in the XML response (see point 6) from TransUnion.

1. b) The identity was confirmed with warnings. See Identity Result -YesWarningPresent

Here we can see there is a warning in that whilst the identity has been matched against 5 separate DOB checks for that address, there is a doubt on the length of time they've been resident.

A warning is for information it can still mean ID is not required.

1. c) The identity was not confirmed. See Identity Result - Refer

Refer essentially means that the person's identity was not confirmed and an officer requires to check this:

5) The ability to surface the details of the checks done/outcomes in the back office application's claim notes for officers to refer to. This passes similar content to that on the PDF to the claim notes for the claim that gets created in Capita/Civica/Northgate Benefit systems.

6) The ability to view the response returned from in XML format for diagnosis purposes

This is accessed from the Forms Portal, as shown below:

Settings

The following settings, which will all be set by IEG4 control the ability to integrate to CallValidate. This is more for information that CVEnabled obviously needs to be true and each needs to have a value. The values in each setting other than CVEnabled will be different for test and live.

Setting
CVEnabled
CVURL
CVCompany
CVUsername
CVPassword
CVApplication