Motor Insurance Database Policyholder Guide Unattended File Transfer

Policyholder Guide - Unattended File Transfer Motor Insurance Database Policyholder Guide Unattended File Transfer The latest version of this document can be found on the MIIC website at www.miic.org.uk/fleet/policyholder_guides.htm MIB June 2007 Version 3.1

CONTENTS 1. INTRODUCTION... 4 2. MINIMUM REQUIREMENTS FOR UNATTENDED FILE TRANSFER... 4 3. DATABASE SYSTEM OVERVIEW... 5 3.1 Mandatory, Preferred and Optional Fields...5 3.2 Setting On- and Off-dates...5 3.3 Timeliness of updates...6 3.4 Quality Assurance...6 3.4.1 Data validation...6 3.4.2 Monitoring timeliness of updates...7 3.4.3 Monitoring regularity of updates...7 3.5 Renewals and change of insurer...7 3.6 Updates from multiple sites...8 3.7 Auditing....8 3.8 Database Enquiry Facility...8 3.8.1 Policyholders who Supply Direct to the MID...8 3.8.2 Policyholders who Supply via the insurer...9 3.9 Helpdesk...9 4. UNATTENDED FILE TRANSFER PROCEDURE... 10 4.1 Getting set up...10 4.1.1 Proxy servers...11 4.2 Summary of data submission process...12 4.3 Standard File Transfer...13 4.3.1 Data items...13 4.3.2 Data rules...14 4.3.3 Spreadsheet template...14 4.3.4 Updating vehicle schedules...15 4.3.5 When to amend a vehicle record using Standard File Transfer...16 Correcting an error...16 4.3.6 Deleting records...18 4.4 Compare and Amend Function...19 Data items...19 Conditions of use for Compare & Amend...20 Treatment of files...22 Changing to Compare & Amend file transfer mid-term...23 Amending vehicle details using Compare & Amend...23 4.4.5 Insurer corrections...24 4.5 Confirmation of error-free file...24 4.5.1 Error Handling...25 5. GLOSSARY OF TERMS... 26 APPENDIX A FILE FORMATS... 29 FORMATS FOR STANDARD AND COMPARE & AMEND FILE TRANSFER...29 CSV File Format...29 Standard CSV File Format Attended and Unattended File Transfer...30 Standard CSV Vehicle Record...30 Page 2 of 68

Vehicle record continued...32 Reject File Format...33 Compare & Amend File Format...33 Example Standard CSV File Format...34 Example Vehicle Record...34 Example Acceptance File...36 Example Reject File Format (1)...36 Example Reject File Format (2)...37 Compare & Amend CSV File Format...38 Example C&A Vehicle Record...38 APPENDIX B ERROR MESSAGES... 39 APPENDIX C VEHICLE DATA... 41 1 Acceptable Registration Mark Formats...41 Acceptable Trade Plate Formats...42 2 Vehicle codes (InStep)...42 APPENDIX D DATA ITEM UPDATE AND VALIDATION RULES... 43 Data Dictionary Index (alphabetical)...43 Numerical listing...44 Data descriptions...44 APPENDIX E - SINGLE DAY ADDITION (SDA)... 67 Page 3 of 68

1. Introduction This Guide should be read in conjunction with Motor Insurance Database Policyholder Guide: Background, which can be found on the Motor Insurers Information Centre (MIIC) website 1 and explains the requirement to submit vehicle data to the Motor Insurance Database (MID). This Guide provides detailed information on how fleet policyholders can submit vehicle data to the MID using Unattended File Transfer. For information on submitting data using Unattended File Transfer, please refer to Motor Insurance Database Policyholder Guide: Attended File Transfer. For additional information on the Compare & Amend function, you are also advised to read Motor Insurance Database Policyholder Guide: Compare and Amend. For guidance on interactive updates, see Motor Insurance Database Policyholder Guide: Interactive Update. As an aid to understanding potentially unfamiliar terminology, a glossary has been included at the end of the document. 2. Minimum requirements for Unattended File Transfer The Unattended File Transfer (UFT) procedure requires certain criteria to be fulfilled to work successfully. These are set out below. Users should ensure that these criteria can be met before using this submission method. You should liaise with your IT provider to ensure that your servers and/or network are correctly configured and that any maintenance activities that they carry out in the future do not adversely affect this connection. 1. Java2SE runtime version 1.4.0_01 must be present on the PC or server on which the UFT client will be installed and run. If this is not already installed, a copy can be found on the CD supplied by Experian. The most up to date version can also be downloaded from the Sun Microsystems website at http://wwws.sun.com/software/java/downloads.html. Installation instructions are included. 2. An active Internet connection is required. 3. If connecting via a firewall, port 443 (HTTP/SSL) must be enabled. 4. If connecting via a Proxy server, its settings must be input during the installation procedure. (IP Address, port, username, password.) See also section 4.1.1 on proxy servers. 5. If the user (in particular brokers or other service providers) is submitting data for policies written by multiple insurers, a separate copy of the UFT client code must be installed in a different directory for each insurer, and a separate digital certificate is required. The digital certificate charge ( 25 per 1 www.miic.org.uk/fleet/policyholder_guides.htm Page 4 of 68

annum) will be levied for each certificate. (However, records for multiple policies with the same insurer require only one copy.) Policyholders should also note that the Unattended File Transfer process has only been tested on Sun Unix and Windows platforms. Other platforms may not work correctly and are not supported. 3. Database System Overview 3.1 Mandatory, Preferred and Optional Fields A weighting has been given to the data items that can be supplied, to indicate whether they are mandatory, optional or preferred. Mandatory fields contain data which is essential for the effective use of the MID, as required by law, and the record will be rejected if the field is not filled with valid data. Preferred data is not essential but policyholders are asked to provide this where it is held on their systems. Information may, for example, be used by a police officer to establish a vehicle record is correct. Suppliers should be aware that later Phases of the MID may change these to Mandatory (perhaps in response to legislation). Some insurers may require that these fields are provided as part of their terms & conditions. Optional data is not compulsory, but may be provided where policyholders (or insurers) consider it to be useful. The data item is not validated. All policyholders supplying data to the MID are requested to make all efforts to provide vehicle make and model details. Policyholders already using the industry vehicle codes formerly known as InStep codes may use these instead. 3.2 Setting On- and Off-dates The On-date identifies when a vehicle is first covered by the policy. In most cases this will equate to the date it was purchased by the policyholder. Where vehicles are leased or hired long-term, the On-date will be the date of acquisition. If, for example, a company offers cover to its employees vehicles, the On-date may be the start of employment for the car s owner. The Off-date is the last day on which the vehicle is covered by the policy, e.g. the date of disposal, or the day a vehicle is written off etc. If this date is unknown at the time of entry, it should be set to the expiry date of the policy, and then changed when the vehicle is no longer on cover, or the Off-date becomes known. If, however, the Off-date is known, it can be set at the time the vehicle s details are added, and no further action need be taken. If this date should change for any reason, it must be amended, to keep the MID accurate. Page 5 of 68

The Off-dates may need to be changed at renewal to extend the cover to the new policy expiry date. However, this is not necessary if the insurer uses the option to have the vehicles automatically rolled over. In this case, any vehicle Off-dates that match the policy expiry date will be extended to the new policy expiry date 3.3 Timeliness of updates Policyholders are required by law 2 to notify and update vehicle data immediately. The Department for Transport (DfT) has expressed the view that the requirement to supply data immediately is likely to be interpreted by the courts as the time taken by a person using reasonable efforts. Reasonable efforts would vary from case to case, but an acceptable range might typically be 10-14 days. However, where systems are in place that would allow updates more frequently or more quickly (e.g. a weekly automated program), then the expectation would be that the 10-14 day timescale should be adhered to. Reports are produced which show the duration of the provision of data. This enables MIB to monitor performance of both insurers and policyholders. The regulatory authority may ask MIB to provide details of these reports to them. 3.4 Quality Assurance MIB will ensure that the data on the MID is as accurate as possible in three ways. 3.4.1 Data validation Data supplied to MID is checked at the point of submission to ensure that the vehicle details supplied direct by the policyholder, such as the Vehicle Registration Mark (VRM), directly by policyholders are valid. Multiple checks are carried out to ensure that mandatory data items are complete, that codes are valid, and that information does not conflict with existing MID data records (e.g. any attempt to amend a vehicle that has not previously been supplied will be rejected). Any errors found will be returned to the policyholder for correction and re-submission. Details of error codes are shown in Appendix B Error messages. Vehicle data entered will be validated against Experian s Car Data Check (CDC) MID (which is a database of over 80 million vehicles used to confirm vehicle identity) to ensure that the VRMs are real, and have not been scrapped. Any resultant warning reports will be returned to the policyholder for action. To allow for the delay in updating the source data for CDC in respect of new vehicles, the check will be carried out at a later date. CDC error messages arising from new vehicles will therefore be sent to the insurer to be taken up with the policyholder. 2 The Motor Vehicles (Compulsory Insurance) (Information Centre and Compensation Body) Regulations 2003 Page 6 of 68

3.4.2 Monitoring timeliness of updates Regular reports issued to insurers and MIB measure the delay between the On-date of a vehicle and the date it was notified to the MID. The reports are produced on a monthly basis, and shows where policyholders have been slow in providing data (the target for data provision is within 14 calendar days). Reports are sent to insurers who will take up any issues with the policyholder. (MIB will also monitor the performance of insurers who supply vehicle data.) 3.4.3 Monitoring regularity of updates Non-activity and non-population reports show where policyholders are not supplying vehicle data, or are updating vehicle records with a lower frequency than might be expected. Monthly reports are sent to insurers who will take up any issues with the policyholder. 3.5 Renewals and change of insurer Only an insurer can submit a policy renewal record to the MID. The policyholder will not be able to submit vehicle details for the new period until the insurer submits the renewal record to the MID. There are two renewal options available to insurers: vehicles can be automatically rolled over into the new policy period (with some restrictions); or vehicles must be manually added to the renewed policy - Policyholders must agree with insurers which method is to be used. Depending on the option chosen by insurers for a particular policy, the policyholder will either: a) need to manually re-load the vehicles for the new period, or b) need to check the vehicles which are rolled over automatically from the previous period. In case (a), the policyholder will need to submit a file containing all vehicles to be added to the new period. To assist them, the policyholder can request a download of all the vehicles on cover at the date of renewal, from the insurer and change the Off-dates as required (or remove vehicles no longer on cover) by creating Amend records and then re-submitting the file for the new policy period. In case (b), the vehicles on cover at the date of renewal will be rolled over to the new policy period (but any vehicle that comes off-cover before the expiry date of the policy will not be rolled over). The policyholder need not change the Off-dates, which will initially be set automatically to the new date of expiry. If your policy expires and renews on the same date with the same insurer and your vehicles are automatically carried forward into the new policy period, please refer to Appendix E for an important notice on how vehicles behave at renewal. If a policyholder changes insurer at renewal, his/ her vehicle data has to be re-sent to the MID with the new policy number using a new version of the UFT software and digital certificate. Vehicle data cannot be Page 7 of 68

copied over from the existing policy, because only the policyholder will know if this information is correct. The policyholder can ask his/ her old insurer to supply a download of the vehicle schedule at the date of renewal (for which there may be a charge). This will allow the policyholder to check the vehicle information and change the policy number before submitting this to his/her new insurer with the relevant dates for the new policy. 3.6 Updates from multiple sites Changes to vehicle data on a given policy may be submitted from different sites/branches, except for the Compare & Amend function (see section 4.4.3). Files from different sites will not be rejected simply because they update the same policy policyholders should therefore take care to avoid sending unnecessary or duplicate updates, since this will add records to the MID, and where the changes submitted from different sites/branches contain different amendments, the results of any subsequent enquiries may not be as expected. Files will be loaded on to the MID in the order they are processed. Files sent via the Unattended File Transfer method will be processed within 24 hours. They will not update the MID immediately on receipt by Experian. 3.7 Auditing. The date and time of all transactions processed by the MID are recorded and are available for audit purposes via insurers. For the Policyholder s protection (with regard to the legislative requirement for policyholders to supply vehicle data to their insurer, or directly to the MID), Experian are able to verify via an audit trail, that a record had been submitted by a policyholder and, for example, subsequently amended or deleted by the insurer. If necessary, policyholders can also obtain such information. This will also be visible via MIDUpdate.com, if the policyholder has been given interactive access in addition to UFT (see section 4.1). 3.8 Database Enquiry Facility 3.8.1 Policyholders who Supply Direct to the MID Policyholders who supply vehicle data directly to the MID can, where such access is granted, view their entire vehicle schedule as at the current date via the web front-end application. This includes vehicle details, On- and Off-dates, and the source of the last change for current, historic and future- dated vehicles. They also have the option to print that vehicle information. The number of vehicles displayed will be limited to 50, but a further enquiry may be made by selecting the "More" hyperlink to display the remainder in 50 vehicle batches. Unattended File Transfer users will need separate log-on IDs to use this function the details set up for Unattended File Transfer relate to the transfer process only and do not confer rights of access to the Page 8 of 68

Internet interface. Details of the Interactive Interface can be found in Motor Insurance MID Policyholder Guide: Interactive Update. Policyholders cannot search the MID for vehicles or policies that are not his/ her own. 3.8.2 Policyholders who Supply via the insurer Policyholders who are not permitted to supply vehicle data directly to the MID, but instead supply the information to his/ her insurer, cannot have access to his/ her records on the MID except where entitled to the information under the Data Protection Act or via the insurer. 3.9 Helpdesk The Experian Helpdesk will deal with insurers only. Experian and MIB are unable to deal directly with a policyholder. Insurers will deal directly with policyholders and brokers for data enquiries, and the allocation and maintenance of User IDs and passwords. Page 9 of 68

4. Unattended File Transfer Procedure 4.1 Getting set up Policyholders should read section 2 to ensure they meet the minimum requirements to use Unattended File Transfer before embarking upon the set-up procedure detailed below. 1. The policyholder must notify his/ her insurer that he/she wishes to submit files via Unattended File Transfer (UFT). The insurer may wish to clarify whether policyholder is willing to bear any costs that may be associated with this (such as the digital certificate, which costs 25 per annum) before proceeding. If the insurer agrees with the request they will provide an application form for the certificate to the policyholder for completion. (These can also be obtained from the MIIC website, at http://www.miic.org.uk/fleet/policyholder_guides_other.htm.) As part of this notification, the policyholder must nominate an e-mail address to which transmission confirmations and error reports will be sent. In the event of a transmission problem, an e-mail will be sent to this address. It is therefore vital that a process is put in place to ensure these messages are actioned quickly. 2. The insurer will set up policyholder access for Unattended File Transfer to the MID and then provide relevant information to Experian so that a digital certificate can be created to allow the policyholder rights to send data via the software. 3. Once a correctly completed and authorised form has been received by Experian, they will send the UFT user (the policyholder) two elements which will enable them to set up his/her connection: a) A CD containing the Unattended File Transfer software will be sent direct to the name and address of the policyholder. Experian will do this within 20 working days of receipt of the request. This software cannot be installed until an authorisation code has been supplied to the policyholder. It should therefore be retained until this code has been received. b) An authorisation code and reference code, which must be used in conjunction with the software, will be despatched once the digital certificate is ready for the policyholder. This will be sent via e-mail to the address quoted on the authorisation form within 20 working days of receipt of the request. 4. Meanwhile, the necessary security to permit the policyholder to submit data to the MID will be set up. This includes the input of an e-mail address to which errors will be returned. An e-mail validation code will be sent to this address, to verify that it has been set up correctly. This code will be needed in stage 7 (and is not the same as the digital certificate authorisation code). The insurer will notify the policyholder that his/ her policy access has been set up, and that they can begin to submit data using the certificate, once installed as explained below. If this code has not been received by the time the Page 10 of 68

insurer informs the policyholder that they have been set up, the policyholder should notify their insurer who can order another access code if required. 5. Once the policyholder has received the authorisation and reference codes, he/she can install the digital certificate and software to support the data submission mechanism in accordance with the instructions accompanying the software. If the policyholder has any difficulty with set-up he/she must contact his/ her insurer for assistance, not Experian. Experian can provide second line support in extreme circumstances at a cost of 777 per day. Please note, the insurer will be invoiced for this charge, and their authorisation will therefore be required before any such assistance is given. It is the insurer s responsibility to agree with the Policyholder who ultimately pays for this support. 6. Once the software has been installed, the policyholder should test the connectivity by running the communications test utility provided with the software. 7. The policyholder must validate the e-mail address for error codes before any files can be sent. This requires a validation code. The code and instructions for doing this are e-mailed automatically to policyholders on set-up. The insurer will send the User ID, which is also required, separately. This may arrive some time after the validation code. (The User ID is only used for this one process, although it may be required again if the e-mail address is changed.) 8. The policyholder can then submit his/ her vehicle information using the UFT software. The policyholder does not need further IDs, which are already embedded in the digital certificate. However, data cannot be sent until the policyholder has been notified that his/ her policy has also been linked to the certificate (step 3). 9. If the policyholder also wishes to view the policy over the Internet and have the ability to make Interactive or Attended File Transfer updates, he/she must request a second User ID with password and pass-phrase. The details supplied for Unattended File Transfer cannot be used to access the MID interactively. Please note that Compare & Amend users cannot use the Interactive website to update data they can only view the vehicle schedule (see section 4.4.3). 4.1.1 Proxy servers Some companies control access to the Internet using Proxy servers and depending on how these have been implemented, an internal User ID and password may be required. The MID UFT software can accommodate a local network User ID/password, if this is required by the proxy server. However, this would mean storing this (potentially sensitive) information on a local machine. This is likely to be contrary to many companies local security policies and may mean that such organisations are unable to use Unattended File Transfer. Page 11 of 68

There may also be an issue if the proxy server requires the password to be reset regularly. To allow for this, a utility program is provided with the UFT software, which allows the user to change the proxy settings stored on the local machine. It is possible to overcome these issues by implementing a dedicated link that does not pass through the proxy server or by allowing the machine performing the UFT access to the Internet without the need for identification at the proxy server. Please consult your IT service provider for advice. 4.2 Summary of data submission process The sequence of events undertaken when submitting data using the Unattended File Transfer mode is as follows: 1. A file transfer is initiated at the user site by running the Unattended File Transfer application manually (from a command line) or automatically (using some scheduling process). The procedure for scheduling this is a matter for the policyholder and is out of the scope of this document. 2. When the program starts it attempts to authenticate the user with Experian s file server. If the user is authenticated, the transmission of the file begins. If the user is not authenticated, a negative response will be returned to the originating machine and the file will not be accepted. 3. The data file is encrypted using the user s digital certificate and transmitted to the secure MID upload Server. 4. The secure MID upload Server checks that the file format is acceptable (but no data validation is carried out at this stage). 5. If the file format is valid, a confirmation response is sent to the originating machine, containing an upload ID and Batch ID for reference purposes, and the file is placed in a queue for processing. If the format of any record is not valid, a negative response will be returned to the originating machine and the file will not be processed. 6. The data is validated, and valid records are applied to the MID. 7. Once the file has been processed, a log file containing the upload ID and any error messages pertaining to specific records, is returned to the e-mail address provided by the user (but see section 3.5 on checks on New vehicles). Page 12 of 68

4.3 Standard File Transfer There are two file types for submitting data to the MID, Standard File Transfer, and Compare & Amend, which is addressed in section 4.4. Users of Standard File Transfer send details of additions and amendments when these occur, and can delete erroneous records if necessary. Many transactions may be batched together into a single file and a different record type is used for each type of transaction. The file to be submitted must conform to a comma separated values (CSV) format and should be created using the specification provided in Appendix A. A standard spreadsheet template is also available on the MIIC website 3 that can be used to generate the file. Versions for Excel and Lotus 123 are available. 4.3.1 Data items For Standard File Transfer, the policyholder must submit the following mandatory details for each vehicle: Record type (this will always be V for vehicle records) Update type (this will be New, Amend, or Delete. depending on the action to be carried out). N.B. Delete may be D for deleting all occurrences of this VRM or O deleting only the identified occurrence Policy number Vehicle Registration Mark (VRM) Trade plate indicator (which must always be populated - either with T where a trade plate, or U, where not) Foreign registration indicator (this must be populated but cannot be set by a policyholder, so it must always be U, or it will be rejected) Vehicle On-date (the first day the vehicle is on cover) Vehicle Off-date (the last day the vehicle is on cover) The following preferred fields should also be submitted where possible: Vehicle Type (car, van etc.) Vehicle Make (Ford, Rover etc.) Vehicle Model (Astra, Transit etc.) Vehicle Derivative (GLS etc.) Vehicle Engine Size (1400 etc.) Number of Seats (for buses and minibuses) Gross Vehicle Weight (for HGVs) Even identical information like policy number must be supplied for every vehicle. This allows transmission of data for multiple policies for the same insurer in the same file. 3 www.miic.org.uk/fleet/file_validation.htm Page 13 of 68

4.3.2 Data rules Details of the data to be supplied in each field can be found in Appendix D Data item update and validation rules. Each data item must be placed in the correct order and separated from the next by a comma. When manually creating a CSV file, care must be taken not to include commas within data items (such as addresses etc.) as this will effectively create a new, out of sequence item. Where an optional (or in exceptional circumstances, a preferred) data item is not known, and the field will therefore be blank, the comma that would normally separate the field must still be inserted. Policyholders will not be permitted to supply Class of Use, Permitted Drivers, or Named Driver details to the MID, although these fields will appear on the file, since it is common to insurers. These fields must nevertheless be taken into account in constructing the CSV file (i.e. the appropriate number of commas must be added). Where insurers have added insurer-only data, such as Class of Use to vehicle records, these records will then be closed to further policyholder update, to avoid changes which might be inconsistent with the cover provided. In these cases, these fields must be omitted but their field-separating commas must still be included. The Vehicle On-Date can be backdated up to the policy Effective Date, and the Vehicle Off-date can be future-dated anytime between the current date and the policy Expiry Date. Similarly, the Vehicle On-date can be future-dated to any date up to the policy Expiry Date, and the Vehicle Off-date can be backdated up to the policy Effective Date. The Vehicle Off-date cannot be prior to the Vehicle On-date. Validation checking will ensure that incomplete or incorrect records are rejected and returned (see section 4.5.1 Error Handling). 4.3.3 Spreadsheet template A template is available on the website, which may be used by policyholders to submit data. Excel and Lotus 123 spreadsheets are both supported. Detailed guides to the templates can be found on the MIIC website (Motor Insurance MID Policyholder Guide: Lotus/Excel Templates). 4 In summary, the templates will allow the user to perform the following actions: 4 www.miic.org.uk/fleet/file_validation.htm Page 14 of 68

Identify and complete all the mandatory fields highlighted by use of different coloured headings and fields Validate certain fields on the template Identify and correct validation errors Save the template as a CSV file, the type required for submission to the MID. 4.3.4 Updating vehicle schedules For Standard CSV files, only the new or changed information should be sent in each transmission, whether using the spreadsheet or not. Policyholders must not re-use the same file again and again, with changes added, for Standard File Transfer since this may result in rejections, or the data will be input onto the MID incorrectly. If, for example, a policy should be updated by the addition of one vehicle and the removal of another from cover, then ONLY those two records (New and Amend) should be sent. Where a vehicle is amended, all the details originally supplied that are not being amended (e.g. make and model) must be included in the Amend record, or they will be lost. Examples First file transmission all vehicle records should be set to N (for New), to add them to the MID. They all have On- and Off-dates. 1/1/06 31/12/06 (N) VRM1 Second transmission one vehicle is taken off cover and another added. The addition is added as a New record. The vehicle coming off cover is sent as an A (for Amend) record, with the Off-date set to the appropriate date. The original record will be truncated to match the new Off-date. 1/1/06 31/12/06 (N) VRM1 1/1/06 31/05/06 (A) VRM1 3/3/06 30/6/06 (N) VRM2 Key: Single horizontal line represents the version of the vehicle present on the MID at the time of the Amend being applied, with the truncated portion shown as a dashed line. The double line is the truncating Amend. The vertical line shows the Off-date which is reset by this Amend. The dotted line is the New vehicle record applied. Third transmission a vehicle Off-date needs changing because the vehicle comes off cover later than expected. This is sent as an Amend record with the new, later Off date set. Page 15 of 68

Vehicles which are unchanged are not sent. The Amend does not extend the Off date of previous vehicles. 1/1/06 31/05/06 (Truncated N) VRM1 1/1/06 31/05/06 (A) VRM1 3/3/06 30/6/06 (N) VRM2 3/3/06 31/07/06 (A) VRM2 Key: Single horizontal lines represents the versions of the vehicle present on the MID at the time of the Amend being applied. The dotted line is the Amend vehicle record applied. Note 1: records should not be deleted when a vehicle comes off cover. A deletion removes the vehicle from the MID completely. To show that a vehicle is no longer on cover, an Amend record with the actual Off-date (the last date of cover) should be sent, which will automatically truncate the original Off-date to match the new Off-date. Note 2: vehicle records expire naturally at their Off-date. Policyholders do not need to make a further update once the vehicle has been added, unless the Off-date differs from that originally set. 4.3.5 When to amend a vehicle record using Standard File Transfer There are two possible types of amendments those required to correct a mistake, and those required because there is a change to the vehicle s details from a certain point in time. The latter is very unlikely to be an issue for a policyholder who can only enter limited data, but this may occur occasionally. The way these different amendments are carried out is set out below. Correcting an error To understand the correction process, it is important to understand that records on the MID are not replaced when they are changed the new record is slotted in front of the old record, but the old record still remains. This means that it may be possible for an enquiry to identify an entry on the MID which is incorrect, if care hasn t been taken to use the correct record type to update the MID. Example 1 Consider the following insurance policy (INSPOL1), running from 1/1/06 to 31/12/06 and vehicle (VAN123) initially on cover from 1/1/06 to 31/5/06. INSPOL1 1/1/06 31/12/06 VAN123 Page 16 of 68

1/1/06 31/5/06 Record 1 If the cover dates for VAN123 are changed to 1/3/06 to 30/6/06, the MID will then look like this: 1/1/06 31/5/06 Record 1 1/3/06 30/6/06 Record 2 If an enquiry dated 15 January is made, then the first record will be seen. If the enquiry is on March 15, then the second one will be seen, as illustrated below. 1/1/06 31/5/06 Record 1 1/3/06 30/6/06 Record 2 15/1/06 15/3/06 This is misleading -what was intended was that VAN123 should appear on cover for only the period shown by Record 2 above (i.e. Record 1 being present is effectively showing a false period of cover from 1/1/06 to 1/3/06). Therefore, to ensure accuracy, a correction must be made rather than simply sending an Amend record. This is done by 1) deleting the incorrect record, by sending the appropriate record type D or O, with the original record details, then 2) sending a record type N (new), with the correct details. This will leave only Record 2. Alternatively if the user is certain there is a previous record relating to that vehicle on the policy, which may be for a different period of time on the same policy, they may use record type A (Amend) in stage 2 to achieve the same result. It is generally recommended that if the user is in any doubt, they should use a New record type following a delete. Please note that these steps must be carried out in the order specified or the result will be to delete the newly corrected record as well (see section 4.3.6 on Deletes). Example 2 The above scenario illustrates how to correct an error in the period of cover whereby the whole period changes. But what if only the Off-date is changed to extend a cover period? Page 17 of 68

Where only the Off-date is to be changed, an update type A (Amend) can be used. A MID enquiry of any date prior to 30/06/06 will return the amended record and show the correct cover period. Users should note however that the original record will remain visible on the previously on cover schedule, because the system cannot easily distinguish between superseded records and previous occurrences. This may confuse users, and it is therefore recommended that the action outlined in example 1 to change On- and Off-dates is taken. Changing details In circumstances where the user wishes to change vehicle details part way through the cover period, as opposed to correcting the cover period, the previous records need to be retained and therefore a different approach is required from that previously described. Suppose that VAN123 above was modified on 1 March by replacing the engine with a bigger one, and kept on for another month. In this case both Record 1 and Record 2 should remain. Therefore, the amendment would be made by sending an Amend record (type A ) with the new dates (On-date 1 March and Off-date 30 June) and the new engine capacity. 1/1/06 31/12/06 Record 1 1600cc VAN123 1/3/06 31/12/06 Record 2 2200cc VAN 123 It is important that the date of the change to details (1 March) is used as the On-date. If the date 1 January were used, this would result in Record 2 overlaying Record 1 completely, and an enquiry using a date of 15 January would show the new details. 4.3.6 Deleting records There are 2 methods of deleting a vehicle depending upon whether the user wishes to delete a single occurrence or more than one occurrence of a vehicle on a policy. The two update types are: D-Delete O-Delete D-Delete Deleting by use of the D update type is essentially designed for situations where the VRM is incorrect, or the vehicle should never have been put on cover. Use of the Update type D will delete all records relating to that vehicle from the date specified on the Delete record. For example: Page 18 of 68

A company regularly hires CAR999 for a month and therefore notifies it to the MID for multiple periods at the beginning of the year (e.g. 1-31 January, 1-30 April, 1-31 July and 1-31 October). However, the incorrect VRM was submitted, and CAR999 is actually CAR888. To delete all of the records for CAR999, a D-Delete should be submitted, using the original On-date for the vehicle, i.e. in this case 1 st January. The user then needs to re-submit all of the data for CAR888. Note that the On-date of the Delete record must correspond to an existing On-date for that vehicle or the Delete record will be rejected, e.g. if the Delete was sent through with an On-date of 29 th December or 2 nd January it would be rejected. O-Delete Selection of the Update type O for vehicle records will only delete the VRM record whose On- and Offdates exactly match those specified in the Delete record. So, using the previous example, if the vehicle turns out to be unavailable in April, an O-Delete record should be submitted with an On-date of 1 st April and an Off-date of 30 th April. It should be noted however that if there are multiple records for the same VRM, all with identical dates, all will be deleted. The reasoning applied here assumed that all previous records must have been incorrect in order for them to have been superseded by the most recent record, and they should all therefore be deleted. In the event this is not correct and the user wanted the previous versions with identical dates to remain on the policy, the previous, correct details would need to be re-submitted. 4.4 Compare and Amend Function Compare & Amend (C&A) is a unique form of File Transfer (FT) that minimises the work for policyholders, particularly those who already hold vehicle details on their fleet management systems. However, Compare & Amend requires daily updates from the user, and in the event of errors arising from the data submitted, correction can be complex. Therefore users should consider the limitations of the function set out below carefully before deciding to use this facility. The policyholder will be able to submit the entire vehicle file, the MID process will compare this with the details previously submitted to the MID, identify the changes to the vehicle schedule, and apply them appropriately to the MID. In summary, vehicles appearing on a file for the first time will be added to the MID record, whilst vehicles which are no longer present will be recorded as going off cover. For a full guide on how this process works, please see the Motor Insurance Policyholder Guide: Compare & Amend, which can be found on the MIIC website (www.miic.org.uk/fleet/policyholder_guides). Data items The submission procedure is the same as for Standard File Transfer but the policyholder will need to select the Compare & Amend option when using Attended File Transfer. For Compare & Amend File Transfer the policyholder must submit the following mandatory details for each vehicle: Page 19 of 68

Policy number Vehicle Registration Mark (VRM) Vehicle On-date (the date the vehicle comes on cover) The Vehicle Off-date (the date the vehicle comes off cover) is optional. The following preferred fields should also be submitted where possible: Vehicle Make (Ford, Rover etc.) Vehicle Model (Astra, Transit etc.) The specification for the record format is contained in. It is essential that this format is used for C&A files to show that the Compare and Amend function is to be actioned. If a policyholder selects the C&A function but uses the Standard File format, the file will be rejected. Conditions of use for Compare & Amend Compare & Amend works by deducing which vehicles are on cover on the policy, and which have come off, by comparing the latest file with the previous one sent. In order to ensure that this process gives the right result there are a number of rules, which must be followed. If these rules are not applied correctly then the data may be wrong, or may not be applied to the MID at all. The rules are as follows: The Vehicle On-Date, policy number and VRM must be included on every record. The policyholder must supply files containing vehicles on cover on a daily basis (365 days per year; Note that it is accepted that policyholders may not be able to transmit Compare & Amend files at weekends and public holidays.), even where it is known that no changes have occurred. This is to avoid inaccuracies arising from the removal of a vehicle between updates which might be allocated an Off-date several days out of date (see explanation below). Errors arising in a file must be addressed immediately they are received, and no further files can be sent until the error is corrected (see examples below). Where the policyholder has more than one policy with the same insurer, and uses Compare & Amend for all those policies, a single file must be sent for all vehicles on all policies, so that the comparison uses the same data each time. This works correctly because the policy number is in the record, so the vehicle is applied to the right policy. If this is not done, the Compare & Amend function may add the wrong changes to the policy. To submit separate files for each policy, separate User IDs are required. Page 20 of 68

If the user supplies details for many different policies, they must include every vehicle list every time in the same file. Where a policyholder opts to make changes to the vehicle schedule using C&A, changes cannot be made by using any other method i.e. interactive update or standard file transfer. This is because such changes will put the vehicle schedule on the MID out of step with the C&A file submitted by the policyholder. The exception to this rule will be insurers who will have superuser rights to correct problems that can t be resolved by the policyholder. It will only be possible for the insurer to make these changes via interactive access. Once these changes have been applied, the insurer must inform the policyholder so that the appropriate changes can then be made to the C&A file by the policyholder. Vehicles with a blank Off-date cannot be submitted for the renewal period until the renewal policy has come into force. Compare & Amend uses the current expiry date to set the Off-date if this is blank, so any future-dated vehicles will then be given an Off-date that is earlier than the On-date, and will be rejected. This problem can be overcome by specifying the Off-date in the file (and it is planned that the functionality will be changed to prevent this problem in future). Should a policyholder decide that he/she no longer wishes to submit data using Compare & Amend, he/she must notify their insurer, who can arrange for the Compare & Amend-only constraint to be removed. However, changing submission methods is complicated, and it is strongly recommended that this is only done if absolutely necessary, and preferably at renewal time. This will minimise any problems, which may arise. Vehicles cannot be wholly deleted using a Compare & Amend file, since the absence of a vehicle on a file is taken to mean it has come off cover. To delete vehicles entirely the policyholder must contact his/ her insurer, who can make this change. (NB that this does not refer to removing vehicles from the policy because they have ceased to be on cover, but to total deletion of an erroneous record) Multiple occurrences of the same vehicle are not permitted in any one file. This is because the system is not able to determine which of the records is correct and should be applied to the MID and may therefore amend the database incorrectly. The file should represent a snapshot of the vehicle fleet on a particular day. To ensure compliance with the daily file submission requirement, a report will be sent to insurers on a weekly basis, identifying all those policyholders who are supplying data via the Compare & Amend function, who have not submitted sufficient files in the previous 7 calendar days. Note that it is accepted that policyholders may not be able to transmit Compare & Amend files at weekends and public holidays. Page 21 of 68

Treatment of files When the Compare & Amend file is received the date of receipt will be logged. This date is then used to generate a nominal Off-date when vehicles are removed from cover. The date a vehicle comes off cover will be assumed to be the date of receipt minus one day ( DOR-1 ). The following assumes that no vehicle records are currently held on the MID when the Compare & Amend function is first used. The next section flags where differences may be seen if a policyholder changes from interactive update or Standard File Transfer to Compare & Amend. Changes will be applied as follows: Where a vehicle is present on the file for the first time, and is therefore coming on cover, and the Vehicle Off-date has not been supplied, then the Vehicle Off-date will be set to the policy Expiry Date. Where a vehicle is present on the file for the first time, and is therefore coming on cover, and both On- and Off-dates have been supplied, the vehicle will be added to the MID with the dates given (subject to all fields passing validation). These dates may be either future or past, as long as they are within the policy period. Where a vehicle is present on the previous day s file but not present on today s, and the therefore is presumed to have come off cover, then the Vehicle Off-date will be set to DOR-1 (i.e. the previous day). The system will also delete the original record from MID to avoid it remaining visible on enquiry as explained below. Where vehicles have previously been on cover and reappear on the schedule with dates outside the original cover period, they will be treated as if new to the policy. That is, the On- and Offdates will be set as above; the previous record for that vehicle will not be extended or amended. Where a specified vehicle Off-date changes to bring it forward, the revised Off-date will be set accordingly. Providing no other details have changed, the previous record will be deleted, since it is assumed that the cover period beyond the new Off-date no longer applies. Where a vehicle with a specified Off-date is present on a file beyond that Off-date (e.g. the policyholder has forgotten to remove it from the file, or it has been added in the past) the Offdate will not be changed when the vehicle is subsequently removed from the file. Therefore, to extend the Off-date (if that is required), an amended record with a later Off-date must be submitted. This functionality applies only when the Off-date was specified in the file, and the vehicle appears/remains on the file beyond that date. Where a vehicle is already present on the MID schedule, and is currently on cover, but the details of that vehicle have been changed, the impact on the record depends on the nature of the change. This is explained in the next section. Where the policyholder submits an empty file, this will be rejected. The MIB publication Motor Insurance Policyholder Guide: Compare & Amend sets out a number of illustrations of how this function will work in practice. Page 22 of 68

Changing to Compare & Amend file transfer mid-term Compare & Amend works by comparing the records sent with the previous day s record. It does not compare to the record currently held on the MID. Therefore, if a policyholder has previously transmitted data to the MID by Standard File Transfer, or added vehicles interactively, there may be anomalies when transferring to the Compare & Amend method. For further details about potential problems when changing to Compare & Amend file transfer mid-term, please see the Motor Insurance Policyholder Guide: Compare & Amend, which can be found on the MIIC website (www.miic.org.uk/fleet/policyholder_guides). Amending vehicle details using Compare & Amend Amendments to records via Compare & Amend are made by the system applying certain rules to changes identified on the vehicle schedule to generate update records to be applied to the MID. In summary: Where a vehicle appears for the first time, a New record is generated Where a vehicle disappears, an Amend record with a new Off-date, but the original On-date and make and model details, is generated Where any of the vehicle details have changed, an Amend record is generated containing all the details in the revised vehicle entry. (Where no Off-date is included, this is automatically set to the expiry date of the policy) It is important to understand that the Amend records created by the comparison in this last case, or where the On-date is changed, do not supplant the original record, but create a new record, which sits in front of the old record. This means that changes to the On- date, which are required because of an error cannot always be made by using Compare & Amend file transfer. For example, consider the following insurance policy (INSPOL1), running from 1/1/06 to 31/12/06 and vehicle (VAN123) initially on cover from 1/1/06 to 31/5/06. INSPOL1 1/1/06 31/12/06 VAN123 1/1/06 31/5/06 Record 1 If the next file changes the cover dates for VAN123 to 1/3/06 to 30/6/06, the MID will then look like this: 1/1/06 31/5/06 Record 1 1/3/06 30/6/06 Record 2 Page 23 of 68

If an enquiry dated 15 January is made, then the first record will be seen, as illustrated below. If the enquiry is on March 15, then the second one will be seen. 1/1/06 31/5/06 Record 1 1/3/06 30/6/06 Record 2 15/1/06 15/3/06 This is misleading as what was intended was that VAN123 should appear on cover for only the period shown by Record 2 above (i.e. Record 1 being present is effectively showing a false period of cover from 1/1/06 to 28/2/06). Therefore, if amendments are made other than simply changing the Off-date (for example changing make, model or On-date), policyholders should check for superfluous records using MIDUpdate. Compare & Amend cannot be used to delete a record. If you need to correct an erroneous entry on the vehicle schedule, which is supplied using Compare & Amend, you should follow the procedure in The Compare & Amend Policyholder Guide, section 6 examples 2 and 4. 4.4.5 Insurer corrections Where a policy is marked as being Compare & Amend, then all other maintenance and supply routes are disallowed, except for those carried out by the insurer. The policyholder must ask the insurer to make any change that cannot be accommodated on their file (e.g. a deletion). When the insurer brings up the vehicle schedule for amendment, a warning message will advise that this is a Compare & Amend policy and that the insurer must inform the policyholder of any change they make (otherwise this file will be out of step with the information held on the MID). This will ensure that the change made by the insurer on the database are not lost. The policyholder must then change the next file before submitting it. If the amendment relates to a date that would otherwise be outside the permitted parameters for a policyholder, the update on the next file will not be rejected, in this special circumstance only. The details must exactly match the data on the MID. The validation will include a check to establish that the amendment reflects an insurer amendment, and if so, the entry will be permitted. 4.5 Confirmation of error-free file All File Transfer users, whether Attended, Unattended, Standard or Compare & Amend, will receive a file back as acknowledgement that the data has been loaded to the MID. If there have been no errors, a Page 24 of 68

