Configuration files are files that can augment / improve the control you have over the functionality in the form beyond the settings.

For the eClaim, there are 7 and these files are covered below:

evidencerules.xml

The purpose of this file is to enable one to control, which evidence is presented dynamically to the citizen when NO Risk Based Verification service is enabled. I.e. This is the default configuration file.

Example file

Note - this file is bigger than this - we've taken an excerpt.

Basically this file enables you to control when each of the different evidence paragraphs appear in the eClaim based upon the person's circumstances provided.

For example, there is an evidence resource called Rule_Identity.

And within that section there is a Rules section that outlines the rules

The rule is saying if there is a surname present for the claimant, which there always will be, ask for proof of identity.

livingsituation.xml

This is an important file in the context of eClaim. The contents of it control:

a) What appears in this list:

b) The behaviour of the option selected

Example file

The file contains a section for each drop down option. The following shows the file with only the first drop down option populates for simplicity of understanding:

The following elements are responsible for different behaviours:

ratesandvalueslcts.xml

Example file

Enables you to change the rates of:

• DLA Care

• DLA Mobility

• PIP Daily Living

As and when they change annually.

This file also has the ability, should it ever change, to update the number of hours that are taken into account before a Non-Dependant Deduction is taken.

vulnerabilitytype.xml

This file is specific to Local Council Tax Support.

It enables a council to set a list of different circumstances that should be exempt from the local council tax support scheme in the same way pensioners are.

Example file

The following illustrates an example file with four different vulnerability options:

Simply remove any items or edit the above file if you want to change the default options. These four options end up showing as follows:

You can add additional options by simply adding another section like the following below the above:

cvwarningconfiguration.xml

This file enables councils using the CallValidate functionality to present a warning to staff based upon the responses back from the TransUnion CallValidate API call.

Example file

There are the following types that can be presented as warnings:

• AddressPickListWarning

• BankAccountClosedWarning

• CardAccountClosedWarning

You can choose to make them active or not in this file.

evidencerulescoactiva.xml

The evidencerulescoactiva.xml file controls the evidence paragraphs presented to customers, like the evidencerules.xml file but with additional behaviours to dynamically reflect Risk Score.

The file is largely the same as the evidencerules.xml file but at the top it has a dedicated section that enables the evidence requested to be set for each risk score.

Example file

For example - the following shows the different paragraphs that are applicable where the risk score is 1:

The section after that then covers the rules on which evidence to show from the eligible paragraphs set above. I.e. What are the person's circumstances establishes the evidence blocks applicable. A further check is then done against the risk score rules to see if that evidence block should be shown. So a person would be asked for proof of earnings if their risk score was 1 because this is present in the risk rule for 1:

But it wouldn't be shown where the risk score was 12 because the paragraph for Rule_Earnings does not exist in this risk group:

evidencerulesxantura.xml

This file is identical to the evidencerulescoactiva.xml one, except that:

a) It is where the Xantura RBV service is in use

b) It has a risk score range of 1-15 rather than 1-12

This guide is broken down into two sections.

• The Shared Features/Settings that all forms IEG4 provide can take advantage of.

• The department specific forms and the functionality they specifically provide

IEG4’s Benefit services are some of the most intelligent and powerful services delivered to councils.

Combining legislative compliance with technical acumen, IEG4’s benefit services enable citizens to apply for / report changes quickly and easily; with the data/content/supporting documentation automatically updated into back-office applications.

All IEG4's online form's shared common 'platform' level functions. Details of these can be found in the Platform Functionality section here:

IEG4 has an entire library of digital services provides a ‘Council in a box’ represents an opportunity for local authorities to make a step change forward with their digital strategies, wherever they are in the journey.

These come as a part of being licensed to our OneVu or eDesigner services. Content within the online forms can be edited using the built-in text editor. This means that question wording, guidance notes and help text will be editable by individual councils to suit their own needs. This includes the ability to support additional languages e.g. Welsh.

Services/forms are continuously being added to the Local Government as a Platform (LGaaP) store by customers using the eDesigner module and any of the forms in the library can be added to / manipulated with eDesigner (if this is licensed) too. Forms cover all of the following departments with some examples :

• Council Tax (e.g. Request a refund/Report a death/Evidence Upload)

• Benefits (Two Homes Payments/Overpayment Arrangement)

IEG4’s eChanges service was designed in 2012 and still provides an unrivalled user experience for citizens wishing to report a change in circumstances to their benefit claim. Unparalleled in terms of its functionality, the eChanges solution:

• Authenticates the citizen with the back-office application in real-time based upon their:

  • Name

The eClaim comes with a benefit calculator, which is able to act as a standalone function or as a precursor to an application. I.e. it can be optional if the council wishes it to be so. The calculator is able to work out whether a person would be eligible to receive:

• Housing Benefit AND / OR:

• Council Tax Support (LCTS) / Council Tax Discount (banded scheme) (LCTD)

There is a huge amount of flexibility in how the calculation for LCTS/LCTD is worked out and unlike ‘standard’ calculators available online, this calculator is designed to calculate LCTS and LCTD precisely in line with your scheme. It has built-in intelligence around:

IEG4’s forms enable councils to provide simple to use, powerful online services that citizens can access 24/7 on the device of their choice. Indeed, IEG4 is a trusted partner to local authorities with our online forms chosen by one in every five councils.

Our focus as a company is to deliver digital transformation that is simple and effective irrespective of the complexity of the services. With that in mind, IEG4 forms are designed to provide intelligent and intelligible services for citizens to request, report, apply for some of the highest volume and most complex services in local government. Our focus on delivering better outcomes means that many of our services are simpler to complete than competing products and yet achieve higher levels of automation.

In 2011, we introduced the first example of automation with our online changes form for Housing Benefits and Council Tax support, which could securely authenticate the citizen and personalise their experience. Some of the largest councils that administer Housing Benefits and Council Tax Support in England e.g. Leeds City Council choose IEG4 to provide their digital benefit services.

In 2017, we built the first Taxi Licence Renewal form that was able to authenticate the taxi driver and enable their existing licence details to be retrieved. This shortens the length of the form; ensures we’re not asking the citizen for something they have previously provided, and enables full automation of the update to the licensing application.

IEG4’s eClaim enables citizens to apply for help with:

• Housing Benefit

• Local Council Tax Support/Reduction/Discount

The following table lists common integration failures that can occur when forms submit and outline the cause and what to do to resolve them.

The eClaim already provides a dynamic list of evidence to the citizen but, with RBV enabled, IEG4 can integrate with RBV services to:

• Retrieve a risk score between 1-12

• Assign the risk category Low, Medium and High

• Dynamically reduce the evidence list if the risk is low

• Dynamically insert a risk category specific paragraph to let the citizen know if they can provide

originals and/or scanned/uploaded documents

The eChanges form is capable of integrating to the following back-office applications using national benefit schema (which IEG4 is the custodian of) driven APIs:

• Capita

• Civica

• NEC

The integration we have is:

• Bi-directional (we pull and push data from and to the back office application)

• Secure (we provide you with an , which sits on your council network and provides a secure outbound connection to council's own Microsoft Azure instance)

For eChanges, we search the back office to see if there is an existing claim already held and as long as it is live we also retrieve all of the details of the claim to provide a personalised form to complete.

As finding an existing claim is a prerequisite to proceeding to completion in the eChanges form the data sent is always linked to the appropriate claim upon submission.

Plus, the form's PDF and any associated evidence will also be indexed with the existing claim reference authenticated against.

To change the URL for pulling data out of the back office find the following setting in Form (System) Management for the form and update it to the new URL:

BackOfficeUrl

The integration to the back office for where the data is posted to is set up by IEG4 staff. Therefore if the URL for your back office application changes, (for Capita integration, this also includes the ABC security credentials), you'll need to raise a ticket for this to be done:

Please use this link to raise any new support calls:

And this link is to access details about previous support calls you have raised: (you may be required to Register as a new user, which is simple and quick to do)

Citizens can report that they, their partner or non-dependent are now in receipt of Universal Credit and, where relevant, the user is presented with a page designed in the exact layout of the UC Award letter.

Like the eClaim, this page captures all of the details of the person's UC award. This means that the officer can make a better-informed decision on assessment.

There is an optional module that can be provided with eClaim:

• Risk Based Verification

Details of this is found next.

Configuration files are files that can augment / improve the control you have over the functionality in the form beyond the settings.

For the RBV, there are 2 and these files relate to the two RBV providers. TransUnion (formerly Coactiva) and Xantura.

evidencerulescoactiva.xml

The evidencerulescoactiva.xml file controls the evidence paragraphs presented to customers, like the evidencerules.xml file but with additional behaviours to dynamically reflect Risk Score.

The file is largely the same as the evidencerules.xml file but at the top it has a dedicated section that enables the evidence requested to be set for each risk score.

Example file

For example - the following shows the different paragraphs that are applicable where the risk score is 1:

The section after that then covers the rules on which evidence to show from the eligible paragraphs set above. I.e. What are the person's circumstances establishes the evidence blocks applicable. A further check is then done against the risk score rules to see if that evidence block should be shown. So a person would be asked for proof of a change in capital if their risk score was 1 because this is present in the risk rule for 1:

But it wouldn't be shown where the risk score was 12 because the paragraph for Rule_Earnings does not exist in this risk group:

evidencerulesxantura.xml

This file is identical to the evidencerulescoactiva.xml one, except that:

a) It is where the Xantura RBV service is in use

