How to use Trestle IQ Decision Signals for better anti-fraud

What the service returns

You send a name with a phone, address, email and IP, and the service returns checks on each and a composite identity score.

A single query takes a name, email, phone, address and IP as its key identity inputs. In the vendor’s words, “In a single query, the Decision Signals API returns 70+ data signals and network insights to provide match statuses, validity flags, enriched metadata, and distance calculations between the key identity data inputs of name, email, phone, address, and IP.” The response brings those results together as:

• A composite identity score
• Checks for the primary and secondary phone inputs
• Checks for the primary and secondary address and email inputs
• IP checks
• Warnings and errors

What is Trestle IQ Decision Signals

Trestle IQ Decision Signals is an identity and contact data service organised around a composite identity score. A single response groups the score with phone, address, email and IP checks, plus warnings and errors. You can read the overall identity result alongside the findings returned in the response.

The service covers these signal areas:

• Email contact details and validity
• Phone contact details and ownership matches
• Address validity and identity agreement
• Network trust and connection context
• Agreement across submitted identity inputs

Its contact and network results cover part of the fraud signal set. Device, velocity, list and behavioural signals come from elsewhere in your decision flow:

• Device fingerprints
• Counts measured across time windows
• Negative lists and known-bad records
• Session behaviour and interaction patterns

The identity checks

The four checks support these decisions and return these findings:

Check	What it helps you decide	What it returns
Phone	Whether a number is valid, what kind of line carries it, whether it is commercial or prepaid, which carrier serves it, and whether its name or address agrees with the submitted identity	Line classification as Mobile, Landline, FixedVOIP, NonFixedVOIP, Premium, TollFree, Voicemail or Other; address comparison from Match through partial location matches to No Match
Address	Deliverability, commercial use, forwarding and agreement with the submitted name	For a secondary address, the distance from the primary address in miles and whether the address is linked to the primary resident
Email	Validity, disposable use, mailbox age and name agreement	An email age score from 0 to 100 for the address itself in email_age_score, and domain age in days in email_domain_creation_days
IP and connection	Connection trust, anonymising infrastructure, geolocation and distance from the submitted identity details	A trust score; connection types including Residential, Mobile, Hosting, VPN, Proxy and Tor; geolocation; and four distance measures from the primary and secondary addresses and phones

The identity score

The composite begins at a neutral midpoint of 50 and moves additively from there. The vendor does not publish the weight of any single signal. The vendor describes the construction this way:

“The score is additive: each valid, matching signal contributes positively and each mismatch or invalid signal contributes negatively from a neutral midpoint of 50.”

The resulting number places the identity in one of five published bands:

Score	Band
80–100	High trust
60–79	Moderate
50–59	Neutral baseline
30–49	Below baseline
0–29	Low trust

The band labels the score range in which the result falls.

A partial address leaves the address block empty, so the address check adds nothing. The phone check compares the number against the submitted postal code, and in the controlled calls that comparison moved the score two points. A controlled live comparison shows the effect of that coverage. Holding one identity constant, the score moved from 39 with a name and phone to 52 after adding a full address, an email and an IP. Read the number beside the fields that were actually submitted, because the same identity can produce a different score when the evidence available to the service changes.

The cutoff belongs to you. The vendor says, “Recommended cutoff thresholds will depend on the inputs supplied and the risk profile of your traffic.” The score supplies a band. Your policy supplies the action.

Fraud decision flow

Build the decision flow in this order:

1. Place the paid identity call after free eligibility rules and other cheap knock-outs. Fraud teams usually stage verification with cheap checks first and paid checks only for applications that survive them. The external call belongs behind those early rules, so it runs on applications that have passed the first cut.
2. Read the component checks beside the composite because the same finding can support different dispositions:
   • A hard block that stops the application
   • A score that contributes points toward a total
   • A step-up that requests extra verification
   • A manual review that queues the case for a person
   • A monitor outcome that allows and flags for later analysis
3. Map the composite to one of those five outcomes; your policy can map an individual component to several of them.
4. Set the cutoff against your own traffic and risk profile, then assess fraud rate and decline rate together. Derive age before applying a rule: email_domain_creation_days carries domain age, while email_age_score carries the mailbox-age score.
5. Treat null categorical results such as name_match, is_valid and line_type as their own value, and do not impute them with a default. A null can mean:
   • The input was not provided
   • The input was invalid
   • No data coverage was available
   • The field is reserved

