Third party data

Third party data requirements - consumer file requests

The Third Party Data BRS included a commitment to ensure that all consumer records were fully populated and data was correctly attributed. That meant that all new searches had to be fully populated with name, date of birth and a full address with effect from 24 October 2001. Then all applications had to be processed on TPD compliant systems with effect from December 2004. Not only did that agreement impact on lender searches and processes but also on the consumer files servicing from the credit reference agencies.

The Guide to Credit Scoring and other regulatory guidance states that lenders should give consumers clear information as to the reason for a decline decision. If and only if, the data obtained from a credit bureau contributed to the decline decision should consumers be recommended to obtain a copy of their credit report. They should be told which bureau to approach and given contact details.

Experian is currently receiving between 200 - 450 consumer file applications each day with insufficient information to be processed. This is largely because lenders decline letters or other processes are not informing consumers as to the information they must supply as part of a file request. As a result, consumers are getting frustrated and are not receiving the advice and service they have the right to expect. It is absolutely essential that consumers provide sufficient information when seeking their file.

In order to make this easier for consumers Experian recommends use of bespoke file request systems which may be downloaded from www.experian.co.uk/consumer or call 0870 241 6212 or write to Consumer Help Service, PO Box 8000, Nottingham NG80 7WF, preferably using the application form attached.

This form also seeks other information which improves the data available to the industry for the future. Can we please ask you to check the content of any decline letters/text that you use to ensure that it does seek all the information required and, if possible, direct consumers to either the Experian telephone service, the website or use the pro forma if at all possible.

Credit report application form (pdf) »

Experian position on Third Party Data compliance

All remaining CAIS records should be fully populated by October 2007. There are still significant numbers of records that require updating and members should be working now to ensure that their data meets the terms agreed with the ICO as part of the TPD BRS.

The position on data is clear:

"In accordance with the TPD agreement all data should be compliant by 24.10.2007 and any unpopulated data may become unavailable after 24.10.2007. Lenders with significant portions of their book in this category are then likely to be non reciprocal and potentially outside the PoR. As such, they should be working to populate their data as soon as possible".

Experian has redeveloped the enhancement tool which is available to clients to populate their missing records. This tool is showing significant improvements over previous versions and is regularly providing data in a significant majority of cases. Alternatively clients may undertake an exercise themselves. Account managers will be discussing with all clients their proposal and reporting will be undertaken to SCOR on a regular basis. (4 July 2006)

Third Party Data - the final push

The Third Party Data agreement with the ICO had 3 phases:

By 24 October 2001 - all new searches and CAIS records to be fully populated. Fair Obtaining clauses to be standardised and plans to be in place.
By 31 December 2004 - all applications to be processed on third party data compliant systems.
By 24 October 2007 - all pre October 2001 CAIS records to be fully populated and all customer management searches to be fully populated and where possible all marketing screening to be conducted on full names and pre October 2001 associations created from searches to be purged from CRA databases.

The relevant sections may be found in the Third Party Data BRS as follows:

All pre October 2001 CAIS records to be fully populated - 4.1
All customer management searches to be fully populated - 6.5 box D
Where possible all marketing screening to be conducted on full names - 6.6 box A
Any remaining pre October 2001 associations created from searches to be purged from CRA databases - 5.2.

The result of this is that all relevant lender databases will need to be enhanced in order that the CAIS extract is compliant and the searches generated for any account or customer management activity uses full name and address information in the required format being:

Title
full forename
middle name or initial (if available)
surname
date of birth
PAF valid or postcoded address

Progress towards compliance is already being monitored by SCOR and now over the next few months all CAIS clients will be contacted in order to agree a plan for the management of this, the final phase of the third party data agreement. By the end of December 2005 it is anticipated that every client should have agreed a final plan with their Experian account manager.

Potential Alias processing

Background

The Third Party Data (TPD) Business Requirements Specification covers the agreement between the Information Commission and the financial services industry to eliminate the unacceptable use of data that does not relate to the consumer that has applied for, or is the customer. The principal issues that it addressed were:

The use of data that might or might not relate to an individual as a result of an inability to confidently attribute information to one identity.
The use of data on other individuals either known or assumed to be connected to the applicant or customer because they shared a surname and had lived concurrently with the data subject.

