TMT Analysis is a leading provider of data, intelligence and analytics, helping customers find extra value from the information they hold. Our team of technology and telecommunications specialists has a proven track record empowering companies, brands and agencies around the world to better understand their businesses and their customers. TMT Analysis has a suite of technology and telecommunications data available, for further information, please visit www.tmtanalysis.com or email info@tmtanalysis.com.

The TMT Verify API is a fully flexible system, that allows customers to request only the parameters that they wish to see returned, on a query-by-query basis. The table below summarizes, for each type of request, the data points that will be returned against a given query Data Points:

Request	Data	Responses	Description
type	Number type	Fixed or Mobile	Check if number is fixed or mobile
	Enhanced type	Enhanced number type	Type of number according to range allocation (see notes)
network	Mobile Country Code (MCC)	Numeric value (zero if number is on a fixed network)	Specific Mobile Country Code as defined in ITU-T E.212
	Mobile Network Code (MNC)	Numeric value (zero if number is on a fixed network)	Specific Mobile Network Code as defined in ITU-T E.212
	SPID	Text value (North America) Integer value (Rest of World)	The SPID (for North America) or CIC (for the rest of the world) of the current carrier.
	Network Name	Alpha-numeric value	Human-readable name of the current network
	LRN	Numeric value (zero outside North America)	Carrier LRN (Local Routing Number)
originnetwork	Original Operator MCC	Numeric value	Specific Mobile Country Code as defined in ITU-T E.212
	Original Operator MNC	Numeric value	Specific Mobile Network Code as defined in ITU-T E.212
	Original Operator SPID	Text value (North America) Integer value (Rest of World)	The SPID (for North America) or CIC (for the rest of the world) of the current carrier
	Original Operator Network Name	Alpha-numeric value	Human-readable name of the original network
porteddate	Port Date	Date	Date of last known number port (if applicable)
	Port Date Type	Exact/Before/Null	If the Port Date supplied is exact or approximate (see notes)
porting_history	Known porting history	(Action/TMTNetwork/i_type/TS) – per porting event	All known porting events in reverse chronological order (see notes)
subscriberstatus	Subscriber Status	Present/Not Present/Unknown	Is the subscriber telephone number active or inactive?
roaminginfo	Is Roaming	Yes/No/N/A	Is the mobile subscriber currently roaming Internationally?
	Roaming Country Name	Text value	Friendly name of roaming country
	Roaming Country Code	Numeric value	International dialling code for roaming country
	Roaming Operator Network name	Alpha-numeric value	Human-readable name of the roaming network
	Roaming Operator MCC	Numeric value	Specific Mobile Country Code as defined in ITU-T E.212
	Roaming Operator MNC	Numeric value	Specific Mobile Network Code as defined in ITU-T E.212
	Roaming Operator SPID	Text value (North America) Integer value (Rest of World)	The SPID (for North America) or CIC (for the rest of the world) of the
portfraud	Port fraud risk	Very High/High/Medium/Low/N/A	Port-out fraud risk indicator based upon table below (see notes).
simswap	SIM Swap Risk SIM Swap Date SIM Swap Min SIM Swap Max	Very High/High/Medium/Low/-1	SIM Swap fraud risk indicator and associated information based upon table below (see notes).
deviceswap	Device Swap Risk	Very High/High/Medium/Low/-1	Device Swap fraud risk indicator based upon table below (see notes).
callforward	Call Forwarding on	Yes/No/-1	Unconditional Call Forwarding indication
kycmatch	KYC Match score	Numeric value	KYC Match score (-1-100) based upon supplied parameters in the POST request
deactivation history	North American deactivation check	Up to 10 most recent deactivation events	Events and codes for each event (see notes)
status	Status Status Message	0/1/2/3/4 (see notes) Success/Invalid Number/Not Allowed Destination etc.	Whether the query was performed successfully (mandatory response)

Notes:

• Where the subscriber number has been ported more than once, only the most recent (i.e.current) Mobile Network will be returned as part of the Ported Network Information. In all cases the Original Network Information will remain unchanged by multiple porting events.

• The Enhanced Type (etype) value that is returned as part of a type query is based upon the type of number allocated (typically by the regulator) to the block of numbers in which the queried number resides. There are 33 different potential values that could be against a given number, although it should be noted that not all of the number types are used in every country. The available supported types are:

