Trust Score

introduction trust score api (“trust score”) is a real time indicator of a phone number’s trustworthiness it accurately measures the real time risk of authenticating a consumer using a specific phone number trust score achieves this by analyzing and scoring daily life cycle change events, along with leveraging carrier signals and core telecom infrastructure signals, enabling us to manage the tenure identity behind the phone number most consumers have had their phone number for many years customer verification increasingly relies on “something you have” authentication using phones and phone numbers, an integral aspect of a consumer’s daily life in an increasingly digital economy, accelerated by covid 19, an amplified focus on fraud prevention is essential for many of our customers trust score provides banks, financial institutions, insurance companies, retail companies, and other customers with a tool that can be applied to multiple use cases where knowing the fraud risk of a transaction is critical features trust score establishes the reputation portion of pro model of identity verification p ossession–confirm possession of the phone with “something you have” authentication r eputation–screen for risk to ensure the phone being used to authenticate is not compromised or used by a bad actor o wnership–verifying the phone number associated with the rightful owner or actual consumer to make a trust score call, the phone number is the only piece of information required our proprietary algorithm then consumes carrier signals and uses our managed identity intelligence to generate a trust score for the phone number, a numerical value ranging from 0 to 1,000 (the higher the number, the more trustworthy) in addition to the score itself, reason codes are returned in the api response, signifying the factors that affected the score depending on the parameter passed in the api and the end user mobile consent obtained, some of the attributes used to calculate the trust score can be returned as well, representing more specific data and fields the reason codes and line attributes can be interpreted independently of the trust score, should you want to establish further rules for risk tolerance score component framework there are several inputs and variables that affect the trust score of a phone number, some that increase the score and some that decrease it although specifics cannot be shared for security purposes, below are some general guidelines that may be shared that indicate how the trust score may be affected increase score found long tenure with sim device phone number signzy managing identity carrier clients inquiring on the phone decrease score inactive status (cannot place phone calls or send and receive texts) recent changes to the sim or device many changes in a short amount of time to sim, device, port, phone number higher risk line types (e g , voips not connected to a physical location) no data was supplied from the carrier/telecom the method used to calculate trust score is a point based deduction the process evaluates all of the heuristic based business rules in the model, and for those that meet their conditions, several points are either deducted or added, starting with the perfect score of 1,000 the number of points deducted or added depends on the components’ criteria being met the final score can range between 0–1,000, with the highest level of trust being 1,000 and the lowest level of trust being 0 more information on applying these levels of trust can be found in the trust score interpretation section below for example, if a given phone number meets two rules, one deducting 150 points and another deducting 100 points, the resulting score will be 750 (1,000 – 150 – 100=750) trust score interpretation signzy generally recommends the following integer thresholds for mobile line type numbers when using trust score 0 300 low trust 301 629 medium trust 630 1000 high trust trust score flow response versions the application of the trust score api allows for a degree of customization to best suit your organization’s needs, with two different request and response versions that can control the amount of information returned from the api call there are also three ways you can analyze a trust score using only the trust score integer, the integer and the returned reason codes, or the integer plus the reason codes plus the carrier’s phone line attributes the response body contains the trust score integer, the reason codes and the carrier’s phone line attributes as a standard response additionally, if you pass the details field as true, additional phone line attributes and change events values are returned, potentially including carrier status velocity (or the number of changes within the last 90 days) for phone number port sim device tenure (or length of time seen, shown by mindate and maxdate) for sim our subscriber records phone number carrier device for all these attributes, standard response will store null value for these fields but when details is set to true and consent status is provided then the values will be shown for the above attributes in response note, as mentioned in the consumer consent section above, all phone line attributes listed above are only available from the carrier when consent is obtained from your consumer minimumdate & maximumdate tenure in order to protect consumer's data and keep from sharing exact dates for tenure calculations, the minimumdate and maximumdate fields indicate ranges of time that the most recent date of activation or change could have occurred in the minimumdate is the most recent date/time of that range, and the maximumdate is the earliest date/time see the minimum/maximum logic section for more details api details you must first login before sending the request the authorization header in the request must include the access token obtained from the login api call sample curl curl location 'https //api signzy us/api/v3/us kyc/trust score' \\ \ header 'content type application/json' \\ \ header 'authorization \<auth token>' \\ \ data '{ "consentstatus" "optedin", "phonenumber" "2001001686", "details" "true", "countrycode" "us" }'curl location 'https //api preproduction signzy us/api/v3/us kyc/trust score' \\ \ header 'content type application/json' \\ \ header 'authorization \<auth token>' \\ \ data '{ "consentstatus" "optedin", "phonenumber" "2001001686", "details" "true", "countrycode" "us" }' request body parameters key type mandatory description consentstatus string true the consent status of the phone number possible values are optedin the end user has provided consent for the collection of their personal data optedout the end user has refused to allow collection of their personal data notcollected no attempt has been made to obtain consent from the end user unknown the status of consent collection is unknown note this value must be optedin in order to access mno data phonenumber string true the phone number being queried (without leading plus sign & country code) details string false specifies whether to include additional details in the response input is "true" or "false" countrycode string true the country code associated with the phone number "us" or "ca" response body parameters key type description status integer the status of the request a response of 0 indicates success any non 0 response is an error indication description string a text string that defines the cause of the status code response object the response object containing trust score details transactionid string unique transaction identifier used to identify the results of the request payfonealias string a persistent id that uniquely identifies a telephone subscriber phonenumber string the phone number associated with the subscriber linetype string line type associated with the phone number possible values are mobile, landline, fixedvoip, nonfixedvoip carrier string the carrier related to the phone number countrycode string the country code associated with the phone number statusindex string a bitmapped value that represents networkstatus, accounttype, accountrole, and customertype isbaselined boolean an indicator to communicate whether signzy has ever transacted with the input phone number before the current transaction trustscore number an integer value ranging from 0–1000 that denotes the real time trustworthiness of a phone number reasoncodes string\[] an array of indicators providing additional context about the transaction carrierstatus string carrier status associated with the phone number values include active suspended disconnected unknown null value is returned only if consentstatus=optedin, details=true, else it will be null in standard response phonenumbervelocity integer the number of times the subscriber has changed their phone number value is returned only if consentstatus=optedin, details=true & if phonenumber is changed, else it will be null in standard response portvelocity integer the number of times the subscriber has changed their carrier within the last 90 days value is returned only if consentstatus=optedin, details=true & if carrier is changed, else it will be null in standard response simvelocity integer the number of times the mobile subscriber has changed their sim within the last 90 days value is returned only if consentstatus=optedin, details=true & if sim is changed, else it will be null in standard response devicevelocity integer the number of times the mobile subscriber has changed their device within the last 90 days value is returned only if consentstatus=optedin, details=true & if device is changed, else it will be null in standard response payfonetenure object the amount of time signzy has been able to track the subscriber defined with a minimum and maximum date only returns if details=true minimumdate date time payfone tenure object attribute carriertenure object the amount of time signzy has been able to track the carrier associated with the subscriber defined with a minimum and maximum date only returns if consentstatus=optedin, details=true minimumdate date time carrier tenure object attribute maximumdate date time carrier tenure object attribute phonenumbertenure object the amount of time signzy has been able to track the phone number associated with the subscriber defined with a minimum and maximum date only returns if details=true minimumdate date time phone number tenure object attribute simtenure object the amount of time signzy has been able to track the sim association with the subscriber defined with a minimum and maximum date only returns if consentstatus=optedin, details=true minimumdate date time sim tenure object attribute maximumdate date time sim tenure object attribute devicetenure object the amount of time signzy has been able to track the device association with the subscriber defined with a minimum and maximum date only returns if consentstatus=optedin, details=true minimumdate date time device tenure object attribute maximumdate date time device tenure object attribute porteddate the date associated with a port of the phone number defined with a minimum and maximum date only returns if details=true minimumdate date time ported date object attribute maximumdate date time ported date object attribute sample responses (us) { "result" { "requestid" "65ff22b201c1acf7f5233f69", "status" 0, "description" "success ", "response" { "transactionid" "20496635398", "payfonealias" "79510afc4vk8384926e400823fffd9ff40mekgygsx99p8c87721302e560194d77b5649ea8673ecf5f6g3244cfe2a52a4d84c289e55ed79814e489d3c", "phonenumber" "12245074373", "linetype" "mobile", "carrier" "t mobile usa", "countrycode" "us", "statusindex" "e1", "isbaselined" true, "trustscore" 1000, "phonenumbervelocity" null, "portvelocity" null, "payfonetenure" { "minimumdate" "2023 03 24t23 59 59 000z" }, "phonenumbertenure" { "minimumdate" "2023 03 24t23 59 59 000z" }, "reasoncodes" null, "carrierstatus" null, "simvelocity" null, "devicevelocity" null, "carriertenure" { "minimumdate" null, "maximumdate" null }, "simtenure" { "minimumdate" null, "maximumdate" null }, "devicetenure" { "minimumdate" null, "maximumdate" null }, "porteddate" { "minimumdate" null, "maximumdate" null } } } } sample responses (ca) { "result" { "requestid" "65ff21f001c1acf7f5233f56", "status" 0, "description" "success ", "response" { "transactionid" "20496598648", "phonenumber" "13659948858", "linetype" "mobile", "carrier" "rogers", "countrycode" "ca", "statusindex" "ec", "isbaselined" null, "trustscore" 90, "reasoncodes" \[ { "code" "lp", "description" "low tenure device" }, { "code" "pt", "description" "the phone number is currently in a ported state any number not currently on its original home carrier will have a pt reason code this is not indicative of a recent carrier port " }, { "code" "ls", "description" "low tenure sim" }, { "code" "lt", "description" "low tenure identity" } ], "carrierstatus" "active", "payfonetenure" { "minimumdate" "2024 02 22t23 59 59 000z", "maximumdate" "2023 12 24t00 00 00 000z" }, "carriertenure" { "minimumdate" "2024 02 22t23 59 59 000z", "maximumdate" "2023 12 24t00 00 00 000z" }, "phonenumbertenure" { "minimumdate" "2024 02 22t23 59 59 000z", "maximumdate" "2023 12 24t00 00 00 000z" }, "simtenure" { "minimumdate" "2024 02 22t23 59 59 000z", "maximumdate" "2023 12 24t00 00 00 000z" }, "devicetenure" { "minimumdate" "2024 02 22t23 59 59 000z", "maximumdate" "2023 12 24t00 00 00 000z" }, "payfonealias" null, "phonenumbervelocity" null, "portvelocity" null, "simvelocity" null, "devicevelocity" null, "porteddate" { "minimumdate" null, "maximumdate" null } } } } consent status response comparisons the table below shows which attributes return for optedin versus the attributes returned for optedout, notcollected, and unknown note again that the details field must be set as true to see these detailed attributes optedin optedout, notcollected, unknown countrycode countrycode carrierstatus phonenumbervelocity phonenumbervelocity portvelocity portvelocity simvelocity devicevelocity payfonetenure payfonetenure phonenumbertenure phonenumbertenure carriertenure simtenure devicetenure porteddate porteddate response parameters can be null based on the data availability from the api sources reason codes reason code description additional details cu carrier call was unsuccessful returned when change data was/is not available, which includes \ we do not support subscriber management for a carrier, which is needed for change events \ we do not receive imsi, or imei changes from a carrier (e g , us cellular) \ we did not get a response from the carrier during the transaction (timeout, for example) d2 the phone number was recently deactivated a disconnect event has been detected in the last 2 days dr the device date returned was not obtained real time; there could be a more recent device change returned for a phone number if the mno is a carrier that does not provide imei change events in real time but we can derive an imei change (e g , sprint) this can be used to determine that a device change occurred since the last time it was checked, but the date is ambiguous and could have happened at any point between the max date and the min date dv high device change velocity this may indicate a higher risk of authenticating the consumer, especially during customer onboarding ff call forwarding is not enabled on the consumer’s phone the call forwarding check and mobile consent must be enabled on your account, and consentstatus passed optedin, for this reason code to be returned fo call forwarding is enabled on the consumer’s phone the call forwarding check and mobile consent must be enabled on your account, and consentstatus passed optedin, for this reason code to be returned hv high velocity of change events associated with phone this may indicate a higher risk of authenticating the consumer, especially during customer onboarding i5 indicates zero instant link transactions in the last 90 days for the phone number being queried this reason code only returns if enabled for you, and a higher level of il transaction within the period could indicate a higher risk factor i6 indicates 1–3 instant link transactions in the last 90 days for the phone number being queried this reason code only returns if enabled for you, and a higher level of il transaction within the period could indicate a higher risk factor i7 indicates 4–7 instant link transactions in the last 90 days for the phone number being queried this reason code only returns if enabled for you, and a higher level of il transaction within the period could indicate a higher risk factor i8 indicates 8–15 instant link transactions in the last 90 days for the phone number being queried this reason code only returns if enabled for you, and a higher level of il transaction within the period could indicate a higher risk factor i9 indicates more than 15 instant link transactions in the last 90 days for the phone number being queried this reason code only returns if enabled for you, and a higher level of il transaction within the period could indicate a higher risk factor lp low tenure device this may indicate a higher risk due to low tenure normal circumstances may be a device upgrade if the reason code lt is not present ls low tenure sim this may indicate higher risk due to low tenure on sim pair this with your high risk events to mitigate the phone takeover at the carrier lt low tenure mobile identity this may indicate a higher risk of identity theft or synthetic id fraud, especially at account opening or customer onboarding nd phone number network status information is not available while this may mean no data is available, this may not necessarily be indicative of risk nm not a mobile line type it may not indicate risk but is intended to filter mobiles from non mobile line types np non personal line it could signify a business or government phone line pn mobile phone number is not active the phone number provided is either suspended or deactivated; it cannot place or receive voice calls or sms text messages transmitted over a cell tower pt phone number is currently in a ported state the phone number has been ported outside of the carrier that owns the phone number this reason code will continue to fire while the phone is in the ported state use the ported date field to determine if the port was recent (rather than just relying on the return of this reason code) to manage the risk of carrier takeover via a port attack rl phone number is associated with a high risk line type (non fixed voip or prepaid mvno) this may indicate higher fraud risk rn phone number is at low risk for fraud as a mobile line listed on the override services registry (osr) it may indicate lower risk for mobile line type phone numbers, carriers must authenticate their subscriber to add their number to the osr only the owning carrier can add their mobile phone numbers to the osr rr phone number is at a higher risk for fraud as a non mobile line listed on the override services registry (osr) the phone is at risk of sms forwarding vulnerability but is not necessarily always at high risk for fraud phone numbers that are on the osr are vulnerable to sms message hijacking for non mobile line type phone numbers, adding a number to the osr is not restricted to the owning carrier other carriers, including non major carriers more susceptible to fraud, can add these phones to the osr sa sub account line multiple phone lines are associated with one account, typically on family plans it may not be indicative of risk sr the sim date returned was not obtained real time; there could be a more recent sim change returned for a phone number if the mno is a carrier that does not provide imsi change events in real time but we can derive an imsi change this can be used to know that a sim change occurred since the last time it was checked, but the date is ambiguous and could have happened between the max date and the min date uc insufficient data to calculate trustscore when no data is returned, this negatively affects the trust score but may not indicate risk minimum/maximum date logic to avoid sending specific dates for phone attribute change events (i e , to show sim tenure, device tenure, etc ), we return general time ranges of minimum maximum dates that the most recent change event for the attribute falls under concerning the current date change event time range minimum date field (most recent time possible) maximum date field (longest time possible) unknown or blank no date returned no date returned <=24 hours ago current date with time of 23 59 59 current date with time of 00 00 00 > 24 hours and <=48 hours ago current date minus 1 day & time of 23 59 59 current date minus 2 days & time of 00 00 00 > 48 hours and <=7 days ago current date minus 2 days & time of 23 59 59 current date minus 7 days & time of 00 00 00 > 7 days and <=30 days ago current date minus 7 days & time of 23 59 59 current date minus 30 days & time of 00 00 00 > 30 days and <=90 days ago current date minus 30 days & time of 23 59 59 current date minus 90 days & time of 00 00 00 > 90 days and <=365 days ago current date minus 90 days time of 23 59 59” current date minus 365 days & time of 00 00 00 > 365 days ago current date minus 365 days & time of 23 59 59 no date returned sample error { "error" { "name" "error", "message" " message ", "status" 400, "reason" "badrequest", "type" "ok", "statuscode" 200 } } error response parameters parameter description error this parameter contains the error error name the name of the error error message the error message error status status of the api error reason reason for error error type type of the error error statuscode request status code from signzy getting help please feel free to contact us if you have any questions, require clarification, or have ideas for how to make the documents or any of our services better you can reach out to us at help\@signzy com we strive to provide prompt and reliable assistance, ensuring your queries are addressed effectively we value your feedback and are committed to making your experience smooth and enjoyable our team is dedicated to assisting you with any needs you may have thank you for choosing our services we look forward to helping you!