A test deposit is a small, low-value transfer used to confirm that a bank account change is legitimate before larger payments are sent. It adds a practical check for finance teams handling vendor updates, especially when requests arrive under time pressure or during periods of heightened fraud activity.
What a test deposit is used for
A test deposit is a control-by-confirmation step, not a payment method. Finance teams use it to verify that new or changed account details belong to the intended recipient before sending a larger transfer, which helps reduce the chance of redirecting funds to the wrong destination.
It is most useful when bank details change unexpectedly, when a vendor update arrives through an informal channel, or when the transaction is too important to rely on trust alone. The value of the step is its practical friction: a small transfer creates a verifiable signal without exposing the full payment amount.
That said, a test deposit only proves that some party can access the destination account and confirm the deposit amount. It does not, by itself, prove that the request to change account details was legitimate, that the requester is authorised, or that the change was free from compromise upstream.
Where it fits in accounts payable and vendor-change controls
In a well-run finance process, a test deposit sits alongside call-backs, approved change channels, segregation of duties, and payment-release review. It is a compensating check for situations where bank detail updates carry elevated fraud risk, especially in vendor onboarding, master-data changes, and urgent payment scenarios.
Used properly, it adds a second step between a change request and a material payment. That makes it harder for a fraudster to rely on a single convincing email or form submission. It also creates a clear point where staff can pause and ask whether the account change was initiated through the normal business process.
Its limits matter. A test deposit does not replace confirmation of the requestor, invoice validation, or internal approval. If a business treats the deposit as the only safeguard, it can still pay the wrong account after a convincing impersonation or a compromised vendor mailbox.
For broader identity and trust controls around account changes, NHIMG’s Ultimate Guide to Non-Human Identities is useful for understanding how weak credential handling and overexposure of secrets can widen fraud paths, even when the immediate issue is not a human login.
Why attackers care about payment validation gaps
Fraud actors look for any change-management step that can be rushed, socially engineered, or bypassed. Bank-detail updates are attractive because the attacker does not need to steal the money after payment, they only need to redirect the payment once. The control is therefore only as strong as the surrounding verification process.
The most common failure mode is trust leakage: a team assumes the test deposit itself is sufficient evidence, while the attacker exploits weak upstream verification, poor mailbox security, or a hurried exception process. In practice, the control is strongest when it is paired with independent validation of the request and the destination account holder.
Published evidence on identity compromise shows why layered checks matter. NHIMG reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage. Those figures reinforce the broader lesson that a single verification step is rarely enough when money movement depends on trusted digital channels.
For a related breach pattern showing how legacy trust and weak verification can be abused, see Microsoft Midnight Blizzard breach. For a broader control perspective on account and identity protections, the OWASP Non-Human Identity Top 10 is also relevant as a reference point for overprivilege and secret sprawl.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Test deposits support account-change verification and controlled approval before value is released. |
| Recommendation — Apply Control 6 to verify vendor bank-detail changes before approving payment release. | ||
| NIST CSF 2.0 | PR.AC — Access Control | The control reinforces verifying and limiting who can alter payment destination details. |
| Recommendation — Use PR.AC to require independent approval for changes to payment account details. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secrets and Credential Management | Fraud paths often depend on compromised accounts, exposed secrets, and weak change verification. |
| NHI-07 — Third-Party and Supply Chain Risk | Vendor bank-detail changes are a third-party trust problem where verification controls matter. | |
| NHI-10 — Monitoring, Detection, and Response | Suspicious bank-change requests and unusual verification activity need detection and review. | |
| Recommendation — Protect payment-change workflows by reducing secret exposure and limiting account compromise paths. Validate third-party payment changes through trusted channels before authorising transfers. Monitor for anomalous vendor bank-change activity and escalate suspicious payment requests. | ||
Practitioner Guidance
Why practitioners should care: A test deposit is only effective when it is part of a repeatable vendor-change workflow. Finance teams should treat it as a confirmation step for account changes, not as proof that the request itself was legitimate. In payment operations, the practical question is whether the control reduces error and fraud enough to justify the delay it adds.
Common misunderstanding: Many teams assume a successful small transfer means the change request is safe to act on. In reality, the deposit confirms reachability of the account, not the trustworthiness of the instruction. The stronger the payment process, the more it separates account confirmation from request approval.
Practitioner takeaway: Use test deposits where they add meaningful friction to high-risk payment changes, but pair them with independent request verification and approved-change channels so the control cannot be socially engineered on its own.
Risk and Threat Considerations
Test deposits reduce some payment-fraud risk, but they can also create a false sense of assurance if teams confuse account reachability with legitimacy. The main exposure is redirecting a legitimate payment to an attacker-controlled account after a compromised inbox, spoofed vendor request, or rushed manual override.
Failure mechanism: The control fails when staff treat the deposit as final validation, skip independent callback checks, or allow payment release before the vendor-change request is authenticated through a trusted business process.
Impact: The likely outcome is misdirected funds, delayed recovery, and a stronger fraud path for future payment changes if attackers learn which teams rely on the deposit as their primary safeguard.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