Where it fits

Onboarding and application fraud

For onboarding and application fraud, the service is most relevant to identity and contact checks before later policy actions. It is strongest before an account has its own history, and weakest for account takeover, where behavioural and device signals dominate.

Checkout and payments

At checkout and in payments, place the returned contact and network findings beside the business’s own decision rules. The service forwards no business device information or velocity counts. Those come from elsewhere in the decision flow and sit beside the returned findings when the policy determines the transaction’s disposition. The surrounding policy determines how that combined context is used.

Lending, before the bureau pull

In consumer lending, the lending sequence has six parts:

1. Eligibility check
2. Identity verification
3. Credit assessment and the bureau pull
4. Affordability
5. Pricing
6. Decision

Identity verification is second, after eligibility and before credit assessment and the bureau pull, so the service can supply identity and fraud-screening evidence before the bureau assessment.

A demo case

The captured live set contains 31 Decision Signals responses, based on four public organisations and one consenting individual. Each organisation was checked against the street address, switchboard number and email domain it publishes itself. The identities are recorded in the evidence pack, not published, and no other private individual was queried.

This demo case follows Dana Whitfield as five forms arrive in sequence. Her responses were built for this article from a scoring table calibrated on live calls. The score rises as each form adds identity evidence:

Dana has a mobile line whose subscriber name matches, while the live identity used a company switchboard on a NonFixedVOIP line. A mobile against a NonFixedVOIP line measured 18 points in the controlled calls.

Inputs added	Score
Name and phone	63
City, state and postal code	65
Street line	77
An established email	83
An IP twelve miles from the address	84

Dana's demo response:

identity_score: 84
primary.phone.is_valid: true
primary.phone.line_type: Mobile
primary.phone.name_match: true
primary.phone.address_match: Match

The demo score gains twenty-one points as the forms become more complete.

Reed joins Dana in the second half of the demo case, with the same phone, address and IP results and the same score of 84:

Check	Dana	Reed
identity score	84	84
phone	Mobile, subscriber name matches	Mobile, subscriber name matches
address	Single Unit, resident name matches	Single Unit, resident name matches
IP	Residential, 12 miles from the address	Residential, 12 miles from the address
email	valid	disposable, with the warning "Primary Email: Disposable Email"

Both totals remain 84 because the address Reed used is a well-established mailbox, so the component results still matter beside the total.

Frequently asked questions

Does Trestle IQ Decision Signals cover countries outside the US?

The captured evidence does not establish geographic coverage beyond the documented examples, which are all from the US. An outside-US trial needs coverage confirmation for the checks that matter to your traffic: a Czech mobile reached phone name matching, but the extent of coverage remains unknown.

What is the minimum identity input for the documented score?

The documented minimum for a score is a name plus at least one phone, address, email or IP address. The documentation says a name alone returns 50; a live call with a name alone returned a 400 error asking for a phone or an email. Send a phone or an email with the name.

How can you investigate a low identity score?

Named warnings identify the component finding alongside the composite score. Examples include “Primary Email: Disposable Email”, “IP: Proxy detected” and “Primary Phone: Invalid Phone”, so the investigation can start with the returned check that contributed to the result.

What does the sandbox return?

The sandbox returns pre-stored responses across phone, name, email, address and IP inputs, so it demonstrates response shape and documented scenarios rather than live enrichment. Its canned response is keyed to the scenario and may include blocks for inputs the request did not carry.

Are Decision Signals and the contact-grading product the same product?

They are separate returned products. Decision Signals provides the identity score and component checks, while the captured Real Contact example returned phone.contact_grade “D” alongside activity_score 100 and name_match false for a valid phone.

What do the API error statuses mean?

Each status belongs in a separate branch of your decision flow:

Status	What it means
400	A parameter is missing or invalid
401	The key is missing or invalid
403	The key has no access or is disabled
429	The request was rate limited and not processed
500	A server error occurred

A rate-limited request was not processed, so it should not be retried immediately.

The step that puts this call into a decision flow is configuring the data source. The assistant can do it from the vendor’s documentation page, including its documented inputs, URL, credential header requirement and sandbox setting.