Are wire transfers over $25K dual-control authorized? Is callback verification required for new vendor / banking change?
This is the highest-value procedural control on the entire application, because it stops the most frequent claim in the market outright.
What the carrier is actually asking
The carrier is asking two things: whether transfers above a threshold require two authorised people, and whether changes to vendor banking details trigger a callback to a previously known number. Both are procedural controls in the finance function.
Why it is underwritten
Business email compromise leading to a diverted payment is the highest-frequency loss in cyber insurance. The attack always ends the same way: a plausible request to send money somewhere new. Dual authorisation and out-of-band callback break it regardless of how convincing the request was, which is why some carriers condition funds transfer fraud cover on them.
Where the answer lives in Microsoft 365, Entra ID, and Azure
These are finance procedures, so they are attested. Some technical controls support them and are measurable.
| Platform | Where the setting lives | What has to be true |
|---|---|---|
| Finance procedure | Dual authorisation threshold and how it is enforced | Enforced in the banking or payment platform rather than by policy alone. Attested |
| Finance procedure | Callback verification for new or changed bank details | Callback to a number already on file, never a number supplied in the request |
| Vendor master | Change control on banking details | A separate approval to change a vendor bank record, since that is where the fraud lands |
| Microsoft 365 | External sender tagging and impersonation protection | Technical support for the procedure, making impersonation visible at the point of reading |
| Microsoft 365 | Mailbox forwarding rules on finance accounts | External auto-forwarding blocked, since attackers set forwarding rules to monitor and time the request |
Every one of these frauds arrives with a reason the normal process cannot be followed: a deadline, an executive travelling, a supplier threatening to stop work. The procedure has to be unconditional, because the exception is the entire mechanism.
What a defensible yes requires
- Dual authorisation is enforced by the payment system above a defined threshold.
- Bank detail changes require callback to a number already on file.
- The procedure has no urgency exception.
- Vendor master changes are controlled separately from payment approval.
- Finance mailboxes are protected against forwarding rules and impersonation.
How this answer goes wrong
The procedure exists and is bypassed under executive pressure, which is precisely the scenario it was written for. Or the callback is made to the number in the email signature, which the attacker controls. The second is a procedure that feels like verification and verifies nothing.
Frequently asked
What threshold should trigger dual authorisation?
Low enough that a material loss cannot pass under it. Many organisations set it too high and lose amounts that would have been caught by a lower one.
Does this affect our funds transfer cover?
It can. Some policies condition that cover on verification procedures being followed, which makes this both a control and a coverage term.
What about recurring payments to known suppliers?
They are the target. The fraud changes the bank details on a supplier you pay every month, which is why the control belongs on the detail change rather than on the payment.
Can this be automated?
Partly, through payment platform controls and vendor master workflow. The callback itself is human and deliberately so, because a phone call to a known number cannot be spoofed by mail.
Related questions
Stop answering this from memory
Connect Microsoft 365, Entra ID, and Azure read-only. Insurance Posture reads the live configuration behind each application answer and shows you which ones you can prove before you sign.
Assess your posture