etype	Value	etype	Value	etype	Value
1	Audio Text	12	Mobile to Mobile	23	Shared Cost
2	Calling Cards	13	National Geographic	24	Short Codes Commercial
3	Electronic Services	14	National Rate	25	Specialized Mobile Radio
4	Freephone	15	Non inter-model CC (Portability =Y)	26	Telegram
5	Geographic	16	Paging	27	Universal Access
6	Intermodal Numbers (FIX<->MOB porting	17	Payphone	28	Videotex
7	Internet Service Provider	18	Personal	29	Virtual Private Network
8	Local Rate	19	Prefix Type Unknown (Portability =N)	30	Voicemail (geographic)
9	Machine to Machine	20	Premium Rate	31	Voicemail (mobile)
10	Mobile	21	Routing Code	32	VoIP Telephony
11	Mobile (CDMA)	22	Satellite	33	Wireless geographic

• When responding to requests for Roaminginfo, the is_roaming field is always supplied. If the queried number is currently roaming, the additional fields of Roaming Country Name, Roaming Country Code, Roaming Operator MCC etc. will be provided if they are available from the live network query.

• The porteddate uses data from TMT Analysis’s own records and is not present in Live network queries. In some markets, historic data is available to TMT Analysis dating back to the beginning of Number Portability in that country, in other markets this data is maintained from TMT Analysis’s own records going back to when that market was first on-boarded. Therefore, the combination of Port Date and Port Date Type field are provided to denote the following:

Port Date Type	Port Date	Notes
Exact	DD/MM/YYYY	Port date shown is correct as most recent port Before DD/MM/YYYY The number has been ported in the past, but it has not been done since TMT Analysis onboarded that market. In this case date shown is the date on which TMT Analysis started to gather data.
Null	Null	Number has never been ported

This combination of the Port Date Type and Port Date can be used by the Customer to identify any recent porting activity, regardless of whether date is ‘Exact’ or ‘Before’

• The porting_history field providers a full list of all documented porting events that are contained in TMT Analysis’s own Number Portability database. For this reason, porting_history is only available for on-net countries and the list of events will only be provided from the date on which that country was first on-boarded by TMT Analysis (contact your account manager for a comprehensive list of on-boarding dates). A single porting_history query for a given number will return, in reverse chronological order, all known events against that number. For each event the following information is provided:

Field	Description
action	Either ‘A’ for Add meaning a port of the number to a different Mobile Network Operator or ‘D’ for Delete meaning that the number has returned to the original range holder of that number and is no longer considered as ported.
tmtnetwork	The network identification of the destination Mobile Network Operator of the porting event. As with other datapoints the Mobile Network Operator is identified by MCC/MNC.
i_type	Number type: ‘m’ – mobile, ‘f’ – fixed, ‘o’ - other
TS	Timestamp of when the porting event was recorded in the TMT Analysis database (YYYY-MM-DDTHH:MM:SS)

Note 1: The Timestamp is the time that the change was recorded in the TMT Analysis database, not the precise time on which the porting event will have occurred. Most countries provide daily movement updates so the actual porting event will have occurred within a few days of it being recorded in the database.

Note 2: Because the porting_history contains records since the country was on-boarded by TMT Analysis, numbers that ported before this will not return any records to a porting_history query. Therefore, it would be possible to have a given number with a porteddate of the type ‘BEFORE’ indicating a historical porting event but have a null porting_history.

• The Port Fraud Risk is only provided where a Live network query is possible, and is expressed in terms of the elapsed time since the last recorded porting event. The below table summarizes the responses:

Risk Index	Description
Very High	Number ported within last 24 hours
High	Number ported within last 25-96 hours
Medium	Number ported within last 30 days
Low	Number ported outside 30 days, or not at all
-1	No Live query data available for that country, network or number

• SIM Swap is only provided where data from the appropriate Mobile Network Operator is available, and is expressed in terms of the elapsed time since the last recorded change of the SIM card (IMSI number) associated with the queried number. Because the data from the Mobile Network Operators can be provided in multiple formats, the simswap response can contain up to 4 elements. SIM Swap Risk is generated from the information supplied by the Mobile Network Operator based upon an algorithm as described in the table below:

Risk Index	Description
Very High	SIM/Device changed within last 24 hours
High	SIM/Device changed within last 25-96 hours
Medium	SIM/Device changed within last 30 days
Low	SIM/Device changed outside 30 days, or not at all
-1	No data available for that country, network or number

Some Mobile Network Operators provide the exact timestamp associated with the last SIM card change, where this is available it is provided in the SIM Swap response as SIM Swap Date.

In other cases, where a Mobile Network Operator provides a time for the most recent SIM Swap that is within certain bounds (such as more than 24 hours and less than 72 hours), these min and max thresholds will be provided as SIM Swap MIN and SIM Swap MAX.

• The Device Swap Risk is only provided where data from the appropriate Mobile Network Operator is available, and is expressed in terms of the elapsed time since the last recorded change of the Device associated with the queried number. The below table summarizes the responses:

Risk Index	Description
Very High	Device changed within last 24 hours
High	Device changed within last 25-96 hours
Medium	Device changed within last 30 days
Low	Device changed outside 30 days, or not at all
-1	No data available for that country, network or number

• Deactivation History is only provided for USA numbers. For the supplied number TMT Verify will scan the deactivation list for up to 10 of the most recent events in the database against the supplied number. Each event will contain the name of the Mobile Network Operator who recorded the event, together with the following 2-digit code to show the type of movement:

Code	Meaning
DE	Number deactivated by operator (no longer belongs to subscriber)
SW	Number swapped (transferred) to a different subscriber. Available for T-mobile and Verizon subscribers only.
SU	Number suspended. Verizon subscribers only.
RE	Number reactivated. Verizon subscribers only.

If the number supplied does not appear in the US Deactivation list then an N/A response will be returned. This does not mean that the number has never been subject to a deactivation, suspension or transfer, but it does mean that it has not happened since the beginning of TMT Analysis data for US Deactivation (June 2019).

• The Status is not a customer selectable field and is provided in the response to every query. Two parameters are provided, the Status and the Status Message. The below table summarises the possible status conditions:

Query Result	Status	Status Message
Success	0	Success
Number not valid according to numbering plan for that country	1	Invalid Number
Country queried is not available to be queried by this service	2	Not Allowed Destination
The query has not been completed due to congestion (typically with upstream providers)	3	Congestion
The query has only been partially completed due to the unavailability of one or more data sources	4	Partial Reply

• The KYC Match request (name/address/dob match) is a POST request that requires at least one additional parameter sent in the payload/message body. The POST format provides an additional level of security allowing Customer queries to provide multiple parameters (that are necessary for KYC Match) as part of the query.

The KYC Match API has four logical matching blocks – each block having its own challenges (data) that will be used to generate a score. The provided score ranges between 0 and 100, where 0 is equal to no match, and the higher the score, the closer the match. To assist in providing data that is useful a match score is supplied against each supplied parameter (where possible) within the block. This provides additional useful data in the event that name and address information is not correctly specified or contains minor spelling discrepancies etc.

As part of the POST format used for KYC Match, the below table summarises the elements of each block, the requirements from the Customer and how the matching score is devised. Customers may request multiple blocks as part of a single query but must supply the challenge information for each block requested.

Challenge	Type	Notes
Block 1: Name
first_name	String	Value that will be matched against the first name on file, generating the matching score in the response.
last_name	String	Value that will be matched against the last name on file, generating the matching score in the response.
middle_name	String	If middle name matching is available, the middle name matching score will be returned in the response. If middle name matching is not available, the submitted middle name will be matched with the submitted first_name and an overall first name match score will be returned.
Block 2: DOB
day	Numeric Value	Day of birth. This parameter will be used with month and year to generate an overall matching score for DOB.
month	Numeric Value	Month of birth. This parameter will be used with day and year to generate an overall matching score for DOB.
year	Numeric Value	Year of birth. This parameter will be used with month and day to generate an overall matching score for DOB.
Block 3: Address
The challenge parameters associated with this block will be used to generate individual - parameter level matching scores where data is available. Otherwise, an overall address matching score will be provided.
street_no	String	Value that will be matched against the street number on file, generating a street number matching score where available, otherwise having a weight in the overall address matching score.
street	String	Value that will be matched against the street name on file, generating a street name matching score where available, otherwise having a weight in the overall address matching score.
unit_name	String	house name Value that will be matched against the house name on file, generating a unit number matching score where available, otherwise having a weight in the overall address matching score.
unit_no	String	unit number Value that will be matched against the unit number (building number) on file, generating a unit number matching score where available, otherwise having a weight in the overall address matching score
city	String	Value that will be matched against the city on file, generating a city name matching score where available, otherwise having a weight in the overall address matching score.
province	String	province/county/region Value that will be matched against the province on file, generating a province name matching score where available, otherwise having a weight in the overall address matching score.
postcode	String	Value that will be matched against the postal code on file, generating a postal code matching score where available, otherwise having a weight in the overall address matching score.
country	String	Value that will be matched against the country on file, generating a country name matching score where available, otherwise having a weight in the overall address matching score.
Block 4: Email Address
email	String	Value that will be matched against the email on file, generating the matching score in the response.

KYC Match Response Parameters

The below table summarises how the response format is provided for each KYC Match block. Numeric value between 0 and 100 are provided representing the match score, with code -1 provided if the parameter for the match was not provided either as part of the Customer POST or from the data provided to TMT Analysis from the appropriate data provider.

Name	Type	Notes
Block 1: Name
first_name_score	Numeric Value
last_name_score	Numeric Value
middle_name_score	Numeric Value	If middle name was provided in the request but middle name matching was not available, the request parameter middle name was used to generate the first_name_score.
name_score	Numeric Value	If individual matching scores for first_name, last_name, middle_name are not available, an overall matching score will be provided.
Block 2: DOB
dob_score	Numeric Value
Block 3: Address
street_no_score	Numeric Value
street_score	Numeric Value
unit_no_score	Numeric Value
city_score	Numeric Value
province_score	Numeric Value
postcode_score	Numeric Value
country_score	Numeric Value
address_score	Numeric Value	If previous individual matching scores are not available, the overall address score will be provided.
Block 4: Email Address
email	Numeric Value

Notes on KYC match score:

• Address Scores are returned individually for all available parameters, within the possible range of -1 to 100. A -1 score signifies that the Mobile Network Operator in question does not have any data in their systems for the supplied number with which to respond. This should be interpreted as a neutral result in any trust calculations undertaken by the customer, in comparison to a '0’ score which signifies that the Mobile Network Operator possesses data but that the supplied challenge data does not match (which is a negative result).

• Mobile Network Operators offer a range of different response types for name and address matches. Some operators apply logical matching and return a match score of 1-10 or 1-100 whilst others respond with a more binary ‘Y’ or ‘N’. TMT Verify On-boarding respond always with a numerical score. In the event that the Mobile Network Operator provides a score, it is either passed through (0-100) or multiplied by 10 (0-10) and the binary values are converted from ‘Y’ to 100 and ‘N’ to 0.

• Street and Street number score are from experience very challenging to obtain a match between the customer-supplied data and that of the Mobile Network Operator, particularly in the case of those operators who respond with a binary ‘Y’ or ‘N’. One of the significant benefits of TMT Verify is that it offers a match score against each element of the address individually, so harder to match elements can also be compared with more standardised information such as post/zip code. It is the decision of each customer how the utilise the responses provided to the KYC Match in their own logic and decision making process however many organisations who have tested the service have concluded that they should place a lower weighting on the street and street number than on other attributes such as postcode and date of birth.

• United States of America street addresses conform to a standard format. This is written as street number and street name (commonly known as address line 1) and apartment or unit number (commonly known as address line 2). In order to get the highest level of matches TMT Verify customers should supply address line 1 information as street in an address match query and supply address line 2 as street_no.

• Last name and first name. In common with the point above on street name and street number, it is not uncommon for last or family name to obtain a higher percentage of accurate matches than first name. There are multiple reasons for this including increased probability of miss-spelling, multiple first names etc. As before this is particularly an issue where the operator applies a binary ‘Y’ or ‘N’ match. For this reason generally customers place a much higher weighting on family name than on first name.

As previously mentioned in section 3, TMT Verify is a fully flexible API where Customers can request specific datapoints as and when required. This section gives some example queries and responses for common use cases:

type

Provides information on the type of a given number. This consists of two response parameters, type which allows the customer to see if the number is fixed or mobile, and enhanced type (etype) that provides more information on the allocated type of the number (e.g. premium rate, VoIP etc.):

Example:

curl -L -X POST 'https://XXXXXXXXXX/v3' -H 'X-Api-Secret: xxxxxxxxxxx' -H 'X-Api-Key: xxxxxxxxxxx' -H 'Content-Type: application/json' --data-raw '{"number": "447771000003", "dpoints": "type"}'

Response:

{
 "447771000003": {
  "number": 447771000003,
  "type" : "mobile",
  "etype": "10",
  "status" : 0,
  "status_message" : "Success",
 },
 "query" : {
  "datapoints" :"type",
 }
}

Porteddate

To help combat the increasing risk of so-called port-out fraud, TMT Verify can supply, for all on-net countries the exact date that the most recent porting event associated with the number happened:

Example:

curl -L -X POST 'https://XXXXXXXXXX/v3' -H 'X-Api-Secret: xxxxxxxxxxx' -H 'X-Api-Key: xxxxxxxxxxx' -H 'Content-Type: application/json' --data-raw '{"number": "40721987086", "dpoints": "porteddate"}'

Response:

{
 "40721987086" : {
  "number" : 40721987086,
  "ported" : true,
  "ported_date" : "2016-12-30 15:15:19",
  "ported_date_type" : "exact",
  "status" : 0,
  "status_message" : "Success"
 },
 "query" : {
  "datapoints" : "porteddate"
 }
}

Porting_history

A more detailed history around the porting events that a given number has undergone, which can be a useful indication of the economic activity and longevity of a number.

Example:

curl -L -X POST 'https://XXXXXXXXXX/v3' -H 'X-Api-Secret: xxxxxxxxxxx' -H 'X-Api-Key: xxxxxxxxxxx' -H 'Content-Type: application/json' --data-raw '{"number": "40739521819", "dpoints": "porting_history,network"}'

Response:

{
 "40739521819" : {
  "number" : 40739521819,
  "current_network" : {
  "lrn" : null,
  "mcc" : "226",
  "mnc" : "01",
  "name" : "Vodafone Romania",
  "spid" : 4018720
 },

 "ported" : false,
 "porting_history" : [
   {
     "action" : "D",
     "tmtnetwork" : 4018720,
     "i_type" : "m",
     "ts" : "2022-01-31T00:00:00"
   },
   {
     "action" : "A",
     "tmtnetwork" : 4018740,
     "i_type" : "m",
     "ts" : "2021-03-18T00:00:00"
   },
  ],
  "status" : 0,
  "status_message" : "Success"
 },
  "query" : {
      "datapoints" : "porting_history,network"
      "trxid" : "SDF8hD3"
     }
 }

Deactivation_history

By performing a query against the USA deactivation data, TMT Verify will look for evidence that the supplied number has any history of deactivation, and if so, will append up to the 10 most recent events to the response.

Example:

curl -L -X POST 'https://XXXXXXXXXX/v3' -H 'X-Api-Secret: xxxxxxxxxxx' -H 'X-Api-Key: xxxxxxxxxxx' -H 'Content-Type: application/json' --data-raw '{ "number": "12016572115", "dpoints": "deactivation_history"}'

Response:

{
 "12016572115": {
  "number": 12016572115,
  "deactivation_history": [
  {
    "operator": "ATT",
    "action": "DE",
    "ts": "2021-03-10T00:11:29",
    "number": 12016572115
  },
  {
   "operator": "ATT",
   "action": "DE",
   "ts": "2020-01-10T00:10:55",
   "number": 12016572115
  },
  {
   "operator": "ATT",
   "action": "DE",
   "ts": "2019-07-01T00:10:03",
   "number": 12016572115
  }
 ],
 "status" : 0,
 "status_message" : "Success"
},
"query": {
 "datapoints": "deactivation_history",
}

}

Roaminginfo

By performing a real-time network query, TMT Verify will look for evidence that the user is roaming internationally, and if so, will append roaming details to the response. The values are obtained by querying the 3 different network signalling routes.

Example:

curl -L -X POST 'https://XXXXXXXXXX/v3' -H 'X-Api-Secret: xxxxxxxxxxx' -H 'X-Api-Key: xxxxxxxxxxx' -H 'Content-Type: application/json' --data-raw '{ "number": "40721987086", "dpoints": "roaminginfo"}'

Response:

{
  "40721987086" : {
    "is_roaming" : false,
    "number" : 40721987086,
    "status" : 0,
    "status_message" : "Success"
  },
  "query" : {
    "datapoints" : "roaminginfo"
  }
}

portfraud

portfraud checks TMT Analysis’s own database, as well as doing a live network signalling check to determine if the queried number has undertaken any recent porting activity. Based upon that risk, portfraud returns a risk value as described in section 3.

Example:

curl -L -X POST 'https://XXXXXXXXXX/v3' -H 'X-Api-Secret: xxxxxxxxxxx' -H 'X-Api-Key: xxxxxxxxxxx' -H 'Content-Type: application/json' --data-raw '{ "number": "40721987086", "dpoints": "portfraud"}'

Response:

{
  "40721987086" : {
    "portfraud" : low,
    "number" : 40721987086,
    "status" : 0,
    "status_message" : "Success"
    },
  "query" : {
    "datapoints" : "portfraud"
  }
}

kycmatch

KYC Match takes as input both the queried number as well as the challenges/data that need to be matched. TMT Analysis will use our own data to determine which MNO (Mobile Network Operator) to send the match query to. This query will be made to the operator and then the KYC Match Results will be returned for the queried data.

For each attribute an individual match score is returned, ranging from -1 to 100. This takes account of the variability in the scoring method used by different Mobile Network Operators when comparing the challenge data to their records. For example, some operators use a heuristic-type matching algorithm and provide a numeric score based upon the percentage match, whilst others provide a simple ‘MATCH/NO MATCH’ against the challenge. As described above TMT Verify normalise these responses, responding with the percentage score if one is provided or converting the MATCH/NO MATCH to 100/0 respectively.

In all cases, a -1 value is returned to signify that the Mobile Network Operator does not hold information on that number to match against. This allows customers to accurately distinguish a ‘0’ response (which means that the operator holds data but it does not match the challenge) from a less negative ‘-1’ where the operator cannot say one way or the other whether the data is correct.

Example:

POST /v3 HTTP/1.1
Host: XXXXXXXXXX
Accept: application/json
Content-Type: application/json

curl -L -X POST 'https://XXXXXXXXXX/v3' \
-H 'X-Api-Secret: xxxxxxxxxxx' \
-H 'X-Api-Key: xxxxxxxxxxx' \
-H 'Content-Type: application/json' \
--data-raw '{
  "number": "40721987086",
  "dpoints": "kycmatch",
  "kyc_challenges": {
    "name": {
       "first_name": "John",
       "middle_name": "Robert",
       "last_name": "Smith"
    },
    "dob": {
       "day": "2",
       "month": "11",
       "year": "1985"
    },
       "address": {
       "street": "Omnia",
       "street_no": "23",
       "unit_no": "11A",
       "city": "Toronto",
       "state": "Ontario",
       "postcode": "M4B1B3",
       "country": "CA"
    },
      "email": "john_smith@example.com"
  }
}'

Example Response – Individual Address KYCMatch Scores:

{
"40721987086" : {
    "kyc_results" : {
        "first_name_score": 100,
        "last_name_score": 100,
        "middle_name_score": -1,
        "street_no_score": 100,
        "street_name_score": 80,
        "unit_no_score": -1,
        "city_score": 79,
        "province_score": 0,
        "postcode_score": 100,
        "country_score": 100,
        "dob": 50,
        "email_score": 100,
    },
  "number" : 40721987086,
  "status" : 0,
  "status_message" : "Success"
  },
  "query" : {
   "datapoints" : "kycmatch"
  }
}

Example Response – Overall Address KYCMatch Score:

{
"40721987086" : {
    "kyc_results" : {
    "first_name_score": 100,
    "last_name_score": 100,
    "middle_name_score": -1,
    "address_score": 78,
    "dob": 50,
    "email_score": 100,
    },
  "number" : 40721987086,
  "status" : 0,
  "status_message" : "Success"
  },
  "query" : {
   "datapoints" : "kycmatch"
  }
}