Full article
Overview
Proof-of-purchase campaigns look tidy in a planning deck and rather less tidy once they meet the public internet. This case study covers how a UK brand team tightened delivery risk controls around a POPSCAN redemption flow to improve proof of purchase verification without turning the customer journey into a bit of a faff.
We treated it as a systems problem. Baseline signals across a six-week period in January and February 2026 pointed to duplicate claims, low-quality receipt uploads and inconsistent fulfilment checks. After shipping a layered control model, indexed suspect claims fell, manual review demand dropped and straightforward approvals moved faster. Useful progress, with the usual caveat: fraud adapts. You do not solve it once; you build, ship, test and keep watching the joins.
Starting context
Last Thursday, in our studio just after a cup of tea had gone lukewarm, one dashboard told a familiar story. Approval rates looked healthy enough, but fulfilment notes and support tickets were hinting at a different truth. A campaign can appear efficient while quietly paying out on claims that should never have made it through. That is when I realised, again, that clean top-line redemption numbers can hide messy operational risk.
The brief was precise: improve proof of purchase verification in a UK promotional flow without making honest customers work for it. The campaign relied on uploaded till receipts and pack barcodes to validate eligibility for a consumer offer. Baseline data showed three practical issues. First, duplicate submissions were arriving with small variations in image crop, file compression or claimant details. Second, some receipts were readable to a human but too poor for reliable machine extraction. Third, fulfilment decisions were being made with uneven evidence, which pushed the operations team towards edge cases instead of obvious anomalies.
We cannot publish client-sensitive volumes, so we used indexed figures. Suspect claims sat at 100. Manual review demand sat at 100. Customer service contacts linked to claim uncertainty sat at 100. The point was not theatre; it was comparability. The queue was large enough to slow fulfilment and irritate good customers, which is usually where the hidden cost lives.
We also had a wider signal worth noting. Across digital systems, weak verification points attract pressure. The exact fraud pattern varies by sector, but the mechanics are familiar: replayed evidence, edited documents, mismatched product logic and inconsistent handling. If a platform cannot explain its decisions, it does not deserve your budget. So we avoided black-box scoring and focused on signals the team could inspect and defend.
How we mapped the system and its weak points
Before touching tooling, we mapped the flow end to end: submission, extraction, validation, deduplication, operator review, fulfilment release and post-approval audit. That sounds obvious. It rarely is. Many campaign stacks are assembled by committee, with one vendor handling the form, another the processing and a third the fulfilment. Risk leaks in the joins.
We grouped threats into four buckets. One, replay: the same purchase evidence used multiple times. Two, fabrication: an image or transaction detail appearing edited or synthetic. Three, mismatch: pack, product and retailer logic not lining up. Four, operational drift: internal handling creating inconsistency. The trade-off was straightforward. Every added check can suppress abuse, but it can also suppress legitimate claims if applied too bluntly.
Between 10:00 and 12:30 one Tuesday, we tried an aggressive ruleset on historical data and immediately created too many false positives on crumpled supermarket receipts. Fixed it with a simpler hack: separate evidence confidence from eligibility confidence. In plain English, a poor image is not automatically a bad claim. It is a claim that may need a different path.
That distinction shaped the design. Instead of one opaque pass-or-fail state, we used layered statuses: accepted, accepted with audit flag, manual review and rejected with reason code. That gave operations staff and brand managers a legible chain of evidence. If a claim passed because the receipt date was readable, the retailer matched, the promoted product line aligned and the barcode event was clean, we could show it. If it failed, we could show why.
Intervention design
The intervention had three moving parts, all aimed at reducing abuse without over-collecting personal data.
First came stronger image handling for receipt checks. We added upload guidance at the point of capture, then a pre-processing stage to standardise orientation, contrast and crop detection before extraction. That improved machine readability and reduced the number of cases where operators had to squint at grey thermal paper. We also stored image-quality metadata separately from claimant identity, which kept the architecture privacy-conscious and easier to audit. Cleaner data usually means fewer people need to touch it. Fancy that.
Second came structured barcode matching. Rather than treating barcode presence as enough, we checked whether the scanned or entered code aligned with the promoted SKU set, submission timing and retailer context. If a barcode belonged to the right product family but not the qualifying pack size, the claim did not auto-fail. It moved to manual review when receipt evidence looked strong. That was a deliberate trade-off: harder rejection would cut some abuse, but it would also punish honest confusion and create avoidable support traffic.
Third came a risk layer for promotion fraud controls. This covered duplicate pattern detection across receipt line items, image fingerprints, claim timing and delivery details. We were careful here because similarity is not guilt. Shared IP addresses happen in offices, student halls and mobile networks. Families do buy the same products more than once. So the model only escalated when multiple weak signals combined. Automation without measurable uplift is theatre, not strategy.
We also built a thin audit trail around each decision. Operator actions were tagged with reason categories, and monthly spot checks sampled accepted claims as well as rejected ones. That point is dull but essential. Teams often audit declines while the larger financial leak sits inside over-confident approvals.
Observed outcomes
By the end of the first eight-week live period, from 6 January to 2 March 2026, the indexed results moved in the right direction. Suspect claims fell from 100 to 61. Manual review demand fell from 100 to 68. Customer service contacts linked to claim uncertainty fell from 100 to 73. Average time to clear straightforward claims improved by 19%.
The strongest gain came from better evidence capture and structured validation, not from the more theatrical parts of risk scoring. Worth saying plainly. Better inputs did more work than cleverer dashboards. Rubbish in, rubbish out, only in a smarter font if you are not careful.
We tracked one narrower quality measure as well: the proportion of claims entering manual review because the receipt could not be interpreted with confidence. That dropped by 37% over the live period. Operator notes also became shorter and more consistent because reason codes nudged staff towards the same judgement frame. A decent system makes the right thing easier, not merely available.
There were caveats. First, part of the reduction in suspect claims may reflect deterrence rather than pure detection. When abuse becomes awkward, some bad actors simply move on. Second, campaign mix matters. Grocery promotions with heavy volume behave differently from a niche electronics rebate. Third, no control stack catches every edge case. A recent piece from PhishProtection.com on 6 March 2026 made the broader point that layered anti-abuse measures can improve resilience even when budgets are tight. Fair enough. My caveat is simple: low-cost controls are fine until explainability or support disappears during a spike.
What we would change next
If we were shipping the next version on Monday, I would make four changes.
First, push more retailer-specific logic upstream. Thermal receipts from different chains fail in different ways. A one-size-fits-all parser is tidy for procurement and untidy for outcomes. More setup, fewer exceptions.
Second, add a lightweight learning loop for the review team with strict guardrails. Not a black-box model deciding who gets approved. A suggestion layer that spots repeated patterns in operator-labelled edge cases and proposes new review rules. The human reviewer stays in charge.
Third, tighten post-fulfilment audits. Monthly sampling was useful, but fortnightly checks would be better for higher-risk campaigns, especially in the first six weeks after launch when behaviour is still settling. Early drift is common and expensive.
Fourth, formalise risk thresholds by campaign value. Not every offer needs the same scrutiny. A low-value promotion can tolerate more frictionless approval if downside is modest. A higher-value reward justifies heavier controls. Applying identical handling to every offer is administratively neat and commercially sloppy.
There is a broader lesson for UK teams running redemption mechanics. Treat campaign integrity as an operating system, not a bolt-on plugin. Build clean evidence capture. Validate against product reality. Keep the audit trail legible. Last Wednesday, while Sunderland sat at around 4°C with that bright cold glare on the windows, we reviewed the live queue and found something reassuringly unglamorous: fewer weird cases, faster clean approvals and calmer operators. That is what good control design looks like in practice. If your team wants a practical view of where value is leaking, run a POPSCAN abuse-risk review with Kosmos and we will map the weak joins, the likely failure points and the controls worth shipping first.
