A&B Handshake: A Simple Way to Control Voice Fraud via an Out-of-Band Connection between A & B Operators

Three critical assets form the cornerstones of a solid telecom fraud control program: 1) fraud management systems; 2) experienced analysts, and 3) telephone number databases.

But now, a fourth key asset is starting to take shape: telecom industry handshake systems.

A “handshake” is not only a greeting and a symbolic way to finalize a business agreement.  There’s also a network meaning of “handshake”, which is to exchange agreed upon signals between devices to enable communication or data transfer.

What’s exciting about handshakes is their ability to leap over telecom middlemen to instantly send a private message to either a consumer or another telecom.  And as you’ve probably guessed, cloud systems and global private Internets are making them possible.

This week, in fact, Black Swan published a Solution Guide on SHAKEN/STIR, a handshake providing an authoritative way to inform a consumer whether or not an incoming telephone call is coming from a legitimate business.  Recently implemented in the U.S. market, the hope is that SHAKEN/STIR will one day become an international standard.  Canada expects to launch SHAKEN/STIR sometime in 2020.

And just as SHAKEN/STIR is getting off the ground, another voice handshake system, the A&B Handshake, has emerged whose purpose is to enable real-time out-of-band communication between the A and B operator of a voice call — and to instantly identify fraud.

The GSMA (through its VINES committee) is now evaluating A&B Handshake.  And the proposed standard has gotten a kick-start thanks to two years of software development by Lanck Telecom, a top 25 wholesaler of international traffic.

Joining us to discuss the A&B Handshake is Sergey Okhrimenko, Chief Operating Officer of Lanck.  Sergey does a great job of explaining what this new handshake is about.

He provides: an easy-to-remember way to understand its basic operation; a rundown on the systems/registries required and how they are integrated at low cost; and the significant management benefits of A&B handshaking in controlling fraud, conducting better dispute control, and enabling law enforcement to get involved as the collection fraud evidence becomes far more accessible.

Dan Baker, Editor, Black Swan Telecom Journal: Sergey, it seems like the industry has been yearning for something like this for a long time.  People have tried to block payment for fraudulent calls like IRSF, but responsibility always falls back to the first operator, the one who put the fraudulent call on the network.  And we’re unlikely to see that rule change, in part because the current policy forces local operators to have skin-in-the-game when it comes to security. But A&B Handshake seems like a simple and low cost way to solve the problem by enabling the A and B operator to coordinate and stop toll fraud before it does much damage.  It’s nice to see Lanck Telecom pioneering such an idea.

Sergey Okhrimenko: Thanks, Dan.  As far as being a “pioneer”, that’s not our thinking.  Yes, we want to get a commercial benefit from our work on developing the A&B Handshake, but mostly we like the concept and the opportunity it presents to help bring something highly useful to the international voice business.

We believe it will take away a lot of the fraud risks and payment disputes between operators.  But it goes nowhere unless it receives industry-wide acceptance by the community of anti-fraud professionals.

	What fraud problems is the A&B Handshake designed to address?

It can solve all sorts of fraud problems, Dan.  I did a little investigating and came up with 2019 estimates from the CFCA, GSMA and other sources on how much fraud costs the industry. 

Here’s a short list of frauds where the A&B Handshake can help. 

Total impact is $28 billion to the telecom industry alone.  And that doesn’t even count the fraud costs to enterprises.

	How does the A&B Handshake work?

Dan, for illustration purposes, let’s imagine I am the A Operator and you are the B Operator.

I call your office number in Georgia, USA from my office phone in St. Petersburg, Russia.

Now, simultaneous to the call, we set up a WhatsApp chat line between us.  This simulates our peer-to-peer out-of-band handshake via a secure Internet connection.

“Did you get my call?” is the first question I ask.  And you immediately confirm back that you received a call from me.

So already, we’ve discovered something important.  When you confirmed getting the call, it means we know — with certainty — that no short stopping of the call occurred.  My call to you was not hijacked by a party in the middle of the telecom routing chain.

So we can scratch Short Stopping off our fraud checkoff list.

“What calling number do you see?” is my second question.  And when you answer, +79117274982, I confirm back that was indeed the number I called you from.

So we can now conclude that no CLI spoofing took place on the call.  Nor was there any interconnect bypass.  And no RoboCalling that used CLI spoofing.  And my call was not an inbound Wangiri fraud because CLI spoofing is usually integral to that fraud — though not every time because we often see unallocated ranges where there’s no need to spoof the CLI.

So in a few short info exchanges, several fraud cases are either discovered or ruled out.

Now in reality, this conversation is not between two persons, but between two pieces of hardware.

	Excellent, I like this chat analogy.  Shows the scheme of A&B handshakes is actually quite simple.  What do you believe are the global requirements for delivering such a handshake system to identity fraud?

Dan, I think it boils down to five (5) key requirements:

1. Real-Time — The out-of-band messages between A and B operator should be fast enough to enable pre-blocking of the call or very fast termination.
   
