What's confirmed
The TPS royalty fee is live. Since 1 September 2026 the DMA, which operates the TPS and CTPS registers and licenses the data through TPSL, charges a usage-based royalty on records screened through list cleaners: 10p per 1,000 records processed, per client, per month. The DMA confirmed the model to us in writing on 18 September 2026.
- Rate: £0.10 per 1,000 records processed, calculated per client, per month.
- Start date: 1 September 2026.
- Cap: £3,300 per client per financial year. Once a client reaches it, no further royalty is charged for the rest of that year, so no client pays more than the annual TPS and CTPS licence fee.
- Exemption: a business that holds its own current, direct TPSL licence is not recharged, on proof of the licence.
- Collection: the list cleaner declares monthly volumes per client, receives one monthly invoice itemised by client, and recharges each client on TPSL's behalf.
I first wrote this piece on 6 August 2026, when the fee was a figure floated in provider conversations. The rate and the cap both came in as floated. What follows is the maths, how the market is likely to respond, and how TPSClear handles the fee.
The maths first, because it reframes everything
10p per 1,000 records is one hundredth of a penny per check. Put real volumes against it:
| Screening pattern | Checks per month | Royalty at 10p/1,000 |
|---|---|---|
| SME, event-driven screening on a 20k-contact CRM | ~5,000 | £0.50 |
| Monthly full-book batch, 100k contacts | 100,000 | £10 |
| Monthly full-book batch, 500k contacts | 500,000 | £50 |
| Daily full-book re-screen, 500k contacts | ~15 million | ~£1,500 |
Two things fall out of that table. First, for any sensibly architected screening setup, the royalty is pocket change. Second, for brute-force patterns, the ones that re-screen an entire database every day whether or not anything changed, it is real money. The fee doesn't punish screening. It punishes wasteful screening.
The cap bounds the last row. A daily full-book re-screen of 500k contacts reaches £3,300 in its third month and pays nothing further that financial year. At 10p per 1,000, the cap equals 33 million records a year.
Why a royalty, and why now
The registers have to be funded somehow. Historically that has been flat licence fees from TPSL licensees, who then price their own products however they like: per check, per batch, or flat-rate unlimited. A flat licence with unlimited downstream usage means the register operator's revenue is disconnected from how heavily the data is actually worked. Usage-based royalties reconnect the two. It is the same shift you have seen in every other data industry: credit files, company data, postal address files. From the operator's side it is a rational move. From the buyer's side it means the era of genuinely unlimited flat-rate TPS checking is probably closing, because every check now carries a marginal cost for someone in the chain.
How the market will likely respond
Based on how previous repricing rounds in this space have gone, I expect four reactions, three of them fine and one of them genuinely dangerous.
1. Providers reprice per check
The straightforward response. The DMA's model is a recharge at the royalty rate, but per-check and per-batch providers can fold it into their unit cost with a margin on top. Expect some per-check prices to tick up by more than a hundredth of a penny.
2. "Unlimited" plans grow fair-use clauses
Flat-rate unlimited screening becomes hard to sustain when the upstream cost is metered. Watch for existing unlimited plans to acquire fair-use caps, resale restrictions, or quiet per-check overage tiers. If you rely on an unlimited plan today, read your renewal terms carefully this autumn.
3. Screening architectures get smarter
The good outcome. When every check has a marginal cost, the incentive is to check the right numbers at the right moments instead of carpet-bombing the whole database on a schedule. Event-driven screening, dial-time screening, and sensible caching all get more attractive. More on this below, because it is where the real answer lives.
4. Some teams cut screening to save pennies
The dangerous one. A team sees a new line item, decides screening is now "expensive", and stretches their cadence from monthly to quarterly, or stops re-screening changed numbers. Look at the table above again: the saving is pounds. The exposure is not. ICO monetary penalties for unlawful marketing calls run to six figures, and the enforcement record shows the ICO fines companies for not screening, not for screening imperfectly. Cutting compliance cadence to dodge a royalty measured in hundredths of a penny is the worst trade in telephone marketing.
What the best solutions look like
Under a per-record royalty, the winning architecture is the one that minimises wasted checks while keeping verdicts fresh where it matters. Three principles do most of the work:
Screen on events, not on a calendar. Check a number when it enters your CRM and re-check it when it changes. A contact whose number hasn't changed and who isn't being called doesn't need a daily re-screen. This is the difference between the 5,000-check row and the 15-million-check row in the table above, on the same database. The £3,300 cap bounds the worst case, but a cost you can architect down to pennies is better than a cost you merely cap.
Screen close to the dial. The verdict that matters is the one that is fresh when the rep picks up the phone. Screening a call queue as contacts enter it, or screening at dial-time itself, concentrates your checks on the numbers you are actually about to call. It is simultaneously the cheapest pattern under a royalty and the strongest position under PECR, because the closer to the call you screen, the more defensible you are.
Cache within the data-refresh window. TPS reference data works on a 28-day refresh standard. Re-checking the same number against the same underlying data file five times in a week produces four identical verdicts. A screening layer that remembers what it checked, and only spends a fresh lookup when the answer could actually have changed, cuts royalty-bearing volume without touching compliance posture at all.
How TPSClear meets this
Mostly, we built for this shape before the royalty was floated, not out of foresight but because event-driven screening was already the right compliance answer. Concretely:
Our architecture is event-driven by default. Inside the HubSpot integration, numbers are screened when a contact is created and re-screened when a phone number changes, with workflow actions to screen call queues on demand. We do not re-screen your whole database daily on a timer. Under a per-check royalty, that is the difference between a negligible cost and a four-figure one at scale.
We pass the royalty through at cost. Our terms allow a licensor fee to be passed through on 30 days' notice, limited to a fair reflection of the third-party cost. For the royalty that means the DMA's rate: 10p per 1,000 checks, capped at £3,300 per customer per year. A 10,000-check month carries £1 of royalty. A customer holding their own current TPSL licence is exempt, on proof of the licence. Plan prices are on the pricing page.
We will not compete on cut corners. If the royalty creates a market for "cheaper" screening that quietly checks less often, we are not entering it. The point of TPS screening is standing in front of the ICO with a defensible record. A screening product that optimises its own royalty bill by letting your verdicts go stale has failed at the only job you bought it for.
What to do now
Three cheap moves this month. Ask your current screening provider in writing how they are recharging the TPSL royalty and at what rate. Check whether your plan's pricing terms allow silent repricing or require notice. And look at whether your own screening pattern is event-driven or calendar-driven, because that is the dial that controls how much royalty you pay. If your volume would reach the cap, 33 million records a year, a direct TPSL licence costs about the same £3,300 and carries no royalty.