Compare
Fromenance vs consumer scam detector apps
Scam detector apps and the AI features showing up in mail clients do something useful: they estimate whether a message looks like a scam, for every sender at once. Fromenance is communication provenance, which is a different primitive: the institution itself answers whether it sent the message, from a registry of what it actually sent. One is a probability from a third party. The other is a record from the sender, and only the second is something a bank can put its name on.
Side by side
What each one does
| Question | Scam detector apps and AI inbox features | Fromenance |
|---|---|---|
| Who answers? | A third party app, or an AI feature in the mail client, trained on what scams tend to look like. | The institution the message claims to be from, using its own registry of what it sent. |
| What is the answer? | A score or a label: likely scam, suspicious, probably fine. Useful guidance. Still a probability. | Verified, Not verified, or Known fraud. A lookup, not an estimate, with wording that is locked so it never claims more than the registry supports. |
| What happens with a well written lure? | AI written phishing took away the tells, the grammar and the odd phrasing, that classifiers and people leaned on. A polished lure scores lower. | Writing quality does not enter into it. A lure is not in the registry no matter how good it reads, and a copied footer fails the recipient or the fingerprint check. |
| What happens with your real messages? | Legitimate alerts get flagged often enough that customers learn to ignore the warning, or worse, the alert. | A registered message verifies, with the time you sent it. Your customer learns that real mail from you can be checked, which protects trust in the real alerts. |
| Can the answer be gamed? | Yes.Models can be probed and lures tuned until they pass. Prompt injection is a live concern for AI inbox assistants. | No.There is no model on the verdict path. Regex, MIME parsing, a hash comparison, and a fingerprint distance. Nothing a lure can say changes a verdict. |
| What do you learn? | Nothing. The app belongs to the customer or the mail provider. | Every lure a customer doubted, with indicators, replay flags, and the template it imitates, in your fraud team's admin app within seconds. |
| What does the customer install? | An app, an extension, or a mail client feature, with its own permissions over their inbox. | Nothing. Forward to verify@ or paste on your verify page. No account, no install, and our name is nowhere on it. |
| Who stands behind the answer? | The app vendor's terms disclaim the result. | You do, with "matches a communication we registered" and "no registered communication matches". The reply never uses stronger language than that. |
The gap
Detection and provenance
Both have a place. They are different questions.
Detection asks
- Does this message look malicious?
- Is this domain suspicious?
- Does this resemble scams we have seen?
Good detection catches a lot. It cannot catch a lure that looks exactly like the real thing, and it cannot confirm that the real thing is real.
Provenance asks
- Do we have a record that this institution sent this exact message to this person?
That is a lookup only the institution can make. Customers already forward messages to a friend, search online, and call support. We point a habit they already have at the one party that knows.
Honestly
The honest limit
We only answer for institutions that register their communications. A scam detector app covers every sender at once, at the cost of never being certain. For the institutions that adopt it, Fromenance is certain about what they sent, and it is the only approach that turns the customer's question into intelligence for the institution.
Start with one stream and a 60 to 90 day pilot.
Pick your fraud alerts or your transaction alerts, the messages your customers already squint at. At the end you get a written report: how many people asked, what they were told, which campaigns turned up, and what your existing feeds missed.