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

  1. 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.

  2. 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.

  3. 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.

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/privacy

Ask the bank

Codes belong to one recipient. Send a code without the address it went to and we treat it as a copied footer, so it comes back Not verified. Change this address and watch the same code fail.

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.

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

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.