TL;DR some of your calls will be blocked in 7 days
On this blog last week we explained the additional actions we were taking to combat nuisance calls both to your customers and in some cases by your customers. We explained how we’d implemented changes when guidance from Ofcom was published in 2018, which other providers seem to be presenting as new in 2025. This wasn’t a comfortable process for us at the time, being first never is, but Simwood customers led the charge by ensuring for example that all calls had valid CLI. We really appreciated our customers’ cooperation and I think everyone benefited as a result, even though I believe we remain the only network to do this in real-time.
We have blocked millions of calls based on our initial identification of what may or may not be spam/scam calls. We don’t differentiate between calls coming into the network, out of the network, or across the network – they’re all treated equally. If it is bad it is blocked, period, but our threshold for blocking has been set very high. So by definition we’re not capturing 100% but we also know the false positive rate is low. We appreciate those customers that have worked with us where we have had false positives although it’s fair to say that I’ve yet to see an example where on close examination the pattern of behaviour was not inappropriate, even though it wouldn’t be our intention to block that individual user’s activity yet. As we move along, we’ve said we are going to be tightening the screws and patterns of behavior such as this will come into scope. We’re having to be careful though as blocking a legitimate call is potentially worse than allowing a nuisance call through and as explained last week, statistically good calls can look bad, and vice versa.
However, since 2018 there’s been an Ofcom requirement that not only is CLI used valid but it is also dialable and that the number presented uniquely identifies the calling party and they’re able to be reached by dialing back. In our regulatory regime, CPs are de-facto permitted by compliance with the General Conditions of Entitlement and this makes a General Condition – GC C6 no less. It very unambiguously says:
This condition requires communications providers to provide calling line identification facilities by default wherever technically feasible and economically viable, so that call recipients can identify the person calling them and choose whether or not to accept the call.
To assist with the identification of callers and reduce the incidence of nuisance calls, all communications providers should ensure that any telephone number associated with a call at the network level and/or presented to a call recipient is a valid, diallable number which enables the calling party to be identified, so that the call recipient can make a return call to that person.
That, and the CLI guidance which accompanies it is very very clear. Some might say it is black and white, and it has been about since 2018. If you, as a CP, are originating calls with CLI on which the caller cannot be contacted back, or in the case of network numbers behind withheld CLIs, identified by, you are, by our read, in breach of the General Condition on which your entitlement to do business depends. Same for us and any other carrier who transits it.
The fact the rest of the industry seemingly does not care, or these calls have been passing for the 7 years since the GCs were changed, in no way alters what they say. The requirement is neither new, nor ambiguous.
Therefore, we have introduced a filter. The worst numbers statistically are being probed by our network to determine if they are dialable. If they are not dialable they are unambiguously blocked in accordance with the GC. This is where it is used in CLI coming into, across, and out of the network in either direction. As this is a deterministic test, with some obvious guardrails, it has yielded far more blocking than our other approaches which is good news for all of your customers, we believe. As of this morning, 10x as many numbers were blocked for invalid CLI than simple behaviour, even though poor behavior is the trigger for testing in the first place.
That said, we have had a total of three support tickets identifying some fringe use cases which have some semblance of legitimacy (albeit with simple solutions to avoid blocking that are within our customer’s control). Given the unambiguous nature of the rule, it is very hard for these to be considered false positives, but we have taken the step of pausing this block for 7 days because it appears some customer’s use cases need some time to catch up with 7 year old rules.
Having checked with our compliance guru Pete, there will be an exceptionally high bar for any exceptions. Not least, because as and when other networks catch up on this requirement or use our BYOC functionality, these exceptions, or bypasses, will likely be rendered irrelevant. Any whitelisting we do would not affect any calls not touching us.
Numbers used as CLI (network or presentation) must be dialable and in 7 days we will resume blocking those which aren’t, but only those which have stuck their head above the parapet for some other reason and caused us to test in the first place.
Lastly, we piggy-backed on notifying these alerts alongside other notifications, which appears to be causing confusion. We are reverting those alerts back to their original purpose, while we balance transparency versus the risk of providing a basis upon which the controls can be circumvented.
We’d like to again thank customers for responding to this cleansing so positively. As with our decades combatting VoIP fraud, we’re determined that your customers get the best protection available, and appreciate the support to that end.
