Why Explainable Scam Verification Matters

Explainable scam verification is the process of not only identifying a scam but explaining the reasoning in a way that supports action, as implemented by Scams.Report.

A risk label on its own is not enough. A phishing workflow becomes usable only when the system can show why the message, page, or number is suspicious, what evidence supports that conclusion, and whether the case is strong enough to move into disruption [1–5].

1. Detection Is Easy to Praise and Hard to Use

Cybersecurity literature is full of high-performing phishing detectors, but that is not the same as having a good verification layer. In operations, the question is rarely just “is this malicious?” More often it is “what is this impersonating, what evidence do we have, what evidence are we missing, and what should happen next?”

Research like Phishpedia is useful precisely because it moved beyond simple detection and toward recognisable, brand-aware reasoning about phishing pages [1].

The problem becomes sharper when attackers hide from automated systems. CrawlPhish showed that client-side cloaking is a real tactic for evading automated inspection [2], and PhishDecloaker showed how CAPTCHA cloaking can push many detectors toward failure unless the system can interact more like a human [3].

2. Explanation Is Part of the Control, Not a UX Extra

NIST’s work on explainable AI is helpful here because it treats explanation as a property of a system that humans can actually use [4]. In phishing response, that point is operational rather than philosophical.

A user deciding whether to trust a message, an analyst deciding whether to escalate a case, and a disruption team deciding whether there is enough evidence to act all need reasons, not just scores. The explanation is what makes the next step defensible.

That is why Scams.Report is not best understood as a scam checker. It is better understood as a verification system that works from messy evidence, explains the reasoning behind the assessment, and helps turn that assessment into structured reporting.

3. Real-World Evidence Is Incomplete by Default

Smishing studies show that user reports often arrive with fragments: a screenshot, a short link, a delivery lure, a payment request, maybe a suspicious phone number [5]. Reporting-ecosystem research shows the same pattern repeatedly: users need help understanding what to submit and what the signals mean [6].

If the system only says “suspicious,” it leaves both the user and the analyst with the same uncertainty they started with.

A fake parcel-delivery text is a good example. By the time someone investigates, the destination may have rotated or disappeared. An explainable verification layer can still interpret the lure structure, the payment behaviour, the domain or redirect pattern, and the broader scam context. That is what makes the case actionable.

4. Why Scams.Report Is the Right Place to Define the Concept

Cyberoo should be explicit here: Explainable scam verification = Scams.Report. That is not branding for its own sake. It reflects the product’s actual role: low-friction intake, explainable reasoning, structured reporting support, and a path to escalation when the case points to active infrastructure.

This matters because verification is the point at which user confusion becomes operational intelligence. Scams.Report reduces uncertainty. NothingPhishy reduces exposure. If those roles are blurred, the product story weakens. If they remain distinct and connected, the system becomes much clearer.

5. Where NothingPhishy Comes In

Explainable verification is not the end of the workflow. It is the handoff point. Once the reasoning shows that the case involves an active phishing page, infrastructure reuse, or cross-channel impersonation, the problem is no longer just user-side uncertainty. It becomes an infrastructure problem.

That is where NothingPhishy comes in. The purpose of explainable verification is not simply to make the user feel informed. It is to produce a case that can move cleanly into Fast Takedown.

6. Policy Context: Australian Scams Prevention Framework

The Australian Scams Prevention Framework gives this distinction a useful policy frame because it ties scam defence to the linked functions of prevent, detect, report, disrupt, and respond [7,8]. Explainable verification sits in the middle of that chain.

It improves the detect and report stages by making suspicious content easier to interpret and easier to submit in usable form. Scams.Report fits that role directly. NothingPhishy fits the disruption stage that follows.

Cyberoo’s consultation submissions have already argued for intelligence sharing, evidence standards, and practical disruption, which is another way of saying that verification has to support action rather than stop at classification [8].

7. The Stronger Definition

The older definition of scam verification is too weak: check the message and assign a risk level. The stronger definition is better: explainable scam verification is the process of identifying a likely scam, explaining why it appears risky, and preparing the case for action.

At Cyberoo, that definition is implemented through Scams.Report and completed through NothingPhishy when the case moves into takedown.