Atestan Atestan

Verified business communications

Keep your habits, keep your email.
Our job is to prove you are really talking to the person you think.

CEO fraud, false invoices, false rent demands, false payroll changes, false transfer orders — every one of them rests on the same move: someone passes themselves off as a party you trust. That move is what Atestan makes verifiable.

A trust layer above Microsoft 365 and Google Workspace. We are not an email provider, and we never will be.

Watch a verification run

The same message — “our bank details have changed” — in three situations that differ only in what the issuer can prove. Pick one and watch the ladder.

This is a scripted demonstration

Nothing on this page performs live cryptography. The engine is built and tested but has not yet been ratified by an external cryptographer, and no production registry is anchored. What you are watching is an exact walk-through of what the ladder reports in each case — with the fictional company “ABC SAS”. We would rather show you a labelled demonstration than a convincing illusion.

Your accounts-payable inbox

ABC SAS · billing@abc-sas.example

Change of bank details — invoice 2026-0431

Following a change of bank, please update our details for all future payments. New IBAN below. Kindly confirm once done — the next invoice falls due Friday.

Channel checks (SPF / DKIM / DMARC) PASS — the domain is authentic

  1. Idle — press “Run the verification”.

Claim ladder

  1. Signed by the issuing organisation

    Signature

    Waiting.

    not evaluated
  2. Addressed to your organisation

    Recipient resolution, at the date of issue

    Waiting.

    not evaluated
  3. Receipt acknowledged

    Acknowledgement / workflow

    Waiting.

    not evaluated
  4. Action not executed

    Closure / proven absence

    Waiting.

    not evaluated
  5. Complete proof, publicly anchored

    Public anchoring at closure

    Waiting.

    not evaluated

This is not another email-authentication tool

Microsoft and Google already authenticate email, and they do it well. Atestan does not compete with SPF, DKIM, DMARC or Defender — it starts where they stop.

What the channel proves

Is this message authenticated by the domain?

SPF, DKIM and DMARC answer yes or no about the domain. That is a real and necessary check, and Atestan assumes it has already run.

What Atestan proves

Was this precise communication authorised under the controls the issuing organisation itself defined — for this recipient, with this content?

A different question, one level up: not who owns the domain, but what the organisation authorised.

The case that separates them

An attacker who compromises a real mailbox sends from a real domain. DMARC says: authentic. Atestan says: this request does not carry the proof your policy requires. Identity authentication and authorisation of a communication are not the same property.

Atestan adds to your business controls, MFA, IAM, DMARC/DKIM and dual-approval procedures. It replaces none of them.

We display the rung we actually reached

No interface should reduce this to a green tick. Each rung is a separate fact, established by a separate mechanism, and shown only when it holds.

Where we are today

  1. Signed by the issuing organisation

    Signature

    Built and tested

    established
  2. Addressed to your organisation

    Recipient resolution, at the date of issue

    Built and tested

    established
  3. Receipt acknowledged

    Acknowledgement / workflow

    Specified, not yet built

    not established
  4. Action not executed

    Closure / proven absence

    Specified, not yet built

    not established
  5. Complete proof, publicly anchored

    Public anchoring at closure

    Specified, not yet built

    not established

Five mechanisms, not one chain

These rungs are not links in a single homogeneous cryptographic chain. Signature, recipient resolution, acknowledgement, closure and anchoring are distinct mechanisms with distinct assumptions. Anyone who tells you “signed, therefore received, therefore not executed” is selling you a chain that does not exist.

One root, many frauds

Every fraud below works the same way: someone impersonates a trusted party to trigger an action — a payment, a change of details, the acceptance of a document. They are one problem wearing different clothes.

$55bn+

cumulative reported losses to business email compromise, 2013–2023 (FBI IC3).

A measure of the pain, not of a market. We size the market from real buyers, never from a headline.

CEO fraud

An urgent, confidential transfer ordered by someone who writes exactly like your CFO.

Supplier impersonation

A real supplier relationship, a payment quietly redirected elsewhere.

Bank-detail change

The narrow, high-ROI case we start from — because it is the easiest to explain and the fastest to prove.

False invoices and payment orders

Plausible documents, correct amounts, the wrong account.

False contracts and mandates

A signature that looks right on a document nobody authorised.

Notary and closing redirection

Funds diverted at the exact moment a property transaction settles.

Payroll redirection

An employee’s salary account changed by someone who is not the employee.

The same question settles all of them — and it is a cryptographic question, not a judgement call.

A trust layer, not a mailbox

Building a mail service would turn a cryptography company into a deliverability company. So we do not. Atestan sits above the mail you already run.

  1. Plugin — Outlook and Gmail

    Verification runs before a critical action, not merely before the message is opened.

  2. Gateway and API

    Server-side control, wired into the systems that actually move money.

  3. Security policies

    Bank details, payments, orders, contracts — your rule, enforced: below the required level of proof, the workflow stops.

  4. Supplier network

    You do not need to enrol the world. For bank-detail fraud, your key suppliers are a finite, high-value set.

  5. Other channels

    Teams, ERP, CRM, invoices, documents — the same proof underneath. Business email compromise is not confined to email, so neither are we.

The honest difficulty: enrolment

Rungs B and above need the issuer enrolled and the recipient resolvable. If only a handful of your suppliers are enrolled, most messages stay unverifiable — and we will show them as unverifiable rather than pretend. That is the hard part of this business, and also its moat.

Talk to our team

We are looking for a small number of pilot organisations with many suppliers and real exposure. If that is you, the fastest conversation starts with what you are actually afraid of.

We use what you write here to answer you. Nothing else — no tracking, no advertising, no resale. Say as little as you like.

Or write to us directly: contact@atestan.com