Appendix tables

Scenario 1: Medium level digital data sharing Scenario 2: High level digital data sharing
  1. The DSO uses an automated trigger to send a snapshot of their data on a regular basis to the IER hub.
  2. An API between the DSO and IER hub is used to transfer data to the hub.
  3. The existing IER hub receives datasets periodically (e.g. monthly) from the DSO and makes it available to EROs for download.
  4. An ERO downloads the dataset from the IER hub into a spreadsheet via their EMS system.
  5. An API and the Public Service Network (PSN) are used to transfer the data from the IER hub to the EMS system.
  6. The ERO has some basic data cleansing and matching tools, but still does manual checks on the quality of the data.
  7. The ERO uses the new data to trigger a mail merge process to contact the identified individuals that could be potential electors, inviting them to register, or existing electors where changes to their personal details have been identified.
  1. The DSO uses an automated trigger to send transactional data as it happens or at regular intervals to the IER hub.
  2. An API between the DSO and IER hub is used to transfer data to the hub.
  3. The existing IER hub packages the transactional data received from the DSO and makes it available to a specific ERO, based on the address data of the transaction.
  4. An ERO downloads the data package specific to their electoral area via their EMS system.
  5. An API and the PSN are used to transfer the data from the IER hub to the EMS system.
  6. The ERO uses advanced data cleansing and matching tools, with light touch manual checks on the quality of the data to identify potential electors from multiple data sources.
  7. Letters are automatically generated by the EMS system for all potential electors or existing electors where changes in personal details have been detected.

 

Scenario 1: Automated registration Scenario 2: Automatic registration
  1. The ERO identifies potential electors or existing electors where details have changed, from one or a combination of data sources.
  2. The citizen is flagged in the EMS system as a potential elector or an existing elector where a change in personal details has been detected.
  3. An electronic electoral registration form is populated with available data from the EMS system to initiate the registration or change to personal details.
  4. If contact details were obtained from a data source, a link to the electronic registration form (with known fields prepopulated) is sent to the citizen in an email or SMS, requesting the citizen to complete the registration. The citizen has X number of days to complete the electronic registration form.
  5. If the citizen has not responded after X number of days, the prepopulated registration form is automatically printed from the EMS system and sent to the citizen.
  6. After X number of weeks, a reminder is sent to the citizen to complete the online or printed registration form.
  7. If the citizen has not taken any action after X number of weeks, their record remains flagged in the EMS system until the canvass period, during which they could be contacted again.
  1. The ERO identifies potential electors from one or a combination of data sources, where there is sufficient information to register the citizen.
  2. The citizen is flagged in the EMS system as a potential elector or an existing elector where a change in personal details has been detected.
  3. An electronic electoral registration form is populated with sufficient data from the EMS system to automatically register a potential elector or update personal details of an existing elector.
  4. If contact details were obtained from a data source, an email or SMS is sent to the citizen to notify them of the proposed electoral registration or update to their existing details on the register. The citizen has X number of days to respond if the information in the form is incorrect or they have a valid reason to opt out of the registration.
  5. If the citizen has not responded after X number of days, the prepopulated registration form is automatically printed from the EMS system and sent to the citizen.
  6. If the citizen has not responded after X number of weeks, to change information or opt out, the citizen is automatically registered.
  7. The ERO sends a notification letter to the citizen to inform them of the actions taken.

Scenario 1: Medium level integration Scenario 2: High level integration
  1. A citizen is given a choice to register to vote at the end of an online application for a new passport, driving licence, or other public service transaction.
  2. The citizen clicks on a link to redirect to the Register to Vote website, with relevant data sent from the source and populated in the electoral registration web form. The citizen follows the standard process to completing the online registration application.

This is a more advanced approach to integrating electoral registration into other public services, with the citizen completing the missing information to register after completing the third party transaction, for example:

  • Additional fields on the third party website would capture missing information required to register to vote, as an extension to the third party transaction, e.g. at the end of an online driving licence application. If the citizen selects the option to register to vote, additional fields appear for the citizen to complete.
  • All of the required information is saved to the third party database and transferred to the relevant ERO via the IER hub.

Prerequisite Summary Benefits Risks

Unique identifier

 

  • Currently there is no identifier in the electoral registers to identify an elector uniquely.
  • Creating local identifiers would not solve the issue of duplicates across multiple registers and therefore a UK-wide identifier should be created.
  • All electoral registration applications are currently verified against DWP data, via the IER hub. Therefore, the unique identifier that is linked to the NINo could be generated during this process by either the DWP or GDS.
  • For existing electors, it might be possible to build on canvass reform. Where register entries are validated against DWP data where there is a match, a unique identifier could be linked to the elector.
  • A unique identifier could help to identify duplicates arising from a change in the elector’s details, e.g. address.
  • A unique identifier could also identify complete duplicate registration applications, e.g. citizen completes an application to register but is already registered at the same address.
  • Existing electors without a match against DWP data during the canvass discernment step would not be automatically allocated a unique identifier.
  • Electors without a NINo will not be automatically allocated a unique identifier.

