Release a $4.82M wire only on a signature.
A finance bot queues the payment. Before money moves, the named approver signs the exact payload from their own device. Then try changing it.
Written for CFO · Treasury · Controller · Bank operations · Internal audit
An invoice from ACME SUPPLY CO arrives with “updated remittance details.” The mailbox is real; the thread is hijacked.
The AP platform queues a $4.82M release. Policy says: callback the approver. The approver is on a flight.
Instead of a callback, the approver’s phone shows the exact amount, beneficiary and account. One tap on the device passkey (Face ID / fingerprint). The wire releases, or it is held.
Each button is a real attack on this action. Press one. The signature stops verifying.
Nothing you press here leaves this tab. In this demo, a keypair generated in your browser signs the receipt. In production, the receipt is signed with Manav's published Ed25519 key after the approver's passkey check, and your gate verifies it offline.
The callback is the control being defeated.
The industry’s answer to a suspicious payment is a phone call to a known number. NIST SP 800-63B-4 classifies that channel as restricted and not phishing-resistant. A callback also assumes the attacker has not compromised the callback channel itself. A passkey signature over the exact payload removes that assumption.
paid out by one Arup employee after a video call where every other face was a deepfake.
Fortune, May 2024What each person gets from the same receipt.
One artefact answers “who approved this and what exactly did they see?” before the insurer or the bank asks.
Vendor bank-detail changes and payment-run approvals become signed events, not a spreadsheet of who said yes.
Re-perform the control from the receipt alone: no vendor portal, no screenshots (PCAOB AS 2201).
Evidence for a UCC §4A security-procedure argument that today rests on a call log.
Check it on a machine we have never seen.
Download the receipt and verify it yourself with any Ed25519 library, offline, on your own machine. Verification needs only the published public key.
// Verify offline (Node 20+). Any Ed25519 library works. // npm i @noble/ed25519 then save as verify.mjs import * as ed from '@noble/ed25519'; // pub: "x" from the published JWKS. msg: the receipt's canonical bytes. // sig: the receipt signature. All three as Uint8Array. console.log(await ed.verifyAsync(sig, msg, pub) ? 'valid' : 'INVALID');
What this receipt does not cover.
A receipt shows the enrolled approver signed this payload. It does not tell you whether the beneficiary is legitimate. Keep your account-verification vendor; we sign what it approved.
This is the control AP and treasury platforms embed.
One sign() before funds move, above a threshold your customer sets. Callback stays as fallback. You are replacing latency, not adding it.
Bring the action you would gate first. We issue a real receipt on your payload, live on the call.
You verify it on your own machine, then change one byte and see it fail.
Where it sits in your stack and what the auditor re-performs. Then a plain yes, no, or not yet.
An engineer, not an SDR. No slides. Your email goes to one inbox and nowhere else.