2. Basic Call Event Details should be exchanged, such as the A and B number, plus the start and end marks of the call.
   
3. Confirmation that the call was terminated to an end user — Both the A and B operators have contracts with end users.  It means: they can confirm the legitimacy of participating end users, which allows treating a call as a legitimate one.  If it then appears that one of the users abused another one, the operator can easily take action against the user it has a contract with.
   
4. Out of Band channel — This is an important requirement for two reasons: 1) security of the private peer-to-peer conversation between A and B; and 2) to avoid the enormous expense and approvals it would require to modify telecom systems or support a high-end database.
   
5. Finally, the system should enable a Comparison of Call Details and Results by A and B parties.  And the results are mutually shared between the two parties.

If we deliver on these five requirements, then we easily stop all sorts of fraud.

	How do you envision A&B Handshake will be deployed?  What cloud systems and registries are required for a worldwide system?

Dan, below is our conception of the international out-of-band system that connects the originating and terminating network via the Internet cloud.

We developed a “call registry” which contains the fraud detection logic — logic which allows you to make a conclusion about fraud after communication with another registry.

The A and B party have to interact with each other and information exchanged includes the start and stop marks of voice calls.

Also, a means must be developed to certify new participants in the Handshake system.  So a central database is required to store relevant information on each operator — a unique ID for each operator, its telephone number ranges, and its IP address for exchanging handshake info.

And once entered, this info is distributed immediately to the call registries of all participants.  In this way, communication can be made directly and securely between one operator and another.

The beauty of this central registry is there’s no need for bi-lateral agreements between all the participants.  It’s automatic.

Today there are many E.164 Range Databases that track global operator phone numbers, but these are generally not updated.  If an operator wants to participate in the Handshake system, they will need to submit the ranges they operate in — and the system will want to keep those ranges confidential.

	Who will manage the Central Repository of Participants?

Well, it will certainly be necessary to have an authority who manages the intersection of ranges.  There will surely be cases where two or more operators submit duplicate number ranges.

On this point, we’ve been negotiating with the GSMA to see if their non-profit units can administer the Handshake if the system is approved by the various operator groups or the GSM community.

We do not see ourselves as the database or central registry coordinator.  Many other companies are better suited to managing such registries.

	Who should participate in A&B Handshake?  And do you still get a benefit in the early stages when not so many operators are participating?

Yes, you are correct.  In the early stages, A&B Handshake will only protect traffic between participants.  Each originating operator will have to set up its own alerting/blocking policy for telephone numbers whose ranges fall outside the system.

Long term, an effective system should welcome all “telecom” players.  In my view, the participants include:

• MNOs
  
• MVNOs
  
• Fixed line operators
  
• Virtual PBX operators
  
• Businesses and apps using SIP agents (Skype-like)
  

Now, I regard huge players like Skype as essential.  If they don’t participate, then there’s an enormous amount of outbound and inbound traffic you can’t do handshakes for.

In turn, fraudsters will initiate Skype-type calls and pretend to be Skype.  So I think you simply must have these players onboard.

	What does an operator need to get started?  How painful is integration going to be?

Almost no integration pain at all, Dan.  That’s the beauty of it.  Lanck Telecom has been developing over the past two years, and we now have integration interfaces for all types of operators and even enterprises.  The objective is to make the integration easy and low cost.  We deliver our integration software free of charge.

For example, we can put our Call Session Control Function software within a SIP network — that’s ideal for small enterprises.

Every switch basically sends us an accounting message that contains the Handshake.  We also do RADIUS, Diameter or HTTP integration with CAMEL gateways or SCPs for MNOs or MVNOs.  Most CAMEL gateways allow you to configure this in a few hours.

Approximate time to deploy:

• Call Registry Hardware setup: one week
  
• Call Registry Software and security setup: one week
  
• Radius accounting, SIP CSCF, or Camel Gateway (each is one week)
  

The whole project can be accomplished by 1 or 2 engineers in one month.

Remember, this is out-of-band communication.  And the mode of communication is asynchronous.  The phone call has a certain sequence and the out-of-band communication has its own separate sequence.

If there are no long delays, this can be switched to synchronous mode, if the operator so chooses.  For instance, you can set up a Handshake first, and the call second.

	OK, so how will Lanck Telecom be compensated for its software development work and integration?

Well, as I said, Dan, we will deploy and integrate the software to let the operator join the system.  If they need a CSCF, we provide that module at no charge.

Now the business model we have in mind will probably be a subscription — an affordable one with early adopters getting sufficient benefits.

And if the operator sends us its wholesale traffic, that’s another factor we will apply to lowering the subscription price.

	What’s the status of deploying the Handshake system?

Lanck deployed its Handshake system in three data centers in Frankfurt, Hong Kong, and New York (at 60 Hudson Street).  And these are simulating 5 operators communicating with each other out-of-band.