b) It has a risk score range of 1-15 rather than 1-12

The following are the settings in eChanges specific to Risk Based Verification:

In August 2020, the DWP issued Housing Benefit Circular A9 2020, which is a special ‘bulletin’ to councils notifying them of a change to policy or process. This specific circular sets out the details of a Housing Benefit Award Accuracy (HBAA) Initiative and the funding LAs will receive to undertake activities to identify unreported changes of circumstances. The funding, from the DWP, is designed to support LAs undertaking specific activities to proactively identify unreported changes and make sure that the right amount of benefit is paid to the right person at the right time. This funding is awarded for councils carrying our Full Case Reviews (FCR).

A FCR requires a council to consider and look at all the current claim details and evidence associated with the claim, as well as any other fresher information or evidence they can source, in order for the weekly HB amount to be reviewed. The key elements are that:

• the Council reviews and validates whether the current information associated with the claim remains correct

• the Council seeks evidence from the claimant where it is possible to do so, in accordance with their review processes

All of this in order to identify any changes of circumstances and recalculate a claimant’s HB award accordingly.

In line with this, IEG4 has built a new form that leverages multiple elements from the eChanges form, which enables a citizen to:

• review all of the detail currently held on their claim about them

• proactively identify areas that have AND have NOT changed

Details of any changes reported in the Full Case Review will be passed in real-time to your back-office benefit processing system.

Benefit rules mean that the effective date of a change is one of the most important values passed to the back-office application. In practice this means dealing with multiple changes. This can be complex for a user as they are required to ensure that the changes are placed in chronological order prior to being processed.

As you wouldn’t want to mandate to the citizen that they provide things chronologically rather than by type, the eChanges form handles all of the logic to derive the correct order for changes to be passed to and updated in the back-office. For example, a citizen reports:

• Partner moved in on 21/11/2017

• New earnings from 01/11/2017

• A change in rent from 01/09/2017

The change in circumstances form will extrapolate out what needs to happen and will push XMLs to the back-office as follows: XML 1 01/09/2017 Change in rent

XML2 01/11/2017 Change in rent & New earnings

XML3 21/11/2017 Change in rent, New earnings & New partner

This intelligence ensures that the back-office benefit periods are updated in the exact same manner they would have been updated were the changes done manually.

The HBAA - Full Case Review form comes with the ability for benefit claimants to review their current circumstances and then indicate what:

• has changed

• has not changed

Self-employed claims are notoriously difficult to administer owing to the way benefit is calculated i.e. on weekly income and the very nature of self-employed people that is the fact they can have highly changeable income. Reflective of this, we have a self employed function that can work standalone or as an inbuilt self-employed function, for eClaim and eChanges.

The form is able to:

• capture details about the business

• calculate a person’s earnings based upon many different categories of income in different payment frequencies

• calculate allowable/disallowed expenditure amounts based upon your own council’s settings

• forecast earnings and expenditure for those who have only recently set up a business.

• calculate their income for housing benefit/local council support purposes including establishing where the person’s income will be below minimum wage

At the end of this process, the citizen will be taken back to the online form with a copy of the Self-employed form in PDF format to append as evidence. This is designed to ensure that even the most complex benefit claims can be administered quickly and easily.

Free School Meals are provided to eligible children throughout school term time.

But, as a result of efforts from those in the public eye, such as Marcus Rashford, there has been pressure on the government to make such meals available to these same children out of term time too.

Responding to this many forward thinking councils, like Trafford MBC, now have this in place. Forward thinking because the benefits to children of nutritious meals on their overall long term outcomes are well understood.

IEG4 has developed a powerful, end to end online form and workflow solution that, as a result of powerful integration can enable 100% automation levels of such applications.

Online Application

The Application form captures the following data and has 5 integrations built into it that ensure:

a) the data received is high quality

b) only those that are eligible can successfully submit the form

c) fraudulent/repeat applications cannot be made

d) all decisions can be automated

Form Structure

The online form is short and simple to complete with 5 pages total:

The 'Guidance Notes' page is fully editable within edit mode.

The 'Who Are you' page asks about the applicant and the details on this are used to determine eligibility

The 'About Your Household' page asks about partner and children

The 'Payment' page asks about bank details

The 'Declaration' page is where they can review their answers and agree to your council's information governance and general declaration rules.

Form Questions

The following are the questions asked in the form:

• Applicant’s First name

• Applicant’s Last name

• Applicant’s DOB

Configuration files are files that can augment / improve the control you have over the functionality in the form beyond the settings.

For the HBAA - Full Case Review form, there are 2 and these files that are relevant and these are covered below:

evidencerules.xml

The purpose of this file is to enable one to control, which evidence is presented dynamically to the citizen when NO Risk Based Verification service is enabled. I.e. This is the default configuration file.

Example file

Note - this file is bigger than this - we've taken an excerpt.

Basically this file enables you to control when each of the different evidence paragraphs appear in the eChanges based upon the person's changes provided.

For example, there is an evidence resource called Rule_NewPartnerIdentity.

And within that section there is a Rules section that outlines the rules that set whether evidence is requested or not:

The rule above is saying if there if on the page PartnerMovedIn the person says Yes to one moving in, evidence of their identity will be requested.

livingsituation.xml

This is an important file in the context of eChanges. The contents of it control:

a) What appears in the list of living situations for the new address a person is moving to i.e. when the change reported is a change of address

b) The behaviour of the option selected

Example file

The file contains a section for each drop down option. The following shows the file with only the first drop down option populates for simplicity of understanding:

The following elements are responsible for different behaviours:

The DfE (Department for Education) - ECS (Eligibility Checking Service) will provide a real time response when requesting whether a person has entitlement to Free School Meals.

We send a message like this, which takes the data from the form to do so:

And get a response like this if a person is eligible:

Key to automating decisions is a high level of integration. The next set of articles will cover the various integrations that make 100% automation possible.

Whilst we would recommend the use of only BACS to maximise automation, it is possible to also support the issue of vouchers.

Where you don't mandate bank account provision within the form, the customer can then be issued with vouchers. However, you need to be mindful that this means you will be manually recording details of:

a) A URL for the voucher

b) Details of how they can get the voucher if not a URL

For customers subscribed to Digital Benefits via GCloud XII, the following forms are also freely available:

• Landlord/ Letting agent/ managing agent change of circumstances

• Change bank details for payments

• Overpayments - Make a payment arrangement

• Backdated Benefit Application

• Benefits - Two Homes Payments

• Benefits - Send us evidence

• Benefits - Appeal

• Benefits - Direct payment to landlord

• Benefits - Apply for HB or CTB where one already in payment

Details of Digital Benefits can be found below

Enabling citizens to apply for, or end their, Single Person Discount online ensures that you can meet the digital demands of those applying and maximise the likelihood of getting the information from citizens wanting to tell you about someone moving in.

Single Person Discounts can involve ending council tax accounts, transferring people, credits, and even changes in circumstances where Benefits are involved.

The purpose of the form is to enable citizens to provide details of who they are, where they live, their council tax account information and primarily to apply for or cancel a single person discount.

General Functionality

The form supports one cancellation reason and three reasons for SPD applications, which are:

• Someone has moved out • Someone has passed away • I should have been getting the discount already

The form also caters for:

a) The set-up of a Direct Debit where a new account is going to be created because someone has moved out

b) An automated benefit change in circumstances where a person has moved in as a result of a SPD

Once a form is submitted it kicks off a dedicated workflow in IEG4’s RPO engine OpenProcess.

In terms of back-office updates* the SPD form can, depending upon the circumstance:

1. Terminate a current account

2. Transfer a person from an old account to a new account with the discount

3. Create a new person or people where someone/some people has/have moved in

4. Carry out a benefit change in circumstances where someone has moved out

5. Add/remove the Single Person Discount to/from the new account

6. Maintain the occupancy period to ensure this reflects the new occupants

7. Calculate the bill on the old account

8. Generate a bill on the old account

9. Transfer any credit due from one account to another

10. Calculate the bill on the new account

11. Generate a bill on the new account

12. Set up a Direct Debit Payment Method and Instalment Plan if a new account created and they wish to pay by direct debit

13. Adds any contact details for email/phone number to the party completing the form

14. Adds a notepad entry to each account affected to explain the updates made E.g.

“Council tax account 20000868320 has liable party with surname McMahon

Account 20000868320 terminated on 2020-03-31 and new account 2000119406 created

Person 654321 added as a liable party to account 2000119406 from 2020-04-01

Person ‘Claire McMahon' added as a new person. Reference: 987654 Person 987654 added as a liable party to account 2000119406 from 2020-04-01

No balance to transfer from 20000868320 Direct debit setup on account 2000119406"

10. Optionally the account can be suspended for a set period of time prior to billing to allow for QA

The purpose of the form is to enable citizens to provide details of who they are, where they live, their council tax account information and primarily to report a change of address.

General Functionality

The form supports three high level moving reasons, which are:

• Moving out of the council area

• Moving into the council area

• Moving within the council area

The form also caters for:

a) The dynamic capture of the necessary data, evidence upload and thus applications for:

• Uninhabitable discount/exemptions

• SMI discount/exemptions

• Carer discount/exemptions

b) The capture of whether they’d like to notify multiple council departments

c) The automated award and termination of empty unfurnished discounts

d) The automated award and termination of empty furnished discounts

e) The automated award and termination of single person discounts

f) The set-up of a Direct Debit where a new account is going to be created because someone has moved out

The power of the IEG4 solution and reason for the high automation levels its customers achieve are in the real-time checks that are built-in. These are designed to prevent exceptions and forms being submitted in circumstances where you would not want this to happen.

Prior to submission the Change of Address form will:

• check if the council tax account number entered and the surname of the account holder match (Move Out / Move Within only)

• retrieve the user’s address if they successfully authenticate in step 1 (Move Out / Move Within only)

• retrieve the existing occupant’s party references (Move Out / Move Within only

• present the details of the existing occupants for a person to indicate who's moving from one address to another (Move Within)

• check and retrieve details of the responsible parties present on a property when a tenant has not provided details of their landlord etc. This check is used to subsequently upon submission make them liable. (Move Out / Move Within only)

• check the status of occupancy discounts on the property so as to know which / when to remove them from if any are applicable as a result of the data for the move

• check if they’re in receipt of council tax support (Move Out / Move Within only)

• carry out an address look up where a person is moving to a new address (Move In / Move Within only)

• check in real-time, using the industry-leading online bank verification service from Loqate (GBG Group) that the bank account details are valid prior to form submission where they set up a direct debit as a part of the process. If they are invalid, the citizen is told to check and try again. If they are valid the details of their bank are retrieved and automatically populated into the Direct Debit Mandate page.

Where OpenProcess is not used as your document management system, the online form is capable of:

1. Saving the PDF to a file location

2. Automatically indexing the form document into the document management system based upon the account number and whether the process is fully automated or not.

We can provide integration to the following widely used back-office EDM applications:

• Information@Work/ NEC DM

• Civica W2/360/Comino

• Civica Workflow

The power of the IEG4 solution and reason for the high automation levels its customers achieve are in the real-time checks that are built-in. These are designed to prevent exceptions and forms being submitted in circumstances where you would not want this to happen.

Prior to submission, the Refund form will:

1. check if the council tax account number entered and the surname of the account holder match

2. retrieve the user’s address if they successfully authenticate in step 1.

3. check for the presence of a refund

4. retrieve details of the balances of all years

5. offset any refund against monies if applicable to show the true credit

6. check if the account was previously paid via bank payment (DD) and if so default the refund payment details to go back to that account

7. where they want to pay a new account or did not previously pay via a bank account, we will check in real-time, using the industry-leading online bank verification service from Loqate (GBG Group) that the bank account details are valid prior to form submission.

To ensure that the eClaim adapts to your local council tax support scheme, there are dedicated

settings such that you can:

• Ask for proof of capital even where the person is ‘passported’ because your capital thresholds are below the standard £16,000 level

• Ask whether the person is within a ‘vulnerable’ group and therefore exempt from the normal working age rules e.g. in receipt of Personal Independence Payment/has a child under five

• Set different maximum periods for backdating

The eClaim also dynamically detects whether the person is of pension age using their date of birth

and pension equalisation rules. Therefore, ensuring that working age specific rules for LCTS are complied with.

The eClaim is capable of and has proven integration to the following widely used back-office EDM applications:

• Information@Work / NEC DM

• Civica W2/360/Comino

• Civica Workflow

• IDOX

• OpenText

• ICLipse

• IEG4 OpenProcess

The eChanges is capable of and has proven integration to the following widely used back-office EDM applications:

• Information@Work/ NEC DM

• Civica W2/360/Comino

• Civica Workflow

• IDOX

• OpenText

• ICLipse

• IEG4 OpenProcess

Both the form PDF and evidence uploaded during/after submission can be fully indexed automatically.

The eChanges form already provides a dynamic list of evidence to the citizen but, with RBV enabled, IEG4 can integrate with RBV services to:

• Retrieve a risk score between 1-12

• Assign the risk category Low, Medium and High

• Dynamically reduce the evidence list if the risk is low

• Dynamically insert a risk category specific paragraph to let the citizen know if they can provide

originals and/or scanned/uploaded documents

• Determine whether an upload button should be shown e.g. on High Risk a council can choose to

hide this functionality.

• Add the risk score to the cover page of the eChanges PDF passed to the back-office EDMS

• Add the risk to the XML passed to the back-office processing application

• Dynamically enable/disable fast track based upon the risk score

The risk score can therefore be seen by the back-office staff on the PDF, in the back-office

application and within our Forms Portal.

TransUnion are also able to carry out a Credit Reference Agency search on different risk categories

which can be presented to users of IEG4’s software.

IEG4 is able to integrate to both of the following RBV service providers:

• TransUnion

• Xantura

The eChanges is capable of and has proven integration to the following widely used back-office EDM applications:

• Information@Work/NEC DM

• Civica W2/360/Comino

• Civica Workflow

• IDOX

• OpenText

• ICLipse

• IEG4 OpenProcess

Both the form PDF and evidence uploaded during/after submission can be fully indexed automatically.

With online forms for Council Tax comprising a huge proportion of the work councils receive, IEG4’s Council Tax forms have been designed with ease of completion, intuitiveness and automation in mind.

Revenues Process Orchestration (RPO)* is the engine that powers the integration with back-office applications and the functionality it provides ensures the councils using these services are consistently achieving 90% to 100% automation levels without any human involvement.

*RPO and thus integration to the back-office is currently only available for Northgate and Capita back-office Council Tax applications.

The power of the IEG4 solution and reason for the high automation levels its customers achieve are in the real-time checks that are built in.

These are designed to prevent exceptions and forms being submitted in circumstances where you would not want this to happen.

Prior to submission the Single Person Discount form will:

1. check if the council tax account number entered and the surname of the account holder match

2. retrieve the user’s address if they successfully authenticate in step 1

3. checks if there is already a single person discount on their account to prevent spurious activity

4. retrieve the current liable parties/named occupants to enable a user to indicate who has moved out where they are applying for a discount

5. checks the number of resulting occupants is 1 when they are applying for a discount and prevents submission if not

6. enables the user to add additional named occupants that were not present against the account i.e. cater for incomplete back-office data sets

7. check for the presence of a benefit claim and, where, present enable a benefit change of circumstances for people moving out

8. check in real-time, using the industry leading online bank verification service from Loqate (GBG Group) that the bank account details are valid prior to form submission where they want to pay by Direct Debit on the new account.

Once a form is submitted it kicks off a dedicated workflow in IEG4’s RPO engine OpenProcess. In terms of back-office updates*, the moves form will depending upon the circumstance:

1. Terminate a current account

2. Transfer a person or people from an old account to a new account

3. Update the forwarding address on the account ended

4. Perform the equivalent of a ‘Target Move' when moving within the area

5. Check for the presence of a pre-existing discount on the account

6. End an existing account where an empty property discount requires to be set

7. Set an empty and unfurnished discount for a date range when moving out of a property

8. Set an empty and unfurnished discount for a date range when moving into a property

9. Set an empty and furnished discount for a date range when moving out of a property

10. Set an empty and furnished discount for a date range when moving into a property

11. Set a single person discount for a date range when moving out of a property if one person moves out before another for a period of time before all move out

12. Set a single person discount for a date range when moving into a property if only one person is resident for a period of time or indefinitely if no one is moving in later

13. Search for new people being added to the account (Move In/Move Within only)

14. Checks if a person newly added already exists in the council tax system

15. Create a new person or people where someone/some people has/have moved into the new address (Move In/Move Within only)

16. Find and make liable the current responsible party where a tenant moving out has not said who their landlord is. (Move Out/Move Within only)

17. Set the appropriate empty property discount when the landlord is made liable

18. Transfers any credit due from one account to another

19. Sets up a Direct Debit Payment Method and Instalment Plan if a new account created

20. Calculates the bill for the account closed

21. Calculates the bill for an account opened

22. Generates the bill for account closed

23. Generates the bill for an account opened

24. Adds any contact details for phone numbers to the party completing the form

25. Adds any email address provided to the party completing the form

26. Adds the forwarding address for parties moving away

27. Adds a notepad entry to each account affected (up to four separate accounts on move within with notes contextual to each) to explain the updates made e.g.

“Council tax account 20000506618 has liable party with surname McMahon Account 20000506618 terminated on 2020-02-20 and new account 2000119412 created

Person ‘Claire McMahon' added as a new person. Reference: 708369 Person 708369 added as a liable party to account 2000119412 from 2020-02-21”

The power of the IEG4 solution and reason for the high automation levels its customers achieve are in the real-time checks that are built in. These are designed to prevent exceptions and forms being submitted in circumstances where you would not want this to happen. Prior to submission the discounts/exemptions form will:

1. check if the council tax account number entered and the surname of the account holder match

2. retrieve the user’s address if they successfully authenticate in step 1

3. retrieve the existing liable parties / occupant’s party references

There are a couple of additional, optional modules that can be provided with eClaim:

• Risk Based Verification

• CallValidate - ID and Bank Account Verification

Details of these is found next.

Benefit rules mean that the effective date of a change is one of the most important values passed to the back-office application. In practice this means dealing with multiple changes. This can be complex for a user as they are required to ensure that the changes are placed in chronological order prior to being processed.

As you wouldn’t want to mandate to the citizen that they provide things chronologically rather than by type, the eChanges form handles all of the logic to derive the correct order for changes to be passed to and updated in the back-office. For example, a citizen reports:

• Partner moved in on 21/11/2017

• New earnings from 01/11/2017

• A change in rent from 01/09/2017

The change in circumstances form will extrapolate out what needs to happen and will push XMLs to the back-office as follows: XML 1 01/09/2017 Change in rent

XML2 01/11/2017 Change in rent & New earnings

XML3 21/11/2017 Change in rent, New earnings & New partner

This intelligence ensures that the back-office benefit periods are updated in the exact same manner they would have been updated were the changes done manually.

Citizens can report that they, their partner or non-dependent are now in receipt of Universal Credit and, where relevant, the user is presented with a page designed in the exact layout of the UC Award letter.

Like the eClaim, this page captures all of the details of the person's UC award. This means that the officer can make a better-informed decision on assessment.

Once a form is submitted, it kicks off a dedicated workflow in IEG4’s RPO engine OpenProcess.

But generally the form:

1. Sets up the actual Direct Debit Payment Method and Instalment Plan

2. Adds any contact details for email/phone number to the party completing the form

3. Adds a notepad entry to explain the updates made E.g.

"Council tax account 12345034 has liable party with surname McMahon Account is active

No notes found to indicate bounced Direct Debits on account 20000527654 for current financial year

Direct debit setup on account 12345034

Contact details updated for person reference 983474"

The power of the IEG4 solution and reason for the high automation levels its customers achieve are in the real-time checks that are built in. These are designed to prevent exceptions and forms being submitted in circumstances where you would not want this to happen.

Prior to submission the Direct Debit form will:

1. check if the council tax account number entered and the surname/organisation name of the account holder match

2. retrieve the current recovery stage for the financial year and:

a) compare it with a set of recovery stages where direct debits are not permitted

