Definition
Verification-before-reporting is the discipline of confirming a suspected scam through independent evidence — domain history, infrastructure analysis, direct contact with the impersonated party — before publishing a claim, and publicly retracting when that evidence doesn't hold up.
How It Compares
| Surface-level signal | What deeper verification found | |
|---|---|---|
| GreenBridge Capital contact | Outreach from shifting phone numbers, a missed call at the wrong timezone, a DocuSign requesting full personal/business information before disclosing any offer — every individual signal read as a scam | A conversation directly with GreenBridge confirmed the behavior was their own (poorly run) business-development outreach, not an impersonation |
| Brazilian bank subdomain | A banking-branded login form on what looked like a parked, unaffiliated subdomain — the classic phishing shape | The login's SSO was powered by a Microsoft Entra tenant tied to the actual bank — this was shadow IT, not a phishing clone |
The Evidence
The GreenBridge Capital case: an inbound text about startup funding came from one phone number, then a follow-up came from a second number — already an odd sign. A scheduled call was set for the wrong timezone and never happened at either the intended time or the corrected one. When called back, "Jacob" answered sounding half-asleep, gave a vague excuse, and promised a follow-up that never came. Days later, a text from a third, different number picked the conversation back up as if nothing had lapsed. This time, "Luis" sent a DocuSign requesting full personal information and business records — before disclosing any actual terms of the funding offer. That alone would normally be enough to call it a scam outright. But the DocuSign was CC'd to a real email address at GreenBridge Capital, which meant the honest read was either a more sophisticated compromise of a real account, or — the more likely explanation — a poorly run outreach campaign. It failed the "duck test" regardless of which explanation was true, so it was published as a probable scam.
The retraction: after that post, direct contact with someone at GreenBridge Capital confirmed the observed behavior was their own approach to sourcing new business, not an impersonation. The conclusion was retracted publicly — but not the underlying analysis. The standard applied doesn't change based on whether the requester turns out to be legitimate: any contact that asks for personal or business information without first demonstrating who they are and why they need it deserves skepticism until they do, especially when the target didn't initiate contact.
The Brazilian bank false positive: a subdomain carrying a bank's login form and branding, sitting on what looked like a parked domain with no obvious connection to the bank's real infrastructure, had every surface-level hallmark of a phishing clone. Digging deeper rather than stopping at that surface read, the investigation found the login's single sign-on was powered by a Microsoft Entra tenant tied directly to the bank itself — strong evidence this wasn't a scam at all, but the bank's own shadow IT (an internal or vendor-run subdomain that never got properly folded into official-looking infrastructure). The lesson: you cannot always detect a scam just from how a site looks or how its domain is structured — sometimes verification requires going into the technical infrastructure itself.
What To Do About It
- Verify sender/contact infrastructure independently — a shifting phone number, timezone mismatches, or a chain of different contacts on the same case are worth noting, but not sufficient alone to conclude a scam.
- Contact the purportedly-impersonated organization directly, through a channel you look up yourself (not one the suspicious contact gave you), before publishing or acting on a scam conclusion.
- Dig into technical infrastructure, not just appearance, when the stakes warrant it — SSO/identity provider configuration (as in the bank case) can distinguish a genuine internal system from a clone in a way visual inspection cannot.
- Apply the same skepticism standard regardless of outcome. Any unsolicited contact asking for personal or business information before establishing legitimacy deserves the same scrutiny, whether it turns out to be a scam or not.
- Publish a correction promptly and visibly if an earlier call turns out wrong, and preserve what was actually still true in the underlying analysis rather than discarding it along with the conclusion.
Caveats & Edge Cases
This page is a differentiation asset, not just another scam report — it exists to demonstrate that findings here are verified, and corrected when wrong, which is itself a trust signal. Publishing a retraction takes more short-term credibility than staying silent about a wrong call, but it's the only way the "verified" claim on the other pages in this hub means anything.