An Easy-to-Deploy Fraud-Control Handshake for Voice Operators is Here: When Will it Takeoff?

For decades, operators have been losing tens of billions of dollars a year from international traffic fraud.  So why — after all this time — does the problem persist?

There’s no simple answer to that question, but three key factors are at play ensuring traffic fraud remains an on-going problem:

1. Fraud is an electronic cat-and-mouse game.  The fraudster-mice improve their stealth and automation techniques to steal more “cheese”, while the operator-cats work to better detect and tighten their security so the mice give up and attack easier targets.
   
2. The backbone of international voice commerce is the utter certainty that each operator in the voice transit chain gets paid regardless of whether the A operator making the call loses money to a fraudster.  In short, a certain amount of fraud is built-in to the international voice business to ensure calls get through.
   
3. Operators are on their own to detect and block fraud.  Inter-operator sharing of black-lists is widely discussed, but is relatively ineffective.  Plus there’s a lack of  international frameworks and entities to facilitate fraud intelligence exchange and anti-fraud cooperation in real time.
   

Operators have lived with this fraud status quo for so long that it’s been hard for industry players to see a path around these barriers.

But two years ago, an upstart company, AB Handshake, did some thinking outside the box and came up with a fresh, low cost, and easy to implement solution that can have a major industry impact when influential operators and/or regulators adopt it.

Here to discuss the program is AB Handshake’s managing director, Vasily Birulin.

	Dan Baker, Editor, Black Swan Telecom Journal; Vasily to begin, can you explain how the AB Handshake works?

Vasily Birulin: The principle is very simple, Dan.  We establish a secure network to validate calls between operator A and operator B.

We facilitate a real-time handshake — even before the call goes through — and we stay there for the duration of the call.  If a person in the U.S. calls to Guatemala, the call itself can transverse quite a number of carriers.

And somewhere along the path, a carrier can manipulate the call to commit fraud.  But since we create an out-of-band handshake, we can tell both operators immediately whether it is a legitimate call or not — or whether some tampering is going on.  It happens quite fast.

A real-time communication path between operators like AB Handshake seems like such a natural strategy, it makes you wonder why it took so long.  After all, operators are providing plenty of real-time security checks to support the world of smartphones and mobile apps.  Banks are constantly pinging operators to check for SIM card swaps, phone numbers changes, and other indicators of financial fraud.  But strangely, service providers have not developed real-time checks on the fraud that occurs between themselves.

I totally agree, Dan.  It’s time for the voice industry to start sharing fraud intelligence in real-time with each other.

And in one important aspect: the kind of handshake we deliver is quite unique in the marketplace.

Think about it.  Most FMS solutions on the market operate like a voice firewall — they filter incoming voice traffic and check the validity of credentials when the call arrives.

But then, after it allows the call to pass through, it forgets about the call.  The only fraud monitoring point on the call is at its start — that’s what the voice firewall does.  Of course, this voice firewall approach has been with us for a very long time.

Yet anything that happens with the on-going call, the voice firewall doesn‘t see.  However, the AB Handshake secure network software continues to monitor the voice session on behalf of both call controllers in the US and Guatemala.  In this way it keeps the handshake connection alive to check if the call is still valid on both sides.

In our view, fraud screening at call setup time alone is no longer good enough protection.  Protection needs to expand across the entire call with continuous monitoring from start to finish.

	I can think of one particular fraud where continuous monitoring of the voice connections is important and that’s FAS or False Answer Supervision.  Is that what you mean?

Yes, FAS is certainly a fraud that requires continuous monitoring because it’s a technique for a rogue carrier to add a few seconds onto each call.

But there’s also another fraud threat emerging called call stretching, where the fraud impact is much greater.

In call stretching, from either operator A’s or B’s perspective, the call has ended because the caller has hung up.

But monitoring from the opposite side’s view (A or B accordingly), the call appears to be still active, perhaps playing some endless recording on that side, which means something is wrong.

So this is a fraud that AB Handshake can pick up because we monitor the call from start to finish from BOTH sides.  And we do this by monitoring the signaling layer alone — we don’t get any user payload actually — just simple events such as call start, call continue, and call end.

We provide symmetrical intelligence to both sides of the call.  So both the originating and terminating party know exactly where the call went, and whether or not it was properly terminated.

	How about CLI spoofing?  How does AB Handshake monitor that problem?

Yes, detecting and blocking false CLIs is increasingly important and AB Handshake detects it.  With Origin Based Routing (OBR) in Europe, if you send the call between Germany and Spain, for example, the cost is a fraction of a cent per minute.

But if landing a call from outside Europe, it’s still quite a hefty rate — maybe 10, 12 or 20 cents a minute.  But someone lands an international call and spoofs that it originated in Spain and is destined for Germany.  Here normally calls that go through local trunks are terminated for less than 1 cent.

So not to lose the revenue from the international call termination, the German operator would probably not connect the call.  It’s up to the operator to decide, because sometimes if they block these false CLI calls, then certain rules might not work, so the originator sends it through the white route with the original CLI.

	What sort of action do you take when you detect fraud or CLI spoofing?

Well, we don’t automatically block.  We provide information to the operator.  Then, if requested, yes, we can also block.  So there are two modes of operation: monitor or control.We always advise new customers to use AB Handshake in monitor mode where we just alert the operator that “this is not a legitimate call”.