b) for each recovery stage where it is not permitted it will show a custom, user-defined message/ call to action. E.g. if the account is with an enforcement agent, it could provide their details and how to get in touch with them.

3. check whether the citizen has a history of not paying direct debits once they’ve been set up and where this happens a custom, user-defined message/call to action is presented that informs the citizen of what to do next

4. check for a marker added during this financial year that indicates a citizen has made an arrangement and can bypass checks 3 and 4

5. check in real-time, using the industry-leading online bank verification service from Loqate (GBG Group) that the bank account details are valid prior to form submission. If they are invalid, the citizen is told to check and try again. If they are valid, the details of their bank are retrieved and automatically populated into the Direct Debit Mandate page.

Once a form is submitted it kicks off a dedicated workflow in IEG4’s RPO engine OpenProcess. In terms of back-office updates* the Discounts, DBR and Exemptions form can, depending upon the circumstance:

1. Terminate a current account

2. Transfer a person or people from an old account to a new account

3. Create a new person where a new person previously not known is now resident

4. Create a new occupancy period

5. Add a new occupant and make them liable or set them as disregarded

6. Set an empty and unfurnished discount for a date range when moving out of a property

7. Set an empty and unfurnished discount for a date range when moving into a property

8. Set an empty and furnished discount for a date range when moving out of a property

9. Set an empty and furnished discount for a date range when moving into a property

10. Work out periods where a disregard discount is applicable and automate the addition of this for multiple people where appropriate

11. Work out periods where an exemption based upon person status is applicable and automate the addition of this

12. Automate the award of Disabled Band Reduction

13. Work out periods where an exemption based upon property status is applicable and automate the addition of this

14. Transfer any credit due from one account to another

15. Sets up a Direct Debit Payment Method and Instalment Plan if a new account created

16. Adds any contact details for email/phone number to the party completing the form

17. Adds the forwarding address for parties no longer resident

18. Adds a notepad entry to each account affected to explain the updates made e.g. “Person John McMahon added. Reference 950315 Occupancyperiodsetuponaccount612347432685from2019-07-15forpartyrefs950315Student discount added for Person Reference 950223 from 2019-07-13 to 2020-10-20 Student discount added for Person Reference 950224 from 2019-07-20 to 2021-05-20 Student discount added for Person Reference 950315from2019-07-25to2021-02-04Exemptpropertydiscountaddedfrom2019-07-25“

19. Optionally the account can be suspended for a set period of time prior to billing to allow for QA

*The number of steps involved in the automation is dictated by the APIs available in the back-office application. E.g. Northgate has more APIs than Capita, and the ability to transfer a credit from one account to another is not possible with the Capita One (Academy) Council Tax application.

The power of the IEG4 solution and reason for the high automation levels its customers achieve are in the real-time checks that are built-in. These are designed to prevent exceptions and forms being submitted in circumstances where you would not want this to happen.

Prior to submission, the SPARs form will:

1. check if the council tax account number entered and the surname of the account holder match

2. retrieve the user’s address if they successfully authenticate in step 1.

3. retrieve the current liable parties/named occupants to enable any contact details/personal information to be added to the party when the form is submitted

4. retrieve details of the ‘eligible’ debts in line with the council’s policies and check there are debts appropriate to be paid

5. check if the person has a history of trying to set up payment arrangements and then subsequently reneging on the arrangement

6. check in real-time, using the industry-leading online bank verification service from Loqate (GBG Group) that the bank account details are valid prior to form submission where they want to pay the arrangement by Direct Debit on the new account, and

7. checking whether the person has a history of not paying direct debit instalments

Upon submission of the Refund Request these details are automatically passed to the back office

• The amount to refund

• The council tax account number it relates to

• The financial year

• The bank account the monies should be refunded to

• For NEC - the refund is automatically set to endorsed pending the final approval internally

To ensure councils could have as much information as possible in circumstances where the person is claiming UC, the eClaim has a dedicated page for Universal Credit. Designed in the exact layout of the UC Award letter, the page captures all the details of the person's UC award meaning the officer can make a better-informed decision on assessment.

There is also additional dynamic behaviour in the form such that where a person states that they have applied for/or are in receipt of Universal Credit no questions about tenancy, landlord, housing benefit payment are asked for unless the claimant is within an exempt group e.g. Supported Accommodation.

