openapi: 3.0.0
info:
  title: TMT Verify API specs
  termsOfService: https://viteza.tmtid.com/download-terms-and-conditions
  contact:
    name: TMT Support
    email: support@tmtid.com
    url: https://www.tmtid.com
  x-logo:
    url: https://www.tmtid.com/developer/verify_logo_png.png
    altText: TMT Verify
  version: ''
paths:
  /v3/:
    post:
      tags:
      - Standard API Call
      summary: POST method
      operationId: POST
      description: ''
      parameters:
      - name: X-API-Key
        in: header
        description: The API key (obtained from https://viteza.tmtid.com or from Support during customer on-boarding).
        required: true
        schema:
          type: string
      - name: X-API-Secret
        in: header
        description: The API secret (obtained from https://viteza.tmtid.com or from Support during customer on-boarding).
        required: true
        schema:
          type: string
      - name: Content-Type
        in: header
        description: application/json
        required: true
        schema:
          type: string
      requestBody:
        content:
          application/json:
            schema:
              type: object
              properties:
                number:
                  description: The Phone Number with the country code.
                  type: string
                  example: 40721987086
                dpoints:
                  description: Enumeration of the requested data points, comma separated.
                  type: string
                  example: originnetwork,network,type,porteddate,subscriberstatus,roaminginfo
        required: true
      responses:
        '200':
          description: Successful response format
          headers: {}
          content:
            application/json:
              examples:
                response:
                  value:
                    '40721987086':
                      current_network:
                        lrn: null
                        mcc: 226
                        mnc: 10
                        name: Orange Romania
                        spid: 4018740
                      is_roaming: false
                      number: 40721987086
                      origin_network:
                        mcc: 226
                        mnc: 1
                        name: Vodafone Romania
                        spid: 4018720
                      ported: true
                      ported_date: '2016-12-30 15:15:19'
                      ported_date_type: exact
                      present: 'yes'
                      status: 0
                      status_message: Success
                      type: mobile
                      etype: 10
                      query:
                        datapoints: network,originnetwork,porteddate,roaminginfo,subscriberstatus,type
tags:
- description: '

    TMT ID 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 ID has a suite of technology and telecommunications data available, for further information, please visit [www.tmtid.com](https://www.tmtid.com) or email info@tmtid.com.'
  name: About TMT
- description: "\nThe 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\nData Points:\n\n<table>\n <tr>\n  <th>Datapoint</th>\n  <th>Description</th>\n  <th>Response values</th>\n </tr>\n <tr>\n  <td>\"type\"</td>\n  <td>The type associated with the queried number</td>\n  <td>\"Fixed\" or \"Mobile\"</td>\n </tr>\n <tr>\n  <td>\"etype\"</td>\n  <td>The service provides the etype (enhanced type) as well. etype information is provided in the “<number>” block.</td>\n  <td>Number from 1 to 33 indicating type.</td>\n </tr>\n <tr>\n  <td>\"network\"</td>\n  <td>Indicates the current mobile operator that provides services for the queried number. Verify responds with the “current_network” block of information.</td>\n  <td>MCC, MNC, name, SPID, LRN and OCN of the operator.</td>\n </tr>\n <tr>\n  <td>\"originnetwork\"</td>\n  <td>The original mobile operator who issued the number. Verify responds with the “original_network” block of information.</td>\n  <td>MCC, MNC, name, SPID and OCN of the operator.</td>\n </tr>\n <tr>\n  <td>\"porteddate\"</td>\n  <td>The most recent date when the number was ported. Verify responds within the “<number>” block. </td>\n  <td>\"ported_date\" and \"ported_date_type\" fields.</td>\n </tr>\n <tr>\n  <td>\"porting_history\"</td>\n  <td>A list of porting events since TMT ID began logging these events for the country to which the queried number belongs. Verify responds with a “porting_history” block for each porting event. </td>\n  <td>The block contains “ts”, “action”, “tmtnetwork”, “i_type”.</td>\n </tr>\n <tr>\n  <td>\"subscriberstatus\"</td>\n  <td>Returns the presence of a number in the current network. Verify provides the “present” field in the “<number>” block.</td>\n  <td>\"present\" is either \"yes\", \"no\", or \"n/a\".</td>\n </tr>\n <tr>\n  <td>\"roaminginfo\"</td>\n  <td>Indicates if a phone number is currently roaming internationally or not. Verify always returns the field “is_roaming” in the “<number>” block. If the number is roaming, Verify also returns the “roaming_mcc” and \"roaming_mnc\" fields</td>\n  <td>\"is_roaming\" is either \"true\" or \"false\", mcc and mnc also returned if number is roaming internationally.</td>\n </tr>\n <tr>\n  <td>\"deactivation_last\"</td>\n  <td>USA only. Indicates the last time a number deactivation event occurred. The service returns the “deactivation_last” block of fields.</td>\n  <td>\"deactivation_last\" includes “operator”, “action”, and “ts”.</td>\n </tr>\n <tr>\n  <td>\"deactivation_history\"</td>\n  <td>USA only. Provides to up to the 10 most recent deactivation events. The service will return a set of fields for each deactivation event. All sets will be provided in the “deactivation_history” block of fields.</td>\n  <td>Each deactivation event returns the following fields (“operator”, “action”, “ts”, “number”, “number2”).</td>\n </tr>\n <tr>\n  <td>\"simswap\"</td>\n  <td>The most recent SIM card change event connected to the number. Verify returns the “simswap” block of fields.</td>\n  <td>“last_day”, “risk_indicator”, “simswap_min_threshold”, “simswap_max_threshold” and “date” fields.</td>\n </tr>\n <tr>\n  <td>\"portfraud\"</td>\n  <td>Information in relation to any recent porting activity, in the “<number>” block of fields.</td>\n  <td>“present” and “portfraud” fields.</td>\n </tr>\n <tr>\n  <td>\"tmt_score\"</td>\n  <td>Overall number credibility score using the TMT ID score algorithm and several data sources. Verify returns the field “tmt_score” in the “<number>” block of fields.</td>\n  <td>Integer score from \"0\" (low credibility) to \"100\" (high credibility).</td>\n </tr>\n <tr>\n  <td>\"online_presence\"</td>\n  <td>Whether the provided number exists on a range of online platforms. Verify will return the \"online_presence\" block of fields.</td>\n  <td>Within the \"online_presence\" block each supported platform is listed with \"true\", \"false\" or \"N/A\" as appropriate.</td>\n </tr>\n <tr>\n  <td>\"age_verification\"</td>\n  <td>Indicates if the owner of a given phone number is over or under a certain age threshold. Verify will return the “verified” and “threshold” fields in the “age_verification” block of fields.</td>\n  <td>\"verified\" either \"0\", \"1\", \"-1\", or \"-2\", \"threshold\" presented as an integer only when \"verified\" = \"1\".</td>\n </tr>\n <tr>\n  <td>\"kycmatch\"</td>\n  <td>Offers the possibility to match the personal information provided for the holder of a given phone number against the data held by the mobile operators and other authoritative sources. Verify provides results in the “kyc_results” block of fields.</td>\n  <td>“kyc_results” contains the fields “first_name_score”, “last_name_score”, “name_score”, “address_score”, “postcode_score”, “dob_score”. Each provided field contains a match score from \"0\" (no match) to \"100\" (full match).</td>\n </tr>\n <tr>\n  <td>\"normalize\" (part of \"kycmatch\")</td>\n  <td>The service will normalize the address supplied against an external source or offers the option to input the address as a single continuous string</td>\n  <td>Normalised address with option to see how normalisation has modified input data.</td>\n </tr>\n <tr>\n  <td>\"call_forwarding\"</td>\n  <td>The call forwarding datapoint confirms if any type of call forwarding is active for the inquired phone number.</td>\n  <td>\"0\", \"1\", \"-1\", \"-2\"</td>\n </tr>\n <tr>\n  <td>\"market_segment\"</td>\n  <td>The market segment datapoint offers the MNO billing segment for the inquired phone number.</td>\n  <td>\"PAYG\", \"PAYM\", \"Business\", \"n/a\", \"not configured\"</td>\n </tr>\n</table>\n\nNotes:\n\n - 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.\n\n - 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:\n\n <table>\n <tr>\n  <th>etype</th>\n  <th>Value</th>\n  <th>etype</th>\n  <th>Value</th>\n  <th>etype</th>\n  <th>Value</th>\n </tr>\n <tr>\n  <td>1</td>\n  <td>Audio Text</td>\n  <td>12</td>\n  <td>Mobile to Mobile</td>\n  <td>23</td>\n  <td>Shared Cost</td>\n </tr>\n <tr>\n  <td>2</td>\n  <td>Calling Cards</td>\n  <td>13</td>\n  <td>National Geographic</td>\n  <td>24</td>\n  <td>Short Codes Commercial</td>\n </tr>\n <tr>\n  <td>3</td>\n  <td>Electronic Services</td>\n  <td>14</td>\n  <td>National Rate</td>\n  <td>25</td>\n  <td>Specialized Mobile Radio</td>\n </tr>\n <tr>\n  <td>4</td>\n  <td>Freephone</td>\n  <td>15</td>\n  <td>Non inter-model CC (Portability =Y)</td>\n  <td>26</td>\n  <td>Telegram</td>\n </tr>\n <tr>\n  <td>5</td>\n  <td>Geographic</td>\n  <td>16</td>\n  <td>Paging</td>\n  <td>27</td>\n  <td>Universal Access</td>\n </tr>\n <tr>\n  <td>6</td>\n  <td>Intermodal Numbers (FIX<->MOB porting</td>\n  <td>17</td>\n  <td>Payphone</td>\n  <td>28</td>\n  <td>Videotex</td>\n </tr>\n <tr>\n  <td>7</td>\n  <td>Internet Service Provider</td>\n  <td>18</td>\n  <td>Personal</td>\n  <td>29</td>\n  <td>Virtual Private Network</td>\n </tr>\n <tr>\n  <td>8</td>\n  <td>Local Rate</td>\n  <td>19</td>\n  <td>Prefix Type Unknown (Portability =N)</td>\n  <td>30</td>\n  <td>Voicemail (geographic)</td>\n </tr>\n <tr>\n  <td>9</td>\n  <td>Machine to Machine</td>\n  <td>20</td>\n  <td>Premium Rate</td>\n  <td>31</td>\n  <td>Voicemail (mobile)</td>\n </tr>\n <tr>\n  <td>10</td>\n  <td>Mobile</td>\n  <td>21</td>\n  <td>Routing Code</td>\n  <td>32</td>\n  <td>VoIP Telephony</td>\n </tr>\n <tr>\n  <td>11</td>\n  <td>Mobile (CDMA)</td>\n  <td>22</td>\n  <td>Satellite</td>\n  <td>33</td>\n  <td>Wireless geographic </td>\n </tr>\n </table>\n\n - 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.\n\n - The porteddate uses data from TMT ID’s own records and is not present in Live network queries. In some markets, historic data is available to TMT ID dating back to the beginning of Number Portability in that country, in other markets this data is maintained from TMT ID’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:\n\n\n <table>\n <tr>\n  <th>Port Date Type</th>\n  <th>Port Date</th>\n  <th>Notes</th>\n </tr>\n <tr>\n  <td>Exact</td>\n  <td>DD/MM/YYYY</td>\n  <td>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 ID onboarded that market. In this case date shown is the date on which TMT ID started to gather data.</td>\n </tr>\n <tr>\n  <td>Null</td>\n  <td>Null</td>\n  <td>Number has never been ported</td>\n </tr>\n </table>\n\n  > 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’\n\n - The porting_history field providers a full list of all documented porting events that are contained in TMT ID’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 ID (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:\n\n\n <table>\n <tr>\n  <th>Field</th>\n  <th>Description</th>\n </tr>\n <tr>\n  <td>action</td>\n  <td>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.</td>\n </tr>\n <tr>\n  <td>tmtnetwork</td>\n  <td>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.</td>\n </tr>\n <tr>\n  <td>i_type</td>\n  <td>Number type: ‘m’ – mobile, ‘f’ – fixed, ‘o’ - other</td>\n </tr>\n <tr>\n  <td>TS</td>\n  <td>Timestamp of when the porting event was recorded in the TMT ID database (YYYY-MM-DDTHH:MM:SS)</td>\n </tr>\n </table>\n\n  > Note 1: The Timestamp is the time that the change was recorded in the TMT ID 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.\n\n  > Note 2: Because the porting_history contains records since the country was on-boarded by TMT ID, 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. \n\n  - 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:\n\n\n <table>\n <tr>\n  <th>Risk Index</th>\n  <th>Description</th>\n </tr>\n <tr>\n  <td>Very High</td>\n  <td>Number ported within last 24 hours</td>\n </tr>\n <tr>\n  <td>High</td>\n  <td>Number ported within last 25-96 hours</td>\n </tr>\n <tr>\n  <td>Medium</td>\n  <td>Number ported within last 30 days</td>\n </tr>\n <tr>\n  <td>Low</td>\n  <td>Number ported outside 30 days, or not at all</td>\n </tr>\n <tr>\n  <td>-1</td>\n  <td>No Live query data available for that country, network or number</td>\n </tr>\n <tr>\n  <td>-2</td>\n  <td> if several datapoints, including the Simswap were requested, indicates that the specified phone number belongs to an MNO that is either not configured or unauthorized for Simswap.</td>\n </tr>\n </table>\n\n  - 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:\n\n\n <table>\n <tr>\n  <th>Risk Index</th>\n  <th>Description</th>\n </tr>\n <tr>\n  <td>Very High</td>\n  <td>SIM/Device changed within last 24 hours</td>\n </tr>\n <tr>\n  <td>High</td>\n  <td>SIM/Device changed within last 25-96 hours</td>\n </tr>\n <tr>\n  <td>Medium</td>\n  <td>SIM/Device changed within last 30 days</td>\n </tr>\n <tr>\n  <td>Low</td>\n  <td>SIM/Device changed outside 30 days, or not at all</td>\n </tr>\n <tr>\n  <td>-1</td>\n  <td>No data available for that country, network or number</td>\n </tr>\n <tr>\n  <td>-2</td>\n  <td> if several datapoints, including the Simswap were requested, indicates that the specified phone number belongs to an MNO that is either not configured or unauthorized for Simswap.</td>\n </tr>\n </table>\n\n   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.\n\n   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.\n\n  - 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:\n\n\n <table>\n <tr>\n  <th>Risk Index</th>\n  <th>Description</th>\n </tr>\n <tr>\n  <td>Very High</td>\n  <td>Device changed within last 24 hours</td>\n </tr>\n <tr>\n  <td>High</td>\n  <td>Device changed within last 25-96 hours</td>\n </tr>\n <tr>\n  <td>Medium</td>\n  <td>Device changed within last 30 days</td>\n </tr>\n <tr>\n  <td>Low</td>\n  <td>Device changed outside 30 days, or not at all</td>\n </tr>\n <tr>\n  <td>-1</td>\n  <td>No data available for that country, network or number</td>\n </tr>\n <tr>\n  <td>-2</td>\n  <td> if several datapoints, including the Simswap were requested, indicates that the specified phone number belongs to an MNO that is either not configured or unauthorized for Simswap.</td>\n </tr>\n </table>\n\n  - 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:\n\n\n <table>\n <tr>\n  <th>Code</th>\n  <th>Meaning</th>\n </tr>\n <tr>\n  <td>DE</td>\n  <td>Number deactivated by operator (no longer belongs to subscriber)</td>\n </tr>\n <tr>\n  <td>SW</td>\n  <td>Number swapped (transferred) to a different subscriber. Available for T-mobile and Verizon subscribers only.</td>\n </tr>\n <tr>\n  <td>SU</td>\n  <td>Number suspended. Verizon subscribers only.</td>\n </tr>\n <tr>\n  <td>RE</td>\n  <td>Number reactivated. Verizon subscribers only.</td>\n </tr>\n </table>\n\n   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 ID data for US Deactivation (June 2019).\n\n  - 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:\n\n\n <table>\n <tr>\n  <th>Query Result</th>\n  <th>Status</th>\n  <th>Status Message</th>\n </tr>\n <tr>\n  <td>Success</td>\n  <td>0</td>\n  <td>Success</td>\n </tr>\n <tr>\n  <td>Number not valid according to numbering plan for that country</td>\n  <td>1</td>\n  <td>Invalid Number</td>\n </tr>\n <tr>\n  <td>Country queried is not available to be queried by this service</td>\n  <td>2</td>\n  <td>Not Allowed Destination</td>\n </tr>\n <tr>\n  <td>The query has not been completed due to congestion (typically with upstream providers)</td>\n  <td>3</td>\n  <td>Congestion</td>\n </tr>\n <tr>\n  <td>The query has only been partially completed due to the unavailability of one or more data sources</td>\n  <td>4</td>\n  <td>Partial Reply</td>\n </tr>\n </table>\n\n  - 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.\n\n   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. \n\n   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.\n\n <table style=\"margin-left:auto;margin-right:auto\">\n <tr>\n  <th>Challenge</th>\n  <th>Type</th>\n  <th>Notes</th>\n </tr>\n <tr>\n  <th colspan=\"3\" style=\"text-align:center\">Block 1: Name</th>\n </tr>\n <tr>\n  <td>first_name</td>\n  <td>String</td>\n  <td>Value that will be matched against the first name on file, generating the matching score in the response.</td>\n </tr>\n <tr>\n  <td>last_name</td>\n  <td>String</td>\n  <td>Value that will be matched against the last name on file, generating the matching score in the response.</td>\n </tr>\n <tr>\n  <td>middle_name</td>\n  <td>String</td>\n  <td>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.</td>\n </tr>\n <tr>\n  <th colspan=\"3\" style=\"text-align:center\">Block 2: DOB</th>\n </tr>\n <tr>\n  <td>day</td>\n  <td>Numeric Value</td>\n  <td>Day of birth. This parameter will be used with month and year to generate an overall matching score for DOB.</td>\n </tr>\n <tr>\n  <td>month</td>\n  <td>Numeric Value</td>\n  <td>Month of birth. This parameter will be used with day and year to generate an overall matching score for DOB.</td>\n </tr>\n <tr>\n  <td>year</td>\n  <td>Numeric Value</td>\n  <td>Year of birth. This parameter will be used with month and day to generate an overall matching score for DOB.</td>\n </tr>\n <tr>\n  <th colspan=\"3\" style=\"text-align:center\">Block 3: Address</th>\n </tr>\n <tr>\n  <td colspan=\"3\">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.</td>\n </tr>\n <tr>\n  <td>street_no</td>\n  <td>String</td>\n  <td>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.</td>\n </tr>\n <tr>\n  <td>street</td>\n  <td>String</td>\n  <td>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.</td>\n </tr>\n <tr>\n  <td>unit_name</td>\n  <td>String</td>\n  <td>house name<br>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.</td>\n </tr>\n <tr>\n  <td>unit_no</td>\n  <td>String</td>\n  <td>unit number<br>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</td>\n </tr>\n <tr>\n  <td>city</td>\n  <td>String</td>\n  <td>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.</td>\n </tr>\n <tr>\n  <td>province</td>\n  <td>String</td>\n  <td>province/county/region<br>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.</td>\n </tr>\n <tr>\n  <td>postcode</td>\n  <td>String</td>\n  <td>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.</td>\n </tr>\n <tr>\n  <td>country</td>\n  <td>String</td>\n  <td>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.</td>\n </tr>\n <tr>\n  <th colspan=\"3\" style=\"text-align:center\">Block 4: Email Address</th>\n </tr>\n <tr>\n  <td>email</td>\n  <td>String</td>\n  <td>Value that will be matched against the email on file, generating the matching score in the response.</td>\n </tr>\n </table>\n\n\n<h3>KYC Match Response Parameters</h3>\n\nThe 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 ID from the appropriate data provider.\n\n<table> <tr>\n <th>Name</th>\n <th>Type</th>\n <th>Notes</th>\n</tr> <tr>\n <th colspan=\"3\" style=\"text-align:center\">Block 1: Name</th>\n</tr> <tr>\n <td>first_name_score</td>\n <td>Numeric Value</td>\n <td></td>\n</tr> <tr>\n <td>last_name_score</td>\n <td>Numeric Value</td>\n <td></td>\n</tr> <tr>\n <td>middle_name_score</td>\n <td>Numeric Value</td>\n <td>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.</td>\n</tr> <tr>\n <td>name_score</td>\n <td>Numeric Value</td>\n <td>If individual matching scores for first_name, last_name, middle_name are not available, an overall matching score will be provided.</td>\n</tr> <tr>\n <th colspan=\"3\" style=\"text-align:center\">Block 2: DOB</th>\n</tr> <tr>\n <td>dob_score</td>\n <td>Numeric Value</td>\n <td></td>\n</tr> <tr>\n <th colspan=\"3\" style=\"text-align:center\">Block 3: Address</th>\n</tr> <tr>\n <td>street_no_score</td>\n <td>Numeric Value</td>\n <td></td>\n</tr> <tr>\n <td>street_score</td>\n <td>Numeric Value</td>\n <td></td>\n</tr> <tr>\n <td>unit_no_score</td>\n <td>Numeric Value</td>\n <td></td>\n</tr> <tr>\n <td>city_score</td>\n <td>Numeric Value</td>\n <td></td>\n</tr> <tr>\n <td>province_score</td>\n <td>Numeric Value</td>\n <td></td>\n</tr> <tr>\n <td>postcode_score</td>\n <td>Numeric Value</td>\n <td></td>\n</tr> <tr>\n <td>country_score</td>\n <td>Numeric Value</td>\n <td></td>\n</tr> <tr>\n <td>address_score</td>\n <td>Numeric Value</td>\n <td>If previous individual matching scores are not available, the overall address score will be provided.</td>\n</tr> <tr>\n <th colspan=\"3\" style=\"text-align:center\">Block 4: Email Address</th>\n</tr> <tr>\n <td>email</td>\n <td>Numeric Value</td>\n <td></td>\n</tr> </table>\n\nNotes on KYC match score:\n\n\n - 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).\n\n - 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. \n\n - 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. \n\n - 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.\n\n - 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. "
  name: Available data
- description: "\nAs 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:\n\n<h3>type</h3>\nProvides 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.):\n\nExample:\n\n\n    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\"}'\n\n\nResponse:\n\n\n    {\n     \"447771000003\": {\n      \"number\": 447771000003,\n      \"type\" : \"mobile\",\n      \"etype\": \"10\",\n      \"status\" : 0,\n      \"status_message\" : \"Success\",\n     },\n     \"query\" : {\n      \"datapoints\" :\"type\",\n     }\n    }\n\n\n<h3>Porteddate</h3>\nTo 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:\n\nExample:\n\n\n    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\"}'\n\n\nResponse:\n\n\n    {\n     \"40721987086\" : {\n      \"number\" : 40721987086,\n      \"ported\" : true,\n      \"ported_date\" : \"2016-12-30 15:15:19\",\n      \"ported_date_type\" : \"exact\",\n      \"status\" : 0,\n      \"status_message\" : \"Success\"\n     },\n     \"query\" : {\n      \"datapoints\" : \"porteddate\"\n     }\n    }\n\n\n<h3>Porting_history</h3>\nA 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.\n\nExample:\n\n\n    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\"}'\n\n\nResponse:\n\n\n    {\n     \"40739521819\" : {\n      \"number\" : 40739521819,\n      \"current_network\" : {\n      \"lrn\" : null,\n      \"mcc\" : \"226\",\n      \"mnc\" : \"01\",\n      \"name\" : \"Vodafone Romania\",\n      \"spid\" : 4018720\n     },\n\n     \"ported\" : false,\n     \"porting_history\" : [\n       {\n         \"action\" : \"D\",\n         \"tmtnetwork\" : 4018720,\n         \"i_type\" : \"m\",\n         \"ts\" : \"2022-01-31T00:00:00\"\n       },\n       {\n         \"action\" : \"A\",\n         \"tmtnetwork\" : 4018740,\n         \"i_type\" : \"m\",\n         \"ts\" : \"2021-03-18T00:00:00\"\n       },\n      ],\n      \"status\" : 0,\n      \"status_message\" : \"Success\"\n     },\n      \"query\" : {\n          \"datapoints\" : \"porting_history,network\"\n          \"trxid\" : \"SDF8hD3\"\n         }\n     }\n\n\n<h3>Deactivation_history</h3>\nBy 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.\n\nExample:\n\n\n    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\"}'\n\n\nResponse:\n\n\n    {\n     \"12016572115\": {\n      \"number\": 12016572115,\n      \"deactivation_history\": [\n      {\n        \"operator\": \"ATT\",\n        \"action\": \"DE\",\n        \"ts\": \"2021-03-10T00:11:29\",\n        \"number\": 12016572115\n      },\n      {\n       \"operator\": \"ATT\",\n       \"action\": \"DE\",\n       \"ts\": \"2020-01-10T00:10:55\",\n       \"number\": 12016572115\n      },\n      {\n       \"operator\": \"ATT\",\n       \"action\": \"DE\",\n       \"ts\": \"2019-07-01T00:10:03\",\n       \"number\": 12016572115\n      }\n     ],\n     \"status\" : 0,\n     \"status_message\" : \"Success\"\n    },\n    \"query\": {\n     \"datapoints\": \"deactivation_history\",\n    }\n   }\n\n\n<h3>Roaminginfo</h3>\nBy 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.\n\nExample:\n\n\n    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\"}'\n\n\nResponse:\n\n\n    {\n      \"40721987086\" : {\n        \"is_roaming\" : false,\n        \"number\" : 40721987086,\n        \"status\" : 0,\n        \"status_message\" : \"Success\"\n      },\n      \"query\" : {\n        \"datapoints\" : \"roaminginfo\"\n      }\n    }\n\n\nportfraud\n\nportfraud checks TMT ID’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.\n\nExample:\n\n\n    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\"}'\n\n\nResponse:\n\n\n    {\n      \"40721987086\" : {\n        \"portfraud\" : low,\n        \"number\" : 40721987086,\n        \"status\" : 0,\n        \"status_message\" : \"Success\"\n        },\n      \"query\" : {\n        \"datapoints\" : \"portfraud\"\n      }\n    }\n\n\n<h3>kycmatch</h3>\n\nKYC Match takes as input both the queried number as well as the challenges/data that need to be matched. TMT ID 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.\n\nFor 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.\n\nIn 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.\n\nExample:\n\nPOST /v3/ HTTP/1.1<br> Host: XXXXXXXXXX<br> Accept: application/json<br> Content-Type: application/json<br>\n\n\n    curl -L -X POST 'https://XXXXXXXXXX/v3/' \\\n    -H 'X-Api-Secret: xxxxxxxxxxx' \\\n    -H 'X-Api-Key: xxxxxxxxxxx' \\\n    -H 'Content-Type: application/json' \\\n    --data-raw '{\n      \"number\": \"40721987086\",\n      \"dpoints\": \"kycmatch\",\n      \"kyc_challenges\": {\n        \"name\": {\n           \"first_name\": \"John\",\n           \"middle_name\": \"Robert\",\n           \"last_name\": \"Smith\"\n        },\n        \"dob\": {\n           \"day\": \"2\",\n           \"month\": \"11\",\n           \"year\": \"1985\"\n        },\n           \"address\": {\n           \"street\": \"Omnia\",\n           \"street_no\": \"23\",\n           \"unit_no\": \"11A\",\n           \"city\": \"Toronto\",\n           \"state\": \"Ontario\",\n           \"postcode\": \"M4B1B3\",\n           \"country\": \"CA\"\n        },\n          \"email\": \"john_smith@example.com\"\n      }'\n\n\n**Example Response – Individual Address KYCMatch Scores:**\n\n\n    {\n    \"40721987086\" : {\n        \"kyc_results\" : {\n            \"first_name_score\": 100,\n            \"last_name_score\": 100,\n            \"middle_name_score\": -1,\n            \"street_no_score\": 100,\n            \"street_name_score\": 80,\n            \"unit_no_score\": -1,\n            \"city_score\": 79,\n            \"province_score\": 0,\n            \"postcode_score\": 100,\n            \"country_score\": 100,\n            \"dob\": 50,\n            \"email_score\": 100,\n        },\n      \"number\" : 40721987086,\n      \"status\" : 0,\n      \"status_message\" : \"Success\"\n      },\n      \"query\" : {\n       \"datapoints\" : \"kycmatch\"\n      }\n    }\n\n\n**Example Response – Overall Address KYCMatch Score:**\n\n\n    {\n    \"40721987086\" : {\n        \"kyc_results\" : {\n        \"first_name_score\": 100,\n        \"last_name_score\": 100,\n        \"middle_name_score\": -1,\n        \"address_score\": 78,\n        \"dob\": 50,\n        \"email_score\": 100,\n        },\n      \"number\" : 40721987086,\n      \"status\" : 0,\n      \"status_message\" : \"Success\"\n      },\n      \"query\" : {\n       \"datapoints\" : \"kycmatch\"\n      }\n    }\n\n<h3>Online Presence</h3>\n\n\"online_presence\" offers information regarding if the queried number is linked to an active account on a range of business and social platforms. The query returns a list of the available platforms for the corresponding country and the status of the number on that platform.\n\nFor queries against valid numbers, \"online_presence\" returns a complete list of all supported platforms with one of the following responses for each:\n\nThe service will provide the “online_presence” json block, including information related to each of the following platforms: WhatsApp, Telegram, Amazon, Google, Office365, Instagram, LinkedIn, Skype, Facebook, Viber, Twitter.\n\n**Request format:**\n\n\n    curl -L -X POST 'https://api.tmtverify.com/v3/' -H 'X-Api-Key: apikey' -H 'X-Api-Secret: apisecret' -H 'Content-Type: application/json' --data '{\"number\":\"13476841xxx\",\"dpoints\":\"online_presence\"}'\n\n\n**Response (valid number):**\n\n\n    {\n      \"40737105xxx\": {\n        \"number\": 40737105xxx,\n        \"online_presence\": {\n          \"whatsapp\": 1,\n          \"telegram\": 0,\n          \"amazon\": 1,\n          \"google\": 1,\n          \"office365\": 1,\n          \"instagram\": 1,\n          \"linkedin\": -1,\n          \"twitter\": 1,\n          \"skype\": 0,\n          \"flipkart\": -1,\n          \"viber\": 0,\n          \"bukalapak\": -1\n        },\n        \"status\": 0,\n        \"status_message\": \"Success\"\n      },\n      \"query\": {\n        \"datapoints\": \"online_presence\",\n        \"trxid\": \"LHfPR6J\"\n      }\n    }\n\n\n**Response (Vendor request failed):**\n\n\n    {\n      \"40737105xxx\": {\n        \"number\": 40737105xxx, \"online_presence\": {},\n        \"status\": 4,\n        \"status_message\": \"Partial Reply\"\n      },\n      \"query\": {\n        \"datapoints\": \"online_presence\",\n        \"trxid\": \"J7v1ofP\"\n      }\n    }\n\n\n**Response (Authorization):**\n\n\n    {\n      \"40737105xxx\": {\n        \"number\": 40737105xxx,\n        \"type\": \"mobile\",\n        \"etype\": \"10\",\n        \"online_presence\": {\n          \"error\": 2,\n          \"error_description\": \"Authentication failed\"\n        },\n        \"status\": 4,\n        \"status_message\": \"Partial Reply\"\n      },\n      \"query\": {\n        \"datapoints\": \"online_presence,type\",\n        \"trxid\": \"J7v1ofP\"\n      }\n    }"
  name: Specific Datapoint responses
x-tagGroups:
- name: Introduction
  tags:
  - About TMT
- name: Service Specifications
  tags:
  - Standard API Call
  - Available data
  - Specific Datapoint responses
servers:
- url: https://api.tmtverify.com
components: {}