What TrustVerify's 0–100 trust score includes, what a missing check does to it, and how a UK marketplace should read it before approving a seller.
A trust score condenses check results into one number from 0 to 100, where higher means lower risk. It is a sorting aid for a reviewer. It is not, on its own, a decision to let a seller trade.
TrustVerify uses that name for two different calculations. Mixing them up is the mistake this guide is here to prevent. One number sits on an identity-verification report and is built from the checks that ran on that person. The other is an API call: you send signal values you already hold, and the API weights them. A UK marketplace should know which number it is looking at before it writes a rule around it.
This article explains both, with the bands and caps the product uses today, a worked example from a UK marketplace, and the point at which a person still has to decide.
When someone completes an identity check, the report carries a trust score, a risk band, and the individual results beside it. The score is there so a reviewer can see, at a glance, how strong the biometric evidence was and whether a document problem has already pulled the number down.
It is not a blend of every check TrustVerify can run. A Companies House result does not move this number. A sanctions result does not move it either. Those checks are reported next to the score, and the sanctions result can stop an automatic approval, but they are not ingredients of the arithmetic. If your rule says "approve anyone over 80", you have ignored the company check and the screen. That is the wrong way to read the report.
POST /api/v1/trust-score does something else. You send an entityId and a list of signals. Each signal has a type and a value from 0 to 1. TrustVerify applies fixed weights and returns a 0–100 score, a tier, and a breakdown of the values you sent. With no signals, the score is 50.
Use this when you already hold results — a face-match figure, an AML outcome, an account age — and you want one weighted number for a seller record in your own database. You choose which values to send. You do not choose the weights.
The score on an identity-verification report is calculated only from checks that actually ran. A check that did not run is left out of the calculation, never counted as zero:
The rest of the check is reported alongside the score rather than folded into it:
Two caps sit on top of the arithmetic, and they matter more than the raw face-match figure:
| What happened | What the score can show |
|---|---|
| The document could not be read (no name or document number) | At most 59, which is high risk |
| The document is expired, or the image carried a tamper flag | At most 74, which is below the low-risk line |
| A strong face match and a readable, in-date document | At most 95 |
The score does not go above 95. If the face comparison did not run, and there is no other measured biometric result to include, the score is 55. That is high risk. It is not a pass, and it is not printed as a fabricated zero. A measured zero — a comparison that ran and found no likeness — stays in the calculation. Dropping it out would make the score look better than the evidence.
A single score is useful because a queue can be sorted by it. It is a poor sole gate. An identity check is approved automatically only when all of the following are true:
Anything else is held for a person. The status is approved or held for review. A low score does not decline the seller by itself, and neither does a failed face match. A reviewer sees the score, the band, the document fields and the screen, and records the decision. A strong face match still waits if the document is expired, the name does not match, or the screen did not come back clear. See fraud prevention for order scoring, which is a separate check.
TrustVerify maps the identity-check score to a fixed band:
| Score | Band | What to do with it |
|---|---|---|
| 80 to 95 | Low risk | Biometric evidence is strong and no document cap applied. Still confirm the screen and the details before you treat it as approved. |
| 60 to 79 | Medium risk | Read the report. A cap of 74 means the document is expired or the image was flagged. |
| 55 to 59 | High risk | The face comparison was weak or missing, or the document could not be read. A person should look. |
The bands are not a setting. You cannot move "low risk" from 80 to 70. What you decide is what your team does with each band: list a low-risk, clear-screen seller straight away, or still look at every new limited company before the first payout.
Picture a marketplace in Leeds that sells refurbished outdoor kit. Two sellers apply on the same morning.
A private seller in York wants to list a used jacket. The face match is strong, the document is in date, the name matches what they typed, and the sanctions and PEP screen comes back clear. The score lands in the low-risk band, under the cap of 95. The check can be approved because every gate passed, not because the number was high. A proof-of-address file, if you collect one, is for a person to read. It is not its own score. See identity verification.
A limited company in Sheffield wants to list new electronics under a company name. The person opening the account passes the same identity check, with a low-risk score. That number says nothing about the company. You still look up the company on Companies House, read the officers and the people with significant control, and screen the company and those people. Those results live on the KYB check and, if a person needs to look, on the review queue. A high identity score plus an inactive company is a hold, not an approval. The score did its job by not pretending to include the register.
A third case is the one teams miss. The face match is strong, so the uncapped score would be high, but the passport expired last month. The score is held to at most 74, medium risk, and the check is held for review because the document is expired. The seller is not declined by the number. Someone looks, asks for a current document, and records why.
If you later want one figure on the seller's row in your own admin, send the results you trust into the API trust score. Put the face-match result in as biometric_match and the screen in as aml_result, each scaled from 0 to 1. Leave out anything you did not measure. An empty call returns 50, tier provisional, which is not a reason to pay the seller.
The weights are fixed. A type the table does not list weighs 0.05. Values must be numbers from 0 to 1. A missing or non-numeric value is rejected rather than guessed.
| Signal type | Weight | What you are sending |
|---|---|---|
| biometric_match | 0.25 | How strong the face match was, scaled 0 to 1 |
| aml_result | 0.20 | Your screen outcome, scaled 0 to 1 |
| document_authenticity | 0.15 | How usable the document read was, scaled 0 to 1 |
| device_fingerprint | 0.10 | A device signal you already hold |
| ip_risk | 0.10 | An IP signal you already hold |
| transaction_history | 0.10 | History you already hold |
| account_age | 0.05 | How established the account is, scaled 0 to 1 |
| communication_pattern | 0.05 | A signal you already hold |
| Any other type | 0.05 | Included at a low weight. Prefer the named types |
The score is the weighted average of the values you sent, multiplied by 100 and rounded. Send nothing and it is 50. The tier is then:
| Score | Tier |
|---|---|
| 75 and above | trusted |
| 50 to 74 | provisional |
| 25 to 49 | elevated_risk |
| Below 25 | blocked |
"Blocked" is the tier name on this response. It is not an instruction to close the account, and it is not the identity-check status, which is only ever approved or held for review. The call does not run a face match or a Companies House search. It only weights what you send. If you send biometric_match: 1 without a face match, you have invented the evidence. The breakdown lists the values you sent.
Order and sign-up risk is a different endpoint again: POST /api/v1/fraud/score. You send what you know about the session — an IP address, a device fingerprint from your own client, the shopper's browser details, and the order. The response is a 0–100 score where higher is safer, a risk tier, and an action of approve, review or block.
Inputs include IP reputation, device reuse, bot signals you forward, a billing and shipping mismatch, and the order itself. If no IP result was available, the score is marked as a heuristic, and a heuristic score does not come back as approve. A WooCommerce store can set review and hold thresholds on that order score. Orders at or below them are flagged or held, not cancelled. That setting is on the WooCommerce plugin and does not move the identity-check bands. Shopify stores. See integrations.
Keep the three numbers apart in your runbook:
This section is a summary, not legal advice. Which duties apply depends on your business.
A trust score does not discharge a legal duty. It is evidence you can show alongside the underlying checks.
Your obligations stay with you. The checks and the recorded decision help you show what you did.
Judge the score by whether you can explain it to a payment partner six months later: which checks ran, which did not, what the band was, and who approved the seller. If you cannot, the number was decoration.
KYC, KYB, AML screening and fraud prevention in one place, with published pricing.
Fraud Prevention
Device Fingerprinting and Bot Signals on UK Marketplaces
What device fingerprinting and bot signals can tell a UK marketplace about fake sellers and scripted signups, and how to use them without overreacting.
Fraud Prevention
Designing a Fraud Review Queue That Does Not Become a Backlog
How to design a manual review queue for marketplace fraud and verification: what to route, how to prioritise, what reviewers need and how to keep it small.
Fraud Prevention
Email and Phone Risk Signals at Signup
What email and phone checks reveal at signup: disposable domains, missing mail servers, VoIP numbers and how to act without blocking real users.