The transition arrangement known as “Potential Alias” was agreed as part of the solution to address the first of the above issues. Such an arrangement was required because, at the time, anything up to 90% of data in some areas, could not be confidently attributed to any one individual. There were a number of reasons for this but the major causes were that many records did not contain a full name nor a date of birth.

One of the major contributions to the change is a mandatory tighter definition of data relating to an individual. With effect from 24 October 2001 all search records and new shared credit file records were to contain:

Title
Forename
Second name or initial (recommended and mandatory where available)
Surname
Date of Birth
Address(es) in PAF format or postcoded

The next stage is to address the existing records that were opened before October 2001 and the industry has until October 2007 to supplement those records such that they may be attributed in the approved manner. That work is progressing well under the sponsorship of SCOR who regularly monitor progress.

Prior to the TPD agreement there was no minimum data requirement and many records had one or more of the above fields missing. This was not previously an issue because data could be treated as same person or same family and included in scoring systems based on a lower confidence level.

Following implementation of the TPD agreement it was agreed that data would be categorised at one of 5 levels of match.

Applicant data (including joint applications)
Applicants associated data
Same family data
Potential Alias data
Non-financial address data (e.g. Electoral Roll, demographics) and CIFAS data

With the result that records with insufficient data for the credit reference agency to confidently return the information as category 1 (applicant data) will only become available to those lenders that decide to take category 4 data (potential alias). This was deemed to be the most effective way to manage the records that did not hold sufficient data to be automatically attributed to the data subject. This was to be a “last resort” to manage such records after data cleansing and other activities had taken place.

Each CRA will have different ways of managing the data and some will have different proportions in each “pot”.

Lenders that take the Potential Alias data are not allowed to use it until and unless they have identified whether it actually does relate to the applicant (or their associate) and attributed it accordingly. Additionally, a lender can choose not to check and attribute data that is not likely to make a material difference to the decision so a score can be used to determine whether it is even necessary to check the data. This last provision was agreed to mitigate the impact on lender processes and try to avoid the need to view and update large numbers of closed or unutilised records unless they might contribute to the decision such as in a thin file scenario.

Experian’s systems

When a client generates a search of data at Experian the system first identifies the address and then the individual at that address. When the search hits the address the system will determine whether there is, or appears to be, more than one person at the address with the same name/initial such that existing data may be supplied as category 1 (same person) data or not.

Data that cannot be confidently attributed to the applicant but which might be the applicant (or their associate) will be available as Potential Alias data, if the lender has opted to take that information.

The BRS recognised that despite the sophistication of name matching algorithms there would be many cases where electronic attribution would be difficult unless the matching criteria were set so loose that other names might then also be taken into account. This is because coincidences do occur and, of course, there are a number of households with people of the same or similar name in simultaneous residence. At the same time, by setting the matching rules relatively tightly a significant majority of cases presented to organisations using Potential Alias data would be instantly attributable when viewed by a manual operator. This would negate any requirement to seek any endorsement from the applicant consumer.

In the event that the data cannot be attributed with ease the lender may consult the consumer and ask suitable open questions. At all times they need to bear in mind that the data may not relate to the consumer and so avoid giving away too much information. Guidance was included in the BRS Appendix II.

If the data relates to the applicant’s associate how any query relating to the data might be raised with an applicant will depend on whether it was a joint account application and the nature of the data.

Queries such as "Is your associate the only J Smith living there and in particular in 2003?" Can helpfully establish whether any other possible consumer could “own” the data item.

Experian Potential Alias Process

The process for clients to advise the amendment of data to Experian is detailed in the Potential Alias Procedures.

Process flow for a lender taking Potential Alias (PA) data (pdf) »

Procedures for use of Potential Alias (Word document) »

The future of Potential Alias data

At the time of the TPD BRS it was envisaged that the amount of data that would be in the PA “pot” would diminish over time but never completely go away because of CCJs and the lack of date of birth.

However, with the credit industry committed to cleaning their own data by October 2007 and the recent advent of a requirement to supply dates of birth for court purposes that is set to change.

Experian is monitoring the progress towards fully populated data on the shared database in order to report progress to SCOR and would suggest that a review of the situation takes place in 2007 with a view to considering the future need for the process.

BRS Proposal on tighter definition of the individual (pdf) »

Third Party Data Update

On 31 October 2004 Experian's Consumer Help Service will move to third party data compliant processing. With effect from 1 November any consumer file will only show data on the applicant together with the name of any associate derived from joint applications or accounts or as advised by the consumers themselves.