It is also possible, via settings, to request proof of Universal Credit on the evidence page.

The following lists all of the settings in the eClaim form and what they do.

The eClaim is capable of integrating to the following back-office applications using national benefit schema (which IEG4 is the custodian of) driven APIs:

• Capita

• Civica

• NEC

The integration we have is:

• Bi-directional (we pull and push data from and to the back office application)

• Secure (we provide you with an , which sits on your council network and provides a secure outbound connection to council's own Microsoft Azure instance)

For eClaim, we search the back office to see if there is an existing claim already held i.e. a cancelled/expired one to prevent duplication.

If one is found the claim reference is appended to the new claim data sent to the back office, which links the two things together.

Plus, the form's PDF and any associated evidence can also be indexed with an existing claim reference.

The integration to the back office, i.e. where the data is posted to is set up by IEG4 staff. Therefore if the URL for your back office application changes, (for Capita integration, this also includes the ABC security credentials), you'll need to raise a ticket for this to be done:

Please use this link to raise any new support calls:

And this link is to access details about previous support calls you have raised: (you may be required to Register as a new user, which is simple and quick to do)

eClaim comes with rich PowerBI enabled reports. The reports available are:

Summary

• This report provides a dashboard with:

  • Numbers or completed forms vs incomplete

  • % where integration was successful

  • Forms by gender

  • By Channel

  • % breakdown by risk category

Owing to the interrelationships in place within the dashboard, it is possible to filter the dashboard by clicking on segments of the donut charts.

Year-on-year analysis

To enable Benefit managers to measure the transformation of their services and of impacts of legislative changes (such as the introduction of Universal Credit) there is a year-on-year analysis report:

Again, this provides the means to click on a given month and filter the results, as well as see trends on numbers. The data can be viewed in a table and exported to CSV for interpretation in Microsoft Excel etc.

General analysis

The general analysis report enables Benefit managers to see the breakdown of:

• Age groups

• Session duration i.e. from when they started the form to when they submitted it

• The number of pages visited during the completion of the eClaim

Geographical analysis

Being able to understand the areas (Council wards) where you are receiving the greatest volumes of claims ensures that relevant councillors are aware and that communications can be targeted most effectively.

Risk analysis summary

With this report Benefit Managers can see, at a glance, how their risk profiling has changed over time.

Risk analysis breakdown

With this set of visuals, the Council is able to see how risk is portrayed across different metrics like age groups, gender, who completed it.

Incomplete Forms analysis

With this report the council is able to see which pages claimants are abandoning the form on. We can see (below) that the overwhelming number of people are only looking at the guidance notes and not proceeding. This illustrates that the bulk of people that started but did not complete it did not actually intend to progress with their claim but provide focus on those that have.

Integration Error analysis

This report allows one to see the numbers by form access method and the specific reasons for failures over time.

Average page duration analysis

This report provides the council with the means to see which pages are taking longest to complete and therefore provide the basis for reviewing the content of these and potentially updating them using the built-in edit mode features of eClaim.

The following are the settings in eClaim specific to Risk Based Verification:

Configuration files are files that can augment / improve the control you have over the functionality in the form beyond the settings.

For the RBV, there are 2 and these files relate to the two RBV providers. TransUnion (formerly Coactiva) and Xantura.

evidencerulescoactiva.xml

The evidencerulescoactiva.xml file controls the evidence paragraphs presented to customers, like the evidencerules.xml file but with additional behaviours to dynamically reflect Risk Score.

The file is largely the same as the evidencerules.xml file but at the top it has a dedicated section that enables the evidence requested to be set for each risk score.

Example file

For example - the following shows the different paragraphs that are applicable where the risk score is 1:

The section after that then covers the rules on which evidence to show from the eligible paragraphs set above. I.e. What are the person's circumstances establishes the evidence blocks applicable. A further check is then done against the risk score rules to see if that evidence block should be shown. So a person would be asked for proof of earnings if their risk score was 1 because this is present in the risk rule for 1:

But it wouldn't be shown where the risk score was 12 because the paragraph for Rule_Earnings does not exist in this risk group:

evidencerulesxantura.xml

This file is identical to the evidencerulescoactiva.xml one, except that:

a) It is where the Xantura RBV service is in use

b) It has a risk score range of 1-15 rather than 1-12

Configuration files are files that can augment / improve the control you have over the functionality in the form beyond the settings.

For the eChanges form, there are 4 and these files are covered below:

evidencerules.xml

The purpose of this file is to enable one to control, which evidence is presented dynamically to the citizen when NO Risk Based Verification service is enabled. I.e. This is the default configuration file.

Example file

Note - this file is bigger than this - we've taken an excerpt.

Basically this file enables you to control when each of the different evidence paragraphs appear in the eChanges based upon the person's changes provided.

For example, there is an evidence resource called Rule_NewPartnerIdentity.

And within that section there is a Rules section that outlines the rules that set whether evidence is requested or not:

The rule above is saying if there if on the page PartnerMovedIn the person says Yes to one moving in, evidence of their identity will be requested.

livingsituation.xml

This is an important file in the context of eChanges. The contents of it control:

a) What appears in the list of living situations for the new address a person is moving to i.e. when the change reported is a change of address

b) The behaviour of the option selected

Example file

The file contains a section for each drop down option. The following shows the file with only the first drop down option populates for simplicity of understanding:

The following elements are responsible for different behaviours:

For the RBV, there are 2 and these files relate to the two RBV providers. TransUnion (formerly Coactiva) and Xantura.

evidencerulescoactiva.xml

The evidencerulescoactiva.xml file controls the evidence paragraphs presented to customers, like the evidencerules.xml file but with additional behaviours to dynamically reflect Risk Score.

The file is largely the same as the evidencerules.xml file but at the top it has a dedicated section that enables the evidence requested to be set for each risk score.

Example file

For example - the following shows the different paragraphs that are applicable where the risk score is 1:

The section after that then covers the rules on which evidence to show from the eligible paragraphs set above. I.e. What are the person's circumstances establishes the evidence blocks applicable. A further check is then done against the risk score rules to see if that evidence block should be shown. So a person would be asked for proof of a change in capital if their risk score was 1 because this is present in the risk rule for 1:

But it wouldn't be shown where the risk score was 12 because the paragraph for Rule_Earnings does not exist in this risk group:

evidencerulesxantura.xml

This file is identical to the evidencerulescoactiva.xml one, except that:

a) It is where the Xantura RBV service is in use

b) It has a risk score range of 1-15 rather than 1-12

The following lists all of the settings in the eChanges form and what they do.

The eChanges form is capable of integrating to the following back-office applications using national benefit schema (which IEG4 is the custodian of) driven APIs:

• Capita

• Civica

• NEC

The integration we have is:

• Bi-directional (we pull and push data from and to the back office application)

