Wrong party, real-looking thread
A hijacked reply on a real thread reads like your counterparty — because it is the real thread. Nobody notices during the wire. They notice at reconciliation, after the funds have cleared.
Wire instructions · sealed channel · never money movement
A lookalike reply on a real thread is enough. The funds leave. The clawback fails. SecureRCVD is the sealed channel where only a counterparty you connected with — stepping up with their authenticator — can send or open wire instructions. No stranger can push “updated banking details” at you. You still call back before anyone funds.
Nobody has to break your bank. A lookalike domain replies on a real thread with “updated wiring instructions.” It looks like your counterparty. It isn't. After funds clear, clawback is slow and often fails — and the only question left is who authorized the send.
A hijacked reply on a real thread reads like your counterparty — because it is the real thread. Nobody notices during the wire. They notice at reconciliation, after the funds have cleared.
The second you attach it, you’ve lost custody of the numbers. Phones, downloads, FYI forwards. No revoke, no expiry, and no honest answer to “who has these right now?”
TLS in transit isn’t sealed at rest. The message lands and decrypts into a mailbox — often a shared closing inbox with delegated access. The account number sits in plaintext exactly where it does damage.
No open directory. No stranger can push “updated instructions” at you. Both sides connect on purpose, hold their own keys, and step up with an authenticator to send or open. Key fingerprints let you confirm you're still talking to the same counterparty. The human callback before funding stays — we are not trying to replace it.
Invite on both sides. Keys on each device. Authenticator on each end. No open directory — nobody can push instructions at you uninvited, and you only exchange inside that connection.
You fill in the fields the way you always have. They encrypt in your browser before anything is sent. The readable version never leaves your machine.
Our server stores a block it cannot read, plus who sent it and when. Your counterparty gets an email that says an instruction is waiting — and nothing else.
Only the connected counterparty with their authenticator can unlock. Open is logged. Then the out-of-band callback confirms the numbers themselves, exactly like your policy already says.
Here’s what we’ve tested, what passed, and what’s still open. The last one is open on purpose — an external pen test hasn’t happened yet, and we’d rather you read that here than find out in a questionnaire.
Client-side encryption, device-held keys, TOTP step-up on login, send, and open. Key fingerprints you can compare. Session rotation, rate limiting, a written threat model, and a backup restore drill with matching record counts. What we don’t have: a SOC 2 report. There isn’t one until an independent auditor writes one.
We’re taking a small number of design partners: desks that move real wire instructions and want them out of email. Written beta rules, honest limits in writing, and a standing no-go on unsupervised high-value closings until the external pen test is done. If you want a vendor that tells you what it isn’t ready for, that’s the whole pitch.