MyLicence. Business Process Guide. Version 3.0 July 2014 ABI.ORG.UK. PAGE 1 of 56

Transcription

1 MyLicence Business Process Guide Version 3.0 July 2014 PAGE 1 of 56

2 INTRODUCTION Background The MyLicence programme (formerly known as the Insurance Industry Access to Driver Data or IIADD programme) will give insurers access to accurate data from the DVLA on driving entitlements, convictions and penalty points when they are providing quotes for motor insurance policies. The initiative will work by drivers providing their driving licence number (DLN) when they apply for insurance. An automatic check will then be made to the DVLA database, which will return accurate information on licences. The information provided will include endorsement codes, penalty points, the amount of any fines, conviction dates, disqualifications, type of licence held, length of time licence held, and entitlement to drive (i.e. manual/automatic, motorcycle, HGV, etc.). The MyLicence programme is a joint initiative of the DVLA, the Department for Transport and the insurance industry, represented by the Association of British Insurers (ABI) and the Motor Insurers Bureau (MIB). These organisations have been working together for five years to agree the scope of the service. Insurance intermediaries, comparison sites, and other industry bodies have also been involved in these discussions. The process will direct enquiries through an industry hub which will be operated by the Motor Insurers Bureau. This will ensure system stability and ultimately will be able to add additional useful information, such as no claims discount or claims history, to make quote processes even more accurate. Using data provided by the DVLA will remove the opportunity for customers to make mistakes when declaring their licence entitlement and conviction history. During an information match conducted with the DVLA, we found nearly one in five policyholders understated the number of motoring convictions they have; some by accident, others deliberately in order to pay a lower premium. We therefore estimate that under-declaring motoring convictions adds about 15 per policy to the cost of insurance for those motorists who declare their driver data accurately. In addition, a number of motorists mistakenly provide an incorrect date for motoring convictions that have actually expired, meaning they are paying too much for their insurance. These customers will therefore benefit from lower premiums as a result of this initiative. As well as saving honest customers money, it will mean that insurers will need to ask customers fewer questions when they apply for cover, thereby speeding up the purchasing process for everyone. Importantly, by reducing the incidence of negligent misrepresentation and non-disclosure, the initiative will also greatly reduce the number of cases requiring consideration by the Financial Ombudsman. The purpose of this guidance This document codifies the business processes that the insurance industry will need to follow to efficiently access drivers records through the MyLicence service. It sets out mandatory processing requirements, as well as recommended process flows. PAGE 2 of 56

3 It is intended that this document will enable industry stakeholders to understand how their business processes will need to be adapted to make use of the MyLicence service. The document does not cover the technical requirements that will allow the industry to connect to the MIB Hub. That information is available in the Hub Industry Interface Specification published by the MIB, which is available upon request from The document also does not cover the etrading Standards designed to support the MyLicence changes. These can be obtained from Polaris UK Ltd. More detail about how compliance with the processes set out in this document will be monitored is available when firms register for the MyLicence service via the MIB registration tool. Intended audience The guide is aimed at insurers, intermediaries, software houses and comparison websites. Authors of the guidance The guidance has been compiled by the Association of British Insurers (ABI) and the Motor Insurer's Bureau (MIB), in consultation with Polaris UK Ltd (the industry etrading standards body). The principles and processes documented in this guide have been developed following consultation with the DVLA and the Information Commissioner s Office about data protection requirements and consultation with industry representatives about their user requirements. Development, implementation and review of the guidance This document has been available to the insurance industry in draft since early October This is the final version of the guidance before the MyLicence service is launched and has been updated to reflect feedback from the DVLA and the industry. After the launch of the MyLicence service, this document will be reviewed periodically to ensure that the processes codified here remain relevant and appropriate. Format of the guide The guidance is presented in seven chapters. Chapter one considers the new business process with mid-term adjustments covered in chapter two. The renewal process is outlined in chapter three. Chapter four considers retention of data, while chapter five considers visibility of data. Chapter six includes a set of miscellaneous principles not included elsewhere in the document. Chapter seven provides a glossary of terms used throughout the document, and terms included in that glossary are italicised throughout the document. In addition, there is one appendix to the document. The appendix details two case studies to explain the restrictions on using both DVLA and self-declared data (as discussed in section 6.3). The principles set out in the first five chapters of the document are those applicable to those parties that are allowed access to DVLA data; i.e. they have been through the appropriate registration process with the MIB and are authorised to use DVLA data. PAGE 3 of 56

4 Whilst more detail about the registration process is available via the MIB, the general principles for participation are covered in chapter six, as are the implications for those firms that are not participants. Throughout the chapters of the document, we have identified to which parties the process flows are relevant: i.e. insurers, intermediaries, software houses and comparison websites. Association of British Insurers July 2014 PAGE 4 of 56

5 1 NEW BUSINESS PROCESS 1.1 Collection of Information from the Customer Step Process Proposer is shown and agrees to a fair obtaining notice, informing them how their data will be used. Next Step or 1.2.3(1) Applies To Distributors Notes: It is mandatory for fair obtaining notices (FON) to be presented to the customer, and for the customer to explicitly consent to the fair obtaining notice, in advance of any information being requested from the DVLA. It is strongly advised that this information is presented before any data is requested from the customer. Suggested fair obtaining notice clauses have been provided by the MIB and are available on the ABI website. These clauses are appropriate for any distribution channel. The suggested FON wording is to be used in addition to current FONs in place, it is not a replacement and firms may adapt the wording in the fair obtaining notices as they see fit. We recommend seeking independent legal advice prior to use of the fair obtaining notice. Having an appropriate fair obtaining notice will be part of the user agreement between each organisation accessing DVLA data and the MIB. While consent must be explicit, there is no prescribed method of getting that explicit consent (i.e. a tick-box is sufficient but not mandatory). It is optional for an individual to provide their DLN. Therefore, if an individual disagrees with the fair obtaining notice, no data can be requested from the DVLA and the individual should be asked to selfdeclare their information (in which case the next step is 1.2.3(1)). As per the conditions for processing under the Data Protection Act 1998 an individual may withdraw consent. If consent is withdrawn firms must not use the DLN to request additional data from the DVLA using that individual s DLN. Withdrawing consent does not affect the validity of anything already done on the understanding that consent had been PAGE 5 of 56

6 given Proposer provides DLN, full name, date of birth and gender for each driver with a licence from Great Britain (GB). Notes: It is strongly recommended that proposers are encouraged to provide the DLN for themselves and any named drivers if they hold GB licences, by explaining the benefits for them relative to using selfdeclared data , 1.2.3(2) or 1.2.3(3) Distributors The MyLicence service will only provide information on GB licences (note this covers licences from England, Scotland and Wales and excludes licences from Northern Ireland, the Isle of Man, the Channel Islands or any other state). When requesting information about the proposer and any named drivers it will be necessary to first determine if each driver is a GB licence holder and to explain to the proposer what constitutes a GB licence. This may be done via help text, a specific question or any other method deemed suitable by the distributor. It is only necessary to request a DLN from GB licence holders. Non- GB licence holders will need to self-declare their information (as per step 1.2.3(2)). However, it will be beneficial for the industry if the DLNs of Northern Irish licence holders are requested, as it will allow this information to be included in the CUE database. Firms that collect the DLNs of Northern Irish licence holders for this reason will need to obtain consent from their customers. Distributors seeking the DLN of named drivers must ask the proposer to gain the consent of the named driver for the processing before the DLN of the named driver is processed. It will not be mandatory for individuals with a GB licence to declare their DLN in order to request a quote. Where a driver has a GB licence but will not provide their DLN it will be necessary for them to selfdeclare if the quotation process is to continue (as per step 1.2.3(3)). Requests for DVLA data for each driver can only take place once the full name, date of birth, gender and DLN has been provided for that driver. PAGE 6 of 56

7 Distributors can request the full name, date of birth, gender and DLN from the proposer at any point in the application process. The full name, date of birth, gender and DLN of any named drivers can be requested from the proposer at the same time as the proposer or during a subsequent step. DVLA data about named drivers can either be sought from the MIB Hub at the same time as the information about the proposer or during a subsequent step. However, the overall quote process will be fastest if requests for DLN information are made as early in the question set process as possible. Distributors must not pass DVLA data to panel members for processing until the full application form has been completed, the fair obtaining notice has been seen, explicit consent given, and a quote has been requested. Where distributors use a panel of insurers and/or intermediaries it will be necessary for the question set to request both self-declared data and the DLN for each individual until their entire panel is able to process DVLA data Distributor verifies the Driver Licence Number for each GB licence holder that declares a DLN or 1.2.3(4) Distributors Notes: After collecting the full name (including any middle names), date of birth, gender and DLN for each GB licence holder the distributor is required to validate at least the first 11 characters of the DLN (surname, date of birth and gender). If a DLN cannot be validated, the driver record must not be requested from the DVLA. If validation still fails after asking the individual to correct their details the distributor should ask the individual to selfdeclare (as per step 1.2.3(4)). Once the DLN has been validated, the licence data can then be requested from the MIB Hub. A DLN may not validate if the name or gender of the individual has PAGE 7 of 56

8 changed but the DVLA has not yet issued a new driver licence. Therefore, if a customer has not changed either their DLN or personal details after prompting, distributors may want to ask customers to provide their identity details as they appear on their current licence. Alternatively, the distributor could ask for the customer s previous name, and validate the information using the previous name, rather than relying on self-declared data. If the distributor does validate using the previous name supplied, before sending the request to the MIB Hub they should take all reasonable steps to ensure that the DLNs provided belong to the individuals named in the policy. Moreover, they are accepting the increased risk that the policy is based on data relating to a different individual. Also, if an individual has provided a DLN that has not been updated for their new name or gender, the distributor, intermediary or insurer may want to prompt the individual to update their licence with the DVLA. Note that the DLN takes the following format: A B C D GARDN C99 LY A = the first five letters of your surname. If your surname has fewer than five letters, the remaining letters are made up using the number 9. Where a surname has a special character before the fifth character (e.g. a space, apostrophe or hyphen) the character is ignored. In the case of any surnames beginning MAC, such as MacDonald or Mace, the A is removed, converting them to give the surnames MCDON and MCE99. B = the first and last numbers are the year of your birth. The second and third letters are the month of your birth. If you are female, 5 is added to the second digit, with the total being the number used as the second digit. The fourth and fifth digits are the day of the month on which you were born. C = the first two initials of your first names. If you only have one initial, the second character will be a 9. The third character is normally a 9, but is used as a differentiator when required (i.e. when twins have the PAGE 8 of 56

9 same initials). As it is common for individuals to use a different name to their given name (for example someone named William that purchases insurance under the name Bill), firms may limit validation to the first 11 rather than 13 characters. It is recommended that this is only done when validation of the first 13 digits fails and the customer does not change their name or DLN after prompting, to ensure validation remains as strong as possible for identity verification. There are also approximately 11,000 active drivers in Great Britain who do not have a forename as shown on the DVLA database. In this situation each of the first two initials will be replaced with a 9. D = randomly generated check digits that cannot be fully validated by any distributor. Distributors should check that both characters are letters from the standard English alphabet. If the distributor wishes to do so they can automatically populate those characters of the DLN which they can generate from the personal information declared. However, while this may increase the proportion of customers that provide their DLN, and reduce the probability of miskeying, this may result in a higher error rate for DVLA data enquiries, particularly if the individual has not updated their driving licence following a change of name or if the individual does not have a forename. The DLN may also contain a middle initial, which may not have been provided to the insurer Distributor collects the Driver Licence Number for each GB licence holder that declares a DLN and passes the DLN to panel members to request data from MIB Hub Distributors There will be a transition period in the MyLicence programme where some distributors will collect the DLN from customers and pass this panel members to request the data from the MIB hub. It is mandatory for fair obtaining notices to be presented to the customer, and for the customer to explicitly consent to the fair obtaining notice, in advance of any information being requested from the DVLA. Therefore, distributors should obtain consent at the point where the DLN is collected and must follow the process as per step It will be up to Panel members to ensure that the distributor is obtaining the consent and validating the DLN. PAGE 9 of 56

