Identity Assurance

What do your customers do when they receive a phone call from someone they do not know or a number they do not recognize? Perhaps they answer it, but far more likely they reject it, send it to voice mail, or just ignore it. In our current telecommunications world, everyone does this, because they are barraged by spam and robocalls and assume the worst – someone wants to pitch something I do not need or want, or this will be an attempt to defraud me.

It would be way more useful, if your customers knew, in real-time, on a per call-basis, that the incoming call was from a legitimate source, for legitimate purpose, and had no malicious intent? Accomplishing this is what we call Identity Assurance.

To properly provide identity assurance on a real-time, per-call basis, three attributes need to be known:

  • Identity – who is the originator?
  • Reputation – is this someone I want to talk to?
  • Trust context – where did the call originate and where will it terminate?


The good news is there is a tremendous amount of information available in the telecommunications industry that can be used to determine identity. These include:

  • Known subscriber numbers- from the originating network operator
  • Industry databases, such as: Do Not Originate Lists – numbers that will never originate calls; Un-assigned numbers - from industry databases and from individual network operator databases; and Invalid E.164 calling numbers- based on international telephone number plans, these are numbers that can be screened out in call process
  • Known fraud and spam numbers - from 3rd party databases and from individual network operator databases (blacklists)
  • STIR/SHAKEN attestation – a framework, currently adopted in the US and Canada, to attest and sign the identity of the of call originator and to have that identity verified on the terminating end.

However, verifying caller identity does not address caller intent, so it is possible to have a valid identity, but still have the intent to make nuisance or malicious calls.


Even if you do not know how it is calculated, everyone with a US-issued credit card has likely heard of a FICO score, a measure of consumer credit risk that is a fixture of consumer lending. Now imagine a reputation score that measures caller intent, that would be the equivalent of a FICO score.  To use a reputation as part of identity assurance, it will be paramount to be accurate. If you get the reputation of caller wrong, the value of the score might be worthless. This applies in both directions – too high and too low. What happens when the reputation is excellent, but it should be low so you know when to reject calls? Or even worse, when the reputation is very bad, but it should be high, so the terminating end knows they want to accept calls.

Trust Context

To understand trust context you need to about the originator’s location, where the call enters a network and what information you have about the originating caller. For example, is the call coming from:

  • A known subscriber on a local network interface? These should always be verifiable
  • A known subscriber from a peering partner? These might be spoofed
  • An unknown subscriber from an international carrier? This is most likely not verified and could be spoofed

Ribbon Call Trust Video

Ribbon Call Trust

To assist our customers in their integration of identity assurance into how they handle calls, Ribbon Call Trust, was designed and architected based on the following attributes:

  • Use of dynamic, machine learning (ML) models for reputation scoring, based on multi-source data integration. These are inferred behavior models with iterative learning to adapt to new network conditions, traffic patterns, and data sources
  • An open ecosystem, with open APIs, that can ingest data from other applications or databases to increase the accuracy of the reputation scoring models
  • Open APIs to perform real-time queries of 3rd party transactional policy information, such as real-time attestation of caller identity, based on STIR/SHAKEN Authentication and Verification Services
  • Open APIs to collect non-real time, 3rd party policy data that can be crowdsourced, carrier-based, or Spam/Robocall databases. This information is correlated and stored in a cloud database
  • Leverage Ribbon Analytics which can ingest real-time network and service data (CDRs, KPIs) from Ribbon or 3rd party network elements (SBCs, Call Controllers, and Gateways) to detect robocalls or fraud attempts. This information is fed into the identity assertion modeling
  • Take advantage of public cloud infrastructure to handle massive real-time processing with very low latency, because identity assurance decisions (the output of reputation scoring models) have to be available on a per-call basis, within 50 ms, to avoid affecting post dial delay
  • Robust, high availability architecture because identity assurance is in the call path
  • Ensure the ability to integrate TDM in the future

Ribbon Call Trust is comprised of the following Ribbon products and services: