Communication provenance
Make every customer communication verifiable.
Your customer is looking at an email that says it is from you, and they cannot tell, which is exactly the moment Fromenance, a communication provenance platform for banks, credit unions, insurers, and utilities, is built for. It gives that customer a straight answer from you in seconds: "did you really send this?" answered by the only party who actually knows.
Here is the whole idea. You register every outbound message as you send it. When a customer is unsure, they forward it to verify@yourbank.com or paste it at yourbank.com/verify. We check it against what you sent and reply in your voice with one of three answers: Verified, Not verified, or Known fraud.
- Verified
"Verified: this message matches a communication we registered and sent to you on September 24, 2026 at 10:42 AM UTC."
- Not verified
"Not verified: no registered communication matches this message. That does not by itself mean it is fraudulent, but treat it with caution."
- Known fraud
"Known fraud: this message matches an impersonation attempt our fraud team has confirmed. Do not interact with it."
How it works
Three steps, one answer
Step 1: You register the message as you send it
One HTTPS call from your application, an ESP webhook, or a BCC from the system that sends your statements. We keep a verify code, a one way hash of the recipient's address, and a fingerprint of the text. We never get the address and we never get the body.
Step 2: Your customer asks you
They forward the message to verify@yourbank.com, or paste it at yourbank.com/verify. A screenshot from their phone works too. No account, nothing to install, and our name is nowhere on it.
Step 3: They get a straight answer in seconds
We match the code, the recipient, and the fingerprint against what you actually sent. The reply comes from your domain, in your branding, with what to do next. Every message that fails becomes intelligence for your fraud team.
Verdicts
Three answers, and we do not let anyone soften them
The verdict block in every reply is fixed text. Your fraud team cannot water it down and your marketing team cannot inflate it. It says exactly what you can stand behind, and nothing more.
- Verified
"Verified: this message matches a communication we registered and sent to you on September 24, 2026 at 10:42 AM UTC."
We found the message in your registry. Either the verify code led us to a registration sent to the person asking, or their address and the content fingerprint matched one inside the retention window.
- Not verified
"Not verified: no registered communication matches this message. That does not by itself mean it is fraudulent, but treat it with caution."
Nothing in your registry matches. A real message you never registered lands here too, which is why we say "no record" and never "fraudulent" until you are in Authoritative Mode.
- Known fraud
"Known fraud: this message matches an impersonation attempt our fraud team has confirmed. Do not interact with it."
One of the message's links, domains, or phone numbers is on your fraud list, or its fingerprint matches a lure your analysts already confirmed.
A real message you forgot to register comes back Not verified with the words "no record", never "fraudulent". Once we have reviewed your coverage together, Authoritative Mode changes that reply to "we did not send this".What Authoritative Mode takes.
Demo
Try it yourself, on the production API
This runs on a demo tenant with a public site key. Paste the real alert or the lure and watch the verdict come back. The latency is real, the verdict path is real, and there is no model anywhere in it.
JT Merlin Bank (demo) verify page
This is the demo tenant, JT Merlin Bank (demo), on the production API with site keysk_pub_demo_jtmerlin. The latency you see is the latency your customers would see.
The real alert
We registered this fraud alert at send time, addressed tojane.doe@example.com. The footer carries the code twice on purpose: one copy usually survives whatever a mail client does on the way.
JT Merlin Bank We noticed a card transaction Hi Jane, A purchase of $412.90 at ACME ELECTRONICS was made with your JT Merlin Bank Visa ending in 4471 on September 24 at 10:42 AM. If this was you, no action is needed. If you do not recognize this transaction, review it in the app or call the number on the back of your card. Review this transaction: https://www.jtmerlin.com/app/alerts/tx/98812?utm=email Thank you, JT Merlin Bank Fraud Team Not sure this email is from JT Merlin Bank? Forward it to verify@jtmerlin.com or enter code KX73-PQ9G at jtmerlin.com/verify. Reference: KX73-PQ9G JT Merlin Bank, Member FDIC. 1 Merlin Plaza, Wilmington, DE 19801. Privacy: https://www.jtmerlin.com/privacyJT Merlin Bank Urgent: your card has been temporarily restricted Hi Jane, A purchase of $412.90 at ACME ELECTRONICS was attempted with your JT Merlin Bank Visa ending in 4471 on September 24 at 10:42 AM and has been placed on hold. To avoid permanent suspension of your card, confirm your identity within 24 hours. Confirm your identity now: https://jtmerlin-secure.com/login?ref=8812 Thank you, JT Merlin Bank Fraud Team Not sure this email is from JT Merlin Bank? Forward it to verify@jtmerlin.com or enter code QF29-TH40 at jtmerlin.com/verify. Reference: QF29-TH40 JT Merlin Bank, Member FDIC. 1 Merlin Plaza, Wilmington, DE 19801.
Notice what the reply does not do. It never quotes the suspicious message or repeats its links. It says only what the bank can stand behind: a registered communication matches, or none does.
Why provenance
What DMARC does not answer
SPF, DKIM, and DMARC are necessary. We depend on them. They just answer a different question than the one your customer is asking.
DMARC checks a domain, not a message
A lure from jtmerlin-secure.com with your logo pasted in passes SPF, DKIM, and DMARC, because it really did come from jtmerlin-secure.com. Nothing in that chain tells your customer whether you sent it.
Gateways and classifiers give you a probability
An 87 percent phishing score is useful to your SOC. It is useless to a customer holding the phone, who needs a yes or a no that your legal team can stand behind.
Brand protection finds the lookalike on a lag
Takedown vendors discover impersonation infrastructure after it is live. The customer who just received the lure is the earliest sensor you have, and nobody is listening to them.
Intelligence
Every failed verification is a phishing sample, delivered by its target
A Not verified or Known fraud submission arrives carrying the attacker's domains, links, phone numbers, and QR codes, sent to you by the exact person the lure was written for. We pull those out deterministically, keep them in your tenant, and let you export them as CSV or STIX 2.1 today. Clustering them into campaigns, enriching the infrastructure, and warning other institutions early is the intelligence tier, and it is on the roadmap rather than in the box.
Solutions
Built for the person who owns impersonation
Banks
Fraud alerts, transaction alerts, wire notices.
Credit unions
Member alerts, with a five person fraud team.
Insurance
Claims, policy, and billing messages.
Utilities
Outage, billing, and disconnection notices.
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.