Please see attached for sample credit file:

Sample Credit file presentation (PowerPoint) »

Impact on Lenders

All lenders need to ensure that if they advise consumers to seek a copy of their file they provide all the required information.

The easiest way to do this is to order it over the internet, by telephone on 0870 241 6212 or use the form located on Experian's consumer website. If they prefer to write a letter or use a form provided by lenders they must provide the following information:

Title
Full forename
Middle name or initial (if they have one)
Surname
Date of birth
Full address with a postcode

and send it to:

Experian Consumer Help Service, PO Box 8000, Nottingham NG80 7WF

If any of the above data is missing it may result in a delay in processing the request. At present over 50% of requests are being received without date of birth so it is important that consumers are properly informed by their lenders.

Lenders that are operating Third Party Data compliant systems

These lenders will have to ensure that their decline processes explain to consumers that if they have an associate that they may need to ask their partner to obtain their file too. This will depend on the level of data used in the decision. Lenders that offer the facility to "opt-out" will also need to have put in place an explanation for those applicants declined on the basis of their declaration about their partner data.

Lenders that are not yet operating Third Party Data compliant systems

Consumers will not be able to obtain a file with all the data that may have been used to make the decision and particular care will need to be taken when discussing appeals and reasons for decline with consumers. In order to remain compliant with Data Protection requirements lenders should not discuss data relating to partners but should still advise consumers to ask their partners and (potentially) other family members to obtain their files. Any lender that operates an automated system that does not display the data to underwriters may find that they have particular problems in identifying which data may have contributed to the decision. In such cases they are advised to contact their account manager as soon as possible to discuss options for support until they move to a compliant system.

What is it?

In the early 1990s the Information Commission (then Data Protection Registrar) took enforcement action to prevent credit reference agencies using data on individuals other than the data subject. The outcome was that data on other individuals with the same surname living concurrently at an address and/or those with links to the data subject, were permitted to be included on credit files. Following the 1998 Act the ICO engaged with the industry to resolve this issue and an agreement was reached which removed access to parent/sibling/child data but enabled partner data to still be used to make decisions. This compromise was agreed in order to support efforts to make responsible lending decisions based on the situation of the financial unit.

The implementation detail is included in the Business Requirements Specification which was discussed, at length, between industry and the ICO before being presented to the credit industry at large.

Third Party Data - Business Requirements Specification (pdf) »

Third Party Data factsheet - a useful guide 18 July 2003 (pdf) »

Latest TPD news

Experian has been working hard with clients to meet the 31 October 2004 target date agreed with the Information Commissioner. Although Experian’s internal client support systems have been ready for some time the last piece of the system to go third party data compliant will be Consumer Help Service and the consumer files. That change will take place on the weekend of 31 October 2004. Following that change consumer files will only show information on the file of the applicant and the name and source detail of any links to other parties.

Clients may need to change their text on correspondence and scripts for dealing with consumers to make it clear that consumer files will no longer include partner information. As a result, consumers need to be told that if they have an association they should consider whether to ask their partner to send for their file too.

Latest TPD press releases

Third Party Data target date

Richard Thomas, Information Commissioner has stated that he expects the industry to have migrated to compliant systems by the end of June 2004 rather than the end of 2004.

Experian migrates client systems to third party data compliance

In the Spring/Summer issue of Compliance Briefing the timelines for Experian's third party data roll-out programme were featured. Work has now been completed on all stages – data quality; core software compliance; and additional functionality, including the household override facility.

Alongside this, the new Consumer Indebtedness Index (CII) is available, but only in fully compliant third party data format. To take advantage of the CII benefits outlined elsewhere in this issue of Compliance Briefing clients need to migrate across the third party data compliant platforms.

It is now some time since the Information Commissioner signed-off the Industry's plans for migrating to compliant systems. Strictly speaking the date by which changes should have been in place to avoid Data Protection Act breach was 24 October 2001. However, recognising the complexity of changes faced by the industry, the Commissioner agreed that it would be reasonable to agree to a timescale which reflected the amount of work to be undertaken, both by the credit reference agencies and within lenders' own systems.

Disclaimer: The information contained on this webpage is provided for general guidance only. It is not intended to provide you with professional advice nor is it intended to substitute you obtaining professional advice.

Contact us

Further information on Compliance?

Email us