10 Distributors will need to collect the DLN, full name, date of birth and gender for each driver with a GB licence and should follow the process as per step Distributors will need to pass the full set of selfdeclared data and the DLN to panel members in case the DVLA search fails and insurers need to quote using self-declared data. Panel members receiving the DLN from distributors may request the DVLA data only once they have the full name, date of birth, gender and DLN for each driver. The point at which the DLN information is passed down will be for distributors and panel members to determine, but please note that the quote process will be fastest if all records are requested as soon as possible during the question set process. As set above, panel members must not process DVLA data until the full application form has been received, explicit consent given and a quote has been requested. The distributor must also validate the DLN to at least the first 11 characters before sending the DLN to panel members as per step Driver Record is requested from the DVLA Step Process Next Step Applies To Distributor, intermediary or insurer requests data from MIB Hub Notes: Once the distributor has validated each DLN, the DVLA record associated with that DLN can be requested. This will require the distributor or, where the DLN is passed down, panel members to send a request to the MIB Hub Distributors, intermediaries and insurers The request to the MIB Hub can be made by any distributor (i.e. including comparison sites, software houses and intermediaries, not just insurers), which has collected the information from the customer and is an Authorised Third Party. As noted above, when there are named drivers on a policy requests for the proposer's driver record can either be processed in advance of the named drivers' records, or at the same time as the named drivers' records. Note that the overall quote process will be fastest if all records PAGE 10 of 56

11 are requested as soon as possible during the question set process MIB Hub checks cache and then the DVLA, before responding to the distributor Notes: The MIB Hub will first check its cache to see if the information is already available. If it is, the record will be returned immediately to the distributor without a new request being made to the DVLA. If not, the DLN will be sent to the DVLA, and the DVLA will send a response to the MIB Hub which will then be passed to the distributor or panel member where the DLN has been passed down and the call to the MIB Hub is made by the panel member , 1.2.3(5), 1.2.3(6) or 1.2.3(7) MIB Hub For each DLN submitted, there are four potential responses (the message codes are available in the MIB Hub Industry Interface Specification). Note that returned data responses for each DLN submitted to the MIB Hub for a single quotation are completely independent of any others submitted. (1) The driver record is returned as requested; In this case the distributor will receive the DVLA record and the individual will be able to continue with their application process (as per step 1.3.1). Where a record is returned, the DVLA will disclose up to a maximum of 32 offences (with the associated endorsement code, fine, penalty points, disqualification and custodial sentence information) for each individual. Note that data from the DVLA will not be sent in any particular order (i.e. most recent convictions first). Given that many current industry systems register a maximum of five offences per individual, it will be up to firms to adapt their systems to accept more offences, or trading partners will need to agree rules with distributors to decline the risk or refer the risk to a specialist underwriter where convictions exceed their rating rules. To inform decisions about increasing the capacity of systems, data on the average number of penalty points per individual can be found here: PAGE 11 of 56

12 (2) The driver record is not found; In this case, the MIB Hub will return the response Record for supplied DLN cannot be found. This response will most likely occur because the DLN doesn t match a record on the system, either because the DLN has been miskeyed, an error has occurred when automatically generating the DLN or a DLN has been falsely created. In this case, the distributor may prompt the proposer to correct their details and then resubmit the DLN to the MIB Hub. If the request is successful on a subsequent attempt, the application process can continue. If the request is unsuccessful the distributor has a choice of whether to ask the proposer to correct the details again, or self-declare (as per step 1.2.3(5)). Where details are corrected by the proposer, it is necessary for the distributor to validate them once again before submitting the request to the MIB Hub. Alternatively, this may occur because the DLN is legitimate but cannot be found due to processing error. Accordingly, the distributor may want to refer the customer to the DVLA s View Driver Record service, available on the GOV.UK website. (3) The record cannot be released by the DVLA; In this case the MIB Hub will return the response Record for supplied DLN has been suppressed. The record is expected to be suppressed in roughly one per cent of all cases. This is typically due to the record being under maintenance (for example, an address is being changed), and the insurer should not infer anything from this response, other than the need for the individual to self-declare. In this case, the individual will need to self-declare their information (as per step 1.2.3(6)). There is considerable variation in the length of time a record can be suppressed by the DVLA. Accordingly, if a record is suppressed, it is PAGE 12 of 56

13 strongly recommended to proceed with self-declared data, rather than requesting the data from the DVLA at a subsequent point. As individuals may question why their record has not been released distributors may wish to direct the proposer to the DVLA customer portal on the GOV.UK website so that they can view their record themselves. This may spur the individual to follow up directly with the DVLA to understand why their record is suppressed and improve the record return rate from the DVLA database. (4) The request is invalid; In this case, the MIB Hub will return one of several responses indicating that the request is invalid. This would occur if the request cannot be processed due to error at some point, for example if the data sent to the DVLA is incomplete or in an incorrect format (most likely this would indicate that the distributor s validation process has failed). If the request is successful on a subsequent attempt, the application process can continue. If the error persists the distributor can ask the proposer to self-declare (as per step 1.2.3(7)). If details are corrected by the proposer, it is necessary for the distributor to validate them once again before submitting the request to the MIB Hub The distributor asks the individual to self-declare Notes: Given the above, self-declaration could be caused by one of seven factors, each of which is discussed in more detail below: Ends Distributors and software houses (1) The proposer does not agree to (or disagrees with) the fair obtaining notice; If a distributor uses a fair obtaining notice that includes MyLicence, and an individual does not agree to (or disagrees with) that MyLicence specific fair obtaining notice, data must not be requested from the DVLA. PAGE 13 of 56

14 If the fair obtaining notice applies to all data processing that will occur as a result of progressing a quote, the quote process should not continue as per the principles of the Data Protection Act (2) A driver is not a GB licence holder; In this case, the DVLA will not hold information on the individual, so it cannot be provided. Insurers can choose to offer quotes to only those drivers with a GB licence if they can show that they present a lower risk than those without GB licences. (3) A driver will not declare their DLN; There will be instances where an individual will be a GB licence holder, but is unwilling to provide their DLN. It is up to the distributor to decide if the provision of the DLN should be mandatory for GB licence holders. Similarly, it is for each insurer to decide how they will treat GB licence holders who do not declare their DLN. (4) A DLN cannot be validated by the distributor; If validation still fails after asking the individual to correct their details, the distributor should ask the individual to self-declare. If a DLN has not been validated, the driver record must not be requested from the MIB Hub. A DLN may not validate if the name or gender of the individual has changed but the DVLA has not yet issued a new driver licence. Some options for dealing with this scenario are set out in section (5) The driver record is not found; If the MIB Hub returns a response of Record for supplied DLN cannot be found and the proposer has confirmed that the details are correct, then the individual will need to self-declare their information. This response will most likely occur because the DLN doesn t match a record on the system, either because the DLN has been miskeyed or a DLN has been falsely created. PAGE 14 of 56

15 Alternatively, this may occur because the DLN is legitimate but cannot be found due to a processing error. Accordingly, the distributor may want to refer the customer to the DVLA s View Driver Record service, available on the GOV.UK website. (6) The record cannot be released; It is expected that the MIB Hub will respond with Record for supplied DLN has been suppressed in roughly one per cent of cases. This means that the DVLA acknowledges that the DLN exists but is unable to return the information relating to it. Typically, this will be because the information on the record is being updated (for example because the individual has notified the DVLA of a change of address). There is considerable variation in the length of time a record can be suppressed by the DVLA. Accordingly, if a record is suppressed, it is strongly recommended to proceed with self-declared data, rather than requesting the data from the DVLA at a subsequent point. In these cases, the distributor will need to ask the proposer to selfdeclare the information. A response of Record for supplied DLN has been suppressed will, however, at least confirm the identity of the individual (by acknowledging that the DLN does exist). Furthermore, because this is outside the control of the individual it is recommended that the risk is not declined (or premium loaded) on these grounds. As with the case where the DLN does not exist, the distributor may wish to refer the customer to the DVLA s View Driver Record service, available on the GOV.UK website, so that they might understand why the record was not returned. (7) The request is invalid; The DVLA will provide a response indicating the request was invalid if the request cannot be processed due to error at some point. For example, if the data sent to the DVLA is incomplete or in an incorrect format. If the request is successful on a subsequent attempt, the application process can continue. If not, the proposer will need to self-declare. PAGE 15 of 56

16 Again, because this is outside the control of the individual it is recommended that the risk is not declined (or premium loaded) on these grounds. If details are corrected by the proposer, it is necessary for the distributor to validate them once again before submitting the request to the MIB Hub. General Where there is more than one driver on a quotation there will be cases where DVLA data is available for some of the individuals on a policy, but not others. In these cases, it is possible to use DVLA data where it is available, only resorting to self-declared information when necessary. There will be a different response from the MIB Hub to differentiate between a record that has not been found, a record that cannot be released by the DVLA and a request that is invalid. Distributors may wish to set additional responses to allow insurers to identify if selfdeclaration has occurred due to one of the other four scenarios listed also. In general insurers and intermediaries should not rate on the basis of self-declared and DVLA provided data for the same individual. This is because DVLA data is being provided to replace, not verify selfdeclared data. More information on this restriction and the exemptions to it are set out in detail in section 6.3 and the case studies in appendix A. It is strongly recommended that where there is a choice between DVLA data and self-declared data, DVLA data is taken. The intermediary or insurer must be able to identify if the data they are rating on is self-declared or from the DVLA Responses where the DLN has been passed by distributors to panel members to send a request to the MIB Hub Intermediaries and insurers Where the driver record is returned as requested, intermediaries and insurers will be able to provide a quote or decline a risk (as per step 1.3.2). PAGE 16 of 56

