The Scale of the Problem in 2026
UK petrol station operators are confronting a fuel theft crisis that has moved well beyond manageable nuisance. The British Oil Security Syndicate (BOSS), the not-for-profit trade body that tracks forecourt crime across the UK, estimates that operators collectively lose more than £100 million every year to drive-offs and no-means-of-payment incidents. For an individual site, that translates to an average annual loss of around £12,500.
The situation worsened sharply in early 2026. BOSS data shows that unpaid fuel incidents surged by 19% in March 2026, with April recording a further rise, both directly linked to steep pump price increases that followed a fresh outbreak of conflict in the Middle East. Average petrol prices climbed from £1.37 per litre in the final quarter of 2025 to a peak of £1.58 in April, while diesel rose from £1.47 to £1.92 per litre over the same period. BOSS's Forecourt Crime Index reached 219 in the first quarter of 2026, up 4% on the previous three months, reversing a prolonged decline through much of 2024 and early 2025.
No-means-of-payment (NMOP) incidents, where a driver fills up and then enters the shop claiming an inability to pay, account for a growing share of losses and are structurally harder to prevent than a simple drive-off. In the most recent quarters for which BOSS has published data, NMOP incidents accounted for more than half of all unpaid fuel reports. The average NMOP incident involved roughly 47 litres of fuel, at an average cost to the operator of just under £70 per incident.
Software is now the primary line of defence. A well-built automatic number plate recognition (ANPR) integration running at the forecourt entry point can alert staff before a pump is ever enabled, cross-reference the recognised vehicle against the DVSA make, model and colour data the recognition API returns to catch cloned vehicles, and match against a shared blacklist of known offenders in milliseconds. This guide walks through every engineering decision required to build that system using a cloud number plate recognition API as the recognition and enrichment layer.
How the System Works: the Four-Stage Flow
Before writing a single line of code, it helps to understand the complete data flow. A properly designed forecourt ANPR system operates in four sequential stages.
First, a camera positioned at the forecourt entry captures a clean still frame of the vehicle's front or rear plate as it pulls in. Second, that image is sent via HTTPS POST to a number plate recognition API, which returns a structured JSON response containing the recognised registration, a confidence score, and, in multiple-plate mode, the detected country. Third, the same recognition request returns DVSA vehicle data when the vehicle flag is enabled, confirming the make, model and colour associated with that mark so it can be compared against the vehicle actually on camera. Fourth, the system performs a blacklist match against a locally maintained or shared database of plates linked to previous drive-offs or NMOP incidents at your site or at partner sites. If the plate is flagged, or if the returned vehicle data does not match the physical vehicle visible on the camera, a pump hold is maintained and an alert is dispatched to forecourt staff via webhook. If nothing is flagged, the pump is enabled as normal.
Each of these four stages has discrete engineering requirements. Getting any one wrong degrades the entire chain.
Choosing Your Camera Setup
Camera placement and configuration account for more recognition failures than the underlying software does. The most important principle is to position a dedicated plate capture camera at the single entry lane funnel, where approaching vehicles cannot deviate more than half a car's width from the read line. A camera mounted to cover a general overview of the forecourt will not achieve the pixel density on the plate that reliable ANPR requires.
Resolution matters, but not in the way most procurement teams assume. The critical metric is pixels per metre on the plane of the plate itself. Under the EN 62676-4:2014 standard, which established the DORI framework widely used in UK security procurement, the Identify threshold is 250 pixels per metre. The 2025 revision of that standard, IEC 62676-4:2025, introduced a new seven-level OODPCVS scale with higher thresholds for moving targets; for automated plate capture on a dedicated entry lane, specifying at least 250 pixels per metre on the plate plane remains the practical minimum, and pushing to 300 to 400 pixels per metre provides useful tolerance for adverse conditions. Below 250 pixels per metre, the plate becomes a smear that neither recognition software nor a human reviewer can reliably decode. A 1080p camera covering a scene width of five metres delivers approximately 384 pixels per metre, which is sufficient for a single lane entry point at a forecourt.
Frame rate matters, though vehicles entering a forecourt move slowly enough that 25 frames per second is a practical minimum. Faster entry roads benefit from 30 fps or above to ensure the plate occupies the capture zone for at least one clean frame. Shutter speed is separate from frame rate and must be set aggressively to avoid motion blur. For slow-moving forecourt traffic, a shutter speed of around 1/500 of a second is a reasonable starting point; dedicated ANPR cameras expose at 1/10,000 to 1/20,000 of a second and use a synchronised pulsed infrared illuminator to compensate for the resulting light reduction.
Infrared illumination is non-negotiable for reliable night operation. UK number plates use retroreflective coatings tuned to 850 nm infrared. Cameras equipped with 940 nm stealth IR underperform on plate capture by 30 to 50% compared with 850 nm equivalents. Always specify 850 nm IR when procuring a plate capture camera. Mount the camera so the vertical tilt does not exceed 25 degrees. Beyond that angle, the plate aspect ratio compresses and character recognition degrades regardless of resolution.
Sending an Image to the Recognition API and Interpreting the Response
The number plate recognition API follows a straightforward REST design. You POST a JPEG or PNG of the captured frame to the recognition endpoint, and the service returns a JSON object. A minimal curl example looks like this:
curl -X POST https://nprapi.com/api/v1/recognise \
-H "X-API-Key: YOUR_API_KEY" \
-F "image=@/tmp/forecourt_entry.jpg" \
-F "vehicle=true"
In single-plate mode the response returns the recognised registration string and a confidence value expressed as an integer between 0 and 100. If you enable multiple-plate detection, the response instead returns a plates array, where each element carries its own registration, confidence, and, where identifiable, an ISO country code. A well-captured UK plate on a clean entry camera will typically return confidence values above 90. A confidence of 75 to 89 warrants human staff review before any pump hold decision is automated. Below 75, the system should route to manual review and log the raw image for later audit.
Do not treat confidence as a binary pass-or-fail threshold on its own. A plate that reads confidently but returns no matching vehicle record, or hits a blacklist entry, is more operationally significant than a low-confidence read on a clean plate. Design your logic to act on confidence alongside the vehicle data and blacklist results, not instead of them.
Using the Vehicle Data Lookup Response
Enable the vehicle flag on the recognition request and the API returns, in the same response, the DVSA make, model and colour associated with that registration. This vehicle data is the principal mechanism for catching cloned plates, with no separate lookup call required.
Cloned plates are particularly difficult to detect by any means other than a live vehicle-data cross-check, because the plate string itself will recognise successfully and may even appear clean on a blacklist. The tell is the mismatch: the API tells you the plate belongs to a red Ford Focus, but the camera overview shows a white Volkswagen Transporter. That discrepancy is your trigger.
Request the vehicle data inline by setting the vehicle flag on the recognition call, and run your blacklist query in parallel with it so both results are ready together. Both should resolve before the pump enable decision is made, and the total round trip from image capture to decision should remain under two seconds for a smooth customer experience. You can cache a recognised plate and its vehicle data for the duration of a single visit, but do not cache beyond it, since registration status can change.
Record the make, model and colour returned by the API against the visual description captured by your overview camera. For manual review queues, presenting staff with the expected vehicle description alongside the live camera feed makes it straightforward to spot a mismatch without any technical knowledge.
Building the Blacklist Matching Step
A blacklist is a database of plate strings linked to previous drive-off or NMOP incidents at your site or at other sites in a shared network. The matching step queries this database using the plate string returned by the recognition API and returns a hit or a miss before the pump is enabled.
Repeat offending is a defining characteristic of forecourt fuel theft. A blacklist directly targets this cohort. The structural decision you face is whether to maintain a local list per site or to participate in a shared network. A local list is simple and carries no cross-site data-sharing obligations, but it only catches offenders who have previously visited your specific site. A shared network, such as those operated by BOSS, VARS Technology, and similar industry services, provides substantially broader coverage because a vehicle flagged at a site in Manchester is visible to a site in Bristol within minutes. If you are integrating with an existing operator's platform, check whether their blacklist is available via API, since you can incorporate the lookup into your own pipeline alongside the plate recognition call.
Store blacklist entries with a timestamp and an incident type code that distinguishes drive-offs from NMOP and from aggression incidents. Staff response to a known drive-off vehicle should differ from the response to a vehicle whose driver has previously claimed NMOP and not paid. Treat the blacklist as a soft signal, not an automated enforcement mechanism. A hit should hold the pump and alert staff, not lock the vehicle in or trigger any physical intervention.
Set a review cadence for blacklist entries. Entries based on NMOP incidents where payment was eventually recovered should be removed or marked as resolved. Stale entries that remain active indefinitely will erode operator trust in the system and risk an adverse impact on legitimate customers.
Triggering a Pump Hold or Alert via Webhook
The value of a pre-pump alert collapses if staff receive it after the vehicle has already started filling. The architecture must be event-driven from image capture through to alert delivery, with no blocking synchronous steps that add latency.
Design the flow as follows. When the camera captures a plate, your edge controller immediately POSTs the image to the recognition API with the vehicle flag enabled and runs the blacklist query in parallel. When any of the responses returns a flag, the controller fires a webhook to your in-store alert system. The webhook payload should include the plate string, the hit type (blacklist, vehicle mismatch, or low confidence), the pump number derived from the camera zone, and a thumbnail of the captured image. The alert system renders this on the cashier's screen with an audible tone and holds the pump relay.
Use a message queue between the camera controller and the alert delivery layer rather than a direct HTTP call. This decouples the two systems and ensures alerts are not lost if the in-store network is temporarily unavailable. A lightweight broker is sufficient for the throughput involved, since most forecourts process fewer than a few hundred vehicle arrivals per hour even during peak periods.
Test your end-to-end latency under realistic conditions. Image upload time over a standard broadband connection, API processing time, and webhook delivery together should complete in well under two seconds for vehicles travelling at walking pace into the forecourt. If the round trip exceeds this, profile each stage separately before assuming the API is the bottleneck. In most cases, image file size and connection quality are the variables within your control.
Handling Edge Cases
A production forecourt ANPR system encounters plate conditions that controlled testing rarely surfaces. Plan for each of the following before go-live.
Partially obscured plates arise from damaged plate surrounds, tow bars blocking the lower characters, or deliberate partial covering. When the recognition API returns a partial read, route to manual staff review rather than defaulting to either allow or deny. Log the partial string and the captured image so the incident can be investigated retrospectively.
Foreign plates are increasingly common, particularly at forecourts near ports, motorway services, or tourist routes. The recognition API detects international plates automatically, so enable multiple-plate mode and read the returned country code for each plate rather than assuming every vehicle is UK registered. For non-UK plates, DVSA vehicle data is not available, so apply a reduced confidence threshold for pump authorisation and consider requiring pre-payment for all foreign-registered vehicles at high-risk sites.
Dirty, damaged, or deliberately altered plates are the hardest case. A plate that a human eye cannot read will not be read by any recognition system. At sites with a known history of deliberate plate obscuration, a policy of refusing to enable pumps until a readable plate is confirmed is both operationally defensible and ICO-compliant, provided it is applied consistently and signage makes the policy clear to all customers.
Design a clean fallback for API timeout or service unavailability. Do not leave the pump defaulting to enabled because your integration failed to receive a response. The safe default is a held pump with a manual override for staff, accompanied by a clear error state on the cashier display.
GDPR, the Data (Use and Access) Act 2025, and Data Minimisation
A vehicle registration mark is personal data in the context of a forecourt ANPR system, because the purpose of the system is to identify an individual and potentially take action against them. The UK GDPR, read alongside the Data Protection Act 2018, therefore applies in full.
The Data (Use and Access) Act 2025 received Royal Assent on 19 June 2025. Its provisions affecting data protection law and the Privacy and Electronic Communications Regulations were implemented in staged commencement regulations, with the ICO confirming that all provisions affecting data protection law are now in force. The Act introduces targeted amendments to the UK GDPR and the Data Protection Act 2018, including a new "recognised legitimate interests" lawful basis that removes the need for a Legitimate Interests Assessment for a defined set of activities, and a codified "reasonable and proportionate" standard for responding to data subject access requests. For most forecourt operators, however, the core obligations remain unchanged: necessity, proportionality, and data minimisation still govern what you can collect and how long you can keep it.
The ICO is unambiguous: any organisation deploying ANPR must complete a Data Protection Impact Assessment before going live. The DPIA must show that the processing is necessary and proportionate, that risks to individuals have been minimised, and that data is limited to what is needed to achieve the stated purpose. For a forecourt drive-off prevention system, the stated purpose is the prevention of fuel theft and unpaid fuel incidents. Everything the system collects must be justified against that purpose alone.
Data minimisation is the most directly relevant principle for your integration design. Zero-retention processing means the recognition API processes the image in memory to return the plate string and confidence score, retaining neither the image nor the plate string after the API call completes. Your own system should retain the plate string only for the duration of the transaction. Plates associated with no flag are discarded immediately after the pump authorisation decision. Only plates that hit a blacklist or generate a staff alert are logged, and only for as long as is necessary to support any resulting debt recovery or police referral.
Signage is a legal obligation, not optional courteous disclosure. The ICO requires clear and prominent notices explaining that ANPR is in use, identifying the controller, and indicating how individuals can raise queries. Signs should be positioned at the forecourt entry where they are legible before a vehicle commits to entering the read zone. Your DPIA should document the signage placement as part of your transparency measures. If your site uses a shared network blacklist, the signage and privacy notice must also disclose that plate data may be checked against third-party databases for fraud prevention purposes.
Reference Architecture Summary
The following describes a production-ready architecture. An IP camera with 850 nm IR illumination is mounted at the forecourt entry lane and connected via Power over Ethernet to an edge controller, which may be a small form-factor server running in the cashier's office. The edge controller monitors the camera feed and triggers a still capture on vehicle detection. The captured JPEG is sent via HTTPS POST to the recognition endpoint as multipart form data. The API returns the plate string and confidence score, typically within 300 to 500 milliseconds on a standard broadband uplink.
The recognition call is made with the vehicle flag enabled, so it returns the plate and its DVSA vehicle data together, while a blacklist query against your local or shared offender database runs in parallel. The edge controller evaluates the combined results against your configured rules: a blacklist hit holds the pump and fires the alert webhook; a make, model, or colour mismatch against the returned vehicle data holds the pump and fires the alert webhook; a confidence score below your manual review threshold holds the pump and raises a staff query flag; a clean result on all checks enables the pump. The alert webhook payload is received by the in-store display system, which presents the plate, the hit type, and a thumbnail to the cashier with an audible alert.
The API calls required are minimal: one POST to the recognition endpoint per vehicle arrival, sent with the vehicle flag so the plate and its DVSA vehicle data are returned together, alongside your own blacklist query and, optionally, a write to your blacklist when staff confirm a new incident. The recognition call authenticates with an X-API-Key header and returns structured JSON. No image data is stored by the API after processing completes.
Build Sequence and Deployment Checklist
The architecture described in this guide is implementable by any developer with REST API experience. Most number plate recognition APIs provide a free tier that allows you to run your first plate recognition call in under five minutes using nothing more than curl and a test image. From there, the recommended build sequence is as follows: validate image capture quality using the recognition endpoint and the confidence scores it returns; enable the vehicle flag and confirm you can detect a make and model mismatch against a test plate; build the blacklist data model and query logic; wire up the pump relay via your forecourt management system's API or relay controller; and implement the webhook alert delivery to the cashier display.
Before go-live, complete and document your DPIA, commission an independent test of end-to-end latency under peak traffic conditions, train forecourt staff on the manual review workflow and the pump override procedure, and confirm that entry signage meets ICO requirements. A system that acts before the pump is enabled, rather than after the tank is full, is the most effective single intervention available to a forecourt operator. The fuel theft figures for 2026 make the business case self-evident. The DPIA, the staff training, and the latency testing are what determine whether that case is realised in practice.