Compare
Fromenance vs consumer scam detector apps
Consumer scam detector apps and AI inbox features estimate whether a message looks like a scam; Fromenance communication provenance lets the institution itself answer 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 stand behind.
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, using models 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, but a probability. | Verified, Not verified, or Known fraud. A lookup, not an estimate. The wording is locked and never claims more than the registry supports. |
| What happens with well written lures? | AI written phishing removed the tells (grammar, formatting, odd phrasing) that classifiers and people relied on. A polished lure scores lower. | Writing quality is irrelevant. A lure is not in the registry no matter how good it is, and a copied footer fails the recipient or fingerprint check. |
| What happens with real messages? | Legitimate alerts get flagged as suspicious often enough that customers learn to ignore the warning, or worse, the alert. | A registered message verifies with the send time. The customer learns that real mail from you can be checked, which protects trust in real alerts. |
| Can the answer be gamed? | Models can be probed and lures tuned until they pass. Prompt injection is a live concern for AI inbox assistants. | There is no model on the verdict path. Regex, MIME parsing, HMAC comparison, and SimHash distance. Nothing a lure can say changes a verdict. |
| What does the institution learn? | Nothing. The app belongs to the customer or the mail provider. | Every lure a customer doubted, with indicators, replay flags, and the imitated template, in the 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 the institution's verify page. No account, no install, and the Fromenance name never appears. |
| Liability | The app vendor's terms disclaim the result. | The institution stands behind "matches a communication we registered" and "no registered communication matches". The reply never uses stronger language than that. |
Detection versus provenance
Both have a place. They are different primitives.
Detection asks
- Does this message look malicious?
- Is this domain suspicious?
- Does this resemble known scams?
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 issued this exact communication to this person?
That is a lookup the institution can make authoritatively and nobody else can. Customers already forward messages to friends, search online, and call support. Fromenance points an existing behavior at the one party that knows.
The honest limit
Fromenance only answers 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 tool that turns the customer's question into intelligence for the institution.
Run a 60 to 90 day pilot on one communication stream.
Fraud alerts or transaction alerts are the best first stream. You get a written report of verification volume, verdict distribution, campaigns discovered, and intelligence yield.