• Secure (we provide you with an , which sits on your council network and provides a secure outbound connection to council's own Microsoft Azure instance)

For HBAA, we search the back office to see if there is an existing claim already held and as long as it is live we also retrieve all of the details of the claim to provide a personalised form to complete.

As finding an existing claim is a prerequisite to proceeding to completion in the HBAA form the data sent is always linked to the appropriate claim upon submission.

Plus, the form's PDF and any associated evidence will also be indexed with the existing claim reference authenticated against.

To change the URL for pulling data out of the back office find the following setting in Form (System) Management for the form and update it to the new URL:

BackOfficeUrl

The integration to the back office for where the data is posted to is set up by IEG4 staff. Therefore if the URL for your back office application changes, (for Capita integration, this also includes the ABC security credentials), you'll need to raise a ticket for this to be done:

Please use this link to raise any new support calls:

And this link is to access details about previous support calls you have raised: (you may be required to Register as a new user, which is simple and quick to do)

There is full integration with the Ordnance Survey's Places API for the applicant to find their address. They simply need to enter a postcode to locate their street and then select from the list provided:

Plus, in order to ensure that applications that are made relate only to properties within the boundary of the council, there is the ability to limit the search results to that of your council.

Address Lookup Style

There is a setting that controls the style of the address look up. The setting is:

AddressLookupStyle

The two modes available which needs you to set them as the value for the above setting.

• TypeAheadSearch (this is the default)

If this option is enabled, as the user types in an address or postcode, it will instantly start searching for addresses. This provides a smart way of dynamically getting the results as the user enters their address.

• Postcode

If this option is selected the customer needs to enter a postcode and then physically click a search button.

Prerequisite

In early 2021, Councils became able to use the Ordnance Survey APIs to search for addresses at no cost.

These APIs are documented here:

In order that this can be set up by the IEG4 team, we need to have the council's API key for this. This is free to councils now and simply needs you to create an account per below:

Once you have this simply provide the details to IEG4 support:

Please use this link to raise any new support calls:

And this link is to access details about previous support calls you have raised: (you may be required to Register as a new user, which is simple and quick to do)

When the online application is received a notification is automatically generated to the citizen.

The content of which is able to be edited with the following being an example template:

OpenProcess is IEG4's powerful workflow and case management solution, which you can read more about below:

In the context of Free School Meal Holiday Payments, there is two way integration with OpenProcess.

Because the online form:

• Searches (reads) for a previous award for the claimant's NINO and the UPRN of the property

• Pushes (writes) the details of the application into OpenProcess to enable the bank details to be used in the creation of the BACS file

Checking for a previous award

The service takes the applicant / partners NINO and compares this with already successful awards within the past x weeks. If they have already had an award they will be presented with a message like that shown below:

Viewing applications

Unless you allow people to receive payments by voucher, the only screen that you'd need to look at in OpenProcess is 'Search Processes'.

Full details on how to use Search Processes, can be found here:

The following illustrates how this looks in the specific context of this process:

With the following illustrating the data passed from the form for the purposes of reporting:

Within the Documents tab you are able to see a copy of the form PDF if desired.

Sometimes you might want to know what the outcome of our checks of the following were:

• Department for Education Eligibility Checking Service

• Back office Benefit system

Within IEG4's Forms Portal, which you can read all about here:

It is possible in the Documents tab to see multiple files related to this.

So in the following:

We can see two files:

• FSMQuery.xml - this is the request we sent to the DfE's ECS service

• FSMResponse.xml - this is the response we received from the DfE's ECS service

If someone is ineligible as a result of the DfE's ECS check, we will then check eligibility to LCTS. In that case we log three additional files:

These are:

• CurrentClaim.xml - this is the detail of the benefit claim found

• PersonSearchRequest.xml - This is the search request to find the person in the benefit system

• PersonSearchRequest.xml - This is the search response when trying to find the person in the benefit system

Having access to these files is useful if there is any doubt about eligibility.

Where OpenProcess is not used as your document management system, the online form is capable of:

1. Saving the PDF to a file location

2. Automatically indexing the form document into the document management system based upon the account number and whether the process is fully automated or not.

We can provide integration to the following widely used back-office EDM applications:

• Information@Work / NEC DM

• Civica W2/360/Comino

• Civica Workflow

The Council Tax Direct Debit service is designed to capture information to enable the creation of a new Direct Debit based instalment plan on a council tax account.

General Functionality

The form has the following high-level key functions:

• Capture of the citizen’s

  • name, address, contact details, and

  • council tax account no.

• Capture the citizen's bank details

  • Including a real-time bank validation check

• Capture the frequency/payment day they’d like

• Generate a digital direct debit mandate pre-filled with the content provided

• Submit the data into the back-office

• Submit a copy of the form PDF into the document management/workflow application

• Send an email receipt for the form

• Send an email containing details of the Direct Debit information for a fully paperless DD - see the link below for details on this:

An optional function within the Change of Address form is the ability to notify multiple other departments about the change of address.

Within Form System Management, you can modify which departments are available to choose and also the email addresses to send the details to.

This is done within the Files area of Form System Management. First select the Change of Address form. There will be a file called:

The purpose of this file is to control the behaviour of the notification areas page AND to control the config/content of emails to different organisations.

The file is made up of all ‘Areas’ or departments to which the council wants the citizen to be able to notify the change of address to.

The file is an XML file with each <Area> section controlling the behaviour for that department. To provide an example the following is the Council Tax ‘Area’ section of the XML file:

Notification Mode

There are some things to explain: <Mode> tags

This has three allowed values:

Always

If set to always the question about this department will not appear and an email will always be sent to the department in question using the email address within the Notification section of the file for the given area.

Optional

If set to optional then the citizen will see this as an option with the online form to opt in to have their move details shared

Off

Will hide the department from the form and no emails will be sent to them

<Name> tags

Here is where you can change the name of the department i.e. if I wanted it to say Revenues Department instead of Council Tax I would update the tag as follows:

<Name> <Default>Revenues Department</Default> <ResourceKey>CouncilTaxName</ResourceKey>

</Name>

<Wording> tags

These tags are ONLY to control what appears on the online form beside the department in question and only where the mode is Optional.

So for Adult Social Care the following might be the wording: <Wording>

<Default>If you receive Adult Social Care Services.</Default>

<ResourceKey>AdultSocialCareWording</ResourceKey> </Wording>

<TickBoxWording> tags

Per above, this is simply to be able to modify what is shown beside the check box. I.e. in the above the tags are updated as:

<TickBoxWording> <Default>[Tick to notify this department]</Default> <ResourceKey>CouncilTaxTickBoxWording</ResourceKey>

<Notification> tags

This is where you control what the subject line and body of the email are as well as the email address to send it to. E.g. if I wanted it to go to counciltax@ieg4.gov.uk, have a subject line of Council Tax Move Details and a body of:

"Please find details of the move in the attachment."

One would update the tags as follows:

The following are the settings available for the change of address form and what they do:

Further localisation

Beyond the above, for RPO (Integrated forms) there is further localisation available that is set by IEG4. Details found here:

Where OpenProcess is not used as your document management system, the online form is capable of:

1. Saving the PDF to a file location

2. Saving the uploaded evidence to a file location

3. Automatically indexing the form document into the document management system based upon the account number and whether the process is fully automated or not.

4. Automatically indexing the evidence uploaded into the document management system based upon the account number and whether the process is fully automated or not.

We can provide integration to the following widely used back-office EDM applications:

• Information@Work/ NEC DM

• Civica W2/360/Comino

• Civica Workflow

Owing to the large number of Discounts, Exemptions and the different questions/supporting evidence needed, councils typically have many separate forms. However, digital should be about more than simply replicating paper, it should be an opportunity to provide something better. i.e. A solution that asks a citizen about their circumstances and, from that, guides them to the appropriate Discount/Exemption and the information they need to provide. This service enables citizens to provide details of who they are, the property in question and the means to apply for a reduction based on the person’s status, disability, or property. Supporting 27 different Discount/Exemption scenarios and Disabled Band Relief, it is a one-stop digital shop for citizens seeking reductions.

General Functionality

The form supports these four high level areas:

• Someone isdisregarded

• My property isempty

• My property has been adapted for someone

• The property is an exempt type For disregarded people, the following person statuses are supported:

1. Severely Mentally Impaired

2. Carer

3. School/College Leaver

4. Child BenefitRecipient

The following empty property statuses are supported:

1. Awaiting sale

2. Awaiting let to tenants

3. Awaiting occupation

4. It’s uninhabitable due to structural works

The following are the settings for the Council Tax Single Person Discount form that users will adjust.

Further localisation

Beyond the above, for RPO (Integrated forms) there is further localisation available that is set by IEG4. Details found here:

configuration/exemptiontypes.xml

The file contains details of exemption types available

configuration/reductionstatusmappings.xml

Example file

The file contains a section for each drop down option.

Where OpenProcess is not used as your document management system, the online form is capable of:

1. Saving the PDF to a file location

2. Saving the uploaded evidence to a file location

3. Automatically indexing the form document into the document management system based upon the account number and whether the process is fully automated or not.

4. Automatically indexing the evidence uploaded into the document management system based upon the account number and whether the process is fully automated or not.

We can provide integration to the following widely used back-office EDM applications:

• Information@Work/NEC DM

• Civica W2/360/Comino

• Civica Workflow

Special Arrangements (SPARs) enable councils to maximise their recovery rates by enabling those that have breached the original instalment plans to set up payment arrangements subsequently.

The economic consequences of the lockdown put in place to prevent transmission of COVID-19 are expected to be vast for citizens and businesses alike. Consequently, the likelihood of there being an increase in non-payment by those that would normally pay is significant. Therefore, having an intelligent special arrangement service is going to be of greater value in the coming years.

Enabling citizens to apply for a special payment arrangement online, which conforms to the council’s payment arrangement policies is crucial given the focus on ensuring:

• The removal of physical documents

• the digitization / standardisation of processes, and

• the maximization of the resources the council has available

IEG4’s SPARs solution is intelligent and uses data already known about a citizen to drive a personalised process that results in the complete automation of the process.

General Functionality

The form is able to:

• Authenticate a citizen

• Retrieve their address/account information

• Provide the citizen with details of the amounts (debts) eligible for a special payment arrangement

• Calculate the instalment schedule based upon the option they selected and provide them with a view of the instalment plan for them to agree to prior to submission

• Capture / validate their bank details for the purposes of an arrangement being made via Direct Debit

Further localisation

Beyond the above, for RPO (Integrated forms) there is further localisation available that is set by IEG4. Details found here:

Request a refund is a newly built form that enables citizens to request a refund and for this request to be passed automatically into the back office.

The form has the following functionality:

a) Automatic authentication of the customer (checking that their account number/surname match)

