Call centres carry a regulatory exposure that scales linearly with dial volume. A single misconfigured campaign on a forty-seat floor produces more PECR-relevant call attempts in a week than most in-house sales teams produce in a year. The ICO enforcement pattern reflects that. Almost every public PECR penalty involves an outbound operation, and almost every one cites a screening regime that was either absent or running on stale data.
Volume amplifies risk
At in-house volumes, the maths is forgiving. One bad campaign produces a handful of complaints, the regulator does not usually engage, and the operational fix is cheap. At BPO and outsourced-dialler volumes, the same percentage of bad numbers produces hundreds of complaints, and a handful of those land at the ICO at the same time. The investigation that follows is not about the campaign in front of the regulator; it is about every campaign that touches the same dialler. The fix is no longer cheap and the contractual exposure to the end client widens at the same time.
See the public cases in ICO PECR fines and enforcement cases. The fines that get reported are not the worst-behaved operators; they are the ones whose screening regime collapsed under scrutiny.
Batch screening is no longer sufficient at scale
The traditional pattern is a nightly batch: pull the day's list, push it to a TPS vendor, suppress on return, dial the rest. That worked when daily list churn was modest and most registrations were stable. Two things have changed. First, TPS registration volumes spiked after the recent waves of cold-call enforcement and consumer awareness; the register adds meaningful net new numbers every day. Second, modern outbound stacks pull from multiple data sources continuously, so the list a dialler sees at 11:00 is not the list it screened at 02:00.
The window between the batch screen and the dial is exactly where the breaches occur. A number that registered yesterday evening is on the register this morning and will be dialled at lunchtime if the regime relies on a once-a-day refresh. See how often to check TPS for the cadence that holds up under audit.
Real-time webhook plus daily backfill
The pattern that scales is the one TPSClear is built for: webhook-driven screening on every contact create or phone-number update, plus a daily backfill across the entire dataset. The webhook handles new and edited records inside seconds. The backfill catches the registration changes that happened on the TPS side rather than yours. Together they keep every number's status fresh enough that the dialler never sees a stale verdict.
The cadence-tool gap
Outreach, Salesloft, NICE CXone, Genesys: none of these tools check TPS. They were not built to. They consume a list and execute the cadence. The compliance layer has to live one step earlier, in the system that owns the contact record, and the cadence tool has to be configured to skip rows where the screened status is registered. If the screened status is not on the contact record, or it lives in a separate compliance tool that the cadence tool does not read, the gap is open by default.
Lead-data vendors do not close the gap either. ZoomInfo, Lusha and LeadIQ ship numbers without TPS status. Treating those feeds as compliance-clean because they are paid is a common and expensive mistake. See the lead-data vendor comparison for the detail.
The audit-trail requirement
The ICO request that lands after a complaint is specific. It wants the per-number screen result at the moment of the call, the screening cadence, the system that enforces it, the consent record where one exists, and the policy that ties the regime together. A call centre that can produce only the latest status of a number, not the historical timeline, will struggle. PECR breaches are assessed at the time of the call, not at the time of the investigation.
TPSClear retains six years of per-property screen history per contact, which matches the ICO's investigative window and gives the operations director something concrete to hand the regulator on day one.
Per-agent and per-campaign verdicts
A common failure mode is the contact record where a phone is flagged as registered but the cadence tool dials it anyway, because the flag lives in a different field, or because a manual edit cleared it, or because a campaign-level override was set "for this round" and never cleared. The fix is a screened status per phone property (so a flagged direct dial cannot leak through a switchboard field), a verdict that the cadence tool treats as immutable until a new screen runs, and a clear suppress-on-registration default at the campaign level.
See calling a TPS number with consent for the narrow exception that lets a registered number remain in cadence, and the consent evidence the regulator expects.
The API pattern for very large volumes
At hundreds of thousands of dials a day, the right pattern is often direct API integration upstream of the dialler rather than a CRM-side property. TPSClear exposes a screening endpoint that accepts a number, returns a TPS or CTPS verdict with a timestamp, and is designed for hot-path use ahead of dial. The verdict is logged centrally so the audit trail still resolves to a single source of truth across multiple dialler instances and tenants.
The developer documentation covers the endpoint, the rate model and the recommended cache-and-refresh pattern for very high-volume operators.