We thoroughly tested the logic of the system and it’s working fine.  The system has been operational for three months.

	How do the originating operators manage the screening of their traffic for fraud through the A&B Handshake system.

That’s where our user interface comes into play.  It allows the operator to manage all its fraud call events.  And it’s organized in two sections: one for inbound and one for outbound traffic.

So you can see how it’s partitioned by fraud type: all traffic, provisional, CLI Spoofing, FAS, Call Stretching, PBX Hack, and Diverted (redirected) Calls.

The operator can also download all the logs and use those to open trouble tickets, to open disputes, and to handle payments.

Very important: these logs are EVIDENCE.  This information is shared with the other side: A or B.  And so there’s verifiable evidence that a particular call was a fraudulent one.

All the details are there in the logs: whether CLI-spoofing was involved, or short-stopping, for example.  This evidence can be of enormous help, not just for operators, but also for law enforcement.

Now why is this an important benefit?  It’s because — with legally-admissible documentation of fraud — we can achieve a paradigm shift in managing inter-carrier payments and disputes.  If an operator is withholding payments, these records act as a legal document that a court can use to extract payment from a negligent operator.

It will also arm legal and law enforcement people with information they can use to help the telecom industry.  Let’s face it: law enforcement people know relatively little about telecom fraud and traffic disputes.  And today it’s hard to get them involved because there’s so much back-and-forth requests for documents that it’s hard to move forward with an investigation.

	At the same time, the information exchanged between the A and B provider is a private and secure conversation, is it not?

Yes, that’s true.  The call logs are very sensitive information for each operator, of course, so they need to be secure.  However, to pursue non-paying parties, the operator can use this information as valuable proof or evidence of what occurred.

And managing the fraud or the dispute is simplified for everyone involved.  No need to exchange CDR records and worry about synchronizing records from multiple parties.  It’s all there for examination.

Bottom line: A&B Handshakes gives CSPs the simple tools they need to discover fraud, protect themselves, and manage all aspects of handling fraud — including payments and disputes.

	What about the procedure for blocking fraud?

Well, the way we implement A&B Handshakes, rules of blocking are entirely done by the individual operator.  They have full control over their independent blocking policies and rules for calls.

This is where the energy we put into the interface comes in handy.  Different rules can be set up for different types of fraud.  For example, for call stretching, if the call originator confirms the call was ended at a certain time, the operator can set up to block the call immediately — once they get a confirmation from the other party.

When operators notice bad practices in the enterprise traffic, they can tailor their action.  For instance, if the originating operator notices the outbound call reached the destination network with the wrong CLI, they let those calls go through, because if you block that traffic, it’s very easy to lose the enterprise customer’s business.

So in that case, an operator may decide to switch its routing, but still allow the call to go through.  It’s a matter of striking the right balance between traffic cleansing and enterprise customer satisfaction.

There are hundreds of reasons for allowing the operator to have full control on how blocking is managed: satisfying a customer’s way of doing business, unique operator policies and network configurations, to name a few.

	Sergey, who do you expect to be the early adopters?  One thought I have is the large group operators may find the A&B Handshake useful for managing the internal traffic exchanged between their opcos.

Well, I think the large multi-national networks should already have their own internal checks for traffic between their opcos.

Most of them force their opcos to send each other the traffic they exchange.  If they send traffic to other operators, it means they need to pay other operators.  It’s a valuable revenue stream they don’t want to lose.

However, the multi-nationals may still like this Handshake system as a way to check on their internal discipline of revenue optimization.

We are certainly speaking to a few of our wholesale customers.  We are also talking to one of the largest operators in the world — though our negotiation is still at a very early stage.

I’m also on the road speaking to the industry.  We’ve already presented this at the i3forum group and GSMA.  And recently I also presented to the Canadian CRTC regulator who we answered many questions for.

Sergey, it’s great to see Lanck shepherding this A&B Handshake concept.  I like that Lanck has thought about the fraud problem broadly.  Yes, detecting/blocking fraud is the main objective, but the handshake is also about managing broader fraud issues so operators, enterprises, and even law enforcement can better synch up.  Eager to hear what the industry groups and fraud professionals have to say.

Thanks, Dan.  Our team worked pretty hard on this.  The fraud detection logic was somewhat tricky, but the toughest challenge was making the system work in real-time.

Supplying our FMS to our telecom partners, I’m keenly aware of the extreme effort it takes to stay on top of fraud problems.  Every day we block more than 30,000 calls — most of which we’d qualify as Robocalls and Wangiri calls.  And every day we need to add a few thousand new numbers to our temporary fraud blacklist.

Aside from identifying fraud, one thing I’m personally excited about is that A&B Handshake will take away much of the huge administrative and legal burden of managing fraud problems.

However, we know we cannot do this ourselves.  We are here to cooperate with the Fraud Management and Security professional who are out there today.  We are searching for operators who are willing to spend a few weeks setting this up and testing it in their operation.