Can a tag run a return or deposit scheme?
For beverage containers the deposit is counted by a printed code, because a single use container cannot carry a tag at that price. A tag earns its place on a returnable asset worth tracking one by one, and the hard part is not reading it but making sure a unit cannot be claimed twice.
Which schemes the rules cover
regulation (EU) 2025/40 on packaging requires Member States to set up deposit and return systems for single use plastic beverage bottles and single use metal beverage containers up to three litres, with a deposit charged at the point of sale, and sets minimum requirements for those systems in its annex X.
Those containers are made in enormous numbers and thrown away once. The economics decide the carrier before anything else does, and it is a printed code with a harmonised label beside it.
A tag enters the conversation for the packaging the same regulation treats separately, reusable formats, and for everything outside beverages: the returnable asset that comes back many times.
Where a tag pays for itself
A crate, a keg, a gas bottle, a tool on loan, a rental garment, a refillable container with a deposit attached. Each comes back repeatedly, so the tag is bought once and used for years, and the asset page covers what happens when the tag outlives the thing.
Each is also handled one at a time by a person at the moment of return, which is the reading situation NFC suits. A returns desk with a phone is a reader that costs nothing, and the inventory page sets out when that is the right choice and when it is not.
And each is worth identifying individually, because the deposit is attached to a unit rather than to a type.
Counting each unit once
A deposit turns an identifier into money, which changes the threat model completely. If the scheme pays on a number the tag returns, then a copy of that number is a claim, and identifiers can be copied, as the cloning page sets out.
Two defences do most of the work. The state lives on the server: a unit is marked redeemed when it is paid, and the second claim on the same identifier is refused rather than paid. And the identifier is not guessable, so an attacker cannot enumerate units that exist without holding them.
Beyond that is cryptographic authentication, where the tag proves it is itself rather than repeating a number, which the authentication page weighs. The deposit value per unit is what decides, and for most returnable assets the server side check is enough.
The detection case is worth knowing too: two claims on one identifier is exactly the signal the clone detection page describes, and a scheme sees it before anyone else does.
What the operator has to report
The minimum requirements in the packaging regulation include control procedures and reporting systems that let the system operator obtain data on what was collected. A scheme is measured on what came back.
Per unit records turn that reporting into a query rather than a count, and they answer the question a weight based count cannot: which units never came back, and from where.
That is also the number that pays for the tags. A returnable asset scheme lives or dies on its loss rate, and a scheme that cannot name what it lost cannot reduce it.
Frequently asked questions
Why not put tags on bottles?
A single use container is made in enormous numbers and discarded once. The deposit is counted by a printed code, and the regulation pairs it with a harmonised label.
What stops someone claiming a deposit twice?
The server, not the tag. A unit is marked redeemed when it is paid, and a second claim on the same identifier is refused.
Does the scheme need cryptographic tags?
Only where the deposit per unit justifies it. A server side state and an unguessable identifier handle the ordinary case.
What does per unit tracking add?
It names what did not come back. A loss rate with units attached is actionable, and a weight based count is not.