17 However, where the driver record cannot be found, cannot be released or the request is invalid, panel members will not be able prompt the individual to correct their details and make another request to the MIB Hub or prompt them to check their details on the DVLA s View Driver Record service. In these situations, we recommend that insurers and intermediaries quote based on self-declared data that has been provided by the distributor. Please note that where intermediaries and insurers quote using selfdeclared data because DVLA data has not been returned, it will not be clear to an individual that their quote is based on self-declared data. Individuals providing their DLN and consenting to their DVLA data being processed may have a reasonable expectation that their quote will be based on DVLA data. In this case, it is acceptable for authorised parties to request DVLA data when completing the sale. However, the authorised party must not set a premium different to what would have been offered if DVLA data was used for the original quotation, or decline cover for an applicant that would have been accepted if DVLA data was used for the original quotation. This is set out in more detail in section Generation of quotations Step Process Next Step Applies To Individual requests a quote and DVLA data is passed to panel members Notes: Distributors and software houses Once the individual has completed the question set and confirmed that their information is correct, the DVLA information can be passed from the distributor to their panel members. In general, where the distributor or software house has collected both self-declared and DVLA data to service all their panel members, both sets of data will be made available, however premiums should be based on either DVLA data or self-declared data. Verification should not take place against both sets. This is because DVLA data is being provided to replace, not verify self-declared data. More information on this restriction and the exemptions to it are set out in detail in section 6.3 and the case studies in appendix A. PAGE 17 of 56

18 It is strongly recommended that where there is a choice between DVLA data and self-declared data, DVLA data is taken. Please note that if DVLA data has not been collected at the point of quote (for example, because the distributor cannot collect it) it is acceptable for an authorised insurer to use DVLA data to request DVLA data when completing the sale, provided the consent has been obtained from the customer Panel members provide a quote or decline the risk Notes: Depending on the information provided to the insurer, there will be one of three responses: or Intermediaries and insurers Decline the risk; The insurer will refuse to provide a quote for the risk. In this case the insurer and/or intermediary will need to purge the DVLA data from their systems as discussed in chapter 4 of this document. Referral of the risk to a specialist underwriter; In such cases, the insurer and/or intermediary will be able to view data from the DVLA as per chapter 5 of this document. In the event that an insurer or intermediary is not successful in attracting the business, they will need to purge the DVLA data as per section 4 of this document. Quote is provided; The insurer or intermediary provides a quote. As above, the insurer must comply with the rules regarding data retention and visibility as per chapters 4 and 5 of this document. Regardless of whether a quote is provided or refused, insurers may retain and use data that is in an anonymised or aggregated form indefinitely for modelling, pricing, actuarial or management information purposes, subject to their compliance with the Data Protection Act Refer to chapter 4 of this document for the rules regarding anonymisation and aggregation. Provided that the fair obtaining notice permits such use and they are an authorised, insurers and intermediaries may use third party providers to help rate and interpret the data, if required. Third party providers can connect directly to the MIB Hub if they have been PAGE 18 of 56

19 directly contracted by an insurer, intermediary or software house to access the MIB Hub on their behalf. However, they may only access and process DVLA data for the purposes defined in that contract. They must not use DVLA data for any purpose other than for providing a quotation. More information on this issue is covered in chapters 4 and 5 of this document. 1.4 Issue of the policy Step Process Successful insurer or intermediary completes the sale Next Step Ends Applies To All Notes: The proposer chooses a preferred provider from those insurers that provide a quote, either directly or following a referral. The successful party must comply with the rules regarding data retention and visibility in accordance with chapters 4 and 5 of this document. After the sale is completed, the successful insurer or intermediary must also advise the proposer if any of the DLNs correspond to an expired licence Unsuccessful insurers and intermediaries delete data once quotations lapse All Notes: Once a quotation lapses without the issue of a policy, the data received from the DVLA (excluding the DLN as it was self-declared) must be deleted by all parties in accordance with chapters 4 and 5 of this document. This does not apply to anonymised or aggregated data. PAGE 19 of 56

20 2 MID-TERM ADJUSTMENT PROCESS 2.1 A new driver is added to the policy Step Process Policyholder requests a new driver is added to the policy Notes: In this situation, the insurer or intermediary would be expected to follow the same process as for a new quotation as set out in chapter 1, but only for the additional driver. Next Step As per chapter 1 Applies To Insurers & intermediaries If the policyholder does not proceed with the addition of the new driver, the insurer or intermediary must delete the data relating to the new driver, as per step of the new business process. Insurers and intermediaries must not refresh data for the policyholder and any existing drivers, as the contract was accepted on the basis of their data as provided at the inception of the policy, except in limited circumstances set out in below. Note, at the point of renewal, the holding insurer and/or intermediary will have an opportunity to refresh conviction data for all drivers on a policy. 2.2 Mid-term adjustments requiring additional entitlements Step Process Next Step Applies To Mid-term adjustment is declined due to the licence status or a lack of entitlement Insurers & intermediaries Notes: A mid-term adjustment (MTA) will fail if the licence status and/or entitlement information received at the policy inception does not allow the proposed mid-term adjustment. For example, this might happen if the policyholder tries to change from PAGE 20 of 56

21 an automatic to a manual vehicle during a mid-term adjustment, when the data received from the DVLA at point of quote indicated that the policyholder or one of the named drivers was restricted to only driving automatic vehicles. Similarly, a policyholder may request a change to a vehicle which requires a different type of licence at the beginning of the policy valid period. In these scenarios, declining the mid-term adjustment or cancelling the policy would be inappropriate if the policyholder, or named driver, concerned has since had the restriction on their driving entitlement lifted. Accordingly, where a MTA has declined in the first instance on the basis of licence status or insufficient entitlement, it is possible to request refreshed DVLA driver information and rerun the quote, as per steps below Driver record is requested from the DVLA Insurers & intermediaries Notes: In this scenario, it will be necessary for the insurer or intermediary handling the MTA to request updated driver records from the DVLA. In this case, the insurer or intermediary should follow steps , as set out for the renewal process. This will see the insurer or intermediary gain processing approval from the proposer and named driver, validate the driving licence number(s) and then request the driver record from the MIB Hub. The MIB Hub will then return a response to the requestor Irrelevant data is removed from the new record Insurers & intermediaries Notes: The mid-term adjustment must only be based on the updated licence status and entitlement information. This is because insurance policies are annual contracts and convictions sustained since the inception of the policy should not be included in rating until the policy is renewed. Therefore, of the new information received from the DVLA, the only data fields that can be used in the mid-term adjustment in this scenario are the licence status and entitlement fields. PAGE 21 of 56

22 2.2.4 Mid-term adjustment is completed Notes: After removing the non-relevant information, the insurer or intermediary can update the record and progress the mid-term adjustment, similar to steps and of the renewals process. Ends Insurers & intermediaries 2.3 Any other mid-term adjustment Step Process Mid-term adjustment is made without refreshing DVLA data Notes: For any other mid-term adjustment a new DVLA enquiry is unnecessary and must not be requested. This is because the insurer will be able to retain the data received from the DVLA when the policy was incepted and convictions sustained since inception should only be relevant at the following renewal. Next Step Ends Applies To Insurers & intermediaries It is not permissible to periodically check the DVLA database to check for disqualifications or newly added convictions. Holding insurers and intermediaries will need to continue to rely on the individual advising them if they have been disqualified, in accordance with any policy condition which might be applicable. If a record needs to be verified at the point of claim, this will continue to be possible via the three-way call system already in place. Given that DVLA data will be available at point of quote in future, it is expected that the need for this service will decrease. To ensure validation of a DLN at renewal is successful, it is strongly recommended that the insurer or intermediary prompt the individual to update their licence when advised of a change of name or gender, and then request they are advised of the revised DLN details when they are available. PAGE 22 of 56

23 3 RENEWAL PROCESS 3.1 Where DVLA data is requested during the renewal process Step Process Next Step Applies To Processing approval is given by the proposer and named drivers Insurers & Notes: intermediaries Insurers and intermediaries issuing renewal invitations have a choice of whether to use data from the DVLA if the policy was not previously based on DVLA data and the DLN is available. Where DVLA data has previously been provided, the holding insurer or intermediary can request refreshed data from the MIB Hub to ensure that decisions are based on accurate data. As with the new business process, any organisation processing DVLA data for the purpose of generating a renewal invitation must have the consent of the proposer before the DLN of the proposer is processed. Similarly, insurers and intermediaries processing the DLN of named drivers at the point of renewal must ask the proposer to gain the consent of the named driver for the processing before the DLN of the named driver is processed. To minimise costs it is strongly recommended that the fair obtaining notice used during the new business process outlined above covers both the original quotation and any subsequent renewals for both the proposer and any named drivers. Where the DLN was received for a policy already in force, insurers and intermediaries must gain approval for the processing of DVLA data for renewal quotations before the DLN is used to request data from the DVLA. Where a DLN is already known and consent hasn t been received, the individual must consent to the processing of the DLN for the purpose of producing a renewal invitation before DVLA data can be used during PAGE 23 of 56

24 the renewal process. Suggested FON wording have been provided by the MIB and are available on the ABI website. These clauses are appropriate for any distribution channel. The suggested FON wording is to be used in addition to current FONs in place, it is not a replacement and firms may amend the fair obtaining notices as they see fit and we recommend seeking independent legal advice prior to use of the fair obtaining notice. Having an appropriate fair obtaining notice will form part of the user agreement between each organisation accessing DVLA data and the MIB. While consent must be explicit, there is no prescribed method of getting that explicit consent (i.e. a tick-box is sufficient but not mandatory). If an individual revokes consent, firms must not use the DLN to request additional data from the DVLA using that individual s DLN. However, it is possible to continue to use data received before consent was revoked, including the DLN itself as per the principles of the Data Protection Act Driver licence number is validated by the insurer or intermediary Insurers & Notes: intermediaries As with the new business process, the insurer or intermediary must validate the DLN before any data is requested from the MIB Hub (as per step 1.1.3). If a DLN cannot be validated, the driver record must not be requested from the MIB Hub. As validation of a DLN that had previously been validated could only fail in this step if the policyholder has advised of a change of their name or gender, it is strongly recommended that the insurer or intermediary prompts the individual to update their licence when advised of such a change, and then request they are advised of the revised DLN details when they are available Driver record is requested from the MIB Hub Insurers PAGE 24 of 56