b) Automated retrieval of overall credit (i.e. if -100.00 in credit on this year but £10.00 in arrears on last year, it will show £90.00 credit payable)

c) Automatic retrieval of existing bank details to use for processing the refund request

d) The ability to request the money is paid into a different account

e) The ability to provide bank details if none were previously held on the account

f) It will present an error if there is no refund due

g) It will validate the bank account details entered using the best in class online bank validation provided by .

h) Upon submission it will push the refund request into the back office application (NEC is the only back office this is available for right now)

i) Upon submission it will pass a PDF of the refund request to your document management application

j) Upon submission it will send an email receipt

The following illustrates the form/questions.

As with all RPO forms the customer is authenticated as a part of the process. Below we can see that the authentication has failed and the customer is presented with the message: "We were unable to find a matching council tax account":

Note the wording of this (and virtually all wording) can be changed in the Resources area of eGovHub - forms system management:

Where the customer provides a valid council tax account they're address will be presented and they can continue:

We go on to capture a phone number, email address and where someone is completing the form on their behalf their details.

It is the next page of the form where intelligence is deployed to ensure only valid refunds are awarded.

We will show the various scenarios below but the important thing to note is the form is smart enough to look at the overall balance not simply whether a single year is in credit. I.e.

a) If one year is in credit and others are at £0.00 it knows this is a valid credit for the year (assuming benefit re-calculaton has already happened of course)

b) If one year is in credit and another is >0.00 it knows to offset these to derive the real credit and if there is no credit they will be told they're ineligible

c) If two years are in credit and and others are at £0.00, it knows to refund money back to the respective years.

The following are the various scenarios of functionality:

Scenario 1 - Person has a credit and a pre-existing bank account is held:

Scenario 2 - Person has a credit and a bank account is not currently held:

Scenario - Person is not eligible for a refund:

A message is presented and the customer is unable to submit the form.

Scenario - Person has provided invalid bank details

We can see the message presented and this prevents the form from being submitted until remedied:

Based upon the circumstances of the citizen, the eClaim will provide the user with the specific items that need to be provided in order to support their application:

The user is able to provide this information online and the form will ‘track’ what has and has not been provided so that, upon submission, the user is told what they still need to provide should anything be outstanding.

So, if a person was told five items were required and they uploaded evidence for four, upon submission the remaining item would be shown as outstanding.

The citizen can then come back and upload these within a set period of time (normally one month) with this information then being passed to the EDMS. You can see below what the user sees upon submission where something remains outstanding.

Note that there is a ‘catch all’ Upload Supporting Documentation option which is there to cater for ad hoc/subsequent evidence uploads because the initial documentation uploaded was unsatisfactory.

Evidence Settings

The following settings relate to changing evidence behaviour:

The following settings control types of evidence uploaded:

Evidence Configuration

Because evidence presented in the form is dynamic to a person's household, income etc. it is possible to configure when certain evidence requirements are asked for.

This is set up within the Form Configuration File - evidence.xml. Details at the following link:

The fast track functionality provided within the eClaim ensures that citizens are provided with the ability to choose to provide all of their evidence prior to submission in order to have their claim processed quicker.

If a citizen does not choose the fast track method they will have their application processed in the standard SLA for that council:

Where the citizen opts into Fast Track, the council is able to let the citizen know how long it will be before it is processed; but this will be significantly quicker than the standard SLA:

The beauty of this functionality being embedded into a digital service is that the council gets all of the evidence it needs to process the claim on day one and the citizen is ensuring their claim is processed much faster than it otherwise would have.

Enhanced EDMS integration for Fast Track

When citizens submit a claim/change using Fast Track, the service is able to dynamically inform the EDMS application:

1. That the application/change is fast track or not

2. Separately identify the specific type of evidence as well as indicate whether it is linked to a fast track claim/change or not

Fast Track Settings

Enabling of Fast Track is done by IEG4 so please contact help.ieg4.com to have this enabled for eClaim or eChanges.

The following settings are also present where a council ALSO has Risk Based Verification:

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 . 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 and (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 , IEG4 has integrated its online benefit claim service with 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

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.

The following are the settings that can/should be changed by users to suit their requirements:

Configuration files are files that can augment / improve the control you have over the functionality in the form beyond the settings.

For the Calculator, there are 4 and these files are covered below:

livingsituation.xml

This is an important file in the context of the Calculator. The contents of it control:

a) What appears in this list:

b) The behaviour of the option selected

Example file

The file contains a section for each drop down option. The following shows the file with only the first drop down option populates for simplicity of understanding:

The following elements are responsible for different behaviours:

ratesandvaluesprelcts.xml & ratesandvalueslcts.xml

These two files are generally copies of one another BUT can be very different depending upon your local council tax support/discount scheme.

ratesandvaluesprelcts.xml is used for:

• Housing Benefit

• Pensioners for LCTS

• Vulnerable groups for LCTS if you support them

ratesandvalueslcts.xml is used for:

• LCTS/LCTD for working age people only

Updating the Rates and Values files for LCTS

For LCTS file controls the settings specific to the LCTS scheme being implemented.

The commonly updated values from this file are:

<BandCap>

This controls the maximum band up to which LCTS can be paid e.g C would be entered to limit it to Band C.

<BandCapAnnualAmount>

This is linked to the first item and is the maximum amount for the band that it is to be capped at.

<MaximumLiabilityPercentage>

This is the maximum liability at which a person can get help even if they are passported. I.e. even on JSAIB they would not receive full help if the maximum liability percentage is set to an amount lower than 100.

Council Tax Bands

i.e. <BandA> to <BandH>

Simply a case of adding your current year amounts.

Example

The following illustrates this section of the file when populated for a site with a band cap of band C, a capped amount of 1300, a maximum liability percentage of 75% and various bands:

Each year when the rates change you will need to update the Personal Allowances / Premiums / Non Dependant Deductions etc.

Personal Allowances are catered for in the General Details Data section:

E.g. the following is the first of the allowances for people between 16 and 24 from April 2017:

<GeneralDetailsData>

<PersonalAllowanceSingle16To24>57.90</PersonalAllowanceSingle16To24>

The only thing you need to do is update the amounts inside the XML tags.

Likewise, premiums can be found in these sections:

<ChildrenAndYoungAdultsData>

<CapabilityData>

The Non Dependant Deduction levels can be found within the Other Adults Data section:

<OtherAdultsData>

The calculator’s settings for OtherAdults data allow you to change the options you show.

The following is an example of there being 4 different bands of Non Dependant deduction specific to Council Tax:

If we wanted to change this to be 6 bands with different thresholds from these we would replace the above section with:

Also there are further settings that cater for passported incomes and this is how these are updated:

JSAIB Non-Dependant Deduction Rates

<CTBOtherNonDependantDeductionJSA>0</CTBOtherNonDependantDeductionJSA>

Other Passported Incomes

<CTBOtherNonDependantDeductionMostOthers>3.65</CTBOtherNonDependantDeductionMostOthers>

Other options which are generally changed are:

Income Disregards

These can be found in the Earned Income Data section e.g:

<EarnedIncomeData>

<SingleStandardDisregard>

Some local authorities have increased the amounts of these to reflect the incentive for people to work.

Family Premiums

Family Premiums are no longer included in HB Calculations however some councils do keep them in their LCTS scheme. For these to be excluded the value should be set to 0.00 per below:

<FamilyPremiumNormalRate>0.00</FamilyPremiumNormalRate>

<FamilyPremiumProtectedNormalRate>0.00</FamilyPremiumProtectedNormalRate>

Capital

i.e. <CapitalDisregardAmountBand1> and <TotalAssetsLimit>

The first option provides the means to reduce the threshold at which tariff income comes into place from 6,000 to a lower value.

The second Total Assets Limit allows a site to reduce the maximum Capital threshold from 16,000 to a lower amount.

An example of this is shown here where the threshold for tariff income is reduced to 1000 and the maximum capital limit is reduced to 6000:

<CapitalDisregardAmountBand1>1000</CapitalDisregardAmountBand1>

