Bank transfer problems: wrong recipients, cutoffs, scams and irreversible mistakes

What to take away

Transfer problems become expensive when the sender guesses at the rail or submits another payment before tracing the first. Preserve the confirmation, identify the method, and use the provider's formal process.

Problem 1: wrong account or routing number

An incorrect field can cause rejection, delay, return, or credit to an unintended account. The outcome depends on the method and receiving system.

Act immediately:

The CFPB's recipient-information mismatch guidance advises contacting the provider immediately and warns that incorrect account or routing information can lead to loss. Its remittance discussion may not apply to every domestic transfer, so follow the actual product's procedure.

Problem 2: the recipient name differs

A name mismatch may trigger review or rejection, but do not assume every system matches names before crediting. Ask the provider which field controls routing for that rail.

Verify the legal name and account data with the recipient through a known channel. Do not alter the name until the bank confirms what format it needs.

Problem 3: the transfer missed a cutoff

Customer entry time is not always rail submission time. A bank may review, queue, or hold an instruction. ACH and wire services have processing windows and business-day schedules, while instant services are designed for continuous operation.

Record:

A screen saying scheduled does not mean the payment entered the rail.

Problem 4: the ACH transfer returned

An ACH return means the receiving side sent the entry back under a reason. Common operational causes include account information, account status, authorization, or funds, but use the actual return code rather than guessing.

Ask for:

Do not resubmit automatically. Correct the cause and obtain fresh authorization when needed.

Problem 5: the recipient says nothing arrived

Trace the layers:

Customer instruction -> sending-bank release -> rail record -> receiving-bank receipt -> recipient posting

The sender should obtain the rail reference. The recipient should ask its bank to search using amount, date, sender, and reference. A screenshot from the sender's app may show initiation without proving receiving-bank credit.

Check whether the recipient expected a wire but received ACH, whether an intermediary was involved, and whether the account is restricted.

Problem 6: two payments were sent

Duplicate transfers can arise from a retry, repeated file, manual entry plus automated run, or a replacement sent before the first trace finished.

Compare both entries:

If both settled, ask the recipient to return one through a verified process and tell the bank. Do not ask the recipient to send money to a newly supplied account.

Problem 7: a vendor email changed bank details

Stop and verify with the vendor using a number already on file. A compromised mailbox can preserve the tone and history of a legitimate thread.

Examine the full sender address, reply-to field, domain spelling, attachment metadata, timing, and urgency. Ask the vendor contact to confirm the change and involve a second approver.

Problem 8: money was wired to a scammer

Contact the bank immediately and request its fraud and recall process. Preserve the bank confirmation, messages, beneficiary information, and timeline. Secure any compromised email or banking account and report the fraud.

The FTC's wire-transfer scam guidance explains why scammers prefer transfers that are difficult to recover and tells victims to contact the bank or transfer company promptly and ask about reversal. A request does not guarantee that funds remain available.

Do not pay a recovery agent who promises guaranteed return for an upfront fee.

Problem 9: the transfer says completed but funds are unavailable

Ask which event completed. It may mean the provider released the payment, the rail settled, the receiving institution posted it, or the recipient can use it.

The receiving bank may apply account review or a restriction unrelated to interbank settlement. The sender's provider cannot always explain the recipient's account status.

Problem 10: an internal transfer disappeared

For transfers between accounts at one provider, capture both account ledgers and the internal reference. Check whether the source debit is pending, the destination is restricted, or the transfer moved to a hidden subaccount.

Do not request an ACH trace if no ACH entry was sent. Ask the provider to identify its internal ledger event.

Problem 11: an instant-payment request looked like an invoice

A request for payment is a message asking the customer to authorize a credit transfer. It is not proof of debt or a debit initiated by the recipient.

Verify the requester, obligation, amount, and destination independently. Reject unexpected requests inside a banking app just as you would reject a suspicious invoice email.

An escalation packet

Include:

Keep facts chronological. Do not label a transfer unauthorized if you authorized it after being deceived; state both facts accurately.

Common questions

Can my bank reverse a transfer to the wrong account?

Ask immediately, but do not assume recovery. The route, status, timing, and receiving side affect the result.

Should I send another payment when the first is late?

Not until you know the first payment's status and have a documented plan to prevent a duplicate.

Does a recipient-name mismatch guarantee rejection?

No universal conclusion follows. Ask which fields the rail and receiving bank use.

Is every scam transfer unauthorized?

No. A person may authorize a payment because of deception. Describe what happened precisely so the provider applies the right process.