Nobody legitimate will ever ask for your seed phrase. Not support. Not us. Nobody.
Case fileacquiring

When the Attacker Changes Your Settlement Address

A merchant account compromise redirects settlements rather than stealing a balance. Why it goes unnoticed and what detects it.

Priya Raman · 2 min read

A merchant payment account is a more attractive target than a wallet, because it receives money continuously and the compromise is not visible from the front end. The contrast worth drawing is with a crypto payment gateway with fiat settlement, where this is a requirement rather than a courtesy.

What the attacker changes

Not the balance. The settlement destination.

Payments continue arriving normally. Customers are unaffected. Orders complete. The only change is where the money goes at settlement, and that is a field in a settings page nobody looks at daily.

Why it goes unnoticed

Settlement is periodic. If it is weekly, the compromise has up to a week before anything is due.

The dashboard shows payments received and a pending balance, which looks correct.

Notification emails about the change are deleted from the compromised mailbox.

Finance notices when a settlement does not arrive, and by then the period’s takings are gone.

How access is obtained

The same routes as any account compromise: reused password, phishing page mimicking the provider’s login, or a session token stolen through a compromised browser extension.

Merchant accounts are often shared among several staff with a single login, which widens the exposure and removes attribution. Where funds belong to clients, the requirements are stricter, and crypto rails built for fintech companies is structured for that.

The controls

Individual accounts with individual second factors. No shared merchant login. A hardware key or authenticator application, never text messages.

Settlement address changes requiring a separate approval, with a delay before they take effect.

Notifications on settings changes to multiple people, sent to individual addresses rather than a shared inbox.

Checking settlement arrival on a schedule, not only when someone notices it missing. A short recurring task confirming that the expected amount arrived at the expected account.

Daily settlement where available, which bounds the exposure to one day rather than one week.

Detection

Review the settings change log weekly. Most providers have one and almost nobody reads it.

Reconcile settlements against payments received. A gap between what the dashboard says was collected and what reached the bank is the signal.

If it happens

Contact the provider immediately to freeze settlement and revert the destination.

Change credentials for the account and for the mailbox of everyone with access, because the mailbox is usually the origin.

Ask the provider for the change log showing when the address changed, from which session and which address. That record is what any investigation will need.

The structural point

Any system where a single compromised login can redirect money is a system with a single point of failure.

The fix is not better passwords. It is a second approval on the specific action that moves money somewhere new, which is the same control that protects a wallet allowlist, applied to the settlement destination. Check the coverage list before relying on any of this. a provider you can actually reach publishes it.

If this has already happened to you

Move any remaining funds to a wallet with a newly generated seed phrase before anything else. Then revoke token approvals, and report the incident to your local authorities and the exchange involved. Do not pay anyone who promises to "recover" your coins. That is a second scam, aimed at victims of the first.

acquiringsecuritysettlement

Related cases