25 Notes: Once the holding insurer or intermediary has validated each DLN, the DVLA record associated with that DLN can be requested. This will require the insurer or intermediary to send a request directly to the MIB Hub. & Intermediaries At renewal, the request to the MIB Hub can only be made by the holding insurer and/or intermediary, or software houses or other third party providers contracted to act on their behalf. The insurer or intermediary may request records that had been suppressed during the previous quotation or renewal. It is possible to submit policy renewal requests through the Hub s batch renewal file service or web service. More details on the technical requirements are available in the MIB Hub Industry Interface Specification. As well as submitting the DLN, the insurer or intermediary must also submit the postcode of the policyholder to the MIB Hub. This will allow the DVLA to indicate if there is a mismatch between the postcode provided to the distributor and the postcode on the DVLA database. The postcode check will only be undertaken at renewal due to the high volume of speculative quotes at the new business stage. After the renewal is completed, the successful insurer or intermediary should also advise the policyholder if there is mismatch between the postcode provided to the insurer and the postcode on the DVLA s system and/or if any of the DLNs correspond to an expired licence MIB Hub requests data from the DVLA and responds to the insurer or intermediary or MIB Hub Notes: The DLN will be sent to the DVLA, and the DVLA will send a response to the MIB Hub which will then be passed to the insurer or intermediary. For each DLN submitted, there are four potential responses (the response for each DLN is independent and the responses are the same for both the web and batch request services): PAGE 25 of 56

26 (1) The driver record is returned as requested; In this case the insurer or intermediary will receive the DVLA record and the renewal invitation can be generated as per step (2) The driver record is not found; In this case, the MIB Hub will return the response Record for supplied DLN cannot be found. If the record associated with this DLN has not previously been requested, this could happen because the DLN does not match a record on the system, either because the DLN has been miskeyed or a DLN has been falsely created. If the record associated with this DLN had previously been provided from the DVLA this could happen because an individual has changed their name or gender since the DLN was provided and subsequently had their DLN updated. In this situation, the insurer or intermediary will need to base the renewal on the information used previously, as per step In such cases, the insurer is required to remove any convictions which have become spent (the DVLA will provide the indicative rehabilitation date for each conviction). (3) The record cannot be released by the DVLA; In this case the MIB Hub will return the response Record for supplied DLN has been suppressed. The record will be suppressed in roughly one per cent of cases. This is typically due to the record being under maintenance (for example an address is being changed), and the insurer should not infer anything from this response other than the need for the individual to selfdeclare. There is considerable variation in the length of time a record can be suppressed by the DVLA. Accordingly, if a record is suppressed, it is recommended that the insurer or intermediary base the renewal on the information used previously, as per step In such cases, the insurer is required to remove any convictions which have become spent (the DVLA will provide the indicative rehabilitation date for each conviction). It is also recommended that individuals are asked to selfdeclare any subsequent convictions. PAGE 26 of 56

27 (4) The request is invalid; In this case, the MIB Hub will return one of several responses indicating that the request is invalid. This would occur if the request cannot be processed due to error at some point, for example if the data sent to the DVLA is incomplete or in an incorrect format (most likely this would indicate that the distributor s validation process has failed). If the request is successful on a subsequent attempt, the renewal process can continue. If the data cannot be retrieved from the DVLA the insurer or intermediary will need to base the renewal on the information used previously, as per step In such cases, the insurer or intermediary must remove any convictions which have become spent to ensure that they are complying with the Rehabilitation of Offenders Act. The DVLA will provide an indicative rehabilitation date for each offence to aide this process. General Note that where DVLA data cannot be refreshed because of any of the reasons above, the renewal must be based on DVLA data that was received the previous year, with convictions that have since become spent removed. The DVLA will provide an indicative rehabilitation date for each offence to aide this process. The indicative rehabilitation date is the expected date of rehabilitation for the offence under the Rehabilitation of Offenders Act 1974, (as amended), when the offence is considered independently of any future offences that might extend the rehabilitation period, and is based on the age, disqualification period, fine, custodial period and endorsement code information held by the DVLA. Therefore, insurers relying on this indicative date to calculate the rehabilitation period and adjust for subsequent convictions do so at their own risk. Restrictions on visibility of data mean that the customer cannot be asked to confirm that the data the policy is based on remains correct; however the issuing insurer or intermediary can ask the customer to advise of any convictions received since the date of the last data lookup, which the customer can verify on the DVLA s View Driver PAGE 27 of 56

28 Record service Insurer or intermediary generates a renewal invitation Insurers & Notes: intermediaries This step, and all those preceding it, should be completed in line with the timeframes set out for the issuing of renewal invitations, as stipulated in the rules and regulations set out by the Financial Conduct Authority and/or any other relevant body. Depending on the information provided to the insurer, there will be one of three responses: (1) Decline the risk; The insurer or intermediary will refuse to provide a quote for the renewal of the policy. (2) Referral of the risk to a specialist underwriter; In such cases, the underwriter will be able to view data from the DVLA outlined in chapter 5 of this document. (3) Renewal invitation is provided; The insurer or intermediary decides to invite renewal of the policy. At the point the renewal invitation is communicated to the individual, the insurer or intermediary should also advise the customer if there is a mismatch between the postcode the policyholder has provided and the one on their DVLA record or if any of the DLNs denote an expired licence The policyholder accepts or declines the renewal invitation Notes: The policyholder will either accept or decline the renewal quotation, with or without direct contact with the insurer or intermediary. In each case, the insurer and intermediary must comply with the rules on retention and visibility of data as outlined in chapters 4 and 5 of this document. Ends Insurers & Intermediaries PAGE 28 of 56

29 3.2 Where DVLA data is not requested during the renewal process Step Process Next Step Applies To Renewal is based on previously held information Notes: Insurers and intermediaries issuing renewal notices have a choice of whether to use data from the DVLA if the policy was not previously based on DVLA data and the DLN is available and the customer has provided consent. Ends Holding insurers & intermediaries Where DVLA data was previously used, the holding insurer or intermediary can request refreshed data from the MIB Hub (as per section 3.1) to ensure that decisions are based on accurate data. In cases where DVLA data cannot be refreshed, it is possible to provide a renewal offer on the basis of data already held by the insurer or intermediary (as per scenarios 3.1.4(2) (3.1.4(4)). Where DVLA data is not refreshed, the holding insurer or intermediary must exclude from consideration any convictions which have become spent. To aide this decision, the DVLA will provide an indicative rehabilitation date for each conviction. It is also recommended that individuals are asked to self-declare any subsequent convictions. Rules regarding retention and visibility of data, as set out in chapters 4 and 5 of this document, must still be applied in this scenario. 3.3 When a renewal quote is generated by the non-holding insurer Step Process Next Step Applies To Quotations generated when renewal is expected Notes: Automatic requests for DVLA data at the point of renewal can only be made by the holding insurer or intermediary. While comparison websites, intermediaries and insurers that do not hold the business may retain the DLN (as it was self-declared), they Ends Non-holding insurers & intermediaries, all comparison websites PAGE 29 of 56

30 must not use that DLN to gain refreshed DVLA records for a new quote unless the proposer explicitly agrees to the generation of a new quote immediately before the new quote is generated. Also note there will be rare cases where the DLN has been retained to speed up future requests to the DVLA but the future request is unsuccessful (for example because the record is under maintenance and is suppressed when requested a second time). In these cases, the distributor will need to ask the customer to self-declare their information. This restriction must not be avoided, even if the fair obtaining notice used gains the consent of the licence holder. For the non-holding insurer or intermediary, or any comparison website, any re-quoting (where consent has be given explicitly immediately before the generation of a new quote) is to be treated as a quote for new business as per chapter 1 of this document. PAGE 30 of 56

31 4 RETENTION OF DATA For those firms allowed access to DVLA data (see section 6.1 for access principles), the secure retention of data is one of the major compliance requirements associated with the MyLicence programme. While obligations on the user are specified in the agreement with the MIB, the principles for retaining data are set out below (however in the event of any conflict or inconsistency between the user agreement and this guide, the terms and conditions of the user agreement shall prevail). Note that there are different rules for data retention depending on the necessity of retaining and/or processing data. These rules are determined by the relationship between the data controller/processor and the customer and, therefore, differ between insurers (at one end of the distribution channel) and comparison websites (at the other end). Accordingly, the remainder of this chapter presents separate guidance for each part of the distribution channel. 4.1 Insurers Insurers will receive data from the DVLA in order to produce a quotation. The length of time that data can be retained depends upon whether a policy is or is not issued, the other data retention rules employed by that firm and compliance with the provisions of the Data Protection Act When data is received but a quote is not generated As it is possible for a driver record to be requested as soon as the DLN, full name, date of birth and gender have been provided, it is possible that the insurer will have the driver record for a customer despite the quote journey ceasing before a quote is requested. Similarly, an insurer will have the driver record if they decline the risk. In such cases the insurer must delete the driver record at the same time the quote journey ends or once they decline the risk. The reason for this is that if an individual does not become a policyholder there is no purpose for retaining the data under the DPA. This restriction does not apply to anonymised or aggregated data, which can be used for management, pricing, modelling and actuarial purposes. Note that the insurer can retain the DLN as this was declared by the customer. Therefore, if the customer restarts the quote journey, DVLA data can be requested as soon as the customer s identity has been validated. Also note that there will be rare cases where a future request is unsuccessful (for example because the record is under maintenance and is suppressed when requested a second time). In these cases, the insurer will need to ask the customer to self-declare their information When a quote is generated but a policy is not sold If a quote is generated for a customer, the insurer can retain the data received from the DVLA for as long as the quote remains valid. If the quote expires and a policy has not been issued, the insurer is required to delete all of the data received from the DVLA (note the DLN can be retained as this was received from the customer, with the same implications as described in section 4.1.1). PAGE 31 of 56

32 Data should be deleted from the system as soon as practicable. The same principle applies where an insurer gains data about an additional driver during the life of the policy but the additional driver is not added to the policy When a policy is issued When a policy is issued, insurers have the right to retain the data received from the DVLA for the length of time the policy is valid. Retaining the data for the life of the policy will allow insurers to handle complaints, mid-term adjustments and claims, as well as renewals. Moreover, insurers can retain data received from the DVLA beyond the life of the policy so that claims arising after a policy ends can be managed. However, insurers must not refresh DVLA data once the policy has lapsed. There is no singularly defined time period that an insurer can retain data after a policy ends. However, insurers must comply with the Data Protection Act provisions to hold the data only as long as necessary and the retention period for data received from the DVLA must not exceed the retention period for self-declared data. Note that for any mid-term adjustment, other than the addition of a new driver/drivers or updating licence status or entitlement information, updated DVLA data is unnecessary and must not be requested. This is because the insurer will be able to retain the data received from the DVLA when the policy was incepted and convictions sustained since inception by other than the new driver(s) should only be relevant at renewal. Where a renewal has been generated using refreshed DVLA data and the policy is not sold, insurers may retain the DVLA data in accordance with current industry practices. However, insurers must comply with the Data Protection Act provisions to retain the data for a valid purpose and to hold the data only as long as necessary. The retention period for data received from the DVLA must also not exceed the retention period for self-declared data When data is used in anonymised or aggregated form for analysis purposes Insurers may retain and use data that is in an anonymised or aggregated form indefinitely for modelling, pricing, actuarial or management information purposes, subject to their compliance with the Data Protection Act The user agreement with the MIB specifies what constitutes aggregated or anonymised data. However, the general principle is that anonymised or aggregated data is in a form that does not identify individuals and where it is not possible to identify individuals by combining the anonymised or aggregated data with other data. The insurer may aggregate or anonymise any data received from the DVLA, provided that the aggregation and anonymisation methods are sound. That is, insurers may analyse data even if policies were not issued. Sometimes it may not be possible to anonymise (for example, while it is possible to remove the DLN, name and most address fields, it is necessary to keep the exact postcode that may link to the PAGE 32 of 56

33 electoral role) or aggregate data (for example, if aggregation removes the ability to build accurate models that allow the changing the parameters of interest) in a way that allows accurate modelling. If this is the case, one option is for insurers to aggregate and anonymise this data as much as they possibly can and then treat it as secure source data that is completely inaccessible to individuals (except for the purpose of resolving technical problems, including data errors, or meeting regulatory requirements). This means insurers would utilise use models that are truly aggregated and anonymised, however, these use models would draw from secure, inaccessible, source data that may not be fully anonymised or aggregated. In this context, insurers should remember that once they have obtained the DVLA data from the MIB Hub they will have data protection responsibility for the data and will need to ensure any further processing of the data is compliant with the requirements of the Data Protection Act It is therefore the responsibility of the insurer to ensure that the personal data retained as both source data and in use models is adequate, relevant and not excessive for the purpose, is appropriately protected against unauthorised access and that the data is only retained for as long as is necessary to conduct the analysis. The insurer will also need to ensure that this further processing is fair and that the customer is made aware of the processing that will take place. 4.2 Intermediaries Where an intermediary is operating under delegated authority from the insurer and needs to retain data to fulfil its contractual obligations to the policyholder and/or insurer throughout the life of the policy, the data retention rules will be the same as for an insurer. However, if an intermediary is not operating under delegated authority and has no ongoing contractual relationship with the customer after the policy is sold, and no regulatory obligation to retain data, the intermediary will not need to retain data received from the DVLA. In such cases, the data retention rules for the intermediary are as follows: When data is received but a quote is not generated As per section 4.1.1, if a quote is not requested or if a decision is taken not to offer a quote for the risk, the intermediary must delete the driver record at the same time the quote journey ends or once they decline the risk. As with insurers, the intermediary may retain the DLN, subject to the provisions of the Data Protection Act Therefore, if the customer restarts the quote journey, DVLA data can be requested as soon as the customer s identity has been validated. Again, note that there will be rare cases where a future request is unsuccessful (for example because the record is under maintenance and is suppressed when requested a second time). In these cases, the intermediary will need to ask the customer to self-declare their information. PAGE 33 of 56

34 4.2.2 When a quote is generated but a policy is not issued If a quote is generated for a customer, the intermediary can retain the data received from the DVLA for as long as the quote remains valid. If the quote expires and a policy has not been issued, the intermediary is required to delete all the data received from the DVLA (note the DLN can be retained as this was received from the customer, with the same implications as described in section 4.1.1). Data should be deleted from the system as soon as practicable When a policy is issued When a policy is issued, intermediaries not operating under delegated authority, or at least processing mid-term adjustments or renewals on behalf of the insurer, will no longer have a need to retain data, as they will not be managing mid-term adjustments, claims, complaints or renewals. Unless data is needed to fulfil regulatory obligations, data received from the DVLA must be deleted from the system as soon as practicable. 4.3 Comparison websites Comparison websites act solely as a conduit for data received from the DVLA. That is, they can only request the data from the MIB for the purpose of passing the data on to the insurers and intermediaries whose rates they have accessed, which will then use the data to produce a quote. Accordingly, comparison sites must not use the data themselves. Comparison websites may retain driver data for up to 48 hours from when the data was received from the MIB Hub. This allows comparison websites to make only one request for DVLA data for the production of multiple quotes for each customer for example with differing excess or coverage levels. As soon as the 48 hour period ends, either with or without the generation of one or more quotations, the comparison site must delete the data received from the DVLA. It is not possible for comparison websites to retain records of DVLA data for audit purposes. However, comparison websites may retain a record of the DLN and the fact that data from the DVLA was sent as part of the audit log. As with intermediaries and insurers, comparison websites can retain the DLN, subject to their compliance with the Data Protection Act Therefore, if the customer restarts the quote journey, DVLA data can be requested as soon as the customer s identity has been validated. Again, note that there will be rare cases where a future request is unsuccessful (for example because the record is under maintenance and is suppressed when requested a second time). In these cases, the comparison website will need to ask the customer to self-declare their information. 4.4 Software houses and other third party providers Software houses are able to retain data on behalf of insurers, intermediaries and comparison websites that have contracted them to process data on their behalf. The data retention rules applicable to software houses in receipt of DVLA driver data will be PAGE 34 of 56

35 dependent on the necessity of processing and/or retaining data to fulfil the purposes under which they been contracted by another party, as set out above. Software houses and other third party providers must not use DVLA driver data for any purpose other than those contracted between themselves and the insurer, intermediary and/or comparison website. Where a software house or third party has been contracted to only collect the DVLA data on behalf of an insurer, intermediary and/or comparison website, they will be acting as a conduit, as such they cannot retain the DVLA driver data themselves. While a third party provider can use DVLA driver data to provide a risk rating on behalf of an insurer, the third party provider must not use that data to enrich other data sets that are used for other commercial purposes. Finally, insurers, intermediaries and/or comparison websites must not contract software houses or other third party providers to use DVLA driver data for a purpose not allowed within the terms of their user agreement with the MIB. PAGE 35 of 56

36 5 VISIBILITY OF DATA Restricting the visibility of data is the second major compliance requirement associated with the MyLicence programme. As with the previous chapter, the principles for restricting visibility of data are set out below. As with retention of data, there are different rules for visibility, depending on the role played in providing the customer with insurance. Accordingly, this chapter presents separate guidance for each part of the distribution channel. 5.1 Insurers general principles To ensure that the DVLA shares data in a manner consistent with the Data Protection Act 1998, the DVLA has agreed to share data with insurers on the basis that data will typically be processed automatically and without manual intervention. This means that under normal circumstances data must not be visible to individuals employed by, or acting on behalf of, the insurer (exceptional circumstances where visibility is allowed are described in section 5.2). Moreover, the restriction on visibility of data also extends to communications with customers. Data received from the DVLA must not be disclosed to the proposer, policyholder or any other named drivers (with the exception of alerting the customer to postcode mismatches or expired licences). Restrictions on visibility of data extend beyond displaying specific convictions or entitlements. Staff and customers should also not be given generic information acknowledging the presence or absence of convictions or entitlements. Not adhering to these restrictions is a breach the user agreement with the MIB. Not meeting these restrictions could result in the revocation of an insurer s right to access DVLA data. Specific requirements that must be met to meet these general visibility requirements are set out below: Policy documents and messages to customers must not divulge DVLA sourced data The restriction on visibility of data extends to the proposer, policyholder, named drivers and any other individuals, none of whom should be able to see or infer DVLA data throughout the process of purchasing insurance. As well as not revealing specific DVLA data, messages visible to the customer should also avoid providing generic information acknowledging the presence or absence of convictions or entitlements. To meet this restriction, the insurer must not print DVLA sourced data on quote or policy documents, or display DVLA sourced data back to the individual at any point. For the purposes of printed documents and confirmation screens visible to customers, insurers must only display the information that was declared by the individual; i.e. the DLN. (Note that insurers can refer customers to the DVLA s View Driver Record service on the GOV.UK website if a customer wishes to see the data being used.) Similarly, automated messages given to the customer must not divulge information sourced from the PAGE 36 of 56

37 DVLA, and any automated messages based on DVLA data should not allow the proposer to infer information about any individuals on the application, including them. For example, if an insurer refuses to offer a quote to a proposer on the basis that DVLA data shows a named driver has too many convictions, the insurer s message to the proposer explaining the decision must not identify the named driver s convictions as the cause, or that convictions were the cause, even if the convictions are not attributed to an individual. Similar restrictions apply to messages given directly to the customer by customer services staff. However, if the identity of the customer has been verified, customer services staff can refer to, and discuss with that customer, the DVLA data relating to that customer. This restriction on allowing customers to infer conviction or entitlement information also restricts what information can be given to customers when explaining how a quote or premium was calculated, for example via premium breakdown information. Again though, if the identity of the customer has been verified, customer services staff can refer to, and discuss with that customer, the DVLA data relating to that customer when discussing the premium. In some cases it will not be possible to prevent such inferences. For example, if a policy is already in force and the addition of a named driver results in a substantial increase in premium, it will likely follow that the data received from the DVLA about the new driver contributed to that premium change. However, messages to customers should not positively or proactively identify this. Note that the restrictions on communicating information to customers set out above do not apply to messages to customers about postcode mismatches or expired licences Output message to a customer The restrictions on output messaging may require insurers to adapt their customer service processes to deal with situations where a customer queries a premium or where a quote is not provided using DVLA data. In a scenario where the proposer contacts the insurer or intermediary to query a premium, insurers will need to consider a number of steps: The premium was not based on DVLA data. In this situation, an insurer would follow their normal customer response process. The DVLA data was used to calculate the premium and there are no named drivers included in the quote. Here, an insurer can discuss the drivers DVLA data if their identity has been verified. The DVLA data was used to calculate the premium and there are one or more named drivers included in the quote. In this situation, the insurer must not discuss the DVLA record of named drivers with the proposer and the customer should be directed to the DVLA portal to check their records using the following wording that has been agreed with the DVLA: Your premium has been based on the information provided, including licence information. To see the information the DVLA holds against the licences provided, please visit the DVLA s View Driver Record at PAGE 37 of 56

38 Where an insurer refuses to offer a quote, in the first stance a general non-specific response should be provided to a proposer, for example We regret to inform you that we are unable to offer you with a quote. In a scenario where the proposer contacts the insurer or intermediary for the reasons behind a declined quote based on DVLA data, it will not be possible to refer to the DVLA data as insurer must delete the driver record once they decline the risk (as per section 4.1.1). Insurers may deal with these queries in a number of ways: The customer can be directed to the DVLA portal to check their records using the following wording that has been agreed with the DVLA: Based on the information provided, including licence information, we have decided not to provide a quote in this instance. To see the information the DVLA holds against the licences provided, please visit the DVLA s View Driver Record at Where insurer systems record a reason for a decline they may continue to do so and refer to these when discussing with a customer if their identity has been verified. However, insurers must not divulge named drivers information sourced from the DVLA as per section Or, the query can be dealt with by requote, where a new quote is processed and the risk is referred to a specialist underwriter (refer to section 1.3.2) The DVLA have specifically requested that the message refer to licence information. Insurer s cannot use the term DVLA data in the output messages where named drivers are part of the quote. Where a specific named driver is the reason for a refusal to quote, insurers may offer the proposer a quote excluding a specific named driver(s). However, the output message cannot make any reference to DVLA data as the reason behind the refusal to quote for any specific named driver(s) or infer DVLA information about any individuals on the application DVLA sourced data must not be visible in insurer systems The IT systems used by insurers must not display DVLA sourced data to staff, except in the circumstances as set out in 5.2 below (again, there is an exception for messages to customers about postcode mismatches or expired licences). This will typically require the policy record to be adjusted, so that DVLA data is not visible to staff when a record is viewed. Systems will require further adjustments if DVLA data is accessible in places other than the policy record. Specifically, databases used for modelling, actuarial and management information purposes must not display DVLA data that can be linked to an individual. Any database using DVLA sourced data must limit the data that is visible to individuals to data that is aggregated and/or anonymised Internal output messages must not divulge DVLA sourced data As with automated messages given to the customer, automated messages that are visible to staff must not divulge information sourced from the DVLA and any messages based on DVLA data should not allow staff to infer information about any individuals on the application (with the exception of postcode mismatches or expired licences). PAGE 38 of 56

39 As well as not revealing specific DVLA data, messages visible to staff should also avoid providing generic information acknowledging the presence or absence of convictions or entitlements. For example, if an insurer refuses to offer a quote to a proposer on the basis that DVLA data shows a named driver is disqualified, the insurer s internal messaging must not identify the named driver s disqualification as the cause, or that disqualification was the cause, even if the disqualification is not attributed to an individual. This restriction on allowing staff to infer what is held on a particular DVLA record also restricts what information can be given to staff when explaining how a quote or premium was calculated, for example via premium breakdown information. In some cases it will not be possible to prevent such inferences. For example, if a policy is already in force and the addition of a named driver results in a substantial increase in premium, it could be inferred that the data received from the DVLA about the new driver included some convictions. However, internal messages should not positively or proactively identify this Additional questions must not be dynamic based on data received from DVLA If insurers want to ask additional questions of individuals to gain information that will not be provided by the DVLA, such questions should not be devised as a result of data received from the DVLA (with the exception of postcode mismatches or expired licences). For example, the DVLA will not provide information on blood alcohol level for driving with excess alcohol convictions. Therefore, any insurer wanting to know the blood alcohol level for individuals with such convictions must ask the question of all customers, not just those customers for whom DVLA data indicates there is an excess alcohol conviction. Alternatively, insurers can deduce the severity of an offence by the conviction code, the level of fine, length of disqualification and/or length of the custodial sentence, which takes into account any mitigating factors associated with the offence Encryption It is not mandatory for insurers to encrypt data. However, insurers must put in place the necessary measures to ensure that data is not visible on their systems. These steps may or may not require encryption. Similarly, it is not necessary for EDI messages to be encrypted. 5.2 Insurers - visibility in exceptional circumstances While data cannot be viewed in most cases, there are some exceptional circumstances in which data can be viewed. These are explained below. In all cases where it is necessary for DVLA data to be viewed, visibility must only be granted for the process it is necessary for, and access must be restricted by user profile, with individual records kept of why the record was viewed. In all of these cases, DVLA data can only be divulged to the data subject, and only when it has been verified that the person the message is going to is in fact the data subject. It is understood that for PAGE 39 of 56

40 firms dealing directly with customers, this restriction might make it challenging to answer customer queries and complaints when named drivers are the cause. We recommend that firms in this situation refer their customers to the DVLA customer portal on the GOV.UK website, and implement processes similar to those already widely used in the industry when dealing with credit score information A quote, policy change or renewal cannot be processed automatically Where it is not possible to provide a new business quote, mid-term adjustment or renewal automatically, it is possible for DVLA data to be viewed by an individual to enable the quote, MTA or renewal to be processed. This exception has been agreed with the DVLA to allow the industry to continue the practice of managing by exception. However, insurers should seek to refine underwriting rules to reduce the number of policies for which manual intervention is necessary Responding to complaints and challenges from customers Visibility is also permitted where a customer or policyholder has complained or challenged a decision made by an insurer, and the insurer needs to understand what data was provided by the DVLA to inform the response. However, while the insurer is able to view the data to isolate the reason for the decision, they can only disclose that information back to the data subject and only when it has been verified that the individual the message is going to is in fact the data subject Responding to questions and challenges from regulators Visibility is also permitted where it is necessary to respond to a question or challenge from a regulatory body, such as the Financial Conduct Authority, the Prudential Regulatory Authority or the Financial Ombudsman Service. Whether DVLA data can be disclosed to the regulatory authorities will depend on the individual circumstances, and should be considered by a firm s compliance experts Subject access requests In the event that an individual requests data about themselves under a subject access request, the insurer can view data about that individual if it is necessary in order to respond to the subject access request. If the DVLA data is within the scope of what was requested by the individual it must be included in the response Resolving technical difficulties Visibility of data is also permitted where it is necessary to identify or resolve technical errors in an insurer s IT system Claims handling Visibility of data is also permitted when it is necessary for the purposes of handling or settling a claim PAGE 40 of 56

41 or resolving a claims complaint, and the insurer needs to understand what data was provided by the DVLA to inform the assessment of a claim or respond to a customer. However, while the insurer is able to view the data in these circumstances, they must not disclose named driver DVLA data to the policyholder. Visibility in these circumstances is limited to the DVLA data held on the policy record and does not allow insurers to request refreshed DVLA data at the point of claim. If a record needs to be verified at the point of claim, this will continue to be possible via the three-way call system already in place. 5.3 Intermediaries For intermediaries, the rules regarding visibility of data are the same as those for insurers. 5.4 Comparison websites As stated in chapter 4, comparison websites act solely as a conduit for data received from the DVLA; they must not use the data themselves (with the exception of information messages that allow them to identify if self-declaration is necessary) or interpret the data they receive from the DVLA for their downstream partners rather, DVLA data should be sent as received from the MIB Hub. Therefore, comparison websites must not view any data they receive from the DVLA, except where it is necessary to identify or resolve technical errors in their IT system. 5.5 Software houses and other third party providers Software houses must follow the same restrictions for visibility of data as apply to the insurer, intermediary and comparison website they are contracted by, as set out above. Other Third Parties acting as a conduit must not view any data they receive from the DVLA, except where it is necessary to identify or resolve technical errors in their IT system. PAGE 41 of 56

42 6 GENERAL PRINCIPLES This chapter presents guidance on various issues not covered elsewhere in the document. 6.1 Registration All organisations that come into contact with DVLA data need to register their interest with the MIB. The form of registration will depend on how you receive the data from the MIB: Where an organisation is requesting DVLA data directing from the MIB, they will need to register for the MIB direct service. Where an organisation is receiving data via a conduit (e.g. comparison websites, brokers and/or software houses), they will need to register for the MIB third party service. Please note, where an organisation is providing DVLA data downstream to panel members and other conduits, it will be the responsibility of the organisation to ensure that a panel member is authorised to receive the DVLA data (refer to the MIB s Authorised Third Parties List.) Firms connecting to the MIB Hub directly Any insurer, intermediary, comparison website or software house (with insurers or intermediaries as clients) can connect to the MIB Hub directly. Furthermore, other third party providers can connect if they have been directly contracted by an insurer, intermediary or software house to access the MIB Hub on their behalf; they may only access and process DVLA data for the purposes defined in that contract. No firm will be permitted to connect directly to the MIB Hub without completing the registration process. Once authorised, firms will be able to connect directly to the MIB Hub and request and receive DVLA data. In addition to meeting the technical standards that will allow a firm to request and receive data from the DVLA, registration requirements for firms wishing to connect directly to the MIB Hub will include: Demonstrating that suitable security and data protection standards are in place; Demonstrating that requirements regarding retention and visibility of data can, and will, be met; Acceptance of these obligations are in the User Agreement. Acceptance will be shown by ticking the appropriate box on the MIB Hub Registration Tool Firms connecting to the MIB Hub via a conduit Firms not capable of connecting to the MIB Hub directly will be able to connect via a conduit. Only conduits that have themselves registered (as per section 6.1.1) and are authorised third parties can be used as a conduit to connect to the MIB Hub. All parties receiving DVLA data via a third party will need to register with the MIB s third party service in order to process DVLA data. Firms authorised by MIB to receive DVLA data via a third party, will PAGE 42 of 56

43 be added to the MIB Authorised Third Parties List Conduits will be responsible for ensuring that they only make available DVLA data to authorised parties that are listed on the list. Firms that receive DVLA data directly from the MIB Hub and indirectly via a conduit will not need to register for the third party service as they will have registered directly with the MIB. However, these firms will be listed on the Approved Parties List so that conduits can check that they only make available DVLA data to authorised parties Firms that are not registered or authorised parties Firms that are not confirmed as authorised third parties by the MIB, will have no right to receive or use DVLA data (including error codes indicating data cannot be released). However, firms not able to access DVLA driver data are able to collect the DLN so that they can use it at a later point. It is strongly recommended that any firm that does this gains consent for the DLN to be used to access the licence holder s DVLA record in future (including for renewals), to remove the need to gain consent at another point in future. Firms not able to access DVLA data may still benefit from the MyLicence system through upstream partners, provided they do not access DVLA data themselves via those upstream partners. For example, if an insurer is not an authorised party, but their intermediary partners are, it is possible for the insurer to provide capacity to those intermediaries and give them flexibility over their rates so that those intermediaries can set premiums utilising accurate DVLA data. However, in such a case, the insurer would only be able to access anonymised and/or aggregated management information, and could not access individual DVLA records. It is the insurer s own responsibility to ensure that any such arrangement could meet their regulatory obligations regarding record-keeping. 6.2 Audit Requirements Once connected to the Hub, directly or indirectly, all users of DVLA data are required to operate suitable controls and maintain appropriate audit trails that demonstrate that they have fulfilled their obligations for accessing and utilising DVLA data. The philosophy adopted by the DVLA is trust, but verify and so users should be prepared for the possibility that they will have to demonstrate this. This is a key element of the DVLA s justification for sharing its data with the industry i.e. that it has a mechanism in place to check that its data is not used for unintended or unlawful purposes. 6.3 Using DVLA and Self-Declared Data The MyLicence service is intended to replace the need for individuals to self-declare their information. It is not intended as a means of validating self-declared information. Given this, there are restrictions on the ability of firms to collect and use both self-declared data and DVLA data for the purpose of providing a quote. As with the restrictions on retention of data and visibility of data, the rules for each firm are determined by the role in the distribution chain. Accordingly, the remainder of this section presents separate guidance for each part of the distribution channel. PAGE 43 of 56

44 6.3.1 Insurers For each quotation the insurer can only use one set of data (either self-declared data or DVLA data) from each individual named (including the proposer) on the proposal form. However, if an individual provides DVLA data for one quote and then seeks another quote without using DVLA data (or vice versa, either through the same channel or a different channel), the insurer can use the DVLA data received for the first quote to validate the second quote. There will also be a transitional period in the MyLicence programme where some firms will be registered with the MIB and authorised to use the DVLA data and others are not. During this transitional period, if DVLA data has not been collected at the point of quote (for example, because the distributor cannot collect it) it is acceptable for an authorised insurer to request DVLA data when completing the sale, even if they provided the original quotation on the basis of selfdeclared data. In this case, the insurer is able to requote and base the premium on the DVLA data rather than the self-declared data. However, in this case the authorised insurer must not set a premium different to what would have been offered if DVLA data was used for the original quotation, or decline cover for an applicant that would have been accepted if DVLA data was used for the original quotation Intermediaries As intermediaries will typically generate quotes on behalf of multiple downstream partners, some of whom might be authorised parties and some others who may not be, the considerations for intermediaries regarding the collection and use of DVLA driver data are different than for insurers. Three scenarios are set out below: Scenario 1 An intermediary s entire panel can use DVLA data When considering an intermediary writing business on behalf of a panel where all downstream partners have registered and are authorised parties, the restrictions are the same as for insurers. For each quotation the intermediary can only use one set of data (either self-declared data or DVLA data) from each individual named (including the proposer) on the proposal form. However, if an individual provides DVLA data for one quote from the intermediary and then seeks another quote without using DVLA data (or vice versa, either through the same channel or a different channel), the intermediary or insurers downstream can use the DVLA data received for the first quote to validate the second quote. Again, there will be a transitional period in the MyLicence programme where some firms will be authorised to use the DVLA data and others are not. During this transitional period, if DVLA data has not been collected at the point of quote (for example, because a distributor cannot collect it) it is acceptable for an authorised intermediary to request DVLA data when completing the sale, after providing an original quotation on the basis of self-declared data. In this case, the intermediary is able to requote and base the premium on the DVLA data rather than the self-declared data. However, in this case the authorised intermediary and the intermediary s panel members must not set a premium different to what would have been offered if DVLA data was used for the original quotation, or decline cover for an applicant that would have been accepted if DVLA data was used PAGE 44 of 56

45 for the original quotation. Scenario 2 some panel members cannot access DVLA data, and it is necessary for the intermediary to provide them personal data Where an intermediary is generating quotations for the same proposer on behalf of multiple panel members the intermediary will need both sets of data to service their entire panel if: not all of the panel members are authorised to use DVLA data; and the intermediary is obliged to provide all of the rating information to at least one of the insurers that underwrites the policy, and that insurer cannot access DVLA data. In this scenario, while the intermediary will have access to both self-declared data and DVLA data, the intermediary must not compare the self-declared data provided to some panel members with the DVLA data provided to other panel members. This distinction ensures each insurer receives the same data as it would if it were itself acting as the distributor, and that the intermediary represents them on that basis. As with scenario one above, and the scenario for insurers, if an individual provides DVLA data for one quote from the intermediary, and then seeks another quote without using DVLA data (or vice versa, either through the same channel or a different channel), the intermediary and any onboarded panel members can use the DVLA data received for the first quote to validate the second quote. Again, there will be a transitional period in the MyLicence programme where some firms will be authorised to use the DVLA data and others are not. During this transitional period, if DVLA data has not been collected at the point of quote (for example, because a distributor cannot collect it) it is acceptable for an authorised intermediary to request DVLA data when completing the sale, after providing an original quotation on the basis of selfdeclared data. In this case, the intermediary is able to requote and base the premium on the DVLA data rather than the self-declared data. However, in this case the intermediary and/or panel members must not set a premium different to what would have been offered if DVLA data was used for the original quotation, or decline cover for an applicant that would have been accepted if DVLA data was used for the original quotation. Note that once all of the intermediary s panel members are authorised to use the DVLA data, then the intermediary must act as per scenario 1, above. Scenario 3 an intermediary has flexibility with what information is provided to panel members If an intermediary has a greater degree of control over the rating process than in scenario 2, it may not be necessary to rely on self-declared data, even if some insurers are not authorised to use the DVLA data. Specifically, in this situation it is possible for the insurer to provide capacity to the intermediary and give them flexibility over their rates so that the intermediary can set premiums utilising accurate DVLA data. However, in such a case, the insurer would only be able to access anonymised and/or aggregated management information, and could not access individual DVLA records. It is the insurer s own responsibility to ensure that any such arrangement could meet their regulatory obligations regarding record-keeping. PAGE 45 of 56

46 In such a scenario, for each quotation the intermediary can only use one set of data (either selfdeclared data or DVLA data) from each individual named (including the proposer) on the proposal form. However, if an individual provides DVLA data for one quote, and then seeks another quote without using DVLA data (or vice versa, either through the same channel or a different channel), the intermediary can use the DVLA data received for the first quote to validate the second quote. Again, there will be a transitional period in the MyLicence programme where some firms will be authorised to use DVLA driver data and others are not. During this transitional period, if DVLA data has not been collected at the point of quote (for example, because the distributor cannot collect it) it is acceptable for an authorised intermediary to request DVLA data when completing the sale, after providing an original quotation on the basis of selfdeclared data. In this case, the intermediary is able to requote and base the premium on the DVLA data rather than the self-declared data. However, in this case the intermediary must not set a premium different to what would have been offered if DVLA data was used for the original quotation, or decline cover for an applicant that would have been accepted if DVLA data was used for the original quotation. It should be noted that an intermediary could have a set of panel members that are a mix of those outlined in scenarios 2 and 3. That is, some panel members may be able to provide capacity without receiving personal information while others may require the full set of DVLA data. In that case, each insurer should be treated according to their own circumstances. All of these scenarios are explored in more detail in the case studies in appendix A Comparison websites As stated in chapters 4 and 5, comparison websites act solely as a conduit for data received from the DVLA; they must not use the data themselves (with the exception of information messages that allow them to identify if self-declaration is necessary) or interpret the data they receive from the DVLA for their downstream partners rather, DVLA data should be sent as received from the MIB Hub. Therefore, a comparison website s sole obligation is as a conduit, ensuring that they only make available DVLA data to those firms that are authorised to use the DVLA data, and only make available both DVLA data and self-declared data when there is a legitimate need for both types of data. To this end, it should be noted that the MIB will be keeping a register of firms that are authorised to use DVLA data, and comparison websites must only make available DVLA data to firms on the MIB Approved Parties List Software houses and other third party providers Software houses and other third party providers must follow the same restrictions for comparing data as apply to the insurer, intermediary and comparison website they are contracted by, as set out above. As with comparison websites, software houses and other third party providers will often be acting as PAGE 46 of 56

47 a conduit, and will need to ensure that they only make available DVLA data to those firms that have are authorised to use the DVLA data and only make available both DVLA data and self-declared data when there is a legitimate need for both types of data. To this end, it should be noted that the MIB will be keeping a register of firms that are authorised to use DVLA data, and comparison websites must only make available DVLA data to firms on the MIB Approved Parties List. 6.4 Offshoring of data We had previously advised that DVLA data could not be processed offshore without prior approval from the Cabinet Office. However, the DVLA and the Cabinet Office have confirmed that there will be no additional approval processes or restrictions for firms that process DVLA data offshore. Rather, firms are simply required to meet the standard requirements for processing data offshore, as set out in the Data Protection Act Spent Convictions under the Rehabilitation of Offenders Act 1974 The DVLA must comply with the Rehabilitation of Offenders Act 1974 (ROA) when providing data to the insurance industry. Broadly speaking, this means that the DVLA will not provide details on convictions which are spent under the ROA. Under the MyLicence project, endorsement data currently retained on DVLA s records shall be disclosed to the insurance industry. Typically, endorsement data remains on the DVLA s records for four years, as stipulated in the Road Traffic Offenders Act This is in contrast to the typical rehabilitation period for endorsements under the ROA, which is five years, when considered independently of future offences that might increase the rehabilitation period. However, where the offence code is one of the following: DR10; DR20; DR30; DR80; CD40; CD50; CD60 or CD70, and there has been a disqualification applied, this data will be disclosed to the industry for up to 5 years from the date of conviction. There will be instances where the rehabilitation period extends beyond 5 years. For example, for certain custodial sentences or where the disqualification period is for longer than 5 years. In these instances, the DVLA will continue to disclose the data until the rehabilitation period for that offence expires when considered independently of any future offences that might extend the rehabilitation period. For each offence, the DVLA will provide the indicative date of rehabilitation for the offence under the Rehabilitation of Offenders Act 1974, (as amended), when the offence is considered independently of any future offences that might extend the rehabilitation period, and is based on the age, disqualification period, fine, custodial period and endorsement code information held by the DVLA. Insurers and intermediaries relying on this indicative date to calculate the rehabilitation period do so at their own risk and are advised to calculate the rehabilitation period themselves. Insurers and intermediaries may continue to use endorsement data received from the DVLA until the date of rehabilitation. That is, where they are known, insurers or intermediaries can take account of unspent convictions that are not provided by the DVLA on the most recent record. PAGE 47 of 56

48 More information on the treatment of customers with motoring convictions can be found on the ABI s website. 6.6 Expired Licences and Postcode Mismatches Data provided by the DVLA will indicate if a licence has expired. Where a licence has expired, it is necessary to advise the customer that the licence has expired and that they should renew their licence. During the new business process, this should be done after a policy is issued by the party that completes the sale. There is no defined format for how this message should be delivered. Similarly, the holding insurer or intermediary should advise the customer of an expired licence if they become aware of it during a mid-term adjustment process (where a new driver is added) or at renewal. At the point of renewal the DVLA will also highlight if the postcode for the policyholder does not match the postcode provided by the holding insurer or intermediary. Where the postcode does not match, the holding insurer or intermediary should recommend the policyholder check that the postcode as recorded by the DVLA is correct. Note that there may be legitimate reasons for a mismatch between the postcode given to the insurer and the postcode on the DVLA s system. Where more than one postcode is collected from the policyholder, it is the correspondence address that should be provided to the DVLA. The requirement to advise customers of expired licences or postcode mismatches reduces the legal risk of accessing DVLA data under the Data Protection Act This is because helping the DVLA to maintain accurate records brings the purpose of MyLicence closer to the purpose for which data was collected. It is therefore essential that each insurer and intermediary complies with these requirements. Driving with an expired licence and or having the wrong address listed with the DVLA are both endorsable offences that could attract a maximum fixed penalty of However, the DVLA will not identify customers to target for a fixed penalty through the MyLicence programme. Rather, insurers and intermediaries have the opportunity to provide customers with a low-cost value-add service, which may save them a substantial fine if stopped while driving with an out of date licence or address. 6.7 Entitlement to Drive under Section 88 of the Road Traffic Act 1988 The DVLA will provide information on driving entitlements as part of the data set, which will typically allow the insurer or intermediary to identify if the individual has the right to drive. However, insurers and intermediaries should be aware that there will be some situations where the DVLA record will show no entitlement for the individual to drive but the individual will have entitlement to drive under section 88 of the Road Traffic Act 1988 (RTA). For the section 88 entitlement to be valid the individual s must have either: 1 Had their driving entitlement expire naturally; OR 2 Ended a disqualification; PAGE 48 of 56

49 Furthermore, any individual must meet all of the following conditions: They have made a valid application to have their entitlement reinstated within the last year and the DVLA is in receipt of that application; The driving entitlement is not currently revoked or refused; They would not be refused a licence for medical reasons (until DVLA have completed their enquiries they should check with their doctor or specialist); They have held a driving licence before; They drive in accordance with their previous licence; They are not disqualified by a court; They drive under the condition of the driving licence applied for, such as those applicable to provisional licences. Insurers may choose how to deal with customers claiming entitlement to drive under section 88 of the RTA. In these cases DVLA will not be able to confirm if the individual does in fact have a valid entitlement, but viewing the DVLA data (as per section of this document) will allow the insurer or intermediary to establish if some of these conditions are met. PAGE 49 of 56

50 7 GLOSSARY OF DEFINED TERMS Aggregated Data a new data set, which has been derived from personal or non-personal data about certain policies that has been combined to show general trends or values, without identifying individuals within the new data set. Anonymised Data data in a form that does not identify individuals and where identification through its combination with other data is not likely to take place. Authorised (Party/Parties) an organisation approved by MIB to obtain and/or use DVLA data either directly from the MIB Hub or via a conduit. Comparison website a firm that distributes motor insurance policies on behalf of multiple insurers and/or intermediaries, which allows customers to compare prices for different motor insurance products. Conduit a person or organisation that passes DVLA data between either the MIB Hub and downstream partners, or between upstream and downstream partners. Data Controller a person who (either alone or jointly or in common with other persons) determines the purposes for which and the manner in which any Personal Data are, or are to be, processed, as defined by the Data Protection Act Data Processor any person (other than an employee of the data controller) who processes the data on behalf of the data controller, as defined by the Data Protection Act Delegated authority where an intermediary has been given, through contract, certain forms of control by the insurer over the product they offer. Distributor the firm interacting with the proposer during the quotation process, including direct insurers, intermediaries and comparison websites. Downstream partner a firm that accesses DVLA data indirectly via businesses partners (such as software houses or comparison websites) rather than directly via the MIB Hub. Insurer/underwriting agency the insurance company or syndicate authorised to underwrite motor insurance or the underwriting agency acting on its behalf. PAGE 50 of 56

51 Intermediary a party, authorised by the Financial Conduct Authority, acting on behalf of an insurer including broker offices/call centres, broker websites, Independent Financial Advisors, managing general agents and affiliated partners, but excluding comparison websites, third party providers or software houses. Named Driver any person nominated by the policyholder and named on the insurance policy as being a user of any motor vehicle insured under the insurance policy. Offshore - any jurisdiction outside the United Kingdom, where the UK includes England, Wales, Scotland and Northern Ireland, but excludes the Channel Islands, Gibraltar and the Isle of Man. Offshoring the storage of (for example in data warehouses, data processing centres, disaster recovery centres or hard-drives at local offices etc.) or access to, (for example call centre staff who can access policy records or underwriters based overseas) DVLA data from an offshore location. Panel members the insurers and/or intermediaries that a comparison website acts as a distributor for, or, the insurers that underwrite motor insurance policies through an intermediary. Premium breakdown information that is presented to an insurer, intermediary or customer that separates individual components of the premium. Processing obtaining, recording or holding the information or data or carrying out any operation or set of operations on the information or data. Proposer the individual requesting an insurance quote. Registration the process of MIB approving an organisation to obtain and/or use DVLA data directly from the MIB Hub or via a conduit Software house firms specialising in providing software that allows insurers, intermediaries and comparison websites to trade insurance policies electronically. Source data data which has been processed to remove all personal details as far as the parameters of the use model allows. Stored in facilities inaccessible to employees, save for technical maintenance and maintenance to correct data errors. PAGE 51 of 56

52 Third party providers any party authorised by an insurer, intermediary, software house or comparison website process data their behalf as per the terms of any contract Upstream partner a firm with access to DVLA data, either directly from MIB Hub or through another party, that act as conduits and pass DVLA data to other parties. Use models models that present fully anonymised and aggregated data and are used for the provision of statistical information for pricing and management information purposes, which draw upon source data. PAGE 52 of 56

53 APPENDIX A: CASE STUDIES OF USING DVLA DATA Case Study 1: The use of DVLA and self-declared data Consider a situation where an intermediary (Intermediary A) has been authorised to use DVLA driver data and uses a panel of two insurers to generate quotations for its customers: Insurer X, which is authorised to receive DVLA data; and, Insurer Y, which is not authorised to use DVLA data, and so must rely upon self-declared data. Intermediary A receives DVLA driver data indirectly from a comparison website via a software house, both of whom are authorised parties. The Software House has an additional panel member separate to Intermediary A - Insurer Z. Insurer Z is an authorised party and so can receive DVLA data and will receive applications from the same customers from the Comparison Website as Intermediary A. Finally, assume that for Intermediary A to sell a policy from either Insurer X or Insurer Y the relevant insurer must be able to replicate the quotation in their rating engine at the point of sale. In this example, the Comparison Website will need to collect both self-declared information and DVLA data (as per scenario 2 in section 6.3.2). This is because Insurer Y has not registered and is not authorised to use DVLA driver data. Similarly, the Software House will need to receive both self-declared data and DVLA data to ensure that the correct data can be provided to all downstream partners (Insurers X, Y and Z and Intermediary A). The Software House will provide Intermediary A with both sets of data and Insurer Z will only receive the DVLA data. Intermediary A will generate a quote on behalf of Insurer X using only DVLA data, and in the event of a sale will provide Insurer X with the DVLA data so that Insurer X can validate the quotation provided by Intermediary A. Intermediary A will also generate a quote on behalf of Insurer Y using only selfdeclared data. In the event that the customer purchases the product Intermediary A is selling on behalf of Insurer Y, Intermediary A will provide Insurer Y with the self-declared information so that Insurer Y can validate the quotation provided by Intermediary A. In this example it would be the responsibility of Intermediary A to advise the Software House that it has panel members which are not able to access DVLA data. Assuming Intermediary A has a relationship with the Comparison Website, then Intermediary A should advise the Comparison Website of the requirement to collect both types of data. If Intermediary A does not have a direct relationship with the Comparison Website then the Software House would be required to communicate this requirement to the Comparison Website. PAGE 53 of 56

54 The relationship as described in case study 1 is set out below in diagram 1: Diagram 1: The use of DVLA and self-declared data Customer (Provides DLN and Self Declared data) Asks Customer for DLN and Self Declared Data Conduit (Comparison Website) asks for DLN and Self declared data System interface connections have been on boarded with MIB Hub Collected DVLA Data & Self Declared Data Conduit (Software House) System interface connections have been developed to receive DVLA DVLA Data & Self Declared Data DVLA Data Ready to receive DVLA data Intermediary A Insurer Z Ready to receive DVLA data Self Declared Data DVLA Data Ready to receive DVLA data Insurer X Insurer Y Not ready to receive DVLA data Please note that where comparison websites are only collecting the DLN and passing this down to panel members along with self-declared data, the DVLA data will be collected one step further down the distribution chain by insurers, intermediaries or conduits directly connected to the MIB Hub. PAGE 54 of 56

55 Case Study 2: The use of only DVLA data Taking the same case study as above, but relaxing the final assumption that for Intermediary A to sell a policy from Insurer Y requires Insurer Y to be able to replicate the quotation in their rating engine at the point of sale changes the data flows as set out below. This is scenario 3 in section In this example, the Comparison Website will only need to collect DVLA data. This is because Insurer Y does not require access to the personal data that Intermediary A is basing policies upon. Accordingly, the Software House will only receive DVLA data and will only have that data to provide to its downstream partners (Insurers X and Z and Intermediary A). Insurer Z will act as before, generating a quote on the basis of DVLA data. Again, Intermediary A will generate a quote on behalf of Insurer X using the DVLA data, and in the event of a sale will provide Insurer X with the DVLA data so that Insurer X can validate the quotation provided by Intermediary A. Intermediary A will also generate a quote on behalf of Insurer Y using the self-declared data. As Insurer Y has given the Intermediary A increased flexibility in this scenario, in the event that the customer purchases the product Intermediary A is selling on behalf of Insurer Y, Intermediary A will simply provide Insurer Y aggregated and/or anonymised data on the policy(ies) sold for management information purposes. In this example it would be the responsibility of Intermediary A to advise the Software House that none of its panel members require self-declared data. Assuming Intermediary A has a relationship with the Comparison Website, then Intermediary A should advise the Comparison Website of the requirement to collect only DVLA data. If Intermediary A does not have a direct relationship with the Comparison Website then the Software House would be required to communicate this requirement to the Comparison Website. PAGE 55 of 56

56 The relationship as described in case study 2 is set out below in diagram 2: Diagram 2: The use of DVLA data only Customer (Provides DLN) Conduit (Comparison Website) asks for DLN System interface connections have been on boarded with MIB Hub Collected DVLA Data System interface connections have been Conduit (Software House) developed to receive DVLA DVLA Data DVLA Data Ready to receive DVLA data Intermediary A Insurer Z Ready to receive DVLA data Anonymised and / or Aggregated data DVLA Data Ready to receive DVLA data Insurer X Insurer Y Not ready to receive DVLA data PAGE 56 of 56