Why the Code of Practice Is a Developer Problem
Private parking enforcement in the UK has grown at a striking pace. Private parking companies made 12.7 million requests to the DVLA for vehicle keeper records in the 2023/24 financial year, and issued a record 14.4 million parking charge notices in the year ending March 2025. The majority of those charges originated from ANPR camera systems that log entry and exit events automatically. Behind every one of those events is software: a recognition pipeline, a database write, a timestamp, and eventually a decision to issue or not issue a Parking Charge Notice.
If the software is wrong, the enforcement is wrong. A grace-period buffer that is two seconds short, a timestamp written in the wrong timezone, or an image stored without a confidence score are not minor implementation details. They are grounds for an appeal to POPLA or the IAS, and potentially grounds for the operator to lose DVLA data access entirely. The Single Code of Practice, jointly published by the British Parking Association and the International Parking Community, is not a policy document that lives in a legal team's filing cabinet. It is a set of functional requirements that your ANPR integration must satisfy before a single charge can lawfully be issued.
What the Single Code of Practice Actually Requires
The sector Single Code of Practice was launched in October 2024 and version 1.1 took effect on 17 February 2025. It applies across England, Scotland and Wales to operators who are members of either the BPA or the IPC. The full transition deadline for all aspects of compliance is 31 December 2026, after which all operators must meet the standards in full. A forward update issued in April 2026 aligned signage timescales with the forthcoming statutory code but left the substantive provisions intact.
The Code caps parking charges at £100 and requires a prompt-payment rate of £60 where payment is made within 14 days. Version 1.1 introduced specific rules for car parks managed by camera or ANPR systems. A mandatory grace period must be allowed before any charge can be issued: drivers must be given a minimum of 10 minutes beyond their permitted parking time before a charge can lawfully be raised, plus a separate consideration period on arrival to read signage. These are not guidelines; they are baseline obligations encoded in the Code.
The statutory replacement is still in preparation. The government consulted on a new statutory code between July and September 2025 under the Parking (Code of Practice) Act 2019. The consultation closed in September 2025 and the government has stated it will respond in due course; no confirmed date for laying the statutory code before Parliament has been announced. When it is laid, it will carry real teeth: operators that breach it risk losing DVLA keeper data access, without which post-only ANPR enforcement cannot function. Developers building systems today should treat the current industry Code as the minimum bar, and design for a tighter statutory standard that may arrive at short notice.
The Grace-Period Problem in Code
The grace period is deceptively simple to state but surprisingly easy to implement incorrectly. Your system receives two ANPR recognition events for a given registration: an entry read and an exit read. The duration of stay is the exit timestamp minus the entry timestamp. The permitted stay is whatever the site configuration allows. The overstay is the duration minus the permitted stay. A charge may only be triggered if the overstay exceeds the mandatory grace period.
That means your event pipeline must carry out these operations in strict order. First, ingest the entry event and persist it with a full ISO 8601 timestamp including UTC offset, for example 2025-09-18T14:32:07.000+01:00. Second, ingest the exit event and compute the duration. Third, apply the grace buffer on top of the permitted stay before comparing. Only if the computed duration clears that combined threshold should the pipeline advance to charge creation. The grace buffer must be applied as a hard minimum in configuration, never as an optional flag that a site manager can disable. Millisecond precision matters here: a timestamp stored as 14:32 rather than 14:32:07.000 introduces up to 59 seconds of ambiguity per event, which is enough to create a grace-period dispute in a marginal case at POPLA or the IAS.
Clock synchronisation is equally important. Camera hardware clocks drift. If your entry camera and exit camera are synchronised to different NTP sources, or synchronised infrequently, you can accumulate skew across a long parking session that artificially inflates the computed duration. Camera timestamps should be validated against a trusted server timestamp at ingest time, and any discrepancy beyond an acceptable threshold should flag the event for manual review rather than automated charge creation.
Evidence Image Standards for PCN Bundles
When a motorist appeals to POPLA or the IAS, the operator must provide an evidence pack that includes ANPR images, timestamps, and documentation of the site's signs. Assessors examine whether the ANPR shows correct entry and exit times and whether those times are consistent with the charge issued. If the images are missing, degraded, or lack legible plate text, the appeal is likely to succeed on evidence grounds alone.
A compliant evidence image for a PCN bundle should meet several concrete standards. The registration plate must be clearly legible in the frame. The camera timestamp must be burned into the image or stored as verifiable metadata, and it must match the event record in your database to the second. The site identifier and camera identifier should also appear in the image metadata so that the image can be unambiguously linked to a specific location and event. Each image must be stored in a format that preserves its integrity: a JPEG that has been re-compressed multiple times loses evidential value.
This is where the API confidence score becomes a compliance asset rather than just a development convenience. When you call the recognition endpoint, the response returns a confidence field as an integer between 0 and 100. That score should be written into the event record alongside the registration string. If the confidence is below your defined acceptance threshold, the event should not proceed to automated charge creation; it must route to human review. Storing the confidence score per event means that in an appeal you can demonstrate your system's acceptance criteria and show that only high-confidence reads triggered charges. That audit trail is harder to create retrospectively.
DVLA Keeper-Lookup Sequencing
DVLA keeper data access is the operational foundation of post-only ANPR enforcement. Operators must belong to an accredited trade association to access that data, and losing accreditation means losing the ability to pursue the keeper at all. The Code and the Protection of Freedoms Act 2012 together set precise conditions under which keeper liability transfers, and those conditions depend on notice timing that is anchored to the ANPR event timestamps.
The lookup must not be triggered until the enforcement event record is fully locked: entry timestamp, exit timestamp, confidence score, image references and the computed duration must all be committed to your data store before a keeper request is made. This matters because the timestamp in your data store becomes the timestamp in any subsequent legal proceedings. If you query the DVLA before committing the event record, and the record is later updated or corrected, you create an evidential inconsistency. The correct sequence is: ingest both events, compute the duration, apply the grace check, write the immutable event record, then and only then initiate the keeper lookup workflow.
Vehicle data enrichment follows the same principle. Setting vehicle=true on the recognition call adds DVSA-sourced make, model and colour to the response. That data enriches the event record and the PCN, but it should be appended to an already-locked event rather than used to construct the event. The recognition result and the vehicle metadata are reference data; the enforcement anchor is always the ANPR timestamp pair.
Building the Appeal Data Export
Every event record your system creates should be structured so that it can be exported cleanly to a POPLA or IAS appeal pack without manual assembly. In practice, that means designing your database schema and API responses with the appeal bundle as a first-class output. A compliant event record should contain at minimum: a unique event ID, the site identifier, the camera identifier at entry and exit, the registration string from each read, the confidence score from each read, the full ISO 8601 timestamps for entry and exit, the computed duration in seconds, the permitted duration in seconds, the grace buffer applied in seconds, the charge decision flag with a reason code, the image storage reference for each read, and the vehicle make, model and colour where enrichment was requested.
When using the recognition endpoint in multiple mode, each item in the returned plates array includes the registration, confidence, and where identifiable, the country code as an ISO 3166-1 alpha-2 value. Storing the full API response payload against each event means you always have the raw recognition output as part of the audit trail, not just a derived field. That raw payload is valuable in appeals where a motorist challenges whether the correct plate was read.
For single-read events, the response includes success, registration, confidence, and credits_used. The credits_used field gives you a per-event cost record that supports billing audit as well as compliance audit. Structuring your JSON event records to carry all these fields from the point of creation means your appeal export is a query, not a reconstruction effort.
Data Retention and UK GDPR
ANPR images are personal data under UK GDPR because they can identify a vehicle and, by extension, its keeper. The Code requires that images and associated event records are retained for long enough to support enforcement and appeals, but not retained indefinitely. ICO guidance on CCTV and vehicle recognition systems requires that retention periods are proportionate, documented in a retention schedule, and enforced automatically rather than left to manual deletion.
A defensible approach is to align your retention windows directly with enforcement timelines. Images and event records for events that did not result in a charge should be deleted after a short window, typically 30 days, since there is no enforcement purpose that requires longer retention. Records for events that resulted in a charge should be retained for the duration of the enforcement lifecycle: through any appeal to POPLA or the IAS, through any county court proceedings, and for a defined period thereafter. In practice that means a minimum of two years from the event date for charged records, though you should take independent legal advice on the appropriate period for your specific enforcement context.
If your architecture uses a zero-retention processing mode, where images are processed in memory and not stored server-side, you must implement your own compliant image store. Zero-retention processing changes your compliance architecture significantly: you bear full responsibility for image custody, integrity verification, and deletion enforcement. That is not necessarily a worse position, but it must be designed deliberately rather than discovered at appeal.
A Compliant Entry-to-PCN Pipeline
The following example illustrates a compliant event pipeline for a single enforcement event on an ANPR-managed site. At entry, the camera captures the vehicle and sends the image to the recognition endpoint.
POST https://nprapi.com/api/v1/recognise
X-API-Key: your-api-key-here
Content-Type: multipart/form-data
-F "image=@entry_cam_20250918_143207.jpg"
-F "vehicle=true"The response returns something like:
{
"success": true,
"registration": "AB12CDE",
"confidence": 97,
"credits_used": 1,
"make": "Ford",
"model": "Focus",
"colour": "Blue"
}Your pipeline writes an immutable entry event record: registration, confidence, vehicle data, camera ID, site ID, and a server-generated UTC timestamp. It also stores the original image with the event ID in the filename. At exit, the same call is made with the exit camera image. The pipeline retrieves the entry record, computes the duration, applies the site's permitted stay plus the mandatory grace buffer, and evaluates whether a charge event should be created. Only a confident positive overstay, with confidence above threshold on both reads, advances to the keeper lookup workflow. The keeper lookup itself is a separate, audited step that references the now-immutable event record by its event ID.
Batch processing for high-volume sites can use the batch endpoint at POST https://nprapi.com/api/v1/batch, with status polling via GET https://nprapi.com/api/v1/batch/{uuid}. This allows multiple camera frames to be processed efficiently without blocking the event pipeline.
Common Implementation Mistakes That Invalidate Enforcement
Several recurring integration errors appear in appeal decisions and industry guidance. Timestamps stored in local time without a timezone offset create ambiguity during BST: a system that records 14:32:07 without specifying whether it is UTC or BST can appear to show an incorrect duration to an assessor working from a differently configured system. Always store and transmit timestamps in UTC or with an explicit offset.
Missing grace-period buffers are the single most common reason a technically accurate ANPR read produces an unenforceable charge. If your system computes the overstay correctly but does not subtract the mandatory grace period before triggering charge creation, every charge issued at a borderline duration is vulnerable. The grace check must be in the pipeline logic, not left to operator discretion at the point of review.
Accepting low-confidence reads is another failure mode. A confidence score of 60 might produce a registration string that looks plausible but contains one incorrect character. Issuing a charge against the wrong keeper is not only an appeal defeat; it exposes the operator to a formal complaint. Set a clearly documented confidence threshold, log every read that falls below it, and route those events to human review. The overhead of a human review queue is a straightforward trade-off against the cost of invalid enforcement.
Finally, the absence of an audit trail for rejected reads is a compliance gap that is invisible until an appeal. If your system discards a low-confidence read without logging it, and that read corresponds to a vehicle that later appears at exit with a different recognition result, you have no record of the full event sequence. Every recognition call, including failed or rejected reads, should be logged with its confidence score and the reason for rejection.
Compliance Checklist: Ten Requirements Before Go-Live
Before deploying an ANPR enforcement system under the Single Code of Practice, verify the following ten points.
One: entry and exit timestamps are stored in ISO 8601 format with an explicit UTC offset, to millisecond precision. Two: camera clocks are synchronised to a trusted NTP source and any drift beyond an acceptable threshold flags events for manual review. Three: the grace period, currently a minimum of 10 minutes beyond permitted stay, is enforced in pipeline logic as a non-overridable configuration value. Four: the consideration period on arrival is applied as a separate, additive buffer before the permitted stay clock starts. Five: a minimum confidence threshold is defined and documented; reads below that threshold are logged and routed to human review, never to automated charge creation. Six: entry and exit images are stored with event ID references, site ID, camera ID and server-confirmed timestamps, in a format that preserves evidential integrity. Seven: the confidence score from each recognition call is persisted in the event record. Eight: the DVLA keeper lookup is triggered only after the event record is fully committed and immutable. Nine: the JSON event record schema captures all fields required for a POPLA or IAS appeal export without manual reconstruction. Ten: a documented retention schedule deletes no-charge images within 30 days and retains charged event records for the full enforcement lifecycle, with automated deletion enforcement.
Conclusion
The Single Code of Practice v1.1 and the forthcoming statutory code represent a clear direction of travel: ANPR-based private parking enforcement will be held to precise, auditable technical standards, and the consequences of non-compliance range from lost appeals to loss of DVLA data access. The good news for developers is that the compliance requirements map cleanly onto well-established software engineering practices: immutable event logs, explicit timestamp handling, threshold-based decision logic, and structured data exports. A recognition API that returns structured JSON with a confidence score, vehicle data, and a precise registration string for every camera frame gives you the raw material to build all of these correctly. The compliance engineering is not complicated. What matters is that it is intentional, documented, and in place before the first charge is issued.