What should teams do when a trusted contact requests urgent payment or access by email?

Why an urgent email request should be treated as an exception

A request that arrives by email and asks for money or access deserves the same suspicion you would give to any unusual workflow change. The safest default is to treat it as an exception path that needs proof, not as a trusted instruction. The key question is not whether the sender sounds familiar, but whether the request can be independently validated before any payment or privilege is released.

That matters because email is easy to spoof, relay, forward, and pressure with urgency. Attackers and fraudsters rely on the fact that people often optimise for speed when a familiar name is attached to a time-sensitive request. A routine approval process should not be allowed to collapse just because the message looks plausible.

Independent corroboration is the control that changes the decision. Use a separate channel that was already trusted before the request arrived, confirm the request details, and compare the ask against prior behaviour, normal amounts, approved recipients, and known approval patterns. If any part of the request breaks expectation, it should move into review rather than approval.

What “corroboration” and behaviour checking should look like

The goal is not to prove the email is fake in a forensic sense, it is to prove the business request is legitimate enough to act on. That means validating the request with a callback, a known internal contact method, a recorded approval workflow, or another channel that is not controlled by the same message thread. For access requests, confirm what is being requested, who benefits, and whether the requester is authorised to ask for it in the first place.

Behaviour checks should compare the request to the normal baseline for that contact. Unusual recipient details, a new bank account, a change in urgency, a request outside working patterns, or pressure to bypass established approval steps are all signals that the request should be held. If the request is consistent with prior behaviour but still high impact, corroboration remains mandatory because consistency is not the same as authenticity.

Where the request affects privileges, entitlements, or sensitive payment paths, the review should include the smallest practical approval set and a clear record of who validated what. Teams that rely on email alone often lose the ability to distinguish routine business action from social engineering. A foundational identity and access governance model helps here because it ties requests back to entitlement ownership, review, and least-privilege decisions rather than informal trust.

How to route unusual requests before approval is granted

When a request is out of pattern, the right move is to stop the normal workflow and route it into fraud, identity, or security review depending on what was asked for. Payment changes usually belong with finance and fraud controls; access changes belong with identity governance or privileged access review. The important point is that the request should not stay in the inbox queue waiting for a quick yes.

Teams should also preserve evidence of the original message, the request context, and any follow-up validation. That helps later review when the issue turns out to be a scam, an account compromise, or a simple process failure. It also reduces the chance that someone retries the request through another channel and gets a different answer from a different approver.

For access requests specifically, the decision should consider whether the request creates standing privilege, expands cross-system access, or bypasses normal approval chains. Those are the conditions where a request that seems urgent can become a durable control failure. Guidance on delegated access and identity data handling is useful when the request also exposes personal or sensitive identity information during verification.

Risk and Threat Considerations

Urgent requests are attractive because they compress judgment time and encourage exceptions. The main risks are business email compromise, impersonation, payment diversion, and unauthorized privilege changes. In practice, the dangerous moment is when urgency is used to override verification, not when the email itself looks suspicious.

Failure mechanism: The attacker or fraudster relies on trust in the sender name, message thread, or pressure to move quickly, then pushes the target to approve payment or access before independent validation happens. If the process allows a single email to become an actionable instruction, the control failure is usually procedural rather than technical.

Impact: The outcome can be direct financial loss, expanded account access, credential misuse, or a follow-on compromise that uses the granted access for further abuse. In regulated environments, a single rushed exception can also create audit, fraud, and accountability problems long after the request is resolved.

Practitioner Guidance

What to verify: Verify the request through a channel that predates the email, and confirm both the business need and the exact change being asked for. If the requester is asking for payment, confirm beneficiary, amount, and authority; if the requester is asking for access, confirm role, scope, expiry, and approver.

Decision rule: If the request cannot be independently corroborated, treat it as unapproved regardless of sender familiarity or apparent urgency. If the request is unusual but potentially legitimate, pause it and send it into fraud or identity review rather than trying to “fix” it in-line.

Common mistake: Teams often validate only the sender, then skip the request content. The safer pattern is to validate the request itself, because the account or inbox may already be compromised even when the contact name is real.

Practitioner takeaway: Urgency is a reason to slow down, not to speed through approval. The right control is a deliberate exception process with independent confirmation, not a faster version of normal email handling.

Related resources from NHI Mgmt Group

• How should security teams verify payment requests that arrive through multi-party email threads?
• How should security teams handle access control when accounts and requests are tied to email addresses instead of real authentication?
• How should security teams detect email thread hijacking when attackers reuse an existing conversation to request payment or access changes?
• How should security teams reduce supplier fraud risk when invoices or payment requests arrive from trusted business partners?