Solution Summary Benefits Risks

Decentralised registers with unique identifier

 

  • Current system is decentralised with no unique identifier.
  • However, EMS systems provide tools to identify duplicates within a single, local register.
  • With a unique identifier, duplicates could be detected within a single register.
  • Without the unique identifier, the duplicates problem will not be resolved.
  • Does not allow comparison between registers to identify duplicates.
  • May not be possible to provide unique identifiers for all entries in the register if the elector could not be verified.
Single view of all registers with unique identifier
  • Maintain separate registers, but enable EROs to view (read-only) all entries on all registers.
  • Would enable comparison of all registers to identify possible duplicates, especially if unique identifiers have been allocated to register entries.
  • The single view of registers could support a UK wide lookup tool, without having to develop separate solutions.
  • May increase security risks around personal data.
Four national registers with unique identifier
  • Single national register for England, Scotland, Wales and Northern Ireland.
  • Northern Ireland already has a centralised register.
  • Welsh government is considering this option.
  • This would require national keepers of the registers.
  • Could identify duplicates across multiple registers within a nation.
  • Could facilitate a wider lookup function than local registers, although not UK wide.
  • This would not allow comparison across the national registers.
  • Impact of any data breaches would be far greater than with local registers. 
  • Operational impact, e.g. restructuring of ERO function could be disruptive. 
  • National keepers would be required – potential responsibility and accountability issues to resolve.
  • Could disenfranchise voters if moving across to a different nation and assume that they are still registered.
  • Risk that a citizen could be registered in more than one nation or move has been updated in one nation, but not yet the other.
Single, UK wide register with unique identifier
  • Restructuring electoral registration process so that there is one UK wide register, rather than the current 372 registers.
  • This would require a keeper of the register.
  • Could identify duplicates across all UK registers.
  • Could facilitate a UK wide lookup function.
  • One unique identifier per elector
  • Unique identifier is issued centrally
  • Facilitate electoral reform more generally, e.g. early voting, voting anywhere
  • Impact of any data breaches would be far greater than with local registers.
  • Operational impact, e.g. restructuring of ERO function could be disruptive.
  • National keeper– potential responsibility and accountability issues to resolve.
  • Different governments may have conflicting rules, structures, processes, etc. that could complicate one register. Also different governments would have to actively support the creation of a single register.

  Summary Automation Integration Duplicates Risks
Decentralised registers Current system This would be deliverable under the current system. The IER hub would provide the infrastructure to support automation of registration. This would be deliverable under the current system. IER hub would provide the infrastructure to support a more integrated registration system. Does not allow comparison between registers to identify duplicates. However, EMS systems provide tools to identify duplicates within a single, local register. Will not resolve duplicates problem, especially across individual registers.
Single view of all registers Maintain separate registers, but enable EROs to view (readonly) all entries on all registers This would help to address some of the risks associated with automation under the current system, e.g. confirming whether a potential elector is already registered elsewhere. This would not offer any obvious advantages for developing a more integrated system.

Would enable comparison of all registers to identify possible duplicates. However to identify actual duplicates with certainty, a unique identifier would be required.

Could be used as lookup function, without having to develop separate solutions.

May increase security risks around personal data.
Four national registers

Single national register for England, Scotland, Wales and Northern Ireland.

Northern Ireland already has a centralised register. Welsh government is considering this option. This would require national keepers of the registers.

Would simplify the infrastructure required to support automated / automatic registration by reducing the number of registers linked to the IER hub. Would enable a move toward a more continuous system of registration with less re-registration required, unless you move to a different part of the UK. Would simplify the infrastructure required to support backend processes of integrating electoral registration. No impact on the elector side of integration. This would not allow comparison across the national registers. To be of benefit, this would require a unique identifier to identify actual duplicates within each nation. Could facilitate a wider lookup function, although not UK wide.

Impact of any data breaches would be far greater than with local registers.

Operational impact, e.g. restructuring of ERO function could be disruptive.

National keepers would be required – potential responsibility and accountability issues to resolve.

Single, UK wide register Restructuring electoral registration process so that there is one UK wide register, rather than the current 372 registers. This would require a keeper of the register.

Further simplify the infrastructure by providing a single link to the IER hub.

Would enable a move toward a more continuous, portable system of registration, with updating, rather than re-registering of details.

Further simplify the infrastructure by providing a single link to the IER hub. To identify actual duplicates with certainty, a unique identifier would be required. Could facilitate a UK wide lookup function.

Impact of any data breaches would be far greater than with local registers.

Operational impact, e.g. restructuring of ERO function could be disruptive.

National keeper of register – potential responsibility and accountability issues to resolve.

Different governments may have conflicting rules, structures, processes, etc. that could complicate one register.