The question

In a high‑volume Deposit Return Scheme (DRS), how do Reverse Vending Machines actually prevent fraud and mis‑redemption, what happens when something slips through, and how is the financial risk shared between the scheme operator (DMO), retailers, and technology suppliers?

The direct answer

A well‑designed DRS assumes that fraud attempts will happen and builds multiple technical and financial safeguards around that reality. RVMs use layered validation—barcode, database lookup, material, weight, dimensions, silhouette and high‑frequency movement monitoring—to accept only eligible containers and to block suspicious behaviour such as pull‑backs, swaps or repeated use of already processed containers.

On the financial side, the DMO typically operates a double‑entry system with each retailer: deposits collected on sales are debits, deposits refunded on returns are credits. Differences are settled on a regular cycle. If an ineligible object is accepted and refunded, the cost ultimately sits in the DRS system, so scheme operators issue strict specifications and approval processes for RVMs to minimise that risk.

Retailers, who are obliged to collect containers but want to minimise CAPEX and OPEX, must therefore choose machines that satisfy the DMO’s anti‑fraud requirements rather than the cheapest “bin with a hole and a crusher”. Voucher fraud is controlled the same way: the RVM, via a fleet portal such as RecyHub, obtains single‑use, time‑limited voucher codes from the POS system so that photocopied or reused vouchers are automatically rejected at the till.

What “anti‑fraud technology” really means in an RVM

An RVM in a DRS is not just a compactor with a slot. It is a decision engine. For each container, it typically performs a sequence of checks:

1. Barcode and database lookup

   • Read the barcode.
   • Check against the DRS container database maintained by the scheme operator.
   • Confirm that the product is in scope (material, volume, deposit value).

2. Material verification

   • Confirm that the object’s material matches the database entry (PET vs aluminium vs glass) using appropriate sensors.

3. Weight check

   • Weigh the empty container and compare it to the expected weight range from the DRS data.

4. Length and diameter check

   • Measure the physical dimensions and verify they align with the registered values.

5. Silhouette / computer vision check

   • Capture the outline and key features of the container and compare them to expected patterns for that SKU or category.
   • Reject containers whose shape is inconsistent with the reference, even if the barcode appears correct.

6. Movement and behaviour monitoring

   • Track the container’s movement through the infeed at high frequency.
   • Detect attempts to pull the container back suddenly (“fishing line”) or insert an arm or object to interfere with the mechanism.
   • Abort the transaction and withhold any refund if movement does not match the expected pattern.

Only when all relevant criteria are satisfied does the RVM:

• Accept and compact (or otherwise route) the container.
• Add its deposit to the current session’s total.
• Ultimately issue a voucher or trigger a refund.

This is what distinguishes a compliant RVM from a basic crusher: the ability to say “no”, and to refuse to issue a refund when inputs or behaviour fall outside strictly defined rules.

How the DMO sees it: double‑entry and reconciliation

In a DRS, the scheme operator’s core task is to manage flows of money, data and material between producers, retailers and recyclers. For each retailer, the DMO effectively runs a double‑entry account:

• On sale (debit):

  • When the retailer sells a drink, they collect the deposit from the consumer.
  • This creates a liability from the retailer to the DMO, because that deposit must ultimately be available to refund somewhere in the system.

• On return (credit):

  • When the retailer collects a container and pays a deposit refund (manually or via an RVM voucher), this creates a credit from the DMO to the retailer.
  • The DMO also typically pays a handling fee per container to compensate the retailer for non‑recoverable costs of hosting return points.

On a regular basis (weekly, monthly):

• The DMO aggregates sales and returns data (from producers, EPOS feeds, RVM fleets and manual return points).
• It computes the net position for each retailer.
• A settlement payment flows one way or the other.

For a large retailer with hundreds or thousands of stores and many RVMs, this requires detailed reporting:

• Per store: drinks sold (by DRS category) and deposits collected.
• Per return point: containers returned, vouchers/refunds issued, bag IDs, weights, and error events.

That is why DMOs publish technical specifications for RVMs and operate an approval process: only machines that can provide the required data integrity and anti‑fraud capability may be installed as official return points.

Typical fraud scenarios and how RVMs and vouchers counter them

A well‑designed DRS assumes that people will attempt to exploit differences between markets, packaging and systems. Some common patterns include:

Container swap at the infeed

A fraudster:

• Presents a valid DRS container to the camera or sensor.
• Then quickly swaps it at the entrance for a container that is not deposit‑bearing (for example, from a non‑DRS country over a land border).

Countermeasures:

• Continuous high‑frequency monitoring of the object at the infeed (not just a one‑off scan).
• Barcode read linked tightly to the physical object tracked through the tunnel.
• Silhouette and movement checks that detect a “new” object appearing where a different one was expected.

Fake barcodes on ineligible objects

A fraudster:

• Photocopies legitimate barcodes and sticks them onto rolls of paper or other cylindrical objects.
• Inserts these into the RVM to obtain deposit refunds without returning real containers.

Countermeasures:

• Material detection: reject paper, cardboard and other non‑container materials.
• Weight and dimensions checks: reject objects whose physical properties do not match the registered container profile.
• Silhouette checks: shapes that do not match the expected outline are rejected, even if the barcode is technically readable.

Unpaid containers taken from the shelf

A fraudster:

• Takes a drink from the shop shelf without paying for it.
• Immediately feeds it into the RVM to obtain the deposit value.

Countermeasures:

• DRS design and store procedures (for example return areas beyond tills, physical separation of in‑store consumption, CCTV and loss prevention).
• While this type of fraud is more about retail theft than DRS mechanics, the DMO and retailer must consider it in overall scheme design.

“Fishing line” attempts

A fraudster:

• Attaches string or fishing line to a container.
• Tries to have the machine count and pay out, then pulls the container back to repeat the process.

Countermeasures:

• High‑frequency tracking of the container’s position; if it does not progress as expected, the machine aborts the session and does not issue a refund.
• Pullback detection rules that treat sudden reversals as fraud attempts.
• Internal geometry that makes pullback physically difficult once acceptance has started.

Re‑processing already processed containers

A fraudster:

• Collects compacted containers from bags or from other sources.
• Attempts to feed them through machines again.

Countermeasures:

• Computer vision and silhouette checks that recognise “already compacted” shapes and reject them.
• Weight and dimension anomalies (a crushed can will not behave like a fresh one).
• Scheme‑level rules about material flows and counting‑centre reconciliation.

Photocopying or reusing vouchers

A fraudster:

• Photocopies a valid RVM voucher or takes a clear photo of it.
• Attempts to redeem the same code multiple times at different tills or even different stores.

Countermeasures:

• Voucher issuance controlled by the retailer’s POS or promotions system, not by the RVM itself.
• RecyHub (or the equivalent fleet portal) requests a single‑use voucher code from POS for each completed RVM session; once redeemed, that code is immediately marked as used and cannot be accepted again.
• Time‑limited validity: the POS system can be configured to expire voucher codes after a short period (for example a few hours), so even unused codes become invalid quickly.
• Real‑time validation at the till: every scanned voucher is checked against the POS database; photocopies or screenshots of already‑redeemed vouchers are rejected automatically.

In other words, even if a fraudster can reproduce the image of a voucher, they cannot reproduce its validity: the underlying code is single‑use, centrally managed, and time‑bound.

Who pays when something goes wrong?

Despite best efforts, two broad categories of problem can occur:

1. False negatives – legitimate containers are rejected.

   • Outcome: customer frustration, operational friction, potential complaints.
   • Financial impact: underpayment of deposits; typically addressed through customer‑service processes at store level.

2. False positives – ineligible objects are accepted and refunded, or invalid vouchers are honoured.

   • Outcome: the DRS pays out deposits it should not have paid.
   • Financial impact: the cost of fraud ultimately sits in the DRS system (and indirectly with producers and consumers), unless specific liability is contractually assigned.

Because of this, DMOs:

• Specify minimum technical requirements for RVMs (including fraud‑prevention capabilities).
• Approve only machines that meet these standards as official return points.
• Use data from RVMs, logistics and counting centres to monitor anomalies and adjust scheme parameters over time.

Retailers:

• Want to minimise both CAPEX (purchase or lease cost of machines) and OPEX (maintenance, staff time, space).
• May be tempted to choose the simplest, cheapest hardware.
• Must nevertheless satisfy the DMO’s anti‑fraud and data requirements if they are to operate as authorised return points.

RVM suppliers:

• Carry the responsibility for implementing the required technical controls.
• Provide fleet‑management platforms and reporting that support both retailer needs and DMO interfaces.
• Work with DMOs during approval processes to demonstrate compliance.

In practice, contracts between retailers, suppliers and the DMO will define how specific risks and liabilities are shared for particular incident types.

Why fraud‑resilience is fundamental to a successful DRS

A successful DRS is measured not only by high return rates and clean material streams, but also by:

• Low levels of fraud and leakage.
• Trust from producers, retailers and consumers that the system is fair.
• Predictable, reconcilable cashflows across the value chain.

If RVMs were simply “bins with holes and crushers”, the system would be wide open to manipulation:

• Containers from non‑DRS markets could be monetised repeatedly across borders.
• Fake or altered barcodes could be used to extract deposits without real recycling.
• Photocopied vouchers could be redeemed multiple times.
• The integrity of “return‑to‑retail” models—where stores both sell and take back containers—would be undermined.

Instead, the modern RVM and voucher stack form a controlled gateway:

• The machine refuses containers that do not match all criteria.
• The machine withholds refunds when movement patterns suggest manipulation.
• Vouchers are generated centrally, used once, and expire quickly.
• Detailed event and voucher data feed store, retailer and scheme‑operator reconciliation.

For retailers and DMOs, this is not an optional “nice to have”; it is what makes a high‑performing DRS financially and politically sustainable.

Choosing RVMs and voucher architecture with the right anti‑fraud capabilities

For retail property, IT and finance teams, key points to consider include:

• Does the RVM integrate with the scheme’s official container database and update reliably?
• Which layers of validation are implemented (barcode, material, weight, dimensions, silhouette, movement)?
• How are fraud attempts detected, logged and reported for investigation?
• Is the RVM approved, or approvable, under the DMO’s technical specification for official return points?
• Does the voucher architecture (RVM + RecyHub + POS) guarantee single‑use, time‑limited codes with full traceability?
• Can the supplier’s fleet portal provide the analytics and audit trails required by both your internal teams and the DMO?

Recyclever’s RVMs and RecyHub have been designed around these requirements: multi‑layer validation in DRS mode, AI‑based recognition and silhouette checks where appropriate, and full integration with POS and DRS platforms. To discuss fraud‑prevention requirements for your specific estate and scheme context, visit:

• https://www.recyclever.com/