What Is a Payment-Verification Hold?
Published November 7, 2026 · Reviewed November 2026 · By the Ingenious AI team
The short answer
A payment-verification hold is a mandatory pause on a payment instruction that shows risk signals, lasting until a verification ceremony clears it. In WireWatch, deterministic rules score each instruction 0–100 and a score of 20 or more is held. Release requires a recorded out-of-band callback, two approvers on separate devices, and no reject — never just the passage of time. Threshold and signals as implemented in WireWatch's rules engine, November 2026.
What puts a payment on hold?
| Signal | Points | Why it matters |
|---|---|---|
| Beneficiary not in the vendor master | +45 | A destination nobody verified is the fraud's whole payload — this signal alone holds. |
| Bank details differ from the last verified set | +35 | The classic BEC move: same vendor, new account. Also holds on its own. |
| Instruction arrived over WhatsApp or voice | +15 | Spoofable channels — the Fideuram pattern. A cloned voice cannot be ruled out by listening. |
| Sender does not match the known-good contact | +15 | Lookalike domains and spoofed numbers fail the match against the contact on file. |
| Message demands urgency | +10 | Pressure is the attacker's tool for skipping verification. |
| Amount is $10,000 or more | +10 | High-value wires earn ceremony even when everything else looks clean. |
Same inputs, same verdict, every time — no ML, no voice detection, no guessing. Signals stack: an urgent WhatsApp message from an unknown sender scores 40 before the destination is even considered.
How does a hold end?
Only through the ceremony — the callback verification steps are the release path. The callback to the known-good number on file must be recorded with its confirmation code matched. Two approvals must then exist from distinct approver emails on distinct devices; two approvals from one phone release nothing. And a reject is terminal for that instruction: the payment is blocked and the rejection is recorded. Instructions that score under 20 never enter a hold at all — the engine appends "all signals clean — released without ceremony" — so the hold lands on the risky minority, not on every payment your team makes.
What record does a hold leave?
A complete one. Every event — the hold itself, the callback, each approval, the release or the rejection — is appended to a SHA-256 hash-chained audit ledger: each row stores sha256 of the previous event's hash plus the event's canonical form, so altering any earlier entry breaks every later hash. That is the structure an insurer or auditor actually wants after an incident: who held it, who called, who approved, on what device, in what order. One privacy property of the design: WireWatch stores only a SHA-256 hash of bank account numbers — never the numbers themselves. Why this ceremony exists at all is the subject of how BEC wire fraud works, and the normative version lives in how the ceremony works. The rest of the fleet: getingeniousai.com.
Frequently asked questions
What is a payment-verification hold?
It is a mandatory pause on a payment instruction that shows risk signals, lasting until a verification ceremony clears it. In WireWatch, a deterministic rules engine scores every instruction 0–100 and any score of 20 or more is held. The hold is released only when the out-of-band callback is recorded, two approvers on separate devices have approved, and no approver has rejected.
What triggers a payment-verification hold?
Six scored signals: a beneficiary who is not in the vendor master adds 45, bank details that differ from the last verified set add 35, an instruction arriving over WhatsApp or voice adds 15, a sender who does not match the known-good contact adds 15, urgency in the message adds 10, and an amount of $10,000 or more adds 10. The threshold is deliberately low — the engine's rule is that it would rather hold a clean payment than release a bad one.
How is a held payment released?
By completing the ceremony, not by waiting. The callback to the known-good number must be recorded with a matching confirmation code, and two approvals must exist from distinct approver emails on distinct devices. A single reject ends it: the payment is blocked, with the rejecter's identity recorded in the ledger.
What records does a hold create?
Every step — hold, callback, approvals, release or rejection — is written to a SHA-256 hash-chained audit ledger, where each event stores the hash of the previous event plus its own. That chain makes the record tamper-evident for an insurer or auditor. WireWatch also stores only a SHA-256 hash of bank account numbers, never the numbers themselves.
Is a hold the same as fraud detection?
No. A hold is a process control, not a detection verdict. WireWatch does not detect deepfakes or cloned voices, does not verify that a bank account is real (that is a bank's job), and does not certify regulatory compliance. The hold simply guarantees that no scored-risky instruction can be paid until humans verify it out-of-band — whether it turns out to be fraud or a legitimate change.