Telecom regulation and blockchain - is #RegTech the killer application?

One of the most interesting developments in telecoms technology for a while occurred this week – India’s telecom regulator TRAI issued a set of draft regulations aimed at combating spam and nuisance calls. (link)

At first glance, you could be forgiven for asking why anti-spam rules could possibly be more important than all the hoopla about 5G, market consolidation, network-slicing and, especially, “digital transformation” or RCS messaging (I jest).

The reason is in the details: TRAI has stipulated that telcos should use blockchain-based technologies to enforce its proposed rules, creating a tamper-proof and encrypted ledger of consent records, given by users for opt-in telemarketing. If the rules translate to reality, this is a major step forward in commercialisation of digital ledger technology, and at scale.

"Access  Providers  shall  adopt  Distributed  Ledger  Technology  (DLT)  with

permissioned and private DLT  networks for  implementation of  system, functions and processes as prescribed in Code(s) of Practice: -

(1) to  ensure  that  all  necessary  regulatory  pre-checks  are  carried  out  for  sending

Commercial Communication;

(2) to operate smart contracts among entities for effectively controlling the flow of Commercial Communication;

Access Providers may authorise one or more DLT network operators, as deemed fit, to provide technology solution(s) to all entities to carry out the functions as provided for in these regulations."

But in my view, this could be just the tip of a quite large iceberg. I'm starting to think that regulatory uses for blockchain (especially private/permissioned versions) could be central to the technology's success in telecoms.

Innovation in Regulation Technology, or RegTech, is already a huge domain, especially in sectors like financial services and healthcare. Historic methods for regulatory enforcement, from money-laundering rules, to certification of professionals, have often used reams of paperwork and had cumbersome processes. There is a huge need for automation, better provision of security and authentication, and simpler online access to regulatory resources and approval.

Obviously, telecoms has itself long had technical means for creating and enforcing rules, from spectrum-monitoring and radio-coverage tools, through automated platforms for telecoms licensing, to software aimed at checking broadband QoS and spotting net-neutrality violations.

But given that a lot of telecoms rules tend to involve multiple parties (eg user, telco, advertiser as here, or multiple telcos doing interconnect or wholesale agreements), requirements for "credentials", and there are often registries and other databases involved, the whole sphere looks like an archetypal match for the types of capability normally found in blockchains.

In particular, I think there are many potential use-cases for regulators to assist - or keep tabs on - telco activities that relate to regulatory policy. Adding unarguable timestamps to tamper-proof data storage has huge potential, in particular. Ones that immediately leap out to me include:

• Number portability databases and porting requests
• Storage of call detail records, that may be subject to lawful request at a later date
• Spectrum allocations and permissions, especially for shared, local and dynamic spectrum models.

One other that I think has longer-term potential, but which nobody has talked about yet, is in secure and encrypted storage of network configuration and log files. One of the problems with regulating wholesale interconnect, peering, net neutrality and other rules, is that it is exceptionally hard to prove what happened retrospectively, if someone makes a complaint. This issue will be exacerbated with NFV/SDN, and the move to network slicing, when network configurations will be temporary and highly dynamic.

Given that law-enforcement insists that ISPs retain theur users' data records, it doesn't seem unreasonable to retain the ISPs' own information as well - obviously in a form that's secure and encrypted unless needed for evidence in the case of a legal intervention. It could also make a clear distinction between a problem of network failure (or happenstance in the way the maths of contention works), and deliberate actions.

The Net Neutrality angle here is particularly potent - it would allow any egregious behaviour to be dealt with post-hoc. Most anti-neutrality lobbyists dislike ex-ante regulation, but few could argue against allowing competition authorities or others from investigating alleged infringements that occurred deep inside the network's configurations and policies.

I'm just musing here, but I definitely feel that there's a lot more to telecom #RegTech using #blockchain than just tracking spam calls and SMS. 

This is one of the topics that will get discussed at my upcoming workshop on telecoms blockchain, on July 3 in London. Full details are here (link) or email information AT disruptive-analysis dot COM

Microsoft / LinkedIn helps kill the phone number as a primary B2B identifier

I'll keep this focused, as there will be hundreds of articles dissecting the MS / LI acquisition that will no doubt cover most angles.

For me, the key element is that LinkedIn has one of the only "identity spaces" that allows people from different companies to connect. The two other most-popular ID types, which cover company-to-company communications, are phone numbers and email addresses. Unlike those, LinkedIn actually has a functioning searchable directory, with real names and mutual-connection "opt-in" model to reduce spam. It also follows people from job to job.

Other options are very minor - some business-people connect via Twitter's messaging function, some have industry-specific IM systems like Bloomberg & Symphony in finance, and some interact via channels on Slack and similar services niche collaboration platforms. 

Three other identities stand out - Google ID (used for HangOuts and a few strange folk on G+), Skype, and Lync/Skype for Business. Some business-people probably end up communicating via iMessage but that's usually triggered via an initial phone-number exchange, as is WhatsApp and pretty much all the other major mobile messaging services.

None of the other UC/UCaaS services from Cisco, Avaya, Unify, Mitel or Broadsoft-enabled operators really have their own inter-company addressing, directory and search/discovery function, although they can sometimes use specific federation techniques, or indeed integrate with Microsoft's Office365 and other systems.

If it can put the pieces together, Microsoft now has:

• LinkedIn's real-name addressing
• Outlook / Office365's ability to link email addresses to presence and Microsoft's own identity space
• Skype IDs for both consumers and individual business-people
• Phone numbers provided for SkypeIn and PSTN Calling in Skype4B
• WebRTC/ORTC for "guest access"
• Dynamics for CRM / sales automation

It is thus now the only company that can legitimately claim to control directories for both internal and external connections among business users, plus a fair number of consumers as well. It is already quite common for people to use LinkedIn as a surrogate contact database, when they cannot immediately find someone's phone number or remember their email address - especially when they move jobs.

(It should however be noted that LinkedIn tends to polarise opinion quite a lot - while it has a proportion of regular users who exploit it for networking, recruitment, groups and articles, it also has many members that have neglected profiles and limited active use. I'd been expecting LinkedIn to add realtime communications with WebRTC for some time but nothing has appeared - although it will be interesting to see if there's been anything behind the scenes that Microsoft will accelerate).

That has big implications for two groups:

• Telcos will see the role of the phone-number diminish further in a B2B context, as it becomes ever-closer to being just a lowest common-denominator fallback option. Added to its diminishing scope for B2C (because of in-messaging chat, app notifications etc), this doesn't augur well for E.164's continued primacy
• Cisco, Broadsoft and others need to think closely how to tie together inter- as well as intra-company connections. I'll be interested to see if Cisco tries to leverage its Apple relationship, or if the UCaaS platform-players try to lean on Google [Which has been cropping up regularly at events, pitching Android for Work]. We could also see attempts by competitors to federate their various cloud platforms - perhaps using something like Matrix.org as an intermediary.

This also puts the pressure on Facebook to step up with its long-promised enterprise offer, and means that any sign that Slack, HipChat or peers are gaining viral adoption will be greeted with enthusiasm (and perhaps acquisition offers). We will also see redoubled interest in industry-specific federated messaging in healthcare or finance or government verticals.

[There are also impacts on other companies like Salesforce in the CRM arena, but I'll leave that for others to discuss]

Of course, all this is contingent on Microsoft/LinkedIn gaining approval from competition authorities - and of course also assumes Microsoft can do a rather better job with integration than it managed with Skype in the first place.

But overall, this is hugely important - and has ramifications that extend across the business communications sphere, and may ultimately prove to be (another) nail in the coffin of the phone number & PSTN as the primary B2B identity-space.