Methodology

How Veridex scores a message from 0 to 100

We score five analyzers — URL, email, text message, QR code, and screenshot — on the same deterministic pipeline. Same rules, same weights, same band cutoffs, on every input you paste.

Why we built it this way

A second opinion, not a gatekeeper.

Veridex never auto-blocks a message. It runs a fixed set of deterministic rules — every signal is a named rule a reviewer can argue with — and returns a Trust Score plus the red flags that drove it. If we miss a scam, you can see exactly which rule didn't fire. If we call a real thing a scam, you can override the call because the matched signals are sitting in plain text next to the verdict.

Heuristic, not a guarantee

Every signal is a named rule. There is no opaque model in the loop, and no "trust" verdict — only the absence of matched red flags.

Nothing auto-blocks

We never decide for you. We surface the score, the matched signals, and a concrete next step — the click stays yours.

A second opinion you can act on

The output is the same shape every time, from the URL checker to the screenshot OCR pipeline, so the habit carries across inputs.

The 0–100 scale

Three bands, fixed cutoffs.

A higher score means fewer red flags were matched — not "verified safe". We never claim a thing is safe; we claim we did not see the usual scam signals.

ScoreVerdictNext step
0–39badPotential warning signs detected. Do not enter credentials, payment details, or one-time codes — navigate to the brand yourself in a fresh tab.
40–74warnPotential warning signs detected — verify the sender through a separate channel before clicking or signing in.
75–100okNo major warning signs detected — standard caution still advised; sign in only on sites you reached yourself.

The signal categories

What the pipeline actually looks for.

Eight categories of rule. They are not exhaustive — the URL pipeline alone runs twelve — but they cover the patterns that show up in BEC, smishing, package redelivery, and brand-impersonation scams.

Sender domain mismatch

Pattern

The email's sender domain is impersonating a widely-trusted brand — the real PayPal never sends from paypa1-secure.example. We compare the sender host against an offline brand-token list and flag the impersonation.

  • Sender host takes a known brand token and parks it as the look-alike
  • Display name says one brand, but the actual domain isn't theirs

Reply-to divergence

Pattern

The Reply-To address lives on a different domain than the From: — replying routes your message to an attacker-controlled inbox that need not belong to the brand that sent it.

  • From: support@brand.com — Reply-To: reply@brand-help.example
  • Any time the two domains differ, the divergence is recorded

Suspicious TLDs

Pattern

Less common top-level domains (.top, .xyz, .click …) are cheaper to register in bulk and over-represented in scam infrastructure. A score penalty isn’t dispositive on its own, but a known-bad TLD combined with another signal is.

  • Uncommon sender TLD on an email From: address
  • Uncommon host TLD on a URL the message links to

Urgency and pressure language

Pattern

"Act now or your account will be closed." Banks do not threaten; they notify. We scan the body for urgency, legal-threat, and code-request phrasing — the lexicon shared by BEC, sextortion, and package-redelivery scams.

  • Urgency lexicon hits shared by the email and SMS pipelines
  • Legal-threat or law-enforcement mentions
  • Asks you to reply with a verification code or PIN

Payment redirection to wire or crypto

Pattern

Attorney invoices, vendor payment changes, and rental deposits increasingly ask for wire transfer or crypto wallet addresses instead of the established card-on-file. We flag the wording and pause the pattern.

  • Asks for payment to a new recipient (wire, gift card, crypto wallet)
  • Mentions an attachment or tap-to-view media carrying the redirect

Brand impersonation patterns

Pattern

Hosting a brand token as a subdomain on an unrelated registry is the canonical phishing shape — secure-paypal.example.com is not PayPal. We match the brand token against the registrable domain, never the path.

  • Brand name used as a subdomain of an unrelated registry
  • In-message link points at a brand-spoofing host
  • Display name mentions a brand the sender domain isn’t

URL shorteners

Pattern

A shortened link hides the destination, so the URL pipeline can't fingerprint it before you click. We recognise the host and call it out — never resolve the redirect ourselves, so we can't be weaponised into a phishing payload either.

  • Known URL shortener used as a host in the URL pipeline
  • Shortener link embedded in an email or SMS body

Homoglyphs

Pattern

Punycode (xn--) hosts, mixed-script tokens, and digit-substituted brand names (paypa1, g00gle) are designed to slip past human eyes. We decode the IDN, compare against the brand list, and raise the signal you missed.

  • Punycode in the host IDN
  • Brand token with a digit replacing a letter (paypa1, g00gle)
  • Numeric label parked next to a brand token in the host

Where the limits are

Honest about what the score does not tell you.

  • Heuristic, not a guarantee. We don't auto-block anything. We tell you which rules fired and leave the call to you.
  • No header inspection for arbitrary inbound mail. The email checker reads only the headers you paste; there is no inbox pipe hooked into your mailbox.
  • No live site reputation yet. Scoring is offline — DNS, heuristics, and brand lists. A crawl layer ships later.
  • Weighted rule set, not machine learning. Every signal is a named rule with a fixed weight a reviewer can read and argue with.

Try a verifier

The score shifts when the signals fire.

Run a check on a real input and watch the score update as each rule matches.