A changed bank account before payout
A fraudster takes over an active session and replaces a saved bank account just before a scheduled payout. If the system trusts the same session for both steps, the payout goes to the fraudster. Reapproval of the changed destination and a new payout check break the chain.
Make the change explicit
Show the bank name, account number ending, and account holder name before confirmation. Do not let a later API call swap those details after approval. OWASP transaction authorization guidance says the approved transaction data must stay protected through execution.
Apply step up checks where risk rises
Recheck identity when a new device adds a beneficiary, a dormant account changes one, or a large payout follows a recent change. Keep the risk rules server side. A notification helps the customer respond, but it does not replace approval.
Test old and new sessions
Try a beneficiary change using a stolen session without step up, replay an old approval against a new account, and alter the destination after confirmation. Verify that every attempt leaves a decision record for support and investigation.
Notification and cooling rule
Send a notice to an existing, verified contact when a beneficiary changes. Do not send the only notice to the newly entered account or phone. For a payout scheduled soon after a change, define whether the product pauses it, requires fresh approval, or uses the old version. Make that rule visible before the payout is released. Test a user who changes a beneficiary and immediately logs out, then test a support worker who changes it through an internal route. Both paths must create the same versioned record and notice.
Compare the exact destination at release
A masked account number is for display; it is too short to bind a transfer. Store the full destination in protected storage or store an immutable provider recipient ID that binds the bank and account. Build the approval digest from the canonical bank identifier, full account or bound recipient, currency, amount, and beneficiary version. Keep secrets and full account values out of general logs.
Case PAY-09 uses the policy that holds a queued payout after any account change. Approve beneficiary version 1, create version 2, and try release. The old approval snapshot remains unchanged and the release stops for a fresh decision. Run a separate test if your policy allows a payout to keep its original version; assert that the provider still receives the original destination. Do not mix those two policies in one pass condition.
A bank name lookup can confirm returned account details; it does not establish the caller’s right to redirect funds. Check the change authority separately. Test direct API, support, and batch paths with an expired approval and an old session. Send the change notice through an existing verified contact and provide a working way to report an unknown change. The release check must work even if nobody reads the notice.
Evidence to retain
Keep the old and new beneficiary versions, change approval, notification target, pending payout state, and payout decision.
Sources
Put this into practice
Start with scheduled payouts because a beneficiary change can redirect money without another customer action. Bind them to the approved beneficiary version. See our secure mobile banking sessions and payment gateway testing service. To check a live flow, request a security review.