# How to run a small test payment before a large one and when not to A practical guide for settlement professionals on when a small test payment genuinely reduces risk before a large transaction, and when it creates a false sense of security. --- There is a simple idea that circulates through finance teams, title companies, and operations desks worldwide: before sending a large wire, send a small one first. Wait for it to land. Then send the rest. The logic feels airtight. If the small payment reaches the right account, the large one will too. That logic is correct in some situations and dangerously wrong in others. This article maps the difference precisely — covering what a test payment actually proves, what it cannot prove, and how the underlying mechanics of the payment rails you use determine which category you are in.
$3B+in verified BEC losses logged by the FBI's 2025 Internet Crime Report, across 24,768 complaints
86%of that money moved through wire or ACH transactions before anyone noticed the fraud
66%rise in vendor email compromise attacks in the first half of 2024 alone

Figures cited in this article, detailed in the section on business email compromise.

## What a test payment is designed to verify Before evaluating the technique, it helps to be clear about what it is actually testing. A test payment — typically a nominal sum such as $1 USD / ~$1.55 AUD, or a small round figure like $50 USD / ~$77 AUD — is used to confirm a few specific technical facts: 1. **The destination account exists and is active.** A failed test payment surfaces invalid account numbers or routing details before you commit the full amount. 2. **The payment rails between sender and receiver are functioning correctly.** Correspondent bank chains, intermediary routing instructions, and currency conversion paths can all fail silently when they are first established. 3. **The receiving party can see and confirm receipt.** An out-of-band confirmation call after a $50 USD test costs virtually nothing. After a $500,000 USD / ~$775,000 AUD wire, the emotional stakes of making that call are very different. Best practice in the industry has long been to send a small test wire first for new vendor relationships when possible, then send the full amount. For truly new relationships — a vendor your accounts payable team has never paid before, an international counterparty whose bank details arrived in a freshly opened trade account, a newly incorporated entity in an unfamiliar jurisdiction — this discipline is sound and worth maintaining. The test payment also creates a paper trail. Keeping proof — saving confirmations and reference numbers — helps a bank trace the payment if anything goes wrong later. Running a small transfer first means that by the time you execute the main transfer, you have already established a transaction reference history with the receiving institution. ## The mechanics of the test: how to actually run one
Running a test paymentWorked example: a $500 USD test for a $2,000,000 USD deal
  1. Choose a meaningful but recoverable amountThere is a balance here. A $1 USD transfer may be below the minimum threshold of some international correspondent banks and could be filtered or rejected outright, telling you nothing. A $500 USD / ~$775 AUD test for a $2,000,000 USD / ~$3,100,000 AUD deal represents 0.025% of the total — meaningful enough to clear clearing-house filters but small enough that an error is containable.
  2. Use the same payment instructions and rail as the final transferThis is where many professionals make a structural error. They run the test payment through a different method — say, a domestic ACH — and then send the large amount by international wire. These are different rails with different routing logic. A successful ACH test tells you nothing about whether the SWIFT routing instructions for the full wire are correct. The test must mirror the intended final transfer in every technical parameter: same originating bank account, same destination routing number or IBAN, same currency, same correspondent chain.
  3. Confirm receipt through a separate, verified channelAlways confirm wire instructions through a trusted, independent channel — meaning a known phone number or in-person meeting, rather than a reply to the same email thread that delivered the instructions. This confirmation step is what transforms the test payment from a technical check into a security check. If someone calls back on the pre-established number and confirms the small amount arrived in the correct account, the technical path and the account ownership have both been verified.
  4. Execute the main transfer promptlyOnce confirmed, do not allow unnecessary time to elapse. A confirmed test payment is a snapshot in time. If malicious actors have been watching the transaction — which is not a paranoid scenario in high-value deal flows — a delay between the test and the full transfer gives them a window to substitute new instructions. Execute within the same business day wherever the receiving party's banking hours allow.