dummy reject record, containing a single record of Type X and the comment THIS FILE HAS BEEN SUCCESSFULLY LOADED in the Quoteback field will be sent. All other fields in the dummy reject record will be unpopulated. Please refer to Appendix A File Formats for an example of a dummy reject record. 4.5.1 Error Handling For those policyholders supplying data via Unattended File Transfer, errors will be returned via a CSV file attached to an email to the address registered when they first obtained UFT access. Policyholders should check for error messages (indicated by a code beginning E or W (see Appendix B Error messages or go to www.midupdate.com/insurance2/errorwarnings.html for further details). Further vehicle data can still be submitted by policyholders, even if errors are outstanding, but not for vehicles that were completely rejected. Policyholders should contact his/ her insurers (not Experian or MIB), should they require help or guidance in interpreting and correcting the files for re-submission. Page 25 of 68

5. Glossary of Terms Term Add Definition The process of adding a vehicle to a policy Agent Amend Broker Cancel Comma separated values (CSV) Delegated authority (DA) Delete File Transfer Insurer A (natural or legal) person acting on behalf of a policyholder to submit data, whether direct to the MID or to the insurer. Agents may have access to multiple policies for vehicle updating purposes only. The process of amending vehicle details on a Policy OR amending policy details A specialist who represents buyers of insurance and who deals with either agents or companies in arranging for the coverage required by the customer. In relation to a policy, a termination of cover prior to the policy end date. This may be initiated by the insurer or the policyholder, but the function can only be undertaken by an insurer. (N.B. vehicles cannot be cancelled. They are either removed from/taken off cover or deleted because they should never have been on cover.) A common data exchange format for records within a file which encodes all fields as ASCII characters, and separates each field with commas. Fields may sometimes be enclosed in quote marks - the MID standard is not to use quote marks. Each record within a CSV file is terminated by a Carriage Return/Line Feed character pair. A (natural or legal) person acting on behalf of an insurer in a capacity governed by the insurer s letter of authority. DAs may act on behalf of multiple insurers to submit data and make enquiries. The process of removing a vehicle from a Policy schedule when it should never have been included (N.B. this is not the same as Remove from cover ). This results in the vehicle not appearing on further enquiries. A method for transferring MID data over the Internet. Files transferred using File Transfer may be formatted in a number of ways, such as CSV. File Transfer may be either attended or unattended - "attended" File Transfer is invoked from within a logged-in Web session; "unattended" File Transfer operates with automatic log-in from a computer, without human intervention. The party to the insurance contract who promises to pay losses or benefits. In the context of this document this refers to the person or department with whom they have contact relevant to the MID. Page 26 of 68

Term Interactive Lapse Mandatory MID Off Cover Off-Date Definition In relation to an update of the vehicle schedule, the process that allows the user to amend the schedule by manually adding to and changing it via a form on the website (cf. File Transfer). In relation to a policy, a record that is submitted to the MID to cancel a policy that was not in fact renewed (used where policies are notified as due to be renewed, but the policyholder does not take up the renewal). In relation to a MID data record, a data item which is compulsory and must be completed for the record to pass validation and be loaded. These items are required by law. A database containing information relating to the insurance of vehicles in the UK. Describes the status of a vehicle when there is no insurance cover in force The date on a vehicle acquires a status of Off Cover On Cover On-date Describes the status of a vehicle associated with a Policy for which insurance cover is in force The date on which a vehicle acquires a status of on cover Optional Policyholder Preferred Record Remove from cover Session In relation to a record, a data item which is not compulsory but can be supplied if the policyholder so desires An entity paying a premium to an insurance company in exchange for the insurance protection provided by a Policy In relation to a record, a data item which is not compulsory, but is considered to be of such importance to the MID s goals that it should be provided if possible. Such fields may become mandatory in the future and insurers have been advised to take steps to collect the necessary data if they do not currently do so. A collection of data items related to a single vehicle or policy on or transferred between the MID and its users The process of taking a vehicle off cover. This results in the vehicle appearing on the schedule as off-cover from the relevant date (cf. Delete ). A continuous series of transactions initiated and carried out by a user. Page 27 of 68

Term User View Definition A person (for the purposes of this document usually a policyholder) accessing a system. The process of viewing the vehicles on a policy Page 28 of 68

Appendix A File Formats FORMATS FOR STANDARD AND COMPARE & AMEND FILE TRANSFER CSV File Format Policyholders (or their agents) with the permission of his/ her insurer, are able to submit vehicle details to the MID, via File Transfer over the internet. This data must be transmitted in a CSV (Comma Separated Values) file. To assist the policyholder to create the correct format, a spreadsheet template is available to download from the MIIC web site (www.miic.org.uk/fleet/policyholder_guides.htm). General points to note on the CSV file format: Standard file transfer and Compare & Amend formats are different (although both use CSV format file structures). Experian will identify from the file format whether the file is a Standard or a Compare & Amend file. The Standard file and its Spreadsheet template will contain exactly the same fields. The Compare & Amend CSV file and Spreadsheet template (Compare & Amend CSV file) will contain exactly the same fields. The identity of the supplier (i.e. insurer or policyholder) will determine which fields in the Standard CSV file can be populated and, therefore, which fields Experian will validate. For example, Named Driver Name cannot be submitted by the policyholder. If the policyholder sends a Standard CSV file with this field populated, then Experian will ignore the content of that field, and send a warning message to the policyholder to advise that they are not permitted to populate that field and that the content they supplied for that field has been ignored and will not be loaded to the MID. Each file can contain vehicle details for several different policies, provided that they are covered by a single insurer. This is achieved by populating the Policy Number against each VRM. Where policyholders have policies with several insurers, then one file must be submitted per insurer Each field is separated by a comma Each record starts on a new line. That is, there should be one record per line. Field lengths are variable and are subject to a maximum length. See appendix D for field-length restrictions. Because a comma (,) is used as a field delimiter, all other commas should be omitted, otherwise the data on either side of the comma will be assumed to be separate fields. For example, if a field was submitted with a value of 250,000 it would be interpreted as two fields; one containing 250 and the other containing 000. Where files submitted via File Transfer are error-free, the policyholder will be sent a dummy reject record to acknowledge that the file has been loaded onto the MID. Where files submitted via File Transfer contain invalid records, the policyholder will be sent a file of reject records to verify that these records have not been loaded but that all other records sent have been. Page 29 of 68

The reject file format will be the same irrespective of supply method and route (Standard CSV file, Compare & Amend CSV file, Spreadsheet Standard CSV file, Spreadsheet Compare & Amend file, Attended File Transfer, Unattended File Transfer). The following pages contain the file formats and examples for the different methods of submitting vehicle data to the MID, via File Transfer over the Internet. Standard CSV File Format Attended and Unattended File Transfer The first table illustrates the fields that will be supplied in the standard CSV file format for each vehicle record. The fields Named Driver Name and Excluded Driver cannot be supplied by policyholders but can occur up to a maximum of 6 times. Therefore, each file must contain these fields occurring 6 times. Mandatory fields are marked with an asterisk (*). Standard CSV Vehicle Record Field Description Comments Record Type* Refer to Appendix D, Number EL0001. Update Type* Refer to Appendix D, Number EL0009. Insurer ID* Refer to Appendix D, Number EL0010. Insurer Branch ID Refer to Appendix D, Number EL0011. Quoteback Refer to Appendix D, Number EL0053. Delegated Authority Refer to Appendix D, Number EL0012. ID DA Branch ID Refer to Appendix D, Number EL0013. Policy Number* Refer to Appendix D, Number EL0014. Foreign Registration Refer to Appendix D, Number EL0056. Indicator* Vehicle Registration Refer to Appendix D, Number EL0016. Mark* Trade Plate Refer to Appendix D, Number EL0082. Indicator* Vehicle Type Refer to Appendix D, Number EL0081. Vehicle Make Refer to Appendix D, Number EL0074. Vehicle Model Refer to Appendix D, Number EL0075. Vehicle Derivative Refer to Appendix D, Number EL0076. Vehicle Engine Size Refer to Appendix D, Number EL0077. Number of Seats Refer to Appendix D, Number EL0078. Gross Vehicle Refer to Appendix D, Number EL0079. Weight Vehicle Instep Code Refer to Appendix D, Number EL0018. Vehicle On-Date* Refer to Appendix D, Number EL0070. Page 30 of 68

Field Description Vehicle Off-Date* Comments Refer to Appendix D, Number EL0071. Page 31 of 68

Vehicle record continued The following fields may only be submitted by insurers (so full explanations have not been included in the appendices). Commas are required to separate unpopulated fields. Field Description Permitted Drivers Class of Use Additional Drivers Indicator Number of Named Drivers Named Driver Name (1) Excluded Driver (1) Named Driver Name (2) Excluded Driver (2) Named Driver Name (3) Excluded Driver (3) Named Driver Name (4) Excluded Driver (4) Named Driver Name (5) Excluded Driver (5) Named Driver Name (6) Excluded Driver (6) Comments Page 32 of 68

Reject File Format The following illustrates the fields that will be returned in the reject file. As with the vehicle record above, the file format will be the same, irrespective of whether the file to which it relates was submitted by an insurer or a policyholder. The field Error Code can occur a maximum of 20 times. Therefore, each file will contain this field occurring 20 times. Field Description Record Type Policy Number Party Policy Control Count Sent Party Policy Control Count Expected Vehicle Registration Mark File Production Date Quoteback Experian Reject Reference Error Level Error Code (1-20) Comments Refer to Appendix D, Number EL0001. Refer to Appendix D, Number EL0014. Not applicable to policyholder File Transfer Not applicable to policyholder File Transfer Refer to Appendix D, Number EL0016. Refer to Appendix D, Number EL0006. Refer to Appendix D, Number EL0053. Refer to Appendix D, Number EL0066. Refer to Appendix D, Number EL0083. Refer to Appendix B This field repeats 20 times, irrespective of the number of errors. Compare & Amend File Format This table illustrates the fields that will be supplied in the Compare & Amend CSV file format for each vehicle record. Mandatory fields are marked with an asterisk (*). Field Description Policy Number* Vehicle Registration Mark* Vehicle Make Vehicle Model Vehicle On-Date* Element number EL0014 Refer to Appendix D (This must be completed for every vehicle, even if on the same policy) EL0016 Refer to Appendix D EL0074 Refer to Appendix D EL0075 Refer to Appendix D EL0070 Refer to Appendix D Page 33 of 68

Vehicle Off-Date EL0071 (Optional) Refer to Appendix D Example Standard CSV File Format The following gives an example where the policyholder submits a vehicle record containing all mandatory fields, and some optional fields. The policyholder is not permitted to supply Permitted Driver, Class of Use, Named Driver or Excluded Driver information, but since common file formats apply to vehicle records from both insurers and policyholders, these fields must be taken into account in submitting files. For the purpose of the example, all the field values are shown in upper case. However, in practice, it will not matter if the values are supplied in lower or upper case: Experian will populate the MID as supplied. The only exception to this is where the VRM is supplied in lower case, Experian will automatically convert this to upper case before applying to the database. Acceptable field values and Validation rules can be found in Appendix D. Example Vehicle Record Field Description Element Value number Record Type EL001 V Update Type EL009 N Insurer ID EL0010 911 Insurer Branch ID EL0011 A11 Quoteback EL0053 THIS IS AN EXAMPLE STANDARD CSV RECORD Delegated Authority EL0012 774 ID DA Branch ID EL0013 Policy Number EL0014 POL123456789 Foreign Registration Indicator Vehicle Registration Mark Trade Plate Indicator EL0016 EL0082 Vehicle Type EL0081 PRIVATE CAR Vehicle Make EL0074 VAUXHALL Vehicle Model EL0075 CORSA Vehicle Derivative EL0076 SRI Vehicle Engine Size EL0077 1400 U (cannot be set by policyholder must be set to U) R123ABC U Page 34 of 68

Field Description Number of Seats Gross Vehicle Weight Element number EL0078 EL0079 Value Vehicle Instep Code EL0018 Vehicle On-Date EL0017 20060320 Vehicle Off-Date EL0018 20061231 Permitted Drivers Class of Use Additional Drivers Indicator Number of Named Drivers Named Driver Name Excluded Driver Named Driver Name Excluded Driver Named Driver Name Excluded Driver Named Driver Name Excluded Driver Named Driver Name Excluded Driver Named Driver Name Excluded Driver In CSV format, where the field delimiter is a comma, the above Vehicle Record would be: V,N,911,A11,THIS IS AN EXAMPLE FULL CSV RECORD,774,POL123456789,U,R123ABC,U,PRIVATE CAR,VAUXHALL,CORSA,SRI,1400,,,,20020320,20021231,,,,,,,,,,,,,,,,, In practice, each record would be on one line. When the above file (assumed to be error-free) reaches the Experian system, the following dummy reject record will be sent back to indicate that the file has been received by the Experian system: Page 35 of 68

Example Acceptance File When the above file reaches the Experian system, the following dummy reject record will be sent back to indicate that the file has been received by the Experian system: Field Description Record Type Policy Number Party Policy Control Count Sent Party Policy Control Count Expected Vehicle Registration Mark File Production Date Quoteback Experian Reject Reference Error Level Error Code Value X THIS FILE HAS BEEN RECEIVED Repeats 20 times In CSV format, where the field delimiter is a comma, the above Reject Record would be: X,,,,,,THIS FILE HAS BEEN RECEIVED,,,,,,,,,,,,,,,,,,,,,,, The following example illustrates what the policyholder would have received if the CSV file had passed validation and was loaded to the MID without any errors or warning messages: Example Reject File Format (1) Field Description Record Type Policy Number Party Policy Control Count Sent Party Policy Control Count Expected Vehicle Registration Mark File Production Date Quoteback Value X THIS FILE HAS BEEN LOADED Page 36 of 68

Experian Reject Reference Error Level Error Code (Repeats 20 times) In CSV format, where the field delimiter is a comma, the above Reject Record would be: X,,,,,,THIS FILE HAS BEEN LOADED,,,,,,,,,,,,,,,,,,,,,,, The following example illustrates what the policyholder would have returned, if the CSV file had been put through validation, but a record had been rejected because of: an invalid Record Type (E014); a warning message indicating that the VRM had not been found but that the Trade Plate Indicator had been set (W015); and a warning that the policyholder had tried to submit a field that only an insurer is permitted to supply (e.g., Named Driver Name) (W023). Example Reject File Format (2) Field Description Value Record Type X Policy Number POL123456789 Party Policy Control Count Sent Party Policy Control Count Expected Vehicle Registration Mark R123ABC File Production Date 20060701 Quoteback Experian Reject Reference EXP12345 Error Level V Error Code E014* Error Code W015* Error Code W023* Error Code Blank field then repeats 17 times * see Appendix B Error messages for meanings of error codes In CSV format, where the field delimiter is a comma, the above Reject Record would be: X,POL123456789,,,R123ABC,20020701,,EXP12345,V,E014,W015,W023,,,,,,,,,,,,,,,,,, Page 37 of 68

Compare & Amend CSV File Format The following gives an example where the policyholder has submitted a vehicle record via the Compare & Amend method. For the purpose of the example, all the field values are shown in upper case. However, in practice, it will not matter if the values are supplied in lower or upper case Example C&A Vehicle Record Field Description Value Policy Number POL123456789 Vehicle Registration R123ABC Mark Vehicle Make VAUXHALL Vehicle Model CORSA Vehicle On-Date 20060320 Vehicle Off-Date In Compare & Amend CSV format, the above Vehicle Record would be: POL123456789,R123ABC,VAUXHALL,CORSA,20020320,, In practice, each record would be on one line, with the Carriage Return ( ) used to indicate the end of the line. When the above file reaches the Experian system and has been validated, a dummy reject record is sent back to indicate that the file has been received and successfully loaded onto the MID. If there were any errors identified during the validation process, error records would have been returned in the reject file in the same format as for standard file format. Page 38 of 68

Appendix B Error messages The table below details errors and warnings that may be returned to the policyholder using any type of File Transfer. Errors (prefixed E ) result in the corresponding record being rejected. Warnings (prefixed W ) do not result in rejection: the record is loaded to the MID, but the warning condition should be investigated and corrected as soon as possible. Error E014 E016 E017 E018 E019 E020 E032 E038 E070 E072 E073 E075 E077 E079 E081 E088 E089 E091 E095 E098 E099 E100 E101 E103 E105 E106 E109 E112 E113 Description Invalid record type Insurer ID not known Delegated authority ID not known Delegated authority branch ID not known Invalid policy number Invalid vehicle registration mark format Invalid foreign registration indicator Input record too long Invalid trade plate indicator Invalid vehicle on-date Invalid vehicle Off-date Update Type of Vehicle Record not N, A, D or O Update type on vehicle record is A and existing record not found Update type on vehicle record is N and existing record found No matching vehicle record found for D-Delete No policy record found for vehicle Vehicle on-/off-dates not within policy effective/expiry dates Policyholder does not have access to this policy Policyholder cannot amend or delete this vehicle; it has driver/use data DA branch ID present but no DA ID Vehicle Off-date prior to vehicle On-date Policyholder cannot set Foreign Registration Indicator Compare & Amend file is empty User ID not authorised [for this policy/file] This Policy can only be updated by Compare & Amend batch Policyholder may not supply backdated data Off-date earlier than On-date - Compare and Amend policy No matching vehicle record found for O-Delete Policyholder may not supply backdated Amendments Page 39 of 68

E103 is generated where an authorised user sends a file for a policy or an insurer for which they are not authorised. This probably means that the wrong policy number or the wrong insurer ID has been used. E105 is generated when a Standard File is sent for a policy designated as Compare & Amend and causes the entire file to be rejected. Warning W001 W012 W015 W020 W021 W022 W023 W024 W027 W028 W029 W030 W032 W033 Description Vehicle registration mark not found Update Type is D or O and existing vehicle not found Vehicle registration mark not found but trade plate indicator set There is a later dated version of this policy which will not be updated automatically* Vehicle registration mark not found, delayed check for new vehicle Vehicle registration mark shown as scrapped Policyholder has supplied an insurer-only field, content will be ignored Vehicle Registration Mark shown as Scrapped, delayed check for new vehicle This policy has now been marked as a Compare & Amend policy VRM shown as scrapped, delayed check sent by policyholder VRM shown as exported, delayed check sent by policyholder VRM not found, delayed check sent by policyholder A record lies wholly beyond amend period On- and Off-dates for O Delete record can no longer be found W028, W029, W030 will be sent to the insurer, but may be forwarded to policyholders * Amendments will not be rolled over to future records the policyholder must repeat the submission for the new policy period. Page 40 of 68

Appendix C Vehicle data 1 Acceptable Registration Mark Formats GB A9AAA A99AAA A999AAA A9 A99 A999 A9999 AA9 AA99 AA999 AA9999 AAA9 AAA99 AAA999 AAA9999 AAA9A AAA99A AAA999A 9A 9AA 9AAA 99A 99AA 99AAA 999A 999AA 999AAA 9999A 9999AA AA99AAA AA99AA 99AA99 999A999 NI A9AAA A99AAA A999AAA A9 A99 A999 A9999 AA9 AA99 AA999 AA9999 AAA9 AAA99 AAA999 AAA9999 AAA9A AAA99A AAA999A 9A 9AA 9AAA 99A 99AA 99AAA 999A 999AA 999AAA 9999A 9999AA Page 41 of 68

A = any letter A Z; 9 = any number 0-9 Notes: 1. Any vehicle record submitted with the new GB registration mark format (AA99AAA), for the current six month period (and for a grace period after the changeover) will only be checked after a set period of delay. E.g., between 1 September 2006 and 28 February 2007, New vehicles will be those with the format AA56AAA. Such vehicles will also be treated as New for some weeks from 1 March 2007 (the number of weeks is currently 6 but this is subject to continuous review and may be changed in the future depending on improvements in updating the Vehicles Register with new registrations). 2. So far as military vehicles are concerned, there are now two systems conventional numbers, as catered for within the DVLA formats - and the series 99AA99 (the old system) and AA99AA (the current one). 3. For diplomatic plates (format 999A999), the first 3 numbers indicate the Embassy, the middle letter, which can only be an X or a D, indicates whether it is an Embassy vehicle (D) or a Consular/other international vehicle (X), and the last 3 digits are a serial number. 4. The old Republic of Ireland numbers are also catered for within the existing DVLA format. See also 5 below. 5. Northern Ireland. Initially, only the letters I and Z are issued by DVLNI but it is possible for GB formats to be permanently retained on the DVLNI system (and vice versa) Embedded spaces will be removed during input file processing and the VRM will be stored on the MID left justified e.g. T 238 KKL becomes T238KKL. Policyholders may therefore choose to include or omit spaces as they wish. Acceptable Trade Plate Formats GB 999AA or 99AAA NI 999AAA A = letter A - Z; 9 = a digit 0-9 Notes: 1. DVLA (GB) New style plates were introduced in September 2001, however the 3 numeric 2 alpha format will continue to be valid. Please contact the local Vehicle Registration Office for information. DVLNI (Northern Ireland) - The three numbers are pre filled with zeros e.g. 001 AB. Please contact the appropriate issuing office, as identified by the two-letter suffix. 2 Vehicle codes (InStep) If policyholders wish, they may use codes to submit vehicle data. A database of code lists is available from the Association of British Insurers (ABI) website. See http://www.abi.org.uk/carinsurance/. Page 42 of 68

Appendix D Data item update and validation rules Data Dictionary Index (alphabetical) Element Name Found in Element Number DA Branch ID Vehicle Record EL0013 Delegated Authority ID Vehicle Record EL0012 Error Level Reject Record EL0083 Experian Reject Reference Reject Record EL0066 Gross Vehicle Weight Vehicle Record EL0079 Insurer Branch ID Vehicle Record EL0011 Insurer ID Vehicle Record EL0010 Number of Seats Vehicle Record EL0078 Policy Number Vehicle Record EL0014 Quoteback Vehicle Record & EL0053 Reject Record Record Type Vehicle Record & EL0001 Reject Record Trade Plate Indicator Vehicle Record EL0082 Update Type Vehicle Record EL0009 Vehicle Derivative Vehicle Record EL0076 Vehicle Engine Size Vehicle Record EL0077 Vehicle Instep Code Vehicle Record EL0018 Vehicle Make Vehicle Record EL0074 Vehicle Model Vehicle Record EL0075 Vehicle Off-Date Vehicle Record EL0071 Vehicle On-Date Vehicle Record EL0070 Vehicle Registration Mark Vehicle Record EL0016 Vehicle Type Vehicle Record EL0081 Page 43 of 68

Numerical listing Element Number EL0001 EL0009 EL0010 EL0011 EL0012 EL0013 EL0014 EL0016 EL0018 EL0053 EL0066 EL0070 EL0071 EL0074 EL0075 EL0076 EL0077 EL0078 EL0079 EL0081 EL0082 EL0083 Element Name Record Type Update Type Insurer ID Insurer Branch ID Delegated Authority ID DA Branch ID Policy Number Vehicle Registration Mark Vehicle Instep Code Quoteback Experian Reject Reference Vehicle On-Date Vehicle Off-Date Vehicle Make Vehicle Model Vehicle Derivative Vehicle Engine Size Number of Seats Gross Vehicle Weight Vehicle Type Trade Plate Indicator Error Level Data descriptions The following pages contain details of the data items, the permitted field length and type, and the validation that will be carried out. Page 44 of 68

NUMBER: NAME: DEFINITION: EL0001 Record Type Identifies the record type as being Vehicle or Reject for policyholder files. LENGTH (CHARACTERS): 1 USAGE: FORMAT: PRECISION: A VALIDATION RULES AND COMMENTS: Must be V for the Vehicle Record. Will be X for the Reject Record. For All Files: Mandatory. Page 45 of 68

NUMBER: NAME: DEFINITION: EL0009 Update Type Identifies the Vehicle Record as being New, Amend, D-Delete or O-Delete (see 0) LENGTH (CHARACTERS): 1 USAGE: FORMAT: PRECISION: A VALIDATION RULES AND COMMENTS: Must be either N = New, A = Amend or D = Delete. For All Files: Mandatory. TYPE DESCRIPTION Code New A vehicle which has never appeared before on the Motor Insurance N Database. Amend D-Delete O-Delete An amendment to a vehicle record which already exists on the Motor Insurance Database. The vehicle record is submitted, and not just the fields which have changed. Removes an inaccurate vehicle from the Motor Insurance Database, which should never have been loaded. Removes all records for that VRM on that policy, starting with the date of the Delete Deletes only those occurrences of a vehicle record which exactly match the On- and Off-dates of the O-record A D Page 46 of 68

NUMBER: NAME: DEFINITION: EL0010 Insurer ID Identifies the supplying insurer on the Vehicle Record. LENGTH (CHARACTERS): 3 USAGE: FORMAT: PRECISION: AN VALIDATION RULES AND COMMENTS: Must exist in the Experian allocated list of valid Insurer IDs, which is based on the Instep Server Standard Code List 81. Can be obtained from the insurer. For All Files: Mandatory. Page 47 of 68

NUMBER: NAME: DEFINITION: EL0011 Insurer Branch ID Identifies individual branches within a supplying insurer on the Vehicle Record. LENGTH (CHARACTERS): 10 USAGE: FORMAT: PRECISION: AN VALIDATION RULES AND COMMENTS: Not required for policyholders. For All Files: Optional. Page 48 of 68

NUMBER: NAME: DEFINITION: EL0012 Delegated Authority ID Identifies the file supplier as a delegated authority on the Vehicle Record. LENGTH (CHARACTERS): 3 USAGE: FORMAT: PRECISION: AN VALIDATION RULES AND COMMENTS: Not required for policyholders. For All Files: Optional. Page 49 of 68

NUMBER: NAME: DEFINITION: EL0013 DA Branch ID Identifies a particular supplying branch of a delegated authority on the Vehicle Record. LENGTH (CHARACTERS): 20 USAGE: FORMAT: PRECISION: AN VALIDATION RULES AND COMMENTS: Not required for policyholders For All Files: Optional. Page 50 of 68

NUMBER: NAME: DEFINITION: EL0014 Policy Number Identifies the policy LENGTH (CHARACTERS): 20 USAGE: FORMAT: PRECISION: AN VALIDATION RULES AND COMMENTS: As per the policy. Must be exact or data cannot be loaded. The unique combination of Policy Number, Vehicle Registration Mark, Insurer ID and Delegated Authority ID identifies an individual record on the Motor Insurance Database. For All Files: Mandatory. Page 51 of 68

NUMBER: NAME: DEFINITION: EL0016 Vehicle Registration Mark The VRM of the vehicle that the policyholder has insured for authorised persons to drive. LENGTH (CHARACTERS): 12 USAGE: FORMAT: PRECISION: AN VALIDATION RULES AND COMMENTS: Must be in a valid Great Britain, Northern Ireland, Channel Islands or Isle of Man registration format otherwise the record will be rejected. The unique combination of Vehicle Registration Mark, Policy Number, Insurer ID and Delegated Authority ID identifies an individual record on the Motor Insurance Database. For All Vehicle Files: Mandatory. Page 52 of 68

NUMBER: NAME: DEFINITION: EL0018 Vehicle Code Standard Code identifying vehicle make and model. LENGTH (CHARACTERS): 8 USAGE: FORMAT: PRECISION: AN VALIDATION RULES AND COMMENTS: Full code must be supplied or else spaces if not present. If Vehicle Make and Vehicle Model are also present, Vehicle Instep Code will be used. For Vehicle Record New: For Vehicle Record Amend: For Vehicle Record Delete: Preferred. Preferred. Not Applicable. Page 53 of 68

NUMBER: NAME: DEFINITION: EL0053 Quoteback User-specific information contained in the Vehicle Record. LENGTH (CHARACTERS): 35 USAGE: FORMAT: PRECISION: AN VALIDATION RULES AND COMMENTS: Will be returned with each receipt record exactly as submitted For Vehicle New: For Vehicle Amend: For Vehicle Delete: Optional. Optional. Not Applicable. Page 54 of 68

NUMBER: NAME: EL0066 Experian Reject Reference DEFINITION Reference to help identify the reject in case of query. LENGTH (CHARACTERS): 35 USAGE: FORMAT: PRECISION: AN VALIDATION RULES AND COMMENTS: In the case of a policyholder querying a reject with his/ her insurer they may be requested to quote this reference. For All Files: Not Applicable. Page 55 of 68

NUMBER: NAME: DEFINITION: EL0070 Vehicle On-Date Date when insurance cover on a particular vehicle becomes effective. LENGTH (CHARACTERS): 8 USAGE: FORMAT: PRECISION: Date VALIDATION RULES AND COMMENTS: Must be a valid date in the format CCYYMMDD. Mandatory in all cases. The Vehicle Off-Date cannot be prior to the Vehicle On-Date. Similarly, the Vehicle On-Date cannot be after the Vehicle Off-Date. This field must be a date within the life of the policy. For Vehicle New: For Vehicle Amend: For Vehicle Delete: Mandatory. Mandatory. Mandatory. Page 56 of 68

NUMBER: NAME: DEFINITION: EL0071 Vehicle Off-Date Date when insurance cover on a particular vehicle ceases. LENGTH (CHARACTERS): 8 USAGE: FORMAT: PRECISION: Date VALIDATION RULES AND COMMENTS: Must be a valid date in the format CCYYMMDD. Mandatory for Standard File Transfer. Optional for Compare & Amend files. The Vehicle On-Date cannot be after the Vehicle Off-Date. Similarly, the Vehicle Off-Date cannot be prior to the Vehicle On-Date. This field must be a date within the life of the policy. For Vehicle New: For Vehicle Amend: For Vehicle Delete: For Compare & Amend: Mandatory. Mandatory. Mandatory. Optional Page 57 of 68

NUMBER: NAME: DEFINITION: EL0074 Vehicle Make The make of the vehicle, e.g. Vauxhall. LENGTH (CHARACTERS): 15 USAGE: FORMAT: PRECISION: AN VALIDATION RULES AND COMMENTS: Vehicle Make is not required if Vehicle Code is present. If the Vehicle Code is not present the Vehicle Make is preferred. For Vehicle New: For Vehicle Amend: For Vehicle Delete: Preferred. Preferred. Not Applicable. Page 58 of 68

NUMBER: NAME: DEFINITION: EL0075 Vehicle Model The model of the vehicle, e.g. Astra. LENGTH (CHARACTERS): 15 USAGE: FORMAT: PRECISION: AN VALIDATION RULES AND COMMENTS: Vehicle Model is not required if Vehicle Code is present. If the Vehicle Code is not present Vehicle Model is preferred. For Vehicle New: For Vehicle Amend: For Vehicle Delete: Preferred. Preferred. Not Applicable. Page 59 of 68

NUMBER: NAME: DEFINITION: EL0076 Vehicle Derivative The vehicle trim, e.g. GLS. LENGTH (CHARACTERS): 15 USAGE: FORMAT: PRECISION: AN VALIDATION RULES AND COMMENTS: Vehicle Derivative is not required if Vehicle Code is present. If the Vehicle Code is not present Vehicle Derivative is preferred. For Vehicle New: For Vehicle Amend: For Vehicle Delete: Preferred. Preferred. Not Applicable. Page 60 of 68

NUMBER: NAME: DEFINITION: EL0077 Vehicle Engine Size The cubic capacity of the vehicle s engine, e.g.1600. LENGTH (CHARACTERS): 5 USAGE: FORMAT: PRECISION: N VALIDATION RULES AND COMMENTS: Vehicle Engine Size is not required if Vehicle Code is present. If the Vehicle Code is not present Vehicle Engine Size is preferred. For Vehicle New: For Vehicle Amend: For Vehicle Delete: Preferred. Preferred. Not Applicable. Page 61 of 68

NUMBER: NAME: DEFINITION: EL0078 Number of Seats Number of seats in the vehicle (buses/minibuses etc. only). LENGTH (CHARACTERS): 3 USAGE: FORMAT: PRECISION: N VALIDATION RULES AND COMMENTS: Should only be populated where the vehicle is identified as a coach or minibus, or Other, and the field is relevant to the vehicle type. For Vehicle New: For Vehicle Amend: For Vehicle Delete: Preferred. Preferred. Not Applicable. Page 62 of 68

NUMBER: NAME: DEFINITION: EL0079 Gross Vehicle Weight The Gross Vehicle Weight of the vehicle, measured in tonnes. LENGTH (CHARACTERS): 5 USAGE: FORMAT: PRECISION: AN VALIDATION RULES AND COMMENTS: Should only be populated where the vehicle is identified as a heavy or light goods vehicle or Other, and the GVW is relevant to the vehicle type. For Vehicle New: For Vehicle Amend: For Vehicle Delete: Preferred. Preferred. Not Applicable. Page 63 of 68

NUMBER: NAME: DEFINITION: EL0081 Vehicle Type Identifies the type of vehicle e.g. car, commercial vehicle. LENGTH (CHARACTERS): 20 USAGE: FORMAT: PRECISION: AN VALIDATION RULES AND COMMENTS: If supplied, must be one of the following: Trade Plate, Private Car, Motorcycle, Coach/Minibus, Commercial Veh/Van, Agricultural, Plant, Motor Home, Other. Vehicle Type Agricultural will include tractors, combine harvesters, forage harvesters, and quad bikes. Vehicle Type of Plant should include JCB diggers, teleporters and telehandlers. Taxis should be shown as Vehicle Type Private Car where they are private cars or people carriers (i.e. they are licensed to carry up to 7 people excluding the driver); taxis licensed to carry 8 people or more should be shown as Vehicle Type Coach/minibus. A Vehicle Type of Other has been included for those vehicles that cannot easily be associated with any other Vehicle Type. For Vehicle New: For Vehicle Amend: For Vehicle Delete: Preferred. Preferred. Not Applicable. Page 64 of 68

NUMBER: NAME: DEFINITION: EL0082 Trade Plate Indicator Identifies the VRM as being a trade plate. LENGTH (CHARACTERS): 1 USAGE: FORMAT: PRECISION: A VALIDATION RULES AND COMMENTS: Must be T if the VRM is a trade plate, or else U. This indicator will identify the Vehicle Registration Mark as being a Trade Plate. The VRM will be passed through Car Data Check for validation. Where the Trade Plate Indicator has been set to T, a warning message will be generated to say that the VRM has not been found but will also state that the VRM has been submitted as a Trade Plate. For Vehicle Record New: For Vehicle Record Amend: For Vehicle Record Delete: Mandatory. Mandatory. Not Applicable. Page 65 of 68

NUMBER: NAME: DEFINITION: EL0083 Error Level An indicator to differentiate between policy level errors and vehicle level errors on the reject record. LENGTH (CHARACTERS): 1 USAGE: FORMAT: PRECISION: A VALIDATION RULES AND COMMENTS: Will be either V = vehicle level, or space for file level. For All Files: Not Applicable. Page 66 of 68

Appendix E - single day addition (SDA) This is an important announcement on MID functionality to fleet and motor trade policyholders whose policy expires and renews on the same date with the same insurer (e.g. Expiry Date 30/06/2006 and Renewal Date 30/06/2006 typically a mid-day to mid-day policy period) and have agreed with their insurer that their vehicles will be copied over to the renewed policy period at the point of policy renewal. Please note this does not affect policies which are renewed the day after expiry (e.g. Expiry Date 30/06/2006 and Renewal Date 01/07/2006 - typically a midnight to midnight policy period). The Issue Prior to the policy renewal record being submitted by the insurer, some policyholders are submitting new vehicle records as a single day addition (SDA) VRM with On-date and Off-date which match the Expiry Date of the current policy period, in the belief that the VRM will be copied over to the renewed policy period when the insurer loads the policy renewal record. The above practice will not result in the vehicle being applied to the renewed policy; it will only appear as a vehicle on cover for a single day on the Expiry Date of the current policy. Policyholders are strongly advised not to adopt the practice described above but to wait until the insurer has applied the policy renewal before attempting to add a new vehicle to the renewed policy. What is the impact on policyholders if they have been applying this practice? If policyholders have been applying the above practice then those vehicles will not appear on MID and will be flagged to the police as potentially being uninsured. Therefore, there is likelihood that they will be stopped by the police if they pass an ANPR camera and potentially they could have their vehicle impounded if they can t provide proof of insurance at that time. In addition they will not be able to renew their vehicle licence via the DVLA s Electronic Vehicle Licensing (EVL) system. If policyholders think they have been adopting the above practice then they should log on to MIDUpdate and check that their vehicles are on cover for the correct period and show the correct vehicle details. Similar amend issue A similar issue will occur if policyholders amend the vehicle details (for example change the colour of the vehicle) to be effective from the current Expiry Date of the policy in advance of the expiry/renewal date. In this case their VRM will NOT trigger the ANPR cameras for being uninsured, but they will not be able to use the DVLA EVL system to tax their vehicle. If policyholders think they have been adopting the above practice then they should logon to MIDUpdate and check that their vehicles are on cover for the correct period and show the correct vehicle details. Page 67 of 68

Policyholder best practice advice The following practices should be adopted by policyholders: To add a new vehicle to the renewed policy period ONLY Policyholders must always wait until they can load the VRM for the full cover period required. They can check if the renewal has been loaded to the MID by looking on MIDUpdate. If there is no renewal showing, or when trying to add the VRM an error is generated due to the renewed policy not yet having been loaded, then the policyholder should wait until the renewal date and look again. If the renewed policy is not present on the renewal date then the policyholder should contact their insurer and ask when the renewed policy is likely to be loaded to the MID. Once the renewed policy has been loaded by the insurer the policyholder can add the new vehicle with the correct dates for the cover period. To add a new vehicle to the current policy period ONLY Policyholders should submit the VRM with the On-date set to the date on which they want the cover period to begin within the current policy period and set the Off-date to the date that cover is to cease within the current policy period. If the vehicle will actually come off cover on the current Expiry Date; once the policy renewal has been applied, the policyholder will have to remove the vehicle s renewed cover period, as it will have automatically rolled forward at policy renewal. However there is an exception to this rule please refer to the following practice on To add an SDA on the expiry date of the policy. To add a SDA on the expiry date of the policy If the intention of the policyholder is to simply apply a SDA on the policy Expiry Date then submit the VRM with its On-date and Off-date equal to the policy Expiry Date. For the avoidance of doubt, to submit SDAs that are not for the policy Expiry Date, policyholders should simply submit the VRM with the On-date and Off-date equal to the date they wish the SDA to be applied. SDAs for the renewal period can only be applied once the policy has been renewed. To add a new vehicle to the current and renewed policy period If the policy renewal has not yet been loaded onto the MID, policyholders should submit the VRM with the On-date set to the date on which they want the cover period to begin within the current policy period and set the Off-date to the policy Expiry Date. The VRM will then be copied over to the Expiry Date of the renewed policy when this is added. If the policy renewal is already present on the MID (i.e. it can be seen on MIDUpdate) policyholders can set the VRM Off-date to the renewal Expiry Date if they wish. However, there is an exception - when the On-date of the vehicle is meant to be the Expiry Date of the current policy and the Expiry Date in the policy renewal period. In this case, policyholders must always wait until they can load the VRM for the full cover period required. They can check if the renewal has been loaded to the MID by looking on MIDUpdate. If there is no renewal showing or when trying to add the VRM an error is generated due to the renewed policy not yet having been loaded then the policyholder should wait until the renewal date and look again. If the renewed policy is not present on the renewal date then the policyholder should contact their insurer and ask when the renewed policy is likely to be loaded to the MID. Page 68 of 68