Later, when they are confident enough in the performance of our system, then they often switch on the control mode where, depending on the rules set by the operator, we can automatically pass through or block specific calls.  And in control mode, we can also disconnect a call already in process.

	So looking at your solution in terms of Trusted Communications protection, the superheros at AB Handshake are firmly in the Traffic Fraud Fighting camp as the diagram below shows.

It’s true, Dan.  Pre-call & on-going voice call validation is aimed at identifying frauds such as International Revenue Share Fraud and CLI spoofing used to bypass tariff plans.

However, Operational Efficiency is another key advantage.  When you verify calls with precision, you reduce operator disputes, avoid costly investigation, and remove the financial risk of not getting paid on time.  So validated recording of A to B traffic basically audits the international voice business and leads to greater profits.

	Vasily, your background is in international wholesale, so how did you eventually get to lead AB Handshake?

Well, I was fascinated with the company’s vision.  Yes, I have a solid background in international wholesale and local operations.  Then for a couple years I dived into the Internet of Things before discovering IoT is not the fancy business I thought it was.

So I came back to wholesale but on the side of the vendor.  I initially consulted for AB Handshake and helped them with sales and brand strategy.  Then I agreed to come onboard as their Managing Director.

We are very much an international business.  And being based in the Netherlands I travel representing European business.

The company is actually headquartered in Miami with tech hubs in the U.S., Amsterdam and Frankfurt.  And we have commercial hubs across Europe and Asia.

	I understand AB Handshake has integrated iconectiv’s Tru Number Protect platform.  What value does that add to your platform?

Well, consider the case where a phone call comes from an unknown source.  With AB Handshake’s software, the party B operator can see the call is being connected.  But what if the number is from an unallocated number range — numbers no legitimate operator is supposed to have?

By integrating iconectiv’s TruNumber Protect, a comprehensive database of unallocated and prime-rate number ranges, AB Handshake customers can now identify potential fraudulent calls and take preventive action in real-time.

Our AB Handshake service assumes both parties are involved in a call from the beginning.  However, in cases where no legitimate A party is present in a call, the B party should be well-notified by raising a red flag saying, “This call should not exist.”

	Are you using CDRs in your fraud detection?

We monitor at the signaling layer exclusively.  When the call is established or being requested, we match the signaling events, but do not collect CDR info.  The key reason for such approach lies in the fact that we work in real-time and no one can work with CDRs in real time.

However it’s sometimes useful for us to create our own CDRs.  Say there’s a dispute between operator A and B.  Well, we can produce CDRs as evidence on how a call was connected with which numbers and its duration.  So if Party A and Party B can’t agree on their billing system, they can cross-check in our system for precise call duration and numbers.

Likewise, if there’s fraudulent activity, the CDRs we produce can prove the fraud happened.

	We’ve been talking about how the real-time handshake works, but we skipped discussing the technical details.

Dan, we are a purely software-based solution running on the cloud.  Normally we use the private cloud of the operator since using the public cloud would raise privacy issues.

We connect via IP to the operator’s switching.  And we have about 10 different options for connectivity, supporting legacy protocols like ISUP for example.  It doesn‘t matter for us.  In this respect, we are quite flexible.

However, there are many headaches we deal with!  Integration is highly challenging because you have to cover all network types — and often it’s complicated inside because these networks grew organically.  The technical design team in the operator would deploy network boxes without assessing the full architecture.

	How much progress are you making in AB Handshake adoption?

We have dozens of operator-to-operator connections today.  Overall we are talking to 250+ operators, 38 networks on the platform.

I’ll be perfectly honest with you, Dan.  We still have not reached the snowball effect.

Ideally the platform participants should be pushing others to join in for establishing a strong protection.  We really need a critical mass of support to have a major industry impact.  We are trying to become a de facto standard for validation.

	Regulators may be another fruitful path to pursue.  When the FCC urged U.S. operators to better protect consumers, Stir/Shaken was born, a cooperative carrier program that’s reducing robocalls and voice spam in the American voice market.

Dan, we are working quite tightly with the regulator bodies.  For instance, the European regulator CEPT has recommended us as a solution to combat CLI spoofing.

We are also talking to the authorities in Singapore and the Middle East in UAE, Saudi Arabia, and India.  We’ve had quite extensive discussions, but these negotiations never go fast.

We are also talking to the ITU, and ETSI, and of course we are in touch with the FCC, though the results of successful conversation with the FCC might appear at a much later stage as there is lots of bureaucracy involved in such decisions.

The regulator channel should be a big focus for companies like us as regulators are moving forward the agenda to stop all kinds of fraud.  I can note though that the regulators are often less aware of the operator’s experience in the traffic fraud problem, and more often are acting to protect the subscribers from social engineering schemes.  However, explaining the problem and highlighting industry internal pain points will certainly help to find and deliver a better and faster solution to the fraud.

CLI spoofing is a multifaceted problem involving many parties and all of their concerns should be taken into account in finding the solution.

	Vasily, thanks for the nice briefing.  And good luck on driving AB Handshake, a truly innovative approach to fraud control.

Thanks, Dan.  I think the point behind the real-time handshake is that when operators are given a low cost and easy-to-adopt way of sharing intelligence with each other, some amazing fraud protection can result from that.

The question is: which operators — or regulators — will step up and lead the market towards a simpler way of controlling voice fraud.