## When the test payment approach genuinely works The test payment technique earns its place in the risk management toolkit in three specific scenarios. ### New counterparties with no prior transaction history B2B transactions are often larger and more complex, involving multiple layers of approval and reconciliation. When a settlement agent or closing attorney is distributing proceeds to a party they have never paid before — a remote lienholder, a foreign tax authority, a first-time seller whose bank details arrived in a scanned PDF — there is no prior confirmation that the details are accurate. The test payment is cheap insurance. ### First use of a new payment rail or banking relationship An OTC desk opening a stablecoin-to-fiat corridor for the first time, or a title company wiring to an international bank their institution has no prior correspondent relationship with, faces genuine technical uncertainty. Wire transfers allow large amounts to be sent and received quickly, but once initiated, they are hard to reverse, so businesses should verify all payment information carefully before initiating a wire transfer. The test payment verifies that the full correspondent chain is operational before the large amount enters it. ### High-volume, recurring settlement operations scaling to a new counterparty Running a pilot program — testing the solution with a few non-critical payments before full rollout — is standard practice. An escrow officer onboarding a new disbursement bank, or a broker introducing a new lending party to a recurrent settlement process, should run a test transfer on the first instance. After the relationship is established and confirmed over several transactions, the test-first discipline can be retired or reserved for unusual circumstances. ## When the test payment creates a false sense of security Here is where the advice in most finance checklists becomes dangerously incomplete. The test payment verifies *technical routing*. It says nothing about *account legitimacy* when that account has been compromised or substituted by a sophisticated threat actor. ### Business email compromise and the interception window The FBI's 2025 Internet Crime Report logged more than three billion dollars in verified BEC losses across 24,768 complaints, with 86 percent of the money moving through wire or ACH transactions before anyone noticed the fraud. The attack model that makes a test payment useless — or worse, actively misleading — is one where the fraudster controls the destination account for the duration of the test *and* has the ability to confirm receipt. This is not hypothetical. A growing number of BEC attacks involve compromising trusted third-party vendor email addresses to insert fraudulent payment instructions, and vendor email compromise attacks rose 66% in the first half of 2024 alone. In a sophisticated vendor email compromise, the attacker gains access to the legitimate vendor's email account. They see the test payment arrive. They confirm it. They provide exactly the reassurance your accounts payable team was seeking. Then the full transfer — $350,000 USD / ~$542,000 AUD — lands in a fraudulent account and moves again within hours. Once money leaves through a wire, it often reaches a fraudulent account and moves again within hours, well before a bookkeeper or bank notices anything wrong. A test payment performed through the same compromised email thread does not break this attack chain. It extends it. ### Real estate closings: the highest-risk environment for this failure mode Real estate closings remain a frequent entry point for wire fraud, since a single closing can involve a large wire and multiple parties who are unfamiliar with each other's normal communication habits. Real estate, with its large transaction sizes and frequent use of wire transfers, has proven to be an especially lucrative target for criminals, given that wires are faster than other forms of payment, can handle far larger sums, and are often irreversible. A closing attorney or title company disbursing proceeds to a seller is working with parties they may have never paid before. The seller's bank details arrive — often by email. A test payment is run. The seller (or the person impersonating the seller) confirms. The full proceeds are sent. If the instructions were spoofed, the test payment confirmed nothing except that the attacker was paying attention. Sending $1 first and waiting for confirmation adds delays to the closing timeline and still does not guarantee the recipient is legitimate. This is the blunt assessment from wire fraud specialists who work specifically with title companies. Manual wire transfer verification remains the default at most title companies, and it feels thorough — like real due diligence. But it only catches the mistakes fraudsters weren't careful enough to hide, and today's fraudsters are careful. ### When the test amount itself signals the impending large transfer There is a secondary risk that few articles address: the test payment may announce your intentions to a passive observer. In certain OTC settlement contexts or large commercial deals involving multiple parties, running a $1 USD test on a new account may trigger surveillance systems at financial institutions, alerting all parties — including any malicious ones — that a large transfer is imminent. For deals involving unusual sensitivity, announcing the large payment through a test signal may be the last thing you want to do. ## Multi-party deals and the compounding problem Most large deals do not involve two parties. They involve several. A commercial real estate closing might see one incoming payment split between a seller, a lender receiving payoff, a real estate agency collecting a commission, an attorney receiving fees, and potentially a lien release payment to a third party. Each destination represents a separate risk surface. Running individual test payments to five separate accounts before sending the main transfer introduces a five-fold opportunity for interception, a five-fold delay, and a five-fold confirmation overhead. B2B payments tend to involve larger amounts, are less frequent, and often come with complex contracts and multiple stakeholders. The multi-party structure of large deals is exactly where the test-then-full-transfer model begins to break down operationally — too many moving parts, too many confirmation calls, too many windows of time between the test and the main event. This is the structural problem that onchain routing solves, not by replacing the settlement professional, but by changing the architecture of the payment itself. ## The onchain alternative: why finality changes the calculus When a payment is routed onchain — across Ethereum, using a smart-contract-based distribution protocol like shaka.deal — the logical structure of the transaction is fundamentally different from a sequential wire-and-verify workflow. Transaction finality on a blockchain means the transaction has been permanently recorded and is irreversible. That irreversibility, which sounds like a constraint, is actually what produces certainty. There is no settlement float, no pending status, no inter-bank reconciliation window during which the funds are in transit and therefore vulnerable to substitution instructions. Blockchains introduce a fundamentally different settlement model. Atomic settlement enforces simultaneous, conditional exchange: either both sides of a transaction execute, or neither does. Combined with rapid, economically enforced finality and 24/7 availability, this architecture eliminates a wide range of risks that regulators and market operators have long been forced to manage. With shaka.deal, a settlement agent or closing attorney configures the distribution — designating each party's address and share — before the transaction executes. When the single incoming payment arrives, the protocol routes it simultaneously to every party at the preset shares, in one transaction. There is no sequential disbursement. There is no second transfer to arrange once the first one clears. There is no window between a test and a full transfer during which instructions can be changed. The payment either executes as configured or it does not execute at all. That is the atomic guarantee. ## What this means for the test payment decision If you are using traditional wire rails — domestic or international — the test payment remains a useful but incomplete tool. Use it when: - **The counterparty is new and has never received a payment from your institution.** - **You are using a new payment corridor or correspondent banking chain for the first time.** - **You have independently verified the receiving account through a channel completely separate from the one that delivered the payment instructions.** Phone the party directly, on a number you sourced independently — not from the email footer. This out-of-band verification is what makes the test payment meaningful. Do not rely on the test payment when: - **The payment instructions arrived exclusively by email, and you have not independently verified them through a separate, pre-established channel.** - **You are in a high-urgency closing environment where the gap between test and full transfer will be used as a window by an attacker.** - **The deal involves multiple simultaneous disbursements**, where the operational complexity of test-and-confirm on every leg introduces more risk than it removes. - **The other party confirmed receipt through the same email thread that delivered the instructions.** That confirmation is compromised if the thread is compromised. The risk is not that wire transfers lack security, but that they rely heavily on the accuracy and authenticity of the information provided. When fraudsters successfully manipulate that information, the consequences can be severe. ## The verification layer that actually closes the gap Whether you are using traditional rails or onchain routing, the single most reliable security control is identity verification that is independent of the payment channel itself. The best way to protect yourself is to be extremely careful with any payment instructions received. Always verify wiring details directly with your title company or closing agent using a trusted phone number, and never send money based only on an email. A quick confirmation call can help you avoid losing thousands of dollars to a scam. For settlement professionals managing multi-party disbursements, the most durable approach combines: 1. **Pre-transaction identity verification** of every payee through a channel established before the deal is under time pressure. 2. **Immutable disbursement instructions**, configured and agreed by all parties, that cannot be changed by a last-minute email. 3. **Atomic, simultaneous settlement** so that there is no sequential disbursement window during which one party's payment has cleared and another's has not. That third element is where shaka.deal's architecture is directly relevant to the professionals managing these closings. By routing the full deal amount to all parties in a single transaction — with shares fixed at the outset — the tool removes the multi-step disbursement chain that creates the interception opportunities in the first place. The closing attorney, escrow officer, or OTC desk still owns the deal structure. They still verify the parties. Shaka.deal handles the routing — all at once, with the certainty of onchain finality. ## Practical checklist: before any large payment Regardless of rail, here is a condensed pre-execution checklist for settlement professionals: - **Verify payment instructions via a channel you established independently**, not via reply to the thread that delivered them. - **Check for last-minute instruction changes.** Pay close attention to any changes. Fraud often occurs when wiring details suddenly change at the last minute. Treat any alteration as a red flag and verify it thoroughly before proceeding. - **Confirm the amount, currency, and destination before initiating**, not during or after. - **If using a test payment**, run it on the exact same rail, from the exact same account, with the exact same correspondent instructions as the full transfer. - **If confirming receipt of the test**, do so on a phone number sourced before the deal was under pressure — not one from the same email that delivered the instructions. - **If the deal involves multiple parties**, consider whether atomic onchain routing eliminates the need for sequential confirmations entirely. - **Execute the main transfer the same day** once the test is confirmed — not the next morning. ## Conclusion The test payment is a useful technical tool with a narrow scope of protection. It verifies that the plumbing works. It does not verify that the address on the mailbox belongs to the party you intend to pay. In the current fraud environment — where BEC attacks have risen 30% as of early 2025 and where generative AI is making BEC lures more convincing, with an estimated 40% of BEC phishing emails AI-generated by mid-2024 — the comfort a test payment provides can become a liability if it substitutes for the identity verification step. The professionals who manage large-deal settlements — closing attorneys, escrow officers, title companies, OTC desks — carry a disproportionate share of the responsibility here. Their clients trust them to move large sums correctly, completely, and without delay. Understanding exactly what a test payment does and does not prove is part of discharging that responsibility well. Use the test when the conditions call for it. Pair it with independent verification when you do. And for multi-party deals where the sequential disbursement architecture itself is the vulnerability, explore whether atomic onchain routing through a tool like shaka.deal is a structurally better answer — not because it removes the people from the process, but because it removes the gaps between the steps.