By Simon Woodhead
Back in 2018 we had General Condition C6.6 (GC C6.6) introduced, requiring operators to ensure CLI was valid on the way in and out of the network, amongst other things. I remember it well as we implemented it fully per the Ofcom guidance but were seemingly alone. We had innumerable complaints from customers of a certain major mobile network who apparently couldn’t configure their network consistently around the country or comply with other Ofcom requirements, resulting in them leaking the Network Number, (or PAID depending on your lexicographic preference) which we were now compliantly inserting on calls lacking one. My recollection, put simply, is we had a bit of a spat. Ofcom agreed we’d implemented the guidance properly, but the guidance would be changed such that we would be wrong and the said operator didn’t have to fix their network or comply with other requirements. A shining example of regulatory progress!
Funnily enough, in the recent consultation from Ofcom on this matter, five years on, one of our alleged peers has only just seemed to have woken up to the network number leakage, making us wonder how truly behind the curve they might be with the TDM closure programme.
We’ve made numerous other changes since too, such as filtering outgoing CLI from 2020, our customers taking the pain and avoiding what years later other operators, who still had not complied with GC C6, would extort Origin Surcharges for. As I infamously challenged a BT senior in a Westminster forum: they are able to identify and bill for invalid CLI but they aren’t able to identify and block it, which he confirmed to be the case. You couldn’t make it up and any sane person from any other industry would think this is some kind of comedy sketch. Sadly it isn’t.
So imagine my bemusement and frustration as I’m in transit to ITW and my inbox and our support channels are somewhat active with all these urgent CLI changes other operators are making to comply with new rules. There’s a perception that we’re behind the curve and others are more on the ball. This blog is therefore to say, we’re not, we just did it 5 years ago, when Ofcom told us to do so the first time!
What has changed, to be fair, is that Ofcom have clarified one thing (they inserted a CLI must “uniquely identify the caller”, which was always the accepted definition of network number forever and a day, so merely academic, and updated guidance with respect to blocking UK PAID at the the international gateway unless there is a good reason not to do so. The goal here is to catch the dialer scrotes spoofing from offshore and reduce spam and fraud. A worthy goal, but given the track record of this industry, probably unrealistic!
“What is the international gateway?” I hear you cry. Had to ask Pete this one, and after a few minutes of him rambling about ITU definitions involving submarine cable landing stations, he said “the first switching node within the UK that receives a call from a switching node outside the UK.” In other words, it’s a lot about knowing who your counterparty is and where their switch is. Easier said than done with VPNs and interconnects based on hostnames, but the crux is there – knowing who your customer is and what they are doing.
If you’re a Simwood Carrier Services customer and you have offshore customers yourself, you are the international gateway and you need to be ensuring they aren’t inappropriately setting UK PAID in accordance with the prevailing regulations. If you are one of our Carrier Services customers and offshore, the international gateway is us. That distinction is important because it would be wrong to assume we’re always responsible for things, where in fact you can be, and we have no visibility nor control.
Where this gets a bit grey is that there isn’t a blanket ban on UK PAID from overseas, and there are perfectly appropriate use cases such as failover data centres, calls tromboning in and out when you use an LCR etc. The challenge is in where the distinction lies between a good reason and a not good reason, and, with the flexibility for an off-shore contact centre to register their handsets straight onto a UK node, not a simple black-and-white rule, or interpretation of the rules, can be readily articulated. It is always going to be somewhat subjective and argued in hindsight. However, our customers, and by extension our numbering and our traffic, are very clean because we’ve never tolerated scrotitude, so the likelihood is if you haven’t heard from us your traffic is tending towards the OK end of the spectrum.
In our view, the correct approach to this is something we’ve indicated before and have had in place for some time for newer customers – Know Your Client (KYC). As the world closes in on us in regulatory terms, it becomes increasingly important to understand our customers’ business and traffic profiles. Not least because if legislation currently before Parliament passes, our network will automatically send reports to the Information Commissioner about potential scrotitude. And we don’t want that.
We see this across other industries too and you should expect more of it in telecoms. New customers have already gone through this process and we’re obliged to repeat it periodically for the base too, thus we will have eventually “KYC’d” our entire customer base. To be clear, I stand on stages and preach privacy so we’re not looking to be invasive but we need to know the entities we’re dealing with and the nature of services provided, so we can make a judgement that we can defend when the regulator comes banging on the door. Our sectoral regulator does have dawn raid powers, incidentally (although, strictly, Pete will say that’s exercising their Competition Act not their Communications Act duties).
We’re introducing the concept of trusted/untrusted at trunk level. We’ve had this at account level for a while in respect of fraud controls but we’re extending it to CLI and down to trunks. Most existing customers (for that read known UK-based counterparties) will be marked as trusted across the board and see no change. Anyone untrusted at account level, almost by definition, won’t be a customer anymore; again no change there. However, take the scenario of an offshore customer (i.e. we’re the international gateway) who has clean traffic not purporting to have UK CLI but a few customers who legitimately need to set UK CLI, e.g. tromboning. Going forwards they will have untrusted trunks and trusted trunks, and be required to route traffic appropriately, with only appropriate UK CLI traffic allowed on the trusted trunk. KYC will identify where this is appropriate and where it isn’t, which leads us to a point that anyone with clean traffic but not participating in KYC will not have a trusted trunk but may remain on the network as long as their traffic remains clean in our opinion.
We think this is the right way of going about this, and it puts us in a position to defend and argue a case for ‘trusted’ traffic to regulators, with any scrutiny rightly being on our processes in determining the appropriate markings for a given customer or trunk.
Others seem to have taken a different approach. They are mostly playing catch-up with the changes we made 5 years ago relating to CLI filtering and screening. Our customers have done the hard work there so are well ahead. Filtering international traffic isn’t something anyone else seems to have adequately addressed yet, in our opinion. Some are taking rigid blanket approaches, others have gone away to think about it (i.e. do nothing until 2028), and most worryingly one international operator reselling in the UK market has suggested customers send all traffic with UK CLI down a UK trunk to avoid filtering. A different one to the one we called out on surcharges for suggesting manipulation of the PAID, but there’s a worrying theme developing there.
It is pretty clear where the spam traffic is going to go and whose networks will become a further cesspit, unattractive to global enterprises who require clean numbering, reliable call connectivity and no reputational soiling. We think this is an increasingly important USP for Simwood and Simwood customers and one we’ll be putting to the test in conversations at ITW.
I hope that clarifies the generally non-event here for Simwood customers but please reach out to us if you have any questions.
