Excel parking issue PCN even though paid

"we must clarify that this is third-party software for which we are not responsible. When paying for parking over the phone, motorists should ensure that their payment has been allocated to the correct vehicle registration number, it is imperative that the information used is 100% accurate."

They are responsible for a third party handling VRN data as their contractor.

Try this (below) it's a new idea I have had which can be tried by anyone where wrong VRN or wrong location code data is being relied upon by a parking firm who knows full well from their own ANPR data stream, which car it was and which location that car was in:

Email Excel (see their letters at the bottom, there's an email addy if you do not have it yet).

In the subject line, put Data Rectification Notice - FTAO the Data Controller

Then state that they and their agent, Connect Cashless Parking, are storing and processing data that is incorrect, and that Excel know to be incorrect. Under the GDPR, you require that to be rectified, and remind Excel of their legal duty as set out in simple terms by the Information Commissioner, here:

https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/individual-rights/right-to-rectification/

State that due to a processing error on the part of the new app that Excel have changed to recently, Connect Cashless Parking have brought forward in error, old data regarding a parking session and location code at xxxxxx car park and wrongly applied it to your request for a parking session at xxxxxx car park.

This is a data mismatch and/or error, not caused by the consumer, and Excel have been advised of it already.

As such, you require that Excel tell their agents to rectify the error, which was not keyed in by the driver, but was brought forward by the new system which had unfairly stored an old location code.

Retaining that data for xx months/years is excessive and unjustified data storage, and for that, Connect Cashless Parking is at fault and places consumers at risk of detriment by carrying forward data that makes an assumption about a vital piece of information - the location code - that will cause consumers to suffer loss as a result.

To expect a consumer to assume the burden of having to notice and override incorrect data every time they use a phone app, when the app company have stored that data and introduced it for a completely different parking session by presumption is wholly unreasonable, and this undoubtedly a serious matter for the Information Commissioner to consider.

And it is not just the app that is at fault (Excel being reminded that they remain liable for the actions of their agent, anyway). By failing to rectify the error when advised of it in an appeal, Excel have breached the GDPR and must not continue to rely on what they know or should know, to be inaccurate data.

Not only that, their own data images tell Excel that the vehicle was in the second car park, and that the payment needs to be rectified and matched to that site instead. The ANPR image is a data stream in its own right and Excel must consider it when addressing this data error, and not blame a consumer.

This is clearly wholly within the control of (and is indisputably the data liability of) Excel, and for a parking firm to reject the information in an appeal and mislead a consumer by saying ''we must clarify that this is third-party software for which we are not responsible'' is not only disingenuous, but an untrue statement from the company and the Data Controller must take steps to prevent that sort of flagrant disregard for data protection rules - and negligent misinformation about the law of agency - from happening again.

It may have been different, had the driver actually keyed in the wrong location code, and that would be a matter for the ICO to decide. But in this case, the phone app contractor (appointed and used by Excel to handle the data stream from the app, on their behalf) has introduced old, incorrect data from a long since forgotten parking session.

There can be no quibble that the situation falls squarely within the GDPR:

When is data inaccurate?

The GDPR does not give a definition of the term accuracy. However, the Data Protection Act 2018 (DPA 2018) states that personal data is inaccurate if it is incorrect or misleading as to any matter of fact.

State at the end, that you require a reply from the Data Controller within 30 days, and you wish to exercise your right to request 'restriction of the processing' of your personal data during this period from contesting the data accuracy, while Excel and its phone payment agent check it, in accordance with Article 18 of the GDPR:

What should we do while we are considering the accuracy?

Under Article 18 an individual has the right to request restriction of the processing of their personal data where they contest its accuracy and you are checking it. As a matter of good practice, you should restrict the processing of the personal data in question whilst you are verifying its accuracy, whether or not the individual has exercised their right to restriction.

Finish by telling Excel that they have no proportionate justification to ask for ID, as they hold enough other data to have identified the complainant already, and so now, their only options are:

1 - to confirm that the data is inaccurate, and to rectify it and confirm the fact, or

2 - to confirm that they believe the data is 'accurate' (which it clearly isn't), or

3 - refuse to comply with a request for rectification if the request is manifestly unfounded or excessive (which it clearly isn't).

Should Excel opt for (2) or (3) as their formal response, their Data Controller will be held personally liable, jointly and severally with Excel's own corporate liability, and the response will be used in evidence for a formal Information Commissioner's Office complaint regarding a failure to rectify known inaccurate data fed by their own agent's archive storage, which should have long since been erased.

Forget the IAS.

Send the email I told you to, using my words and subject line. It is not an appeal.

I've added more to this version I wrote for someone:

https://forums.moneysavingexpert.com/showthread.php?p=74774025#post74774025

Really go to town and use the best bits of both versions.

Is there a better address to send other than info@?

No.

Shall I send it to other bodies too?

The second stage is a complaint to the ICO as explained here:

https://forums.moneysavingexpert.com/showthread.php?p=74778358#post74778358

I think the data issue is massive and needs shouting about

So do we, and the ICO is the right ear to shout in, once Excel muck up their response to the Rectification Notice.

This is a new untested fightback tactic which was posted about only days ago for anyone with a PCN from a private firm, which relies upon blaming the driver for 'incorrect data' when in fact the data subject has the legal right to just ask for it to be rectified...and can't possibly be penalised for the trader's data processing 'automated decisions' and failures.

Bring on the ICO complaint ''bombs'', as long as posters word and evidence them well, and understand they are not writing an appeal to the ICO, but a data processing complaint.