Written by Psychevus
Published · Updated
The worst kind of invoice fraud doesn't use a lookalike domain. The attacker gets into a supplier's real mailbox, waits until an invoice is due, and writes from there: our bank details have changed. Every check passes, because the email really did come from the supplier.
The advice for that case has always been the same: call them on a number you already have. It's good advice. It's also the step people skip when they're busy, and the one an AI agent paying invoices can't take at all.
Most businesses that send invoices follow rules they never write down anywhere a computer can read. We don't change bank details by email. Our invoices come from our own domain, or from Xero. These are the two accounts we get paid into.
If that were published on the business's own domain, an email from its hacked mailbox asking for a new account would contradict the business itself. The email says one thing, the domain says another, and the domain is much harder to take over than one person's inbox.
So I wrote a proposal for it. It's a plain text file at /.well-known/payment-policy.txt, in the spirit of security.txt (RFC 9116), which does a similar job for reporting security bugs. A few lines cover it: how bank changes happen (never by email, by phone callback, only through a portal, or by signed letter), which domains send the invoices, and the accounts.
The accounts were the tricky part, because nobody wants an account number in a public file. So the file holds fingerprints instead: a deliberately slow hash of the account (PBKDF2, 600,000 rounds), salted with the domain. If you already have an account number, you can check whether it's on the list, and a fingerprint copied to a lookalike domain doesn't match there.
What a fingerprint can't do is make the number secret. When I first published this, the fingerprint was a single SHA-256 and I wrote that you couldn't get the number back out. That was wrong. A UK account number under a known sort code is one of a hundred million possibilities, and an ordinary laptop can try them all in seconds. The slow hash turns those seconds into hours on a fast graphics card, and far longer on a laptop: a real cost, but not a lock. So the spec now says to list only accounts you already print on your invoices, where they aren't secret anyway.
There's also an optional DNS record holding a hash of the file. If someone breaks into the website and edits the policy without touching DNS, the two stop agreeing, and the checker says so.
Banks have started checking names against account numbers: Confirmation of Payee in the UK, and Verification of Payee, which the EU's Instant Payments Regulation made mandatory for euro transfers in October 2025. Those checks happen inside the bank and cover some payments in some countries. A payment policy is the supplier's own statement, readable by anyone before the payment is even set up, and it works the same everywhere.
I didn't want to start from zero either. iban-check.org already publishes plain IBAN hashes in DNS records named _iban, so the checker reads those too. And none of this replaces the phone call. It makes a fake request much easier to doubt, which is usually the moment that matters.
The checker, the generator and the full spec are on the payment-policy page, free and without signing up. Account numbers you type there are hashed in your browser and never sent. The payment-change check reads a supplier's policy automatically, and AI agents can read it through the API or the MCP tool.
This site publishes its own policy as a working example: no bank changes by email, invoices only from psychevus.com, pinned in DNS. A proposal like this is only worth something if suppliers publish it. If you send invoices, it takes about five minutes. If you pay them, the page writes a short note you can send to your suppliers asking them to publish one.
Short messages are fine.
Start a conversation