What's being proposed
A royalty fee on TPS checks. The DMA, which operates the TPS and CTPS registers and licenses the data through its TPSL programme, is looking at charging a usage-based royalty on top of the licence fees that data providers already pay. The figure being floated in provider conversations is 10p per 1,000 checks, with an expected start in September or October 2026.
There is also talk of a cap on how much royalty can be charged, with a figure of around £3,300 mentioned, though the cap, like everything else here, is still to be determined.
Before anything else: this is not finalised. There is no published rate card, no confirmed start date, and no official announcement at the time of writing. The number and the timing come from conversations in the industry, and both could move. I'm writing about it now because if it lands anywhere near the floated shape, it changes the economics of how TPS screening is priced and architected, and teams that buy screening should understand what is coming.
The maths first, because it reframes everything
10p per 1,000 checks 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.
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. Per-check and per-batch providers add the royalty to their unit cost, usually with a margin on top. Expect per-check prices to tick up by more than a hundredth of a penny, because nobody passes a cost through at cost.
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
If the royalty lands, 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. And if the rumoured £3,300 cap materialises, the worst case is bounded, 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've made pass-through explicit and bounded. We updated our terms this week so that if a licensor fee like this one does land, we can pass it through on 30 days' notice, limited to a fair reflection of the actual third-party cost change. No opportunistic repricing dressed up as a royalty, and no surprise on your invoice: at the floated rate, the pass-through for a typical customer would be pennies per month, and we would say so plainly.
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
Nothing drastic, because nothing is finalised. But three cheap moves this month: ask your current screening provider in writing how they intend to handle a TPSL royalty if one is introduced; 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 if a royalty makes your screening bill move at all, that is the dial that controls it. If the proposal firms up, I'll update this piece with the confirmed numbers.