<CapitalDisregardAmountBand2>10000</CapitalDisregardAmountBand2>

<SharesAndPropertyToWeeklyAmountPensionableAgeDivisor>500</SharesAndPropertyToWeeklyAmountPensionableAgeDivisor>

<SharesAndPropertyToWeeklyAmountNormalDivisor>250</SharesAndPropertyToWeeklyAmountNormalDivisor>

<TotalAssetsLimit>6000</TotalAssetsLimit>

Example LCTS rates and values file

Enables you to change the rates of:

• DLA Care

• DLA Mobility

• PIP Daily Living

As and when they change annually.

This file also has the ability, should it ever change, to update the number of hours that are taken into account before a Non-Dependant Deduction is taken.

vulnerabilitytype.xml

This file is specific to Local Council Tax Support.

It enables a council to set a list of different circumstances that should be exempt from the local council tax support scheme in the same way pensioners are.

Example file

The following illustrates an example file with four different vulnerability options:

Simply remove any items or edit the above file if you want to change the default options. You can add additional options by simply adding another section like the following below the above:

Based upon the circumstances the claimant is reporting a change about, the eChanges form will dynamically tailor the evidence requested to complement the changes. The user is able to provide this information online and the form will ‘track’ what has and has not been provided so that, upon submission, the user is told what they still need to provide if anything is outstanding.

So, if a person was told five items were required and they uploaded evidence for four, upon submission the remaining item would be shown as outstanding. The citizen can then come back and upload these within a month with this information then being passed to the EDMS.

Evidence Settings

The following settings relate to changing evidence behaviour:

The following settings control types of evidence uploaded:

Evidence Configuration

Because evidence presented in the form is dynamic to a person's household, income etc. it is possible to configure when certain evidence requirements are asked for.

This is set up within the Form Configuration File - evidence.xml. Details at the following link:

The fast track functionality provided within the eChanges form ensures that citizens are provided with the ability to choose to provide all of their evidence prior to submission in order to have their claim processed quicker.

If a citizen does not choose the fast track method, they will have their application processed in the standard SLA for that council. Where the citizen opts in to Fast Track the council is able to let the citizen know how long it will be before it is processed; but this will be significantly quicker than the standard SLA.

The beauty of this service being embedded into a digital service is that the council gets all of the evidence it needs to process the claim on day one and the citizen is ensuring their claim is processed much faster than it otherwise would have.

Enhanced EDMS integration for Fast Track

When citizens submit a change(s) using Fast Track, the service is able to dynamically inform the EDMS application:

1. That the change is fast track or not

2. Separately identify the specific type of evidence as well as indicate whether it is linked to a fast track change or not

Fast Track Settings

Enabling of Fast Track is done by IEG4 so please contact help.ieg4.com to have this enabled for eClaim or eChanges.

The following settings are also present where a council ALSO has Risk Based Verification:

Based upon the circumstances the claimant is reporting a change about, the eChanges form will dynamically tailor the evidence requested to complement the changes. The user is able to provide this information online and the form will ‘track’ what has and has not been provided so that, upon submission, the user is told what they still need to provide if anything is outstanding.

So, if a person was told five items were required and they uploaded evidence for four, upon submission the remaining item would be shown as outstanding. The citizen can then come back and upload these within a month with this information then being passed to the EDMS.

Evidence Settings

The following settings relate to changing evidence behaviour:

The following settings control types of evidence uploaded:

Evidence Configuration

Because evidence presented in the form is dynamic to a person's household, income etc. it is possible to configure when certain evidence requirements are asked for.

This is set up within the Form Configuration File - evidence.xml. Details at the following link:

Configuration files are files that can augment / improve the control you have over the functionality in the form beyond the settings.

For the Self Employed function, there are 4 and these files are covered below:

businesscategories.xml

The purpose of this file is to enable a council to control the different type of businesses a person can indicate they are running. I.e. you can control the content of this drop down:

The following is the file format:

So basically each row of the drop down is filled by a row in the above file. The Value is purely to guide a person as to what could go inside the category. E.g. Beauty is the Value below but what the customer sees in the drop down is Beauty / Nail technician.

A new category can be added by simply copying this content and pasting it above or below an existing Business Category row. E.g

selfemployedexpenses.xml

The purpose of this file is to enable the list of expenses a person can select to be customised:

This file also enables a council to indicate whether the amount of the expense should be taken in full, partly or not all in terms of calculating the amount of profit they have.

The following is an excerpt from the file, as it is long:

Within the file example we can see from the <Id> field that there are four distinct expenses. Business Rates, Business Rent, Depreciation and Business Debt.

• The Name element is that is presented to customers in the form is the <Name>Business Rent</Name> element.

• The Description element is what is automatically added as help text.

• The Allowable part is key. This controls whether:

You can add a new expense type, with its own help and set whether it is allowable and to what degree as a result.

The Type element is for information for those updating these. It has no bearing on the calculation.

taxandnirates.xml

The purpose of this file is to hold the rates of income tax and national insurance for the purposes of self employed people.

The file holds sections for Income Tax and National Insurance.

In the Income Tax section it holds the threshold and rate (as a %) for these:

• Personal Allowance

• Basic Tax Rate

• Higher Tax Rate

In the National Insurance section it holds the threshold and rate (as a %) for these:

• Class 2 lower start point

• Class 2 higher start point

• Class 4 lower start point

File Example

taxandnirateslastyear.xml

The purpose of this file is to hold the tax rates for the financial year before this. This is to cater for people completing the form where there is some income/expenses in last year and some in this.

The file format is identical to the taxandnirates.xml file.

The following lists all of the settings in the HBAA - Full Case Review form and what they do.

The following are the settings specific to the Self Employed form:

If a person fails the DfE Free School Meal Check, a check is then done on whether they're entitled to Local Council Tax Support.

This checks for an active claim in your back office application. As it uses the 'National Benefit Schemas' all back office benefit applications are supported and the functionality works the same for Capita, Civica and Northgate.

If the outcome of both the DfE Free School Meal Eligibility Check and the Benefit Check results in there being no eligibility a message like so will be presented.

Prerequisite

In order to carry out this check, the council needs to have access to the necessary benefit APIs:

• PersonSearch

• ClaimDetail

If a council has Benefit eChanges, they will generally be licensed for the above APIs.

To ensure that a person always provides valid details, we have a real time bank verification service set up on this form.

When they provide bank details we:

a) Ensure the bank details and sort code are of a valid format

b) Speak to the bank verification service provided by Loqate:

To ensure they are valid bank account details and you have piece of mind that payments will not be paid to spurious accounts.

Similar to the BACS Extract, it is possible to create an export of your data in a clear and intelligible manner.

As a part of your implementation you'll be provided with an application that you will simply need to provide it with:

• From Date

• To Date

And this will output an extract file that contains a row for each application with all of the following fields (where applicable):

Prerequisite

The application we will provide to is designed to run locally in your council.

So it has built in configuration which tells it how to go and capture these details from the cloud securely.

For security purposes we will provide the information required for the configuration file separately from the application package.

The only thing that you will add outside of this is the network path that you wish to write the file to.

The result of all of the applications is a need to be able to pay citizens.

As a part of your implementation you'll be provided with an application that you will simply need to provide it with:

• From Date

• To Date

And this will output a BACS file like below:

Prerequisite

The application we will provide to is designed to run locally in your council.

So it has built in configuration which tells it how to go and capture these details from the cloud securely.

For security purposes we will provide the information required for the configuration file separately from the application package.

The only thing that you will add outside of this is the network path that you wish to write the file to.

Where OpenProcess is not used as your document management system, the online form is capable of:

1. Saving the PDF to a file location

2. Automatically indexing the form document into the document management system based upon the account number and whether the process is fully automated or not.

We can provide integration to the following widely used back-office EDM applications:

• Information@Work / NEC DM

• Civica W2/360/Comino

• Civica Workflow

To ensure that you can take a fully paperless Direct Debit approach you need to send details of the Direct Debit to be set up within 3 working days.

To optimise the process and remove legacy approaches of sending physical letters to customers, it is possible to automatically email the customer a letter branded with your council's branding.

We need you, as a part of your implementation to provide us with:

• Your council's logo

• Your council's name / department / address / contact info

If you go to the Form's Portal upon submission, you can see the DD_letter at the bottom of the Documents list:

An example letter generated looks as follows, with the details from the form automatically being used in the creation of the template:

Further localisation

Beyond the above, for RPO (Integrated forms) there is further localisation available that is set by IEG4. Details found here: