Clare :
What the difference between MIAFTR2 and MIAFTR?
Not sure you have to worry about notice or consent given MIAFTR purpose was
as a Fraud Prevention database only. 29(1) and or 29(3) come into play
I would have thought the ABI could be of assistance here via undertaking
discussions with the OIC re clearing the personal data processing methods in
MIAFTR2 on behalf of the Motor Insurance Sector as a whole as occurred with
CUE and the MID. If individual insurers operate separately on standards here
they run the risk of making MIAFTR a competitive issue as oppose to a
collaborative process by which fraud can be consistently identified.
I recall the purpose of the register was argued by Insurers as a fraud
prevention tool only. This is an important factor else problem in first
principle compliance do arise.
If Insurers wish to avail themselves of the Crime Prevention and Detection
exemptions in the Act they should ensure a robust system of controls which
prevent the Insurance Sector being brought into disrepute by poor data
handling. A weak system of data control can have substantial impact on
Insurers via 1: Public perceptions of Insurers (impacts on Brand Image) and
2: Claims costs increasing as less data is provided by third parties due to
lack of trust. Fraud flourishes as a consequence.
I suggest some minimum data control considerations are :
1: Access security on the MIAFTR database is actively monitored and
enforced.
2: The database as a fraud prevention tool has a clear supporting protocol
document regards the data access and use.
I suggest this protocol should apply to all participant Insurers equally and
therefore passed by the OIC for consideration via ABI on behalf of all
participant Motor insurers. (I suggest Insurers also need to consider any
best practice lessons from 'Bichard' re sharing of crime prevention data)
3: Employees permitted access should be fully trained in the data use
protocol. Section 55 criminal offences should be brought to employees
attention as applying if they use data beyond the protocols. ie an employee
is on their own if they ignore company rules and training. - If they abuse
data and get prosecuted they may be unemployable by an Insurer given other
regulation relating to financial services employment. Can be a powerful
control if properly presented in employee training.
4: If an employer does not commit to adequate data handling training, in my
view they should be subject to sanctions by the OIC under section 61 neglect
under ensuring appropriate security.
Controls of the type above provide support to an Insurers role in crime
prevention activity and assist the arguments regards use of the Crime
Prevention and detection exemptions in the Act. (Note the database uses must
only be for this sole purpose - the exemptions can be lost if any other
purpose attempted.
Section 29(1) and / or (3) and its reference to non-disclosure exemptions
can apply to MIAFTR use. Non-disclosure exemption are in section 27(4),
where it shows first principle is exempt (fair obtaining notice
requirements). However processing conditions still have to be met..
For Schedule 2 conditions 2 or 6 are arguable by an Insurer.
For Schedule 3 condition 6c has been argued in support of the processing.
Condition 10 linked to SI 417 could also apply. (Hence no need for consent
to process). I recall I was uncomfortable with SI417 drafting and the
exemptions if afforded the Insurance Industry in that it did not go into
sufficient clarity in recognition of the special nature of Insurance
products as a contract of 'utmost good faith'. To cross check SI 417
Sensitive data processing order (section 5 & 6 ) regarding specific
Insurance sector exemptions you have to examine the classes of business an
Insurer is incorporated to conduct. In this case Motor as a General business
class.
It may also be arguable that prevention of Insurance Fraud has a public
interest connection therefore SI 417 section 1 can come into play, again
subject to the proviso that the only purpose and use of the MIAFTR database
is Fraud prevention.
The interpretation issues can become legalistic so recommend checking issues
with your own lawyers, ABI and OIC.
Hope these observation assist.
David Wyatt
----- Original Message -----
From: <[log in to unmask]>
To: <[log in to unmask]>
Sent: Wednesday, March 10, 2004 9:08 AM
Subject: [data-protection] MIAFTR2
> In preparation for implementation of MIAFTR2 (Motor Insurance Anti-Fraud
and
> Theft Register) a query has been raised regarding the input of 3rd party
> details to this register.
>
> I understand it is industry practice (with insurers) to collect 3rd party
> details, relating to a claim, from numerous sources. These are usually
> received orally over the telephone or via written communication. Due to
the
> way this data is obtained no data protection notification is seen or
given.
> It has been stated that in the majority of instances where updating
MIAFTR2
> would be relevant it would not be practical to gain consent.
>
> We want to be able to add 3rd party details and understand other insurers
> already do this.
>
> Please can you let me know your procedures regarding 3rd party details and
> the updating of MIAFTR2. Under what guise, if any, can this data be
> disclosed to the database without consent from the individual? Or do
others
> gain consent?
>
> I would appreciate any feedback regarding this.
>
> Kind regards,
>
> Clare
>
> Clare Bond
> Compliance Officer
> Allianz Cornhill
> Finance Division
> Tel: +44 (0) 1483 552887
> Fax: +44 (0) 1483 552946
> Email: [log in to unmask]
>
>
>
>
> ************************************************************
> Copyright in this message and any attachments remains
> with us. It is confidential and may be legally privileged.
> If this message is not intended for you it must not be read,
> copied or used by you or disclosed to anyone else. Please
> advise the sender immediately if you have received this
> message in error.
>
> Although this message and any attachments are believed
> to be free of any virus or other defect that might affect
> any computer system into which it is received and opened
> it is the responsibility of the recipient to ensure that
> it is virus free and no responsibility is accepted by
> Allianz Cornhill Insurance plc for any loss or damage in
> any way arising from its use.
>
> Cornhill Life, Cornhill Direct and Allianz Global Risks
> are trading names of Allianz Cornhill Insurance plc.
>
> Petplan and DBI are part of the Allianz Cornhill group of
> companies.
>
> Allianz Cornhill Insurance plc, Registered in England
> number 84638. Registered Office: 57 Ladymead, Guildford,
> Surrey GU1 1DB.
>
> Allianz Cornhill Insurance plc is authorised and regulated
> by the Financial Services Authority.
>
> Member of the General Insurance Standards Council for
> general insurance business.
> ************************************************************
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> All archives of messages are stored permanently and are
> available to the world wide web community at large at
> http://www.jiscmail.ac.uk/lists/data-protection.html
> If you wish to leave this list please send the command
> leave data-protection to [log in to unmask]
> All user commands can be found at : -
> http://www.jiscmail.ac.uk/help/commandref.htm
> (all commands go to [log in to unmask] not the list please)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
All archives of messages are stored permanently and are
available to the world wide web community at large at
http://www.jiscmail.ac.uk/lists/data-protection.html
If you wish to leave this list please send the command
leave data-protection to [log in to unmask]
All user commands can be found at : -
http://www.jiscmail.ac.uk/help/commandref.htm
(all commands go to [log in to unmask] not the list please)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
