Every few weeks an engineering lead asks me, half-apologetically, whether they should just build their own TPS check. It is a reasonable question. The TPS and CTPS are well-defined registers, the rules in PECR are stable, and a competent team could absolutely roll their own pipeline. The honest answer is that it depends on volume, on what your engineers are already paid to do, and on how patient your sales team is willing to be.
I have shipped both versions of this. I have built screening pipelines for telephony platforms and I now run a hosted one. What follows is what I tell people on the call before they decide.
What you actually need to build
A working in-house TPS check is not just a database lookup. To do the job that an external service is doing for you, your build has to cover roughly the following:
- A DMA TPSL list-cleaner licence. This is the gateway. You cannot legally hold or use the bulk register data without one. The DMA grants the licence on the basis that you screen against it, not that you republish it.
- A daily ingest pipeline. Download the latest register, parse it, dedupe against what you already hold, store the deltas. This runs every working day, including the days your team would rather be doing something else.
- Phone-number normalisation. E.164 in, the various UK shapes (07, +44 7, 00 44 7, leading zero stripped) reconciled to one canonical form. Get this wrong and your false-positive rate looks fine in QA and terrible in production.
- Per-CRM integration code. HubSpot, Salesforce, Pipedrive, Dynamics, plus whatever the new sales hire used at their last job. Each one has its own auth model, rate limits, and idea of what a phone field is.
- A webhook listener for change events. When a contact is created or a phone number is edited, you need to screen it within seconds, not on tomorrow’s overnight job.
- A backfill scheduler. Every contact you already hold needs re-screening on a cadence, and the cadence has to back off when the register has not moved.
- An audit log retained for six years or more. If the ICO ever asks why you called a registered number, “our system said it was clear” is not enough. You need to show which version of the register was used, when, and what verdict was returned.
- Monitoring and alerting. The download fails. The parser hits a row it has not seen before. The webhook backs up. None of these are exotic problems, but all of them need an on-call owner.
None of this is impossible. It is just a list of work items that someone has to own forever, not just until the launch retrospective.
The honest cost breakdown
Treat the numbers below as rough ranges, not quotes. They will move with your seniority mix, your CRM count, and how much of the work you already have lying around in adjacent systems.
| Line item | Rough cost | Notes |
|---|---|---|
| DMA TPSL list-cleaner licence | Approximately £3,300 / year + VAT for the annual licence | Tiers vary by use case. Ad-hoc one-month options sit around £300. Treat the figures as a starting point and confirm with the DMA. |
| Engineering build | 4 to 8 weeks of senior dev time | At a loaded cost of roughly £600 to £1,200 per day, that is around £15k to £40k for the first usable version. |
| Per-CRM integration | 1 to 3 weeks each | The first integration is the slowest. The third is faster. The fifth is still not free. |
| Ongoing maintenance | Roughly 5 to 10 percent of build cost per year | Register format changes, CRM API deprecations, edge cases the first build did not anticipate, on-call coverage. |
The licence alone, year on year, is in the same ballpark as a couple of seats on a hosted service. The build cost is the part that quietly compounds, because the team that built it usually also moves on.
When build wins
There are real cases where building is the right call.
- You are a large enterprise with strict data residency or on-prem requirements. If your security team will not let phone numbers leave a specific tenancy, an external API is a non-starter regardless of price.
- You already run a similar pipeline. If you ingest and reconcile other regulated lists daily, adding TPS is an incremental cost rather than a new capability.
- You are a regulated entity that security-reviews every external API. Banks, insurers, and a few healthcare businesses fall here. The cost of a vendor review can easily exceed the cost of an internal build.
When buy wins
For most teams I speak to, the picture is the other way round.
- You are a low-volume shop. 60 to 100 calls a day, one CRM, no data team. You need verdicts, not infrastructure.
- Your sales team will not wait eight weeks. The cost of a delayed launch, in pipeline terms, is almost always larger than the licence and subscription combined.
- Your engineering capacity is precious. If your backlog is full of revenue-generating work, the opportunity cost of a TPS build is the feature that did not ship.
The TPSClear pricing wedge
For the low-volume case, our pricing is designed to make the build question moot. The free tier covers a real workload (not a trial), and Starter is £29 per month. Both include TPS and CTPS in a single lookup, with the audit log and the per-CRM integrations already done. Detail is on the pricing page.
The point is not that we are cheaper than the licence. The point is that for teams below a certain volume, the in-house build never pays back, regardless of how lean you make it.
The hybrid path
The most common compromise I see, and the one I would pick if I were on the buyer side, is hybrid. Use TPSClear’s API for the register lookup, and write your own thin integration code on top. That gives you control of the workflow inside your stack, the audit log you want, and the routing rules your compliance team has signed off on, without you owning the licence, the ingest, or the normalisation. The developer docs show what the API surface looks like, and the CRM integrations page shows the off-the-shelf path if you want to skip the integration work entirely.
A five-question decision framework
If you are still on the fence, here is the checklist I work through on the call.
- Are you screening more than a few thousand numbers a day? If no, buy.
- Does your security team prohibit external APIs for phone data? If yes, build (or hybrid with on-prem caching).
- Do you already run daily regulated-data ingest pipelines? If no, the build is more than it looks.
- Can you afford to wait six to eight weeks before the first call is screened? If no, buy.
- Do you have a named owner who will still care about this in two years? If no, the build will rot.
Three or more “buy” answers is, in my experience, the usual outcome.
The honest close
I am obviously not neutral here. I sell a hosted TPS check. But I would rather you build it yourself than buy something that does not fit, and there are teams for whom building is genuinely the right answer. If you are a large regulated business with the engineering depth to absorb the work, do it properly. If you are a sales-led team that just needs verdicts, do not let an engineer talk you into a six-week project that ends in a dashboard nobody owns.
The deeper background on what the register actually exposes, and why the bulk-download model exists at all, is in the TPS register and its API. That is the right next read if you are leaning towards build.