Main Document
Experian Ltd
Motor Insurance Database
Functional Specification
Version 2.4
Main Document
MID Functional Specification
© Experian Ltd
Page 1
22 August 2001
Version 2.4
Main Document
Document History
Motor Insurance Database Functional Specification
Version Control Sheet
Date of
Issue
30/06/00
Document
Version
Version 2.1
Sections
Affected
Section 1.3
30/06/00
Version 2.1
Section 3.9
30/06/00
Version 2.1
Section 3.12
30/06/00
Version 2.1
Appendix A
30/06/00
Version 2.1
Appendix D
30/06/00
Version 2.1
Appendix A
30/06/00
Version 2.1
Appendix D
30/06/00
Version 2.1
Appendix A
30/06/00
Version 2.1
Appendix A
30/06/00
30/06/00
30/06/00
Version 2.1
Version 2.1
Version 2.1
Appendix B
Appendix B
Appendix D
04/08/00
Version 2.2
Section 3.7
04/08/00
Version 2.2
Section 5.1
04/08/00
Version 2.2
Appendix A
MID Functional Specification
© Experian Ltd
Amendment Details
Amend the dates in Section 1.3 Key
Implementation Dates to match those in Section
7.0 Project Plan/Timescales.
Amend the 4th paragraph of Section 3.9
Cancellations, Lapses, Vehicles Laid Up and Reinstatement of Cover to clarify that the Short
Form Record may be used for cancellations and
lapses, as well as deletions.
Under Section 3.12 Renewals, amend Option 2 to
make clear that MTAs are not treated in the same
way as under Option 1.
On the Policy Record, amend Address Lines 2 - 6
to O, under Man/Pref/Optnl/Condt.
On the Policy Record, amend Additional Drivers
Indicator to O, under Man/Pref/Optnl/Condt.
On the Policy Record, amend Vehicle Make and
Model to C, under Man/Pref/Optnl/Condt.
Amend Vehicle Make and Model (EL0017) to
Conditional for Policy New and Policy Amend.
Restate the Validations Rules and Comments.
Add Party Policy Control Count (EL0064) to the
Reject Record.
Add Party Policy Control Count on the Reject
Record as EL0064.
Add Quoteback (EL0053) to the Short Form
Record.
Add Party Policy Control Count (EL0015) to the
Short Form Record.
Delete Data Record Warning Message W003.
Replace the wording under 2. Data Record Errors.
The comment "C = Cancellation" under the
Validation Rules and Comments for Update Type
(EL0009) should be removed, as it contradicts the
first paragraph of Section 3.9.
Additional paragraph for clarification of
processing.
Change to the wording required to clarify the
mechanism(s) for providing access control
functionality.
The field "Record Type" should be in the same
position in each record. Amended to make it the
first field in each record.
Page 2
Amendments
Author
LH
LH
LH
LH
LH
LH
LH
LH
LH
LH
LH
LH
LH
LH
LH
22 August 2001
Version 2.4
Main Document
Date of
Issue
04/08/00
Document
Version
Version 2.2
Sections
Affected
Appendix A
04/08/00
Version 2.2
Appendix A
04/08/00
Version 2.2
Appendix A
04/08/00
Version 2.2
Appendix A
04/08/00
Version 2.2
Appendix B
04/08/00
Version 2.2
Appendix D
30/09/00
Version 2.3
Section 3.3
30/09/00
Version 2.3
Section 3.8
30/09/00
Version 2.3
Section 3.9
30/09/00
Version 2.3
Section 3.12
30/09/00
Version 2.3
Section 3.19
30/09/00
Version 2.3
Sections 4.1
4.3 4.4
30/09/00
Version 2.3
30/09/00
Version 2.3
Section 5.1
Appendix C
Appendix A
30/09/00
30/09/00
Version 2.3
Version 2.3
Appendix B
Appendix C
30/09/00
Version 2.3
Appendix D
MID Functional Specification
© Experian Ltd
Amendment Details
Amend status of "Excluded Driver" as shown on
Appendix A from Mandatory to Optional. This
will bring Appendix A into line with Appendix D,
EL0058.
The Record Type on the Short Form Record
should refer to EL0008 and have a value of "E".
at present it has a value of "X" which should only
apply to the Record Type on the Reject Record.
The "Cancellation/Lapse Indicator" should have
status "C" and not "M" to be in line with EL0025
in the Short Form Record (Appendix A).
Add the field "Foreign Registration Indicator" to
the Short Form Record (Appendix A).
An error type needed for a wrong record count in
the Trailer Record.
Amend Record Type (EL0008) to incorporate the
change of value to Record Type on the Short
Form Record (Appendix A).
Clarification of references to Records and Record
Sets.
Clarification of records available to view through
enquiry system and of temporary change
processing.
Clarification of records available to view through
enquiry system and of re-instatement of laid-up
vehicles.
Amendment to allow renewal options at
insurer/site level.
Clarification of auto renewal process including
leap year processing.
Definition of length of text for expansion of
Permitted Driver and Class of Use codes.
Amendment to search processing, searches now
by VRM and date. Clarification of policies
available to view through enquiry system. Change
to policy details to be displayed, no dates will
now be displayed unless the policy shown is the
insurers own. (see changes to Appendix E)
Change to Insurer Id list to be used by the system
Addition to Policy Record layout to show the
level (Policy or Vehicle) at which each data item
is held.
Change to reject Record format. (see changes to
Appendix D)
New Error and Warning Codes added.
Instep Code List 81 removed (see change to
Section 5.1)
Registration Mark Formats List updated to
include all possible variations acceptable.
New data elements EL0065 and EL0066 added.
Clarification of data items EL0023, EL0036,
EL0046, EL0062.
Change to EL0064.
Page 3
Amendments
Author
LH
LH
LH
LH
LH
LH
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
MM
22 August 2001
Version 2.4
Main Document
Date of
Issue
30/09/00
Document
Version
Version 2.3
Sections
Affected
Appendix E
30/09/00
Version 2.3
Appendix G
2/10/00
Version 2.3
Section 3
2/10/00
2/10/00
20/10/00
Version 2.3
Version 2.3
Version 2.3
Appendix A
Appendix G
Appendices
F, H and I
20/10/00
Version 2.3
Appendix A
20/10/00
Version 2.3
Appendix D
20/10/00
Version 2.3
Appendix B
22/08/01
Version 2.4
Appendices
A, B, D and
G
MID Functional Specification
© Experian Ltd
Amendment Details
Amendment to search processing, searches now
by VRM and date. Change to policy details to be
displayed, no dates will now be displayed unless
the policy shown is the insurers own.
Sample Police Message removed until further
notice. Message contents under discussion with
Police
Amend wording of 3.8, 3.9, 3.10 to show
effective delete by same effective date
amendment
EL0036 - Change from M to C
EL0062 - Add Fire Only
Amend these appendices of the Functional
Specification to be Version 2.3. This involves a
change to the Title Page, to the Footer (version,
date) and to the file name (where distributed
electronically).
Correct errors as follows:
1. Several of the fields in the Reject File Format
had been removed in error. An amended
version of Appendix A has been issued. This
version re-issues with those changes.
2. The text for the Short Form record (3 rd para
of Input File Format) should show a
cancellation record as Update Type "A"
Appendix D - changes to text for EL0012,
EL0015, EL0021, EL0022. Change to type and
length for EL0066. Additional text for EL0063
(1) EL0012 DA Id - clarification about the value
that should be set by Insurers, and change of
Validation Rules to "Mandatory"
(2) EL0015 PPCC - is Mandatory for Delete, and
for Cancellations / Lapses
(3) EL0021 Effective Start Date - Mandatory for
Deletes, Cancellations and Lapses
(4) EL0022 Effective Start Time - clarify that
this is not used to determine effective date
(5) EL0066 Experian Reject Reference - should
be 35 chars and type AN, as per Appendix A
(6) EL0063 Additional Drivers Indicator include text that it must not be set unless all 6
driver positions have already been filled
Include 4 extra error codes - E049, E050, E051
and E052
(1) E049 - Attempted back-dated amendment not
allowed
(2) E050 - No match for Delete
(3) E051 - Incorrect additional driver indicator
(4) E052 - Short form cancellation with a future
date
All reference to “Driving Other Cars” has been
amended to “Driving Other Vehicles”.
(CR38)
Page 4
Amendments
Author
MM
MM
IW/RG
IW/RG
IW/RG
IW
IW
IW
IW
LH
22 August 2001
Version 2.4
Main Document
Date of
Issue
22/08/01
Document
Version
Version 2.4
Sections
Affected
Appendices
A and D
Amendment Details
Inconsistencies have been corrected as follows:
Amendments
Author
LH
In Appendix D, the format of EL0018 Vehicle
Instep Code has been amended from AN to N.
The Validation Rules and Comments have been
amended to state must be zero-filled if not
present.
In Appendix D, Validation Rules and Comments
have been amended for EL0027 Policyholder
Date of Birth and EL0047 Named Driver Date of
Birth to state must be zero-filled if not present.
22/08/01
Version 2.4
Section 3.19
22/08/01
Version 2.4
Appendix E
Appendix F
22/08/01
Version 2.4
Appendix B
In Appendix A, EL0062 Vehicle Cover Type has
been amended from A to AN.
(CR39)
Section 3.19 has been amended to reflect that
delegated authorities may have their own specific
Class of Use and Permitted Driver code lists.
Where the term “insurers” is used, this has been
amended to “insurers or delegated authorities”.
(CR41)
The enquiry screens have been included in
Appendix E. The MIB and MIIC screens in
Appendix F have been incorporated into
Appendix E.
(CR42)
Included 8 new error codes for insurers and
delegated authorities:
E056 Additional driver indicator not Y or space
E057 Duplicate vehicles in policy set
E058 More than one trailer record
E059 More than one header record
E060 Trailer record not found
E061 Header record not found
E063 Cancellation/lapse for unknown vehicle
E064 Cancellation/lapse for different number of
vehicles
LH
LH
LH
Amended wording to E030 from “Driving other
cars not Y or N” to “Driving other vehicles not Y
or N or for Companies not Space”
22/08/01
Version 2.4
Section 4.2
Appendix G
MID Functional Specification
© Experian Ltd
The following error codes are for Police use only:
E053 Invalid transaction ID
E054 Invalid enquiry date
E055 Enquiry date may not be in the future
E062 Invalid message length
E065 Same VRM enquired on more than 5
successive times
(CR43)
An example Police message has been included in
Appendix G. The wording in Section 4.2 has
been amended to reflect this.
(CR44)
Page 5
LH
22 August 2001
Version 2.4
Main Document
Date of
Issue
22/08/01
Document
Version
Version 2.4
Sections
Affected
Appendix D
22/08/01
Version 2.4
Section 3.19
Section 4.2
Appendix C
Amendment Details
The Validation Rules and Comments have been
amended for EL0022 Effective Start Time and
EL0024 Time of Expiry.
(CR46)
The wording has been amended to reflect changes
to Class of Use and Permitted Driver descriptions.
This is to allow for easier readability by the
Police:
Amendments
Author
LH
LH
Section 3.19 has been amended to include a
description of the process for translation.
Section 4.2 has been amended to describe what
the Police will see.
22/08/01
Version 2.4
Section 4.4
Section 5.2
22/08/01
Version 2.4
Appendix B
22/08/01
Version 2.4
Section 4.1
22/08/01
Version 2.4
Appendix I
22/08/01
Version 2.4
Section 3.8
Section 3.9
Appendix B
Appendix C has been amended to include the
reduced set of descriptions.
(CR47)
Placeholder required for the interface to the eseries XML servlet for MIB and MIIC.
Reference is made to the MID – MIIC/MIB
Version Functional Specification V1.2.
(CR49 & 53)
Validation has been included to prevent policies
being loaded to the database where the expiry
date is earlier than the effective date. A new error
code has been added to Appendix B:
E067 Expiry date earlier than effective date
(CR50)
The enquiry screens have been amended to allow
the input of a foreign vehicle registration mark.
The wording in Section 4.1 has been amended to
reflect this.
(CR51)
Example Management Information reports have
been added to Appendix I.
(CR55)
Wording has been amended in Sections 3.8 and
3.9 to indicate that backdated cancellations will
be accepted, provided that the short form record
format is used.
LH
LH
LH
LH
LH
New error code has been included in Appendix B
as follows:
E066 Long form cancel/lapse cannot be
backdated
(CR57)
MID Functional Specification
© Experian Ltd
Page 6
22 August 2001
Version 2.4
Main Document
Date of
Issue
22/08/01
Document
Version
Version 2.4
Sections
Affected
Section 6.4
Appendix B
22/08/01
Version 2.4
Section 3.9
22/08/01
Version 2.4
Appendix C
Appendix D
MID Functional Specification
© Experian Ltd
Amendment Details
Wording in Section 6.4 has been amended to
indicate that warning message W001 Vehicle
Registration Mark Not Found will be suppressed
for VRMs in a valid Channel Islands or Isle of
Man format.
Note has also been added to W001 in Appendix
B.
(CR58)
Wording has been amended to clarify that future
dated cancellations must use long form record
format.
(CR60)
Note has been added to Appendix C, and
Validation Rules and Comments amended in
Appendix D for EL0016 to state that VRMs
should be supplied in upper case. If they are
supplied in lower case, Experian will convert
them to upper case.
(CR67)
Page 7
Amendments
Author
LH
LH
LH
22 August 2001
Version 2.4
Main Document
CONTENTS
1.0
1.1
1.2
1.3
2.0
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
3.0
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
3.17
3.18
3.19
4.0
4.1
4.2
4.3
4.4
5.0
5.1
5.2
6.0
6.1
6.2
6.3
6.4
6.5
6.6
MANAGEMENT SUMMARY .............................................................................................................. 11
SCOPE OF THE PROJECT ......................................................................................................................... 11
OBJECTIVES OF THE DATABASE............................................................................................................. 13
KEY IMPLEMENTATION DATES .............................................................................................................. 13
TELECOMMUNICATIONS................................................................................................................. 14
COMMUNICATIONS ................................................................................................................................ 14
DIAL UP ACCESS ................................................................................................................................... 14
LEASED LINE CONNECTION ................................................................................................................... 14
FILE TRANSFER ..................................................................................................................................... 15
SECURITY .............................................................................................................................................. 15
ENQUIRY SYSTEM ................................................................................................................................. 16
SERVICE AVAILABILITY ........................................................................................................................ 16
NETWORK CUSTOMER SERVICE (SYSTEMS HELP DESK) ....................................................................... 16
DATABASE SYSTEM OVERVIEW ................................................................................................... 17
DATA SUPPLY........................................................................................................................................ 17
DATA INTEGRITY................................................................................................................................... 17
DATA LOADING ..................................................................................................................................... 17
ADDING NEW POLICIES TO THE DATABASE ........................................................................................... 18
REJECT RECORDS ................................................................................................................................... 19
REJECTS AND MULTI-VEHICLE POLICIES .............................................................................................. 20
UPDATE PROCESSING ............................................................................................................................ 20
AMENDMENTS TO POLICIES ON THE DATABASE .................................................................................... 21
CANCELLATIONS, LAPSES, VEHICLES LAID UP AND RE-INSTATEMENT OF COVER ................................ 22
DELETING POLICIES ON THE DATABASE ................................................................................................ 24
PARTY POLICY CONTROL COUNTS ........................................................................................................ 24
RENEWALS ............................................................................................................................................ 26
QUALITY ASSURANCE ........................................................................................................................... 27
PREFERRED FIELDS................................................................................................................................ 28
FIELDS FOR FUTURE USE ....................................................................................................................... 29
ARCHIVING............................................................................................................................................ 29
AUDIT TRAIL ......................................................................................................................................... 29
NAMED DRIVERS ................................................................................................................................... 30
CODE LISTS ........................................................................................................................................... 31
DATABASE ENQUIRY OVERVIEW ................................................................................................. 32
ON-LINE ENQUIRY ................................................................................................................................. 32
POLICE ACCESS ..................................................................................................................................... 33
INSURER ACCESS ................................................................................................................................... 33
MIB/MIIC ACCESS ............................................................................................................................... 34
ACCESS CONTROL ............................................................................................................................. 35
SUPPLY OF INFORMATION .................................................................................................................... 35
ENQUIRY ACCESS CONTROL.................................................................................................................. 36
MANAGEMENT REPORTING ........................................................................................................... 41
DATA SUPPLY CONTROL REPORT .......................................................................................................... 41
TIME TAKEN TO SUPPLY DATA TO THE MID ......................................................................................... 41
TIME TAKEN TO CANCEL/LAPSE A RENEWED POLICY ........................................................................... 41
CAR DATA CHECK EXCEPTION REPORT .................................................................................................. 42
DUPLICATE RECORDS ............................................................................................................................ 42
NUMBER OF ENQUIRIES ......................................................................................................................... 42
MID Functional Specification
© Experian Ltd
Page 8
22 August 2001
Version 2.4
Main Document
6.7 NUMBER OF ENQUIRIES BY ACCOUNT NUMBER......................................................................................... 42
6.8
NUMBER OF PNC ENQUIRIES ................................................................................................................ 43
6.9
TIMING OF ENQUIRIES ........................................................................................................................... 43
6.10 VRMS WITHOUT CURRENT COVER ....................................................................................................... 43
6.11 SEARCH ON VRMS BY PREVIOUS INSURER........................................................................................... 43
7.0
7.1
7.2
7.3
7.4
7.5
7.6
8.0
8.1
8.2
8.3
PROJECT PLAN / TIMESCALES ...................................................................................................... 44
MID DETAILED PROJECT PLAN / REPORTING OF PROGRESS .................................................................. 44
MODIFICATIONS TO THE MID PROJECT PLAN........................................................................................ 44
MID PROJECT PLAN .............................................................................................................................. 45
MID INSURER PROGRESS CHECKLIST OVERVIEW ................................................................................. 47
MID MILESTONES ................................................................................................................................. 49
MID DELIVERABLES ............................................................................................................................. 51
CHANGE CONTROL ........................................................................................................................... 53
OVERVIEW ............................................................................................................................................ 53
CHANGE CONTROL PRIOR TO IMPLEMENTATION ................................................................................... 53
POST IMPLEMENTATION ........................................................................................................................ 54
MID Functional Specification
© Experian Ltd
Page 9
22 August 2001
Version 2.4
Main Document
APPENDICES
Appendix A .............................. Input File Format, Reject File Format and Short Form Record
Appendix B ..................................................................................... Input File Error Conditions
Appendix C .................................... Instep Code Lists and Vehicle Registration Mark Formats
Appendix D ................................................................. Data Item Update and Validation Rules
Appendix E ........................................................................................................ Insurer Screens
Appendix F ........................................................................................... MIB and MIIC Screens
Appendix G ........................................................................................ Example Police Message
Appendix H ................................ Change Request Form and Change Request Evaluation form
Appendix I ................................................................................ Example Management Reports
MID Functional Specification
© Experian Ltd
Page 10
22 August 2001
Version 2.4
Main Document
1.0 Management Summary
The motor insurance industry has suffered an ever-increasing financial burden due to the
problem of uninsured driving, in terms of paying compensation to the victims of accidents
involving such drivers and the loss of premium income. At the same time, government
pressure has increased on the industry to implement a suitable solution to tackle this problem.
After consideration, the motor insurance industry, including the Motor Insurers’ Bureau,
concluded that the way forward was to build a database, containing details of all insured
drivers and their policy details, which could be accessed by the police at the roadside, in
order for them to determine whether or not a person had current insurance and thereby aid
enforcement of the law.
This document defines the functionality that will be available within the Motor Insurance
Database, communications to and from the system, and the planned development and
implementation schedule.
1.1
Scope of the Project
The initial aim of the Motor Insurance Database is to include all records of
“individually insured vehicles”, that is vehicles which are not insured as part of a
blanket policy. By definition this excludes most fleets and motor trader policies.
Establishing the insurance position on these vehicles will be the subject of a separate
exercise required to implement the Fourth EU Motor Directive which will require that
provision be made for the identification of the insurer of all vehicles via the VRM.
The database will be capable of holding the record of any insurance policy as long as
it contains the VRM of the vehicle insured and other key details of the policy cover.
Rather than try to impose a strict definition of “individually insured vehicles”, the
principle will be that all vehicles which are identifiable by VRM on a policy should
be included. Insurers will be expected to submit details of all policies which can be
accommodated, irrespective of the policy and vehicle type.
MID Functional Specification
© Experian Ltd
Page 11
22 August 2001
Version 2.4
Main Document
Insurers will not be required to convert existing multiple-vehicle policies into
individual policies.
Policy “sets”, relating to more than one vehicle, should be
submitted as separate records for each vehicle, even if the policy number is the same.
Insurers should note that they will be responsible for the provision of the required
details even if that data is captured and maintained by another party on their behalf
(delegated authority business). It may be, however, that the delegated authority is
responsible to the insurer for the direct transmission of the required data to the
database and its subsequent maintenance.
As regards geographic scope, insurers are required to provide information on all
vehicles registered within the United Kingdom. Submission of details for vehicles
registered in the Channel Islands and the Isle of Man is not compulsory at this stage.
It is recognised that in many cases it may not be straightforward for insurers to
identify and block the sending of data pertaining to such vehicles. At present the
police have no legal right to view details of these policies and consequently provision
will be made to block police enquiries against such vehicles for the time being.
Insurers and the MIB will be able to search on Northern Ireland vehicles immediately
(with the remainder being blocked for the time being).
In the absence of a common approach within the insurance industry to the provision
of temporary cover, it is accepted that, again for the time being, where a temporary
adjustment is provided without being recorded on the insurer’s own computer system,
then such cover is out of scope.
Enquiry access will be built to the database for the police, MIB, MIIC and insurers to
gain access to the information. The database will only be available to UK mainland
police. Similarly, only UK mainland-registered vehicles will be available for the
police to enquire upon, but insurers will be able to enquire on any vehicle on the
database.
MID Functional Specification
© Experian Ltd
Page 12
22 August 2001
Version 2.4
Main Document
1.2
Objectives of the Database

To provide the police with information to enable them to determine whether
insurance is in force.

Identification of third party insurers, by the MIB, MIIC and motor insurers. This
will be required by law when the EU Fourth Motor Directive comes into force.

Ultimately to allow the DVLA to confirm that insurance is in force, for electronic
licensing purposes. This will form part of the next phase of development of the
database.
1.3
Key Implementation Dates

Insurers ready for testing
November 2000 – December 2000

Database load
January 2001 – February 2001

Database go-live
July 2001
Please refer to Section 7.0 Project Plan/Timescales for further details.
MID Functional Specification
© Experian Ltd
Page 13
22 August 2001
Version 2.4
Main Document
2.0 Telecommunications
2.1
Communications
Communications are supported via LU6.2, LU2 (3270), LU6.1, LU6.0, NJE, RJE,
X25 and TCP/IP protocols. FTP will also be supported, subject to security clearance.
The IBM Value Added Network supporting Information Exchange will also be
available. Experian currently has over 300 links of this type, supporting or emulating
the above. In addition, magnetic tape, cartridge and diskette can also be supported.
These links interface with a wide range of platforms including:
Data General
IBM 3174 and compatibles
DEC
IBM ES/9000, 3090, 3084, 3081
Honeywell Bull
IBM AS/400
ICL
IBM System 36, 38 and 88 (Stratus)
LAN – Token Ring and Ethernet
IBM 8100
NCR
Unisys
Unix devices
Tandem
PCs
2.2
Dial Up Access
Customers can dial Experian direct using PCLink5, Experian’s own 3270 emulation
package.
2.3
Leased Line Connection
Experian supports communications via a leased line, with speeds ranging from 9K
BPS to 64K BPS.
MID Functional Specification
© Experian Ltd
Page 14
22 August 2001
Version 2.4
Main Document
2.4
File Transfer
Files may be supplied in either ASCII (PC format) or EBCDIC (Mainframe format).
File transfer via leased lines is available using XCOM 6.2, NJE, RJE or CONNECT
DIRECT. These are IBM mainframe packages but will also work on PC, AS400,
Windows NT and Unix hardware. TCP/IP and FTP will be available, subject to
security clearance.
The IBM Value Added Network supporting Information Exchange will also be
available.
File transfer using a dial up connection can be made via the IBM Global Network.
Any clients who do not have access to this could be supplied with AVCO software.
Experian would supply the software and set up any scripting required. Encryption
and compression are built into this software as standard.
2.5
Security
All necessary steps will be taken to ensure that only valid users gain access to the
system by using full user ID/password protection.
The systems operating
environment will be secured via the utility package TOP SECRET, supplied by
Computer Associates.
All transactions will be further secured using an Experian package called MARS
(Multiple Application Routing System) which ensures that all Experian mainframe
access is authorised.
MID Functional Specification
© Experian Ltd
Page 15
22 August 2001
Version 2.4
Main Document
2.6
Enquiry System
Screens will utilise standard 3270 format, or Web Browser, subject to cost. The
information available on the Browser will be the same as that on the 3270 screen.
2.7
Service Availability
The system will be available 24 hours a day, 365 days a year (366 days in a leap
year).
Experian operates 4 IBM compatible mainframes situated at 2 separate sites 5 miles
apart in Nottingham, connected by fibre optic cables.
Response time targets are set out below:
Time Band (seconds)
Cumulative % of Response
Up to 1
90
Up to 2
95
Up to 3
98
Up to 4
99
The response times do not include any communication times outside of the Experian
environment.
2.8
Network Customer Service (Systems Help Desk)
Network, communications or systems availability issues will be dealt with by
Experian’s Network Customer Service Helpdesks, based in Nottingham and
Aldermaston. Service level agreements are to be confirmed.
MID Functional Specification
© Experian Ltd
Page 16
22 August 2001
Version 2.4
Main Document
3.0 Database System Overview
3.1
Data Supply
Participating insurers will supply data to Experian by electronic transfer, tape, cartridge or
diskette, in a standard format (see Appendix A). Insurers may, by agreement, arrange for
delegated authorities to submit data to the database on their behalf.
Insurers will supply data on a minimum weekly, or maximum daily basis. Experian will
endeavour to update valid data within 12 hours if received by electronic transfer, and
within 24 hours for all other means. Data supplied to Experian will at all times remain
the property of the supplying insurer.
3.2
Data Integrity
Validation checks will be required to ensure that the details submitted by insurers for
update are valid. There will be checks to ensure that mandatory data items are complete,
that codes are valid, and that cross validation checks are satisfied. Details of input file
error conditions are shown in Appendix B, and details of all mandatory and preferred data
items are shown in Appendix D.
3.3
Data Loading
Data supply schedules will be agreed between Experian and individual insurers and must
be strictly adhered to whenever possible. Every supplier will provide an initial load file
with details of all policies currently in force. Following the initial load, suppliers will
provide update files containing previously supplied records that have changed and details
of new policies. The same input file format will be used in all media, and for both the
initial load and the later updates.
MID Functional Specification
© Experian Ltd
Page 17
22 August 2001
Version 2.4
Main Document
The input file format will have 3 valid “update types”: New, Amend and Delete. In the
initial load file, every policy record will be New. Update files may include records of
every update type. Policy records will include a number (up to a maximum of 6) of sets
of Named Driver details.
For multi-vehicle policies, that is if a policy contains several vehicles under a single
policy number, then the insurer will submit one record for each vehicle. The unique
combination of policy number and vehicle registration mark (VRM) will identify each
record on the database.
For example, if VRMs R123 ABC, R456 DEF and R789 GHK are insured under the
policy number AN123456789, then the insurer will submit 3 separate records: the first
record would show policy number AN123456789 and VRM R123 ABC, the second
record would show the same policy number and VRM R456 DEF, and the third record
would show the same policy number and VRM R789 GHK.
In the remainder of this document, the term “Record” should be taken, when
considering policies with multiple vehicles, to refer also to “Record Sets”.
In
particular, validation (and therefore possible rejection) applies to entire record sets,
not just individual records (please refer also to section 3.6).
3.4
Adding New Policies to the Database
Details of policies which have never before been notified to the MID will be supplied as
New. For example, when an insurer writes a new policy it will be submitted to the MID
as a record with update type New. The Effective Start Date will be the date that the
insurance cover commenced.
The record will be put through a validation process to confirm that all mandatory fields
are populated with valid data. If the record passes validation then it will be loaded to the
MID. If the record is rejected then a reject record (see Appendix A) will be sent back to
the insurer in order that the record may be amended and re-sent.
MID Functional Specification
© Experian Ltd
Page 18
22 August 2001
Version 2.4
Main Document
There may be circumstances when the record may fail validation but will still be loaded
to the database and a warning message generated, which will be sent to the insurer with
the reject records. (See Appendix B for input file error conditions).
The VRM in every new record supplied to the MID will be looked up on Car Data Check
at the time of file validation. Full Car Data Check details will not be available to view,
but records will be flagged as exceptions if the input VRM is not found on Car Data
Check, or is listed there as belonging to a vehicle that has been scrapped or exported.
These records will be accepted and loaded to the database if they pass all the other
standard validation. In this instance, a warning record will be sent to the insurer
along with any reject records.
3.5
Reject records
Experian will maintain, as part of the database control structures, a figure for the expected
acceptance rate across all insurers. These thresholds will be set before the supply of live
data begins. The thresholds will make it easier to halt processing if an unexpected
problem arises with a particular update file.
For example, the threshold could be set at 96%. If fewer than 96% of the records in any
one update file were accepted, processing would halt until the supplier had confirmed that
the accepted records should be updated to the database.
In some cases, particularly if the acceptance rate is far below the threshold, the supplier
may prefer to cancel the update entirely and re-supply the file. Normally, however, it is
to be expected that the acceptance rate will exceed the threshold, so that accepted records
will be updated to the database, and details of rejected ones returned to the supplier for
investigation, correction, and re-supply.
Files (not paper reports) of reject records, containing the policy number and VRM of the
record rejected, will be returned to each supplier via the same medium (cartridge,
MID Functional Specification
© Experian Ltd
Page 19
22 August 2001
Version 2.4
Main Document
electronic file transfer, etc.) used to send the input files to Experian. Transmission of
reject records will not be available via E-mail. Files of reject records sent from Experian
to a supplier, will not be encrypted.
Details of the reject file format are shown in Appendix A. In the case where a whole
file is rejected, the insurer will be contacted directly by the Experian Customer Help
Desk.
3.6
Rejects and Multi-Vehicle Policies
If the policy contains several VRMs under the same policy number then, just as the
insurer must submit all of the associated records when a record with update type New or
Amend is submitted, then if a single record is rejected, the whole policy set will be
rejected. For example, if 3 vehicles are covered under the same policy record and a
named driver is added for only one of the VRMs, the insurer must submit all 3 records as
update type Amend, even although the change only affects one of the records.
If that record with the additional named driver subsequently fails validation and a reject
record is sent to the insurer then, the other 2 records will be rejected too and the insurer
notified that the policy set has not been loaded and details of the particular record in the
policy set which has failed validation. The whole policy set must be submitted again
when the record has been corrected. That is, all 3 records must be re-sent. Rejects apply
to policy sets and not individual records.
3.7
Update Processing
Changes to policy details or named drivers, and cancellation or lapse of policies will
normally be notified as Amend update types. The insurer will supply a “snapshot” of the
policy record. That is, the complete record as it stands at the date of the change, and not
just the fields that have been amended. In this instance the Effective Start Date will be
the date from which the amended policy record is in force and, therefore, is the current
record. The field Party Policy Control Count applies to how many versions of the policy
MID Functional Specification
© Experian Ltd
Page 20
22 August 2001
Version 2.4
Main Document
record have been sent to the MID and not how many versions have been generated on the
insurer’s own system, or number of records on the database, and will be used to indicate
which version is the most recent where several snapshots are supplied with the same
Effective Start Date. (See Section 3.11 Party Policy Control Counts)
Note that the insurer does not need to establish whether the policy change affects fields
held on the MID. All changes may be sent to the MID.
3.8
Amendments to Policies on the Database
If the policy contains several VRMs under the same policy number, then the insurer must
submit all of the associated records when a record with update type Amend is submitted.
For example, if 3 vehicles are covered under the same policy record and a named driver is
added for only one of the VRMs, the insurer must submit all 3 records as update type
Amend, even although the change only affects one of the records. That is, updates
apply to policies and not individual records.
If a record is loaded to the database with an Effective Start Date in the future, then that
record will not become the current record until the Effective Start Date is reached. For
example, if an insurer generates a record for submission to the MID when running
renewals, which may be several weeks in advance, the record will be loaded to the
database even although the Effective Start Date is some time in the future, but the record
will not be available to view. That is, it will not yet be the current record.
For example, when a policyholder notifies an insurer of a change of address, this
information will be amended on the insurer’s system, and then a complete record will be
submitted to the MID with the changed details. This record will become the current
record on the database with the Effective Start Date indicating the date that the change to
the policy (the policyholder’s new address) came into force.
MID Functional Specification
© Experian Ltd
Page 21
22 August 2001
Version 2.4
Main Document
If a record with the same Effective Date as a record already on the database is submitted
for loading, then the earlier version will not be available to view but will remain on the
database for audit purposes.
Temporary changes should be sent only if currently processed in an insurers system. If
sent, a subsequent amendment must be sent to restore the original details. Note that if an
insurer intends to send temporary changes, they must not choose renewal option 1 (see
Section 3.12 Renewals).
The MID does not currently support backdated amendments. That is to say, the effective
date of an amendment may not be earlier that the effective date of the last policy version
submitted.
The exception to this is a backdated cancellation, provided that this is
submitted via the short form record (see Appendix A). Please refer to the following
Section 3.9.
3.9
Cancellations, Lapses, Vehicles Laid Up and Re-instatement of Cover
If a policy is cancelled or lapsed, the insurer must submit a record with update type
Amend and the appropriate value in the Cancellation/Lapse Indicator field of “C” for
cancelled or “L” for lapsed.
Where a policy has been lapsed, the insurer will submit a policy record with update type
Amend and an “L” in the Cancellation/Lapse Indicator field.
Where a policy has been cancelled, the insurer will submit a policy record with update
type Amend and a “C” in the Cancellation/Lapse Indicator field. If the full policy record
is used the Effective Start Date (i.e., the date when the amendment becomes active) and
the Expiry Date must be the same, (i.e., the date of cancellation).
The insurer will be required to submit one cancellation record per vehicle if the
whole policy set is cancelled.
MID Functional Specification
© Experian Ltd
Page 22
22 August 2001
Version 2.4
Main Document
Note that if an amendment cancels a vehicle from the date that the vehicle was added to
the policy the original record will no longer be available to view. Thus this effectively
serves to delete the vehicle. But see the final paragraph of section 3.8 above.
Where a policy has been cancelled or lapsed, the insurer may choose either to send the
full Policy Record or the Short Form Record. Please see Appendix A for details of these
records.
In instances where a cancellation record is dated in the future (future dated cancellations)
the insurer will need to send the full policy record. This is because short-form records
that have an effective date in the future will be rejected (please refer to Appendix B).
In instances where a cancellation record is dated prior to the current record on the
database (backdated cancellations) the insurer will need to send the short form record.
This is because long form records that have an effective date prior to the current record on
the database will be rejected (please refer to Appendix B).
Where a vehicle has been laid up (i.e. it is not covered for any RTA liability) the insurer
will submit a policy record with update type Amend and the Type of Cover field
populated with the appropriate value. For example, if the field was populated with “04”
the vehicle would be covered against fire and theft only, but there would be no RTA
cover in force for that particular vehicle. (See Appendix D, Number EL0062) Where an
enquiry is made on a vehicle which is laid-up on the date given, no record will be
returned in response to the enquiry.
For those policies where cover is re-instated after cancellation or laying-up, the insurer
would send a policy record with update type Amend and leave the Cancelled/Lapse
Indicator field or vehicle cover type unpopulated. As re-instatement is from the date of
cancellation, this would have the effect of automatically re-instating cover from the
Effective Start Date shown on the Amend policy record.
.
MID Functional Specification
© Experian Ltd
Page 23
22 August 2001
Version 2.4
Main Document
3.10
Deleting Policies on the Database
A Delete option is available to allow insurers to remove a record from the database - for
example, when an incorrect VRM (albeit in an acceptable format) has been supplied.
A record with update type Delete would be submitted to remove the record completely
from the database. In this instance the insurer may choose to send either a full policy
record or a short-form record (see Appendix A for details of these record formats).
For multi-vehicle policies, where Delete is used, the full policy set is not sent - only
the records to be deleted should be sent.
Note that an amendment that cancels a vehicle from the date that the vehicle was added to
the policy effectively serves to delete the vehicle. But see the final paragraph of section
3.8 above.
3.11
Party Policy Control Counts
Party Policy Control Counts are required to ensure that all updates to a policy have been
supplied, and that the updates have been loaded in the correct order to ensure data
integrity on the database. The Party Policy Control Count applies to how many
versions of the policy have been sent to the database and not the number of versions
generated on the insurer’s own system or number of records on the database. Party
Policy Control Counts do not have to start at one.
For example, a record which is loaded to the database for the first time may have a Party
Policy Control Count of “1”. If a change is subsequently made to the record, such as the
policyholder notifies a change of address, the insurer will submit a record with update
type Amend which will be a “snapshot” of the policy with the changed address details.
The Effective Start Date will be the date from which the change takes effect. The Party
Policy Control Count on this Amend record will now be “2”, and illustrates that one
change has been made to the policy since it was originally loaded onto the database.
MID Functional Specification
© Experian Ltd
Page 24
22 August 2001
Version 2.4
Main Document
Where an automatic renewal has been generated, the Party Policy Control Count will not
be incremented by 1. This is because the insurer will not have sent an update to the
database to renew the policy and, as Party Policy Control Count corresponds to the
number of versions of the policy sent by the insurer, an automatic renewal will not cause
the Party Policy Control Count to be incremented as the insurer has not sent an update of
the policy to the database at renewal.
In the case of an automatic renewal where an MTA is made to the record to be applied
before the renewal date, the database will not reject the MTA, because the Party Policy
Control Count will be 1 greater than that on the automatic renewal.
Where a multi-vehicle policy exists, with more than one VRM covered under the same
policy number, and an additional vehicle is being added to the policy, the insurer will
send a policy set of records with update type Amend and the Party Policy Control Count
incremented by 1.
For instance, during the period of cover, the policyholder notifies the insurer of a new
vehicle to be added to the policy. In this instance the insurer must submit all 3 records to
the database as they form a policy set even though 2 of the records remain unchanged
(the 2 records already on the database).
A reject policy record which the insurer has corrected and re-sent to the database should
have the same Party Policy Control Count as the original record, for audit purposes. For
example, a record which is loaded to the database for the first time may have a Party
Policy Control Count of “1”. If a change is subsequently made to the record, such as the
policyholder notifies a change of address, the insurer will submit a record with update
type Amend which will be a “snapshot” of the policy with the changed address details.
The Party Policy Control Count on this Amend record will now be “2”, and illustrates
that one change has been made to the policy since it was originally loaded onto the
database.
However, if the Amend record fails validation, a reject record will be sent to the insurer
in order that the policy record be corrected and re-submitted to the database. This record
MID Functional Specification
© Experian Ltd
Page 25
22 August 2001
Version 2.4
Main Document
should have a Party Policy Control Count of “2”, which is the same Party Policy Control
Count as when the Amend record was first sent to the database, and should not be
incremented by one to give a value of “3”. This is because the insurer is, in essence, resubmitting the reject record and not sending a new record.
3.12
Renewals
There will be 3 possible methods for renewals to be updated on the Motor Insurance
Database. Individual insurers will be able to select in advance of starting to load data one
of the following options, subject to prior agreement with Experian. The options are
available at insurer/site level.
Option 1: Experian will automatically renew policies on the database when they reach
midnight on their expiry date. The insurer will then submit a record to the database if the
policy is subsequently found to have lapsed. If a policy is automatically renewed, the
Party Policy Control Count will not be incremented by 1. (See Section 3.11 Party Policy
Control Counts).
Where a policy is automatically renewed the new expiry date will be set to the current
expiry date plus 1 year i.e. current expiry date 3/3/2001 new expiry date 3/3/2002. To
clarify the position with leap years, where the current expiry date is 29th February the new
expiry date will be 1st March. Where the current expiry date is 28th February and the next
year is a leap year, the new expiry date will still be 28th February. Where the current
expiry date is 1st March and the next year is a leap year the new expiry date will still be 1st
March.
If an insurer chooses to send temporary adjustments to the database they must not choose
this automatic renewal option, as this may result in renewal on the wrong date.
Where an insurer has chosen to have policies renewed automatically, and an individual
policy is not to be renewed, the insurer should submit a lapse record prior to renewal.
The system will therefore recognise the lapse and not renew the policy.
MID Functional Specification
© Experian Ltd
Page 26
22 August 2001
Version 2.4
Main Document
Option 2: Insurers will submit anticipated renewals and will then submit another record
to the database should the policy subsequently lapse. This is basically the same as Option
1; the only difference is that the insurer will send a renewal record to the database rather
than the policies being renewed automatically.
In circumstances when an MTA occurs and is sent to the database after the renewal has
been sent, but the Effective Start Date of the MTA is prior to the renewal date, then the
insurer will need to re-send the renewal.
Option 3: The policy on the database will expire at the end of the policy period and the
insurer will submit a record showing that the policy has been renewed when this has been
confirmed. The insurer will not have to send a lapse record.
Insurers will be able to change in the future to a different renewal option, subject to
giving notice and prior agreement with Experian.
3.13
Quality Assurance
At regular intervals to be agreed, quality and audit checks will be required to ensure
data integrity. These checks will be carried out on individual insurer’s data and
random samples taken from the database, with results reported to MIIC and the
insurers concerned, and will include the following:
1. Checks to ensure that the VRM of cars with current insurance are still valid, i.e.
the vehicle has not been scrapped, exported or the VRM transferred to another
vehicle.
This will be done by validating VRMs against Car Data Check,
Experian’s own vehicle database. By searching on VRM it will be possible to
confirm a vehicle’s identity and specification.
Where a vehicle is identified as having been scrapped, information can be
returned detailing the date it was scrapped, the number of previous keepers and
MID Functional Specification
© Experian Ltd
Page 27
22 August 2001
Version 2.4
Main Document
dates of keeper change. There will be an additional charge, to be advised, for this
service, which will be borne by the insurer concerned.
Where a vehicle is identified as having been exported, information can be returned
detailing the date it was exported, the number of previous keepers and dates of
keeper change and dates of any colour change. There will be an additional charge,
to be advised, for this service, which will be borne by the insurer concerned.
2. Checks to ensure that insurance is not in force with more than one insurer for the
same vehicle for an extended period, e.g. more than 3 months, to prevent fraud
and to check that insurers are keeping records up to date.
3. Checks to ensure that updates are reaching the database within agreed timescales,
e.g. new records being loaded to the database within one month of the insurer
writing the business, to maintain data quality and integrity.
3.14
Preferred Fields
It is recognised that not all insurers will be able at the time of the initial implementation
to supply all the data items that the database really requires. Certain fields in the Policy
record have therefore been designated as preferred, but it is highly desirable that they be
supplied wherever possible.
All insurers and delegated authorities supplying data to the MID are requested to make all
efforts to provide the following “preferred fields”:

Vehicle Make and Model. This may be supplied as code or text, depending on the
format in which it is stored on the supplier’s system: either as an ABI Instep code, or
as a combined make-and-model text field.

Time fields (to add precision to the associated date fields): Effective Start Time,
Expiry Time.

Date of Birth, or Age for cases where the precise date of birth is not held.
MID Functional Specification
© Experian Ltd
Page 28
22 August 2001
Version 2.4
Main Document

Postcode: If possible this should be supplied in the dedicated field, rather than
included in the address lines.
Details of all mandatory and preferred data items are shown in Appendix A.
3.15
Fields for Future Use
Several fields have been built into the Input File Format for future use, and will not be
currently supplied by insurers. Population of these field will not be mandatory.
Insurers wishing to populate these fields and view the data supplied by other insurers
in these fields, will do so on a reciprocal basis, which will not be compulsory.
Any access would only be granted after the relevant legal and commercial
considerations had been fully discussed and agreed.
For details of these fields, please refer to the following in Appendix D: EL0037,
EL0038, EL0039, EL0040, EL0041, EL0042, EL0043, EL0059, EL0060 and
EL0061.
3.16
Archiving
Records will be available on-line for 30 months from date of expiry. The archive will
be retained off-line for 54 months from date of archiving. The method of accessing
the archived data will be determined nearer the time when the prevailing technology
can be determined.
3.17
Audit Trail
For security purposes a full audit trail of all enquiries will be maintained and will be
the subject of periodic reporting. The audit process will utilise TIOA (Terminal Input
Output Area) whereby images of all screens are captured. These images are saved to
MID Functional Specification
© Experian Ltd
Page 29
22 August 2001
Version 2.4
Main Document
disk during the day and then transferred to cartridge overnight. The images are
retrieved via a batch job, which will give a paper print of all screens requested.
In addition, audit information recording the date and time of new records,
amendments to records and deletions to records processed by the system will be held
and available for audit purposes.
3.18
Named Drivers
Up to six Named Drivers may be included in a Policy record. To save space, the
Named Driver fields have been designated as “variably occurring”.
A special
indicator allows the number of Named Drivers to be specified, and the subsequent
Named Driver fields in the record will occur the specified number of times.
The Policyholder may or may not be shown as a Named Driver. If the policyholder is
shown as a named driver, then he must be included in the count entered in the
Number of Named Drivers field.
Any named driver can be excluded from driving under the policy by populating the
Named Driver field, with the Excluded Driver flag set to “E”. If the Excluded Driver
flag is a space, then the Named Driver is permitted to drive under the policy. (See
Appendix D, Number EL0058)
The Input File Format (see Appendix A) allows for up to 6 named driver details to be
displayed. This will be adequate for most policies but there may be occasions when
more than 6 named drivers are covered under the policy. In these circumstances, the
insurer may issue a manual certificate as there are more named drivers than can be
held on the insurer’s system. The insurer will populate the field Additional Drivers
Indicator with “Y” for yes. (See Appendix D, Number EL0063)
MID Functional Specification
© Experian Ltd
Page 30
22 August 2001
Version 2.4
Main Document
When more than 6 named drivers are present on the policy, a message will be
generated for the police to alert them to the fact that there are more named drivers
than can be displayed.
3.19
Code Lists
The Permitted Driver and Class of Use data will be held on the database in coded
form.
The codes will normally be the Instep Code List 13 (for Permitted Driver) and
insurers’ or delegated authorities’ own bespoke code lists for Class of Use. Bespoke
codes can be used in the MID input by special arrangement only: in such cases,
Experian will create special tables for the insurers or delegated authorities concerned.
The supplying insurer’s or delegated authority’s own codes will actually be held on
the MID (since it is likely that in some cases there will be no precise equivalent in the
Instep code lists), and expanded into the insurer’s or delegated authority’s own text
when the data is reported to enquirers.
The codes will be expanded into text, using a special look-up table, for enquiry
purposes. The text allowed for expansion of Permitted Driver and Class of Use codes
is referenced from the MID / Police agreed text, which is listed in a table in Appendix
C. Insurers and delegated authorities must cross-reference their own codes, or those
from Instep Code List 13, to the MID / Police agreed texts.
Code lists can be held at site level but not at branch level.
MID Functional Specification
© Experian Ltd
Page 31
22 August 2001
Version 2.4
Main Document
4.0 Database Enquiry Overview
4.1
On-line Enquiry
On-line enquiry will be made available to the police, insurers and the MIB (Motor
Insurers’ Bureau) 24 hours a day, 365 days a year.
The search key to access
information on the database will be vehicle registration mark and date. The vehicle
registration mark does not have to be in a valid format, as shown in Appendix C.
That is, a foreign vehicle registration mark can be enquired upon, as there are such
vehicles on the database. The search will be carried out with a default time of today’s
date unless a different date has been specified.
Where a record has been superseded by an amendment with the same effective date,
the superseded record will not be shown.
The level of information returned will depend on the status of the enquirer. Details of
data supplied to the database are shown in Appendix A. Insurers will be able to view
all or part of the information depending upon whether or not they are enquiring on
one of their own policies, or that of another insurer.
The police will view all the data supplied to aid them in determining that current
insurance is in force, and the MIB will also view all the data supplied to aid
identification of potentially liable insurers in the event of a claim.
Delegated
authorities may be granted access to view the records they administer on the insurers’
behalf, but only with the express agreement of the particular insurer concerned.
It may be possible in some cases for a vehicle to be insured under 2 separate policies.
For example, if the policyholder has recently changed insurer at renewal, it may be
possible for his new insurer to have submitted the policyholder’s details to the
database before his previous insurer has submitted a lapse record. In this instance,
both policies would be displayed.
MID Functional Specification
© Experian Ltd
Page 32
22 August 2001
Version 2.4
Main Document
If the policyholder has cancelled his cover with an insurer and taken out cover
elsewhere then again, it may be possible for his new insurer to have submitted the
policyholder’s details to the database before his previous insurer has submitted a
cancellation record. In this instance, if both policies had the same Expiry Date, then
both policies would be displayed. However, if the new policy had a later Expiry Date
then that is the record which would be retrieved as the current record, and an option
given to the user to view the other policy record with the earlier Expiry Date.
4.2
Police Access
UK mainland police will have potential access to all records on the database, via an
enquiry which identifies the VRM and the date at which the enquiry should be
targeted.
Experian will supply a message-based system to the police, which they will then
incorporate into their existing screens. An example of a police message is shown in
Appendix G. Note that the insurer’s contact details (e.g. contact name, telephone
number, fax number and email address) will be returned to the police computer should
the police officers wish to contact them.
4.3
Insurer Access
An insurer enquiring on the MID will use the vehicle registration mark and date as the
search key. The policy details that were current at the entered date will be displayed.
There may be more than one policy displayed if more than one policy was current at
the date of enquiry. Where two policies exist where the insurer id, vehicle registration,
policy number, effective start date are the same, the PPCC will be used to decide
which version of the policy is displayed i.e. the version with the highest PPCC. Where
a policy has the same effective start date and expiry date as the entered date i.e. the
policy is cancelled or lapsed, then the policy record will not be shown.
MID Functional Specification
© Experian Ltd
Page 33
22 August 2001
Version 2.4
Main Document
An insurer enquiring on one of their own policies, using vehicle registration mark,
will be able to view the entire record as at the date entered.
An insurer enquiring on a vehicle which is insured by another insurer will be able to
view limited information confirming the vehicle registration mark, policy number and
the name, telephone number, fax number and email address of the insurer. Examples
of insurer screens are shown in Appendix E.
4.4
MIB/MIIC Access
The MIB/MIIC will be able to view all details of the policy in force on the date
entered. Examples of MIB/MIIC screens are shown in Appendix E.
The MIB/MIIC will also be able to utilise an XML (message based) enquiry system.
This will allow the MID to return, when queried, all records held on the MID for a
particular vehicle registration mark, within a set period of time. (Please refer to the
MID – MIIC/MIB Version Functional Specification V1.2)
MID Functional Specification
© Experian Ltd
Page 34
22 August 2001
Version 2.4
Main Document
5.0 Access Control
5.1
Supply of information
The MID system will make use of Experian-assigned Id’s to identify the insurers and
delegated authorities which will have been allocated by the time of database creation. The
list of suppliers will be drawn up by MIIC and supplied to Experian . This list will be
based on Instep Standard Code List 81 wherever possible. Delegated authority and insurer
ID codes will be verified with each individual supplier, well before the supply of live data
to the MID begins.
The keys to the database records are Insurer ID, Delegated Authority ID, Policy Number,
Vehicle Registration Mark, and Effective Date. It is the combination of these fields that
will make each MID record unique.
Both insurers and delegated authorities may wish to split their data supply between
different parts of their organisation. To make this possible, the Header record, which is
used to identify the supplier of an input file, includes a “Site Number” field.
The Header includes a file sequence number, which is used to ensure that all files
produced for the MID actually reach the database. If the sequence number of a file is not
one up on the most recent file received from that supplier, then processing will be
stopped, and either the “missing” file(s) must be located or the original file re-submitted
with the correct sequence number. This file sequencing is controlled at the level of Site
Number, so Experian will also need from every supplier a list of all valid Site Numbers
before the start of live data supply.
It is important to note that Site Numbers are used as a control for file sequencing
purposes, security and the return of reject records. A Site Number – whether for an
insurer or a delegated authority – is validated against the supplier’s list of Site Numbers
only when it appears in the Header record.
MID Functional Specification
© Experian Ltd
Page 35
22 August 2001
Version 2.4
Main Document
5.2
Enquiry Access Control
Online enquiries on the MID will be made by:

The Police

The MIB and MIIC

Insurers

Delegated Authorities
Two levels of access to the database will be supported. Full access will allow the
enquirer to see all details held on the database for that particular vehicle. Limited access
will restrict the information supplied to relevant insurer details.
The Police, the MIB and MIIC will in general be allowed to see full details of all policy
records on the database. Insurers will be able to view full details of their own policies
(and subject to agreement within their own organisation any Group company information)
but will only be provided with limited detail about any third party information.
Where the MIB or MIIC enquire on the MID, via the XML (message based) enquiry
function then, where the VRM is found, full details of all policies found on the database
will be returned. (Please refer to the E-Series Insurance – Motor Insurance Database –
Functional Specification Version 1.2)
Access control will be provided and managed at user level. Each user will be given a
unique user ID and password. That user ID will have an associated authorisation profile
which details exactly what level of access is available to that user.
Within each user profile, the level of access will be controlled using the unique Insurer
and/or Delegated Authority ID’s. The profile will specify for each ID the level of access
(full or limited) that user has to records for that insurer/DA. Therefore, on a user by user
basis, we can control precisely the level of information any particular user has access to.
MID Functional Specification
© Experian Ltd
Page 36
22 August 2001
Version 2.4
Main Document
Supplying insurers must inform Experian in advance of all users who are to be allowed
access to the insurer’s policies.
MID Functional Specification
© Experian Ltd
Page 37
22 August 2001
Version 2.4
Main Document
Scenario Examples
The following table details some examples, as described in the notes following the table, of
particular scenarios that may be applicable in certain circumstances. It should be noted that
these are purely examples and do not necessarily reflect the requirements of any particular
insurer / delegated authority.
POLICY RECORD IDENTIFICATION
N
O
T
E
1
2
3
4
5
6
INSURER 1
USER
ID
DELEGATED
AUTHORITY
1
USER 1
DELEGATED
AUTHORITY
4
USER 1
(CLAIMS)
DELEGATED
AUTHORITY
3
USER 1
DELEGATED
AUTHORITY
1
INSURER 2
DELEGATED
AUTHORITY
2
NO D.A.
IDENTIFIED
I.E. ACCESS
TO ALL
POLICIES
DELEGATED
AUTHORITY
1
DELEGATED
AUTHORITY
3
NO D.A.
IDENTIFIED
I.E. ACCESS
TO ALL
POLICIES
YES
YES
YES
INSURER 1
USER 1
YES
DELEGATED
AUTHORITY
4
USER 2
DELEGATED
AUTHORITY
5
USER 1
MID Functional Specification
© Experian Ltd
YES
Page 38
22 August 2001
Version 2.4
Main Document
Case specific notes
1. Delegated Authority 1 administers policies for Insurer 1 and for Insurer 2. Insurer 1 has
given permission for DA1 to access the policies supplied by DA1. Insurer 2 has not given
similar permission.
2. Delegated Authority 4 is a delegated Claims Handler for Insurer 1 with no policy
administration responsibility and does not contribute policies to the MID. Insurer 1 has
given permission for DA4 to access any Insurer 1 policy record.
3. D.A.3 administers policies for Insurer 2, who has given permission
to view those
policies.
4. This Insurer 1 user has access to all of Insurer 1’s policies.
5. DA4 is also a delegated Claims Handler for Insurer 2 but only in respect of a scheme for
which DA3 administers the policies.
6. DA5 is a delegated Claims Handler for several Insurers, with no policy administration
responsibility and does not contribute any policies to the MID. No Insurers have given
permission to access their records.
In a situation where, for example, DA 2 administers policies for Insurer 1 but Insurer 1 has
not given permission for DA 2 to access the records DA 2 has submitted and, DA 2 has no
claims handling role requiring access to third party insurer information, then since no access
is required no table entry would be required.
General Notes
A. The table records permitted access to full policy details. The presence of a row for a User
indicates access to the database. A “YES” in a column indicates permission has been
given by the Insurer for full access to the records identified. The absence of a “Yes”
implies “No” except that a “Yes” under the “ALL” column renders entries in all other
columns for that insurer unnecessary and implies “Yes” for all columns.
B. Each insurer controls access to his own policies. No User has right of access without the
insurer’s permission .
MID Functional Specification
© Experian Ltd
Page 39
22 August 2001
Version 2.4
Main Document
C. When an insurer grants access to a user for ALL policies, the DA identity on a policy, if
present, is ignored.
D. All authorised users (enquirers) will be given at least “third party” information ie Screen
11, Policy Ref Insurer Name and Contact details. Access to full policy details requires a
“Yes” in the table.
MID Functional Specification
© Experian Ltd
Page 40
22 August 2001
Version 2.4
Main Document
6.0 Management Reporting
Examples of each report can be seen in Appendix I.
6.1
Data Supply Control Report
A control report will be produced for MIIC (Motor Insurers’ Information Centre)
showing the level of rejects by company, to allow MIIC to audit the quality of the
information on the database. It will be produced at the beginning of each month, to show
the statistics for the previous month.
6.2
Time Taken to Supply Data to the MID
Reports will be produced for MIIC detailing the average number of days from the
Effective Start Date of a policy to the File Production Date. This will allow monitoring
of the time delay between an insurer writing a new policy or making an amendment to a
policy and that information reaching the MID. It will be produced at the beginning of
each month, to show the statistics for the previous month.
6.3
Time Taken to Cancel/Lapse a Renewed Policy
Reports will also be produced for MIIC detailing the average number of days from the
automatic renewal of a policy on the database to an insurer notifying the database that the
policy has subsequently lapsed or been cancelled. This will allow monitoring of the time
delay between a policy being automatically renewed on the database and the insurer
submitting an Amend record to show the policy has lapsed or been cancelled. It will be
produced at the beginning of each month, to show the statistics for the previous month.
MID Functional Specification
© Experian Ltd
Page 41
22 August 2001
Version 2.4
Main Document
6.4
Car Data Check Exception Report
A report is produced listing all the vehicles which were flagged as exceptions by the Car
Data Check lookup process. This is produced for every file processed, and can be sent to
the supplier if required, although the data will also be sent in the Reject file. The reason
for the exception (VRM not found, Vehicle scrapped/exported) will be printed for every
record.
The warning message W001 Vehicle Registration Mark Not Found will be suppressed for
Channel Island and Isle of Man VRM formats (see Appendix C).
6.5
Duplicate Records
MIIC will be supplied with details of duplicate VRMs appearing on the database under
different policy numbers for longer than a specified period of time. This will be set
initially to 60 days. The report will be produced monthly.
Following an insurer’s initial policy load the report will be produced to show only
duplicates which do not involve another supplier. These will be supplied to MIIC.
6.6
Number of Enquiries
Details of enquiries made by insurers and delegated authorities (where applicable) will
be reported on to allow MIIC to monitor use of the database. The report will show
separate totals for the number of enquiries resulting in a policy being found; and those
not found. The report will be produced monthly.
6.7 Number of Enquiries by Account Number
MID Functional Specification
© Experian Ltd
Page 42
22 August 2001
Version 2.4
Main Document
Details of enquiries made by an insurer or delegated authority Account number, will be
reported on an ad-hoc basis, covering a specific time period, in the event of any Invoice
queries .
6.8
Number of PNC Enquiries
Police usage of the database will also be reported on to determine the total number of
police enquiries. This will be broken down to show the number of enquiries where a
match for the VRM is found, and the number of enquires where no match is found.
6.9
Timing of Enquiries
A report will be compiled to show the spread of total enquiries by police and insurers
over a 24-hour period to show when the database is being accessed.
6.10
VRMs without Current cover
The report will give details of policies that have been cancelled/ lapsed or have expired,
and another policy record has not been submitted either by the last shown insurer, or any
other insurer. The report will be produced monthly.
6.11
Search on VRMs by Previous Insurer
If an insurer enquires on a vehicle that is covered by another insurer, they will see only
limited information including the insurer’s name. There is a need to prevent insurers
using this facility to find out where a policyholder has gone. This monthly report will
give details of such enquiries.
MID Functional Specification
© Experian Ltd
Page 43
22 August 2001
Version 2.4
Main Document
7.0 Project Plan / Timescales
7.1
MID Detailed Project Plan / Reporting of Progress
Experian will maintain the detailed plan for the MID project. Progress against the plan
will be reported on a bi-weekly basis to the MID Project Team and to those insurers
intending to go live in the first phase (second quarter 2001). All other MIIC insurers will
receive a regular high level progress bulletin.
Those Insurers intending to go live in the first phase (second quarter 2001) will be
required to submit to Experian monthly progress reports, on the 1st of each month from a
date to be agreed by the Insurers and the MID Project Team. This information will be
fed into the overall plan and then provided to the MID Project Team. Progress should be
reported against the MID Insurer Progress Checklist shown in subsection 7.4 (MID
Insurer Progress Checklists Overview).
Milestones and deliverables are included in the Functional Specification for
illustrative purposes and, for purposes of this document, are frozen. Full details will
be included in an overall project plan and changes will not require change control.
7.2
Modifications to the MID Project Plan
Any changes to the key dates given in subsection 7.3 (MID Project Plan) must be agreed
by the MID Project Team and will be reported to all parties as part of the regular
reporting cycle. An update to the MID Project Plan will be issued with the weekly
progress report.
MID Functional Specification
© Experian Ltd
Page 44
22 August 2001
Version 2.4
Main Document
7.3
MID Project Plan
The following table shows the expected start and end dates for each major phase of the
MID Project:
Phase
Start
End
Responsible
MID Functional Specification
Aug 6 1999
Sep 24
MIIC / Experian
1999
MID Functional Specification
Sep 24
Mar 9 2000 MIIC
Signed-Off
1999
MID Computer Systems Design
Feb 28
May 26
2000
2000
Identify Initial Group of Insurers
Mar 2000
Apr 2000
MID Systems Development
May 30
October
2000
2000
MID Systems Testing
Oct 2000
Nov 2000
Experian
Insurer User Acceptance Testing
Nov 2000
Dec 2000
MIIC
Dec 2000
Dec 2000
Insurers
System Signed-Off by Insurer UAT
Dec 22
Dec 22
MIIC
Team
2000
2000
*Initial Group Extract Policy Loads
Jan 2001
Jan 2001
MIIC
PNC Developments complete
Jan 31
Jan 31
PNC
2001
2001
Feb 2001
Mar 2001
Experian
Experian
(UAT)
Insurers’ own developments
complete
Remaining Group Policies Loaded
Experian /
Insurers
Initial Group Commence Regular
Feb 2001
Transmissions
Remaining Insurers
MIIC / Experian
/ Insurers
Mar 2001
MIIC / Experian
/ Insurers
MID Functional Specification
© Experian Ltd
Page 45
22 August 2001
Version 2.4
Main Document
Phase
Start
End
Responsible
PNC Acceptance Testing
Mar 2001
Apr 2001
PNC/Experian
MIB Acceptance Testing
Mar 14
Apr 2001
MIB/Experian
Apr 30
Apr 30
PNC
2001
2001
Apr 30
Apr 30
2001
2001
May 2001
Jun 2001
2001
PNC Sign-off
MIB Sign-off
Police Pilot
MIB
MIIC / PNC /
Experian
Stress Testing
Jun 2001
Jun 2001
MIIC / PNC /
Experian /
Insurers
PNC Live
Jul 2 2001
MIB Live
Jul 2 2001
For ease of implementation, the plan is to take a phased approach to the initial load of
MID Policies.
Insurers will be allocated slots for their initial loads through
January/February 2001 and, whilst these will to an extent be negotiable, every effort will
be made to ensure any changes do not compromise the project go live date.
The User Acceptance Test team will initially focus their attention on the QA and
Add/Update functions of the system to allow these areas to be signed-off in advance of
the rest of the system and thus allow Experian to start the testing and QA of insurer data
as soon as possible.
*Initial Group is the critical mass of companies identified by MIIC to allow the database
to go live.
MID Functional Specification
© Experian Ltd
Page 46
22 August 2001
Version 2.4
Main Document
7.4
MID Insurer Progress Checklist Overview
Guidelines for completion of the checklist and the checklist itself will be issued prior to
commencement of monthly progress reporting.
 Item To Be Progressed
Planned
Actual
Date
Date
Functional Specification received
Implementation Survey received
Implementation Survey returned
Data Protection wordings received
Data Protection wordings on relevant documents
MID Set-up Package received
MID Set-up Package returned
System Design started
System Design completed
 data extraction/submission
 daily submission new/update/deletions
 rejection handling
 communications
System development started
System development completed
System testing started
System testing completed
Test extract submitted
Test results returned
Production of live extract approved
Communications line installed
Communications software installed
Communications handshake completed
MID data test completed
MID Functional Specification
© Experian Ltd
Page 47
22 August 2001
Version 2.4
Main Document
 Item To Be Progressed
Planned
Actual
Date
Date
Link testing started
Link testing completed
Live extract sent
Catch-up submitted
Daily transmissions started
MID Functional Specification
© Experian Ltd
Page 48
22 August 2001
Version 2.4
Main Document
7.5
MID Milestones
Milestones
Due
Responsible
DPR approval of consent wordings and
Jan 31
MIIC
data
2000
Approved DP wordings issued to MIIC
Feb 1 2000
MIIC Project Office
Mar 30
MID Project Team
members
Functional Specification signed-off
2000
Project reporting strategy signed-off
Mar 30
MID Project Team
2000
Project Reporting Strategy implemented
Mar 31
Experian/MID Project
2000
Team
Functional Specification issued to MIIC
Mar 31
MIIC Project Office
members
2000
Implementation Survey issued to all
Mar 31
MIIC members
2000
Insurer Project Reporting Strategy
Mar 31
issued to MIIC members
2000
Implementation Survey results returned
Apr 20
Experian
MIIC Project Office
All MIIC Members
2000
Initial Group identified
May 30
MID Project Team
2000
Computer System Design completed
May 26
Experian
2000
MID System Program Specifications
Jul 31 2000 Experian
completed
Participating Insurers agreements signed
MIB rules agreed
MID System Test Plan produced
Aug 31
Experian
2000
MID Functional Specification
© Experian Ltd
Page 49
22 August 2001
Version 2.4
Main Document
Milestones
Due
Responsible
MID System test cases created
Aug 31
Experian
2000
MID programs coded and unit tested
Aug 25
Experian
2000
MIIC test scripts
Sep 1 2000
MIIC
MID system testing completed
Nov 17
Experian
2000
UAT testing completed
Dec 22
All MIIC Members
2000
MID signed-off by insurers
Dec 22
MIIC/MID Working
2000
Group
Insurer/PNC/MIB
Dec 22
MID Working Group
Procedures/Guidelines produced
2000
MID initial group tests signed-off
Dec 22
MIIC/Experian
2000
Initial Group link tests completed
Dec 22
Initial Group/Experian
2000
Initial Group start extracting policy
Jan 8 2001
Initial Group
Feb 23
Experian
loads
Initial Group Policies loaded
2001
Initial Group daily transmissions started
Feb 26
Initial Group/Experian
2001
MID system signed-off by PNC
Apr 27
PNC
2001
MID system signed-off by MIB
Apr 27
MIB
2001
Full System Live
MID Functional Specification
© Experian Ltd
Jul 2 2001
Page 50
22 August 2001
Version 2.4
Main Document
7.6
MID Deliverables
Deliverable
Due
Responsible
Data Protection wordings
Jan 31 2000
MIIC
High-level Project Plan
Mar 31 2000
MIIC/Experian
Project Reporting Strategy
Mar 31 2000
MIIC/Experian
Functional Specification
Mar 31 2000
MID Project Team
Insurers Implementation Survey
May 1 2000
MIIC/Experian
results
Police Memorandum of
Understanding
Signed insurers agreements
MIB rules
MIIC test scripts
Sep 1 2000
Computer System Design
May 26 2000
Experian
MID Program Specifications
Jul 31 2000
Experian
MID System Test Plan
Aug 31 2000
Experian
MID system test cases
Aug 31 2000
Experian
MID program code
Aug 31 2000
Experian
Tested system
Nov 17 2000
Experian
Signed-off Insurer system
Dec 22 2000
MIIC/MID Teams
Insurer Procedures/Guidelines
Dec 22 2000
MIIC
PNC Procedures Guidelines
Dec 22 2000
MIIC/PNC
MIB Procedures Guidelines
Dec 22 2000
MIIC/MIB
Initial Group policy loads
Jan 8 2001
MIIC
MID Functional Specification
© Experian Ltd
Page 51
22 August 2001
Version 2.4
Main Document
Deliverable
Due
Responsible
Loaded database
Mar 26
Experian
2001
Signed-off Police Enquiry System
Apr 27
PNC
2001
Signed-off MIB Enquiry System
Apr 27
MIB
2001
Live System
MID Functional Specification
© Experian Ltd
Jul 2 2001
Page 52
All
22 August 2001
Version 2.4
Main Document
8.0 Change Control
8.1
Overview
This document will be frozen at sign-off by MIIC and Experian. From this time, it will
be subject to change control.
A MID Change Control Group will be established for the development period and will
consist of one business representative and one technical representative from MIIC, one
business representative and one technical representative from Experian.
8.2
Change Control Prior to Implementation
Change requests will be documented utilising the Change Request Form found in
Appendix H and sent in a timely manner to Experian. The request will be logged and
classified as either a minor or major change. This classification will be made by the
MID Change Control Group.
Minor Changes
Minor changes (subject to volume) will be implemented as soon as scheduling
allows.
Major Changes
Major changes will be categorised as:

Urgent

Required prior to implementation

To be applied post-implementation.
MID Functional Specification
© Experian Ltd
Page 53
22 August 2001
Version 2.4
Main Document
Details of all changes will be circulated on the form found in Appendix H:
Change Request Evaluation Form to the members of the MID Change Control
Group for impact analysis, assessment, and categorisation.
The members of the group will complete and return the document to Experian
within five (5) working days.
On receipt of the completed Change Request Evaluation Form the decision to
progress the change will be made by an MIIC Project Board nominee and an
Experian nominee and the change request will be signed-off.
Implementation of the change will depend on its categorisation. Changes to be
applied post-implementation will be documented to be prioritised and scheduled
at a later date.
Change Control Administration
Experian will be responsible for maintaining a complete list of all change
requests, impact analyses and sign-offs.
A status report of all changes will be issued monthly to participating insurers
including details regarding major changes.
Participating insurers will be notified of changes to be made once agreed.
Document updates will be distributed monthly.
8.3
Post Implementation
Post Implementation change control procedures will be controlled through a nominated
change control group.
MID Functional Specification
© Experian Ltd
Page 54
22 August 2001
Version 2.4