Your customer is staring at an email and cannot tell if it is you.

• The fake fraud alert

  "We noticed a card transaction" from jtmerlin-secure.com, your logo, a link to a login page that looks like yours. It passes DMARC, because the attacker owns that domain. Forwarded to verify@, it comes back Not verified, and the domain is in your indicators before the second customer calls.

• The copied footer

  Attackers copy your real verify footer to look legitimate. The code belongs to one registration and one recipient, so a copied code on a different message comes back Not verified and raises a replay flag. The lure just walked itself into your fraud team.

• The wire recall lure

  A commercial customer gets "your wire is on hold, confirm the details". Your registered wire notices verify in seconds. This one returns no record, and once you are in Authoritative Mode, the reply says you did not send it.

• The compromised vendor account

  Mail from a real but compromised third party domain passes SPF and DKIM cleanly. It is not in your registry, so it cannot verify. Your customer gets a definitive answer and the sending address becomes an indicator.

• The QR code statement

  A PDF or image with a QR code pointing at a lookalike. Your customer uploads a screenshot on yourbank.com/verify; OCR reads it into the same deterministic extractors and the QR payload is stored as an indicator.

• The "is this real" call

  Every contact center call tagged "is this real" costs you roughly $8 to $15, and the agent often cannot answer with certainty anyway. The verify@ reply answers in seconds, on your domain, with your fraud contact for anything that still looks off.

1. 01

   Fraud alerts

   The stream customers scrutinize most and forward most. The best first stream for a pilot, and where you will see footer replay first.

2. 02

   Transaction and card alerts

   High volume, template driven, easy to register from the ESP webhook. Customers already know what a real one looks like, so a lure stands out when it fails.

3. 03

   Wire and ACH notifications

   Lower volume, highest value per message. Register them with one call from the core banking or treasury platform, or through the journal path.

4. 04

   Statements and account notices

   Batch runs from a statement vendor. Use the batch endpoint (up to 1,000 per call) or add journal-{slug}@ingest.fromenance.com as a BCC on the vendor's sending system.

• Fewer calls

  "Is this real" call volume on the pilot stream, before and during. You bring the contact center tags; we bring verification attempts split by forward and web.

• Abuse mailbox triage that becomes review

  Volume before and during, and analyst time on suspicious message triage per week. Submissions arrive with the indicators pulled out and a verdict already attached, so triage becomes review.

• Fewer takeovers to clean up

  Account takeover events traced to phishing of the pilot stream, plus the card reissues, disputes, and reimbursements that follow. Earlier Known fraud verdicts shorten the window in which a campaign works.

• Campaigns you found first

  Unique campaigns and the time from first submission to analyst confirmation. Lookalike domains discovered. Intelligence yield: the indicators your existing feeds did not have.

• Customers who keep reading your mail

  Every campaign teaches customers to distrust real mail, which drags on digital servicing. A verifiable footer on every alert gives them a reason to keep opening yours.

• An answer you can stand behind

  "We sent this to you on September 24 at 10:42" or "no registered communication matches". Wording your legal and compliance teams reviewed once and that never drifts in production.

Fromenance is a customer facing fraud control with a paper trail. Every verdict is immutable, every analyst action is logged, and every registered communication carries a record of when it was sent and to whom, as a one way hash. That lines up with what examiners ask about under FFIEC guidance on customer authentication and fraud response, and it gives your incident reports a timestamped source of truth. We do not claim a certification. We give you the evidence and let your compliance officer frame it.

1. 1

   Step 1: Week 0

   We sign the contract and the DPA and create your tenant. You publish one TXT record and one redirect rule. The wizard sends itself a test message and tells you when the rule is right.

2. 2

   Step 2: Week 1

   You register one stream and paste the footer into that template. Replies go out from your own domain. The first customers usually ask that week.

3. 3

   Step 3: Weeks 2 to 12

   It runs. We sit with your fraud lead for 30 minutes a week over Submissions and Indicators, and you get a report at day 30, 60, and 90.

FAQ

Questions we get on the first call

Do we have to route customer mail through Fromenance?

Only the messages your customers choose to forward to verify@yourbank.com, and only after the forwarding hop passes DKIM or ARC for your domain and your TXT record checks out. If your security review would rather start smaller, the web verify page needs no mail routing at all.

What does the customer actually see?

A reply from verify@verify.yourbank.com, or a subdomain you choose, in your branding, with the locked verdict and a next step. Our name is nowhere on it. On the web page, the same template renders in place.

How does this fit with our DMARC, gateway, and brand protection?

It sits above them. DMARC authenticates your domain, the gateway filters what reaches your staff, brand protection takes down lookalikes. None of them answer the customer holding the phone. We do, and we feed indicators back to all three.

Which stream should a bank pilot first?

Fraud alerts and transaction alerts. Customers already scrutinize them, they are template driven, and an ESP webhook or a single call at send time registers them without touching the core.

Our core banking vendor cannot call an API. Now what?

Add journal-{slug}@ingest.fromenance.com as a BCC or journaling target on the vendor's sending system. We receive the full message, hash the recipient, fingerprint the body, and register it. Pair it with a static per template code or the reserve flow so the footer still carries a code.