Wallet to bank transfer case: reconciling a missing payment

What to take away

This wallet to bank transfer case is fictional: the people, providers, bank, references, dates, and amounts are invented. It demonstrates record-based diagnosis, not a real company's process; actual provider terms, fees, and legal coverage must be checked for the account involved.

The reported problem

Nina Alvarez keeps $1,240 in a nonbank wallet after customers pay for weekend catering orders. On Monday at 8:14 a.m. ET, she requests a standard $900 withdrawal to her checking account.

The wallet immediately reduces its displayed balance to $340. On Tuesday afternoon, the app marks the transfer "complete." On Thursday, the bank account still shows no pending or posted credit.

Nina describes the money as vanished. That description captures the practical problem, but it does not locate the transaction.

Evidence preserved

Before contacting support, Nina saves:

She does not request another $900 withdrawal. A retry could create a second debit while the first remains in process.

Four-ledger map

Nina draws the possible chain:

The wallet ledger establishes that the provider reduced Nina's claim on it. It does not show whether the provider created an ACH entry, whether a receiving institution accepted it, or whether a return is in progress.

First support response

Nina sends the transaction ID, amount, initiation time, destination suffix, and bank statement. The provider replies:

The transfer is complete. Please allow your bank more time to post it.

The answer gives no rail, trace number, sending date, or receiving-institution confirmation. Nina responds with a narrower request:

Please identify the payment rail, date sent to that rail, destination routing institution, trace or reference number, and whether the item settled, returned, or entered exception handling. The destination bank has searched the amount and date but sees no credit.

The trace information

Support escalates the ticket and provides:

Federal Reserve Financial Services describes a FedACH payment trace request as an institution-to-institution request concerning a payment that was not received, returned, or posted. Its required fields include settlement date, originating and receiving institutions, trace number, amount, account number, transaction code, and originator information.

Nina cannot submit that institutional request herself, but the field list shows why the trace number and settlement date are stronger than the app's word "complete."

The Electronic Fund Transfer Act and Regulation E govern qualifying consumer electronic fund transfers, but Nina uses this wallet for catering business receipts. She should not assume those consumer protections apply without checking the account's purpose and the provider's terms.

The ACH Network's Nacha Operating Rules govern participating institutions' ACH processing and returns. Since this fictional case identifies no actual institution or return code, Nina should ask the provider for the return information it received and an explanation of how the account-type mismatch led to the return; the example does not establish that a particular fee is allowed.

Receiving-bank search

Nina gives the bank the ACH trace suffix, amount, settlement date, and originator name supplied by the wallet. The bank finds no posted credit to account 5176. It also notes that the trace points to its routing number, so the transfer reached the correct institution family.

The bank asks Nina to have the originating institution investigate. Nina records the bank case number and sends it to the wallet provider.

At this stage:

No evidence yet supports fraud, a recipient mistake, or bank retention.

The return appears

On Friday afternoon, the provider reports that the ACH credit was returned because the account type in its outgoing entry did not match the receiving account record. The wallet posts $895 back to Nina's balance and retains a $5 return fee.

This creates a new discrepancy. The initiation screen showed a zero standard-transfer fee, and the saved fee schedule does not list a return fee for this condition.

Nina separates the returned principal from the fee and records the wallet events with their running balances:

Event	Wallet change	Running wallet balance

The principal is no longer missing. The remaining issue is fee authority and the inaccurate "complete" status.

Correcting the fee and status record

Nina sends one written request:

The provider finds that its bank-link import classified the checking account as savings. It credits $5, changes the status to Returned, and asks Nina to reconnect the bank account.

Nina verifies the account type in both systems and tests a $25 withdrawal. She waits until the bank posts it before moving the remaining amount.

Escalation file

If the provider had not resolved the issue, Nina's file was ready for a formal complaint. The Consumer Financial Protection Bureau's money-transfer complaint guidance recommends a clear account of what happened, the requested resolution, supporting documents or screenshots, and notes showing whom the consumer contacted and when.

It excludes passwords, one-time codes, and unnecessary full account numbers.

Why the first diagnosis failed

Three wording errors delayed the case:

"Complete" was provider-specific

The app treated file submission or a sender-side milestone as completion. The label did not prove customer posting at the receiving bank.

"The bank has it" was unsupported

The first agent inferred receipt from elapsed time. The bank later found no customer credit, and the return explained why.

"The money vanished" combined two issues

The $900 principal was in a return process. After $895 came back, a separate $5 fee issue remained. Combining them would have obscured the final reconciliation.

Controls adopted

Nina changes her payment routine:

These controls do not prevent every failure. They reduce uncertainty and the cost of proving what happened.

Final closeout

The case closes only when all records agree:

Before closing the case, Nina checks that:

The resolution is not "support found the money." It is a documented return, corrected fee, repaired account mapping, and successful controlled retest.

Common questions

Does an ACH trace number prove the recipient received funds?

No. It identifies the entry for investigation. The item can still be rejected, returned, or not posted to the intended customer account.

Should the receiving bank investigate without a trace?

It may search by amount and date, but the rail-specific trace and settlement information can make the search more precise.

Why test with a small transfer?

It confirms the repaired link and posting path while limiting exposure if the configuration remains wrong.

When is the case resolved?

When principal, fees, status, and both ledgers reconcile, and any necessary error or complaint record is complete.