The seller had four years of good reviews. The seller changed last week.

A marketplace storefront is a credential. It carries years of accumulated trust, it can be stolen in an afternoon, and every signal a careful buyer is told to check is exactly the part the attacker inherited. The loss does not happen at signup. It happens at the payout endpoint.

Picture a woman who has sold restored audio equipment on a large marketplace since 2021. Two and a half thousand orders. A rating that rounds to five stars. She knows which couriers damage boxes and she photographs every unit before it ships. On a Tuesday morning she opens her seller dashboard to print labels and finds that her bank details are not her bank details.

She had received an email nine days earlier about a policy update. It looked exactly like the marketplace's other emails, because it was a proxy of the marketplace's actual login page. She typed her password and approved the prompt on her phone, and the page that appeared afterwards was the real dashboard, because by then the attacker was relaying her session. Nothing looked wrong. Nothing was wrong, from the platform's point of view. Someone holding a valid authenticated session updated a payout account, which is a thing sellers do.

In the nine days since, her storefront listed forty units of a popular headphone model at a price that was good but not absurd. Three hundred and twelve buyers ordered. None of them received anything. They ordered because the shop had four years of history, two and a half thousand orders, and a rating that rounds to five stars, and every one of those signals was true. It just no longer described the person operating the account.

What actually happens in a marketplace seller takeover?

The sequence is boringly consistent, and its boringness is the point. Nothing in it requires a novel exploit.

Step one: acquire the session

The attacker does not usually need the password in isolation. Modern phishing kits operate as a reverse proxy: the victim is shown the genuine login page, relayed through attacker infrastructure, and authenticates against the real platform. What the kit captures is the session token issued after successful authentication, including after multi factor authentication succeeded. We wrote about this mechanism in detail in your MFA worked perfectly, the attacker was already inside the session. The seller's account is not broken into. It is inherited.

Step two: establish independent access

A stolen session expires. Durable access does not. So the attacker enrols a new authenticator, adds a new recovery address, or generates an API credential, converting a temporary foothold into co-ownership that survives a password reset. This is the operation we called out separately in the takeover button is labelled Add authenticator, and on marketplaces it matters even more than on consumer accounts, because sellers rarely audit their own security settings.

Step three: change the payout destination

This is the pivotal action, and it is the same pivotal action as in commercial banking. The money has to arrive somewhere the attacker controls. Everything before this step is preparation and everything after it is harvesting. We treat this class of operation at length in the payee add is the real transaction: the industry hardens transfers and treats destination changes as settings, when the destination change is what decides the outcome.

Step four: convert reputation into orders

Now the attacker lists goods. The choices are predictable: high value, easily desirable, plausibly in stock, priced attractively but not so cheaply as to trip the platform's own anomaly checks. Sometimes the existing listings are simply edited, which is quieter than creating new ones. The storefront's history does the persuading.

Step five: exit before settlement

Marketplaces do not pay sellers instantly. There is a settlement cycle, and often a hold on newly changed payout accounts. The attacker's entire operating problem is to accumulate enough orders inside one settlement window, and their entire operating advantage is that the seller may not look at the dashboard for a week. The buyers who complain first are the ones who paid for expedited shipping.

Why does the standard buyer advice actively mislead?

Every consumer protection guide tells buyers to check the seller's history: how long the account has existed, how many orders it has fulfilled, what the rating is, whether the reviews look organic. This is good advice against a newly created fraudulent storefront, which is the common case and which those guides were written for.

Against a takeover it is precisely inverted. The attacker chose that account because of its history. Account age, order count, rating, review depth and photo quality are not merely useless here, they are the mechanism of the fraud. A buyer performing careful diligence is more likely to order, not less, because diligence surfaces exactly the signals the attacker acquired.

That is an uncomfortable thing to say plainly, so let us say it plainly. Under takeover conditions, the reputation signals a marketplace publishes are adversarially controlled, and the more a buyer relies on them the more effectively they are steered. It is not the buyer's fault and there is nothing better for them to look at, which is the real indictment.

Read the last two rows together. The single most predictive signal available, a recent change of payout destination, is known to the platform and shown to nobody. The signal that would settle the question does not exist.

What does the INFORM Consumers Act actually require?

In the United States, the INFORM Consumers Act took effect in 2023 and requires online marketplaces to collect, verify and, for certain high volume third party sellers, disclose identifying information including bank account details, contact information and a business tax identifier. The Federal Trade Commission publishes guidance for marketplaces on what the statute demands.

It was a sensible law and it addressed a real harm, which was anonymous high volume sellers moving stolen and counterfeit goods with no traceable party behind them. It should be credited for that.

What it does not do is govern the rest of the relationship. The statute is oriented around collection, verification and disclosure of seller information, largely at onboarding and on an ongoing certification basis. It does not require that a payout change be authorised by the verified human, because that is not the problem it was written to solve. A marketplace can be entirely compliant while an attacker who inherited a session redirects the payouts of a verified high volume seller, since the verified information on file remains accurate. It describes a person who is no longer the person acting.

This is the shape of a false floor. Verification at signup creates a reasonable belief that seller identity is a solved problem on the platform, and that belief is correct exactly once, at the beginning, about a fact that then stops being checked.

Why do payout holds not close the window?

Marketplaces are not naive about this. Changing a payout account typically triggers a hold, a notification, sometimes a re-verification step, and often a delay before funds settle to the new destination. These are real controls and they defeat a meaningful share of attempts. Any honest treatment has to say so.

They leave a window open for three structural reasons.

First, the notification goes to the account's contact channels, which the attacker may already control, and to an email address the seller may not read promptly. A notification is a detection mechanism that depends on the victim's attention, and attention is exactly what a busy seller does not have on a Tuesday in the middle of a shipping run.

Second, the re-verification step usually re-checks the session or sends a code to a registered channel. Both are satisfied by the attacker who holds the session. This is the recurring structural failure across this entire series: a control that consumes the same credential the attacker already stole cannot distinguish the attacker from the owner.

Third, and most importantly, the hold delays settlement but does not delay selling. The listings go live immediately. Orders accumulate immediately. Buyers pay immediately. Even when the platform successfully blocks the diverted payout, the buyers were still defrauded, the goods were still never shipped, the refunds still come out of somebody's pocket, and the seller's rating still absorbs three hundred non delivery complaints. Blocking the payout saves the money and does not save the seller.

Why is an aged marketplace account worth real money?

There is a second market that runs on the same underlying fact, and it is worth understanding because it explains why the problem is durable rather than incidental.

Marketplace reputation is deliberately non transferable. Platform policies generally prohibit selling or transferring seller accounts, and reputation cannot be exported to a competitor. That policy exists for a defensible reason, which is that a transferable rating would be immediately gamed. But it produces a predictable second order effect: a thing that is valuable and cannot be legitimately transferred acquires a grey market.

So aged accounts with clean histories are bought and sold. The buyer is not always a fraudster. Sometimes it is a legitimate operator who wants to skip the cold start problem that every new seller faces, where nobody buys from you because nobody has bought from you. That cold start is a genuine business obstacle, and the grey market is partly a rational response to it.

The uncomfortable observation is that the policy prohibiting transfer does not prevent transfer. It only ensures the transfer is undisclosed. The buyer of the storefront gets the reputation of the seller who earned it, the platform's records still name the original party, and shoppers are told to rely on a history that describes someone who left.

What would signed seller actions look like?

The control follows directly from the diagnosis. If the loss concentrates at a small number of account shape changes, then those specific operations should require something the session does not contain.

The seller enrols a device once, using a passkey and a companion device check. Afterwards, a defined set of high consequence operations requires a fresh signature over the exact payload of the operation, produced on that enrolled device. The platform stores the resulting receipt against the account record.

Here is what gets signed for the pivotal operation. The important property is that the signature covers the specific new destination, not a generic assertion that someone approved something.

{
  "action": "seller.payout_account.change",
  "marketplace": "example-marketplace",
  "seller_id": "S-4471902",
  "old_account_last4": "8812",
  "new_account_iban_hash": "sha256:1f3a...c904",
  "new_account_holder": "AUDIO RESTORATION LTD",
  "effective_at": "2026-09-25T09:14:22Z",
  "requested_from_session": "sess_7d19b2",
  "nonce": "8f2b41d0"
}

The seller's device signs the SHA-256 of the canonical serialisation of that object. The platform verifies the assertion, records the receipt, and only then writes the new payout destination. An attacker holding the session can submit the request. They cannot produce the signature, because the signature requires the private key held in the seller's device, and that key never leaves it.

Verification is ordinary and does not require calling us:

const keys = await fetchOnce('https://manav.id/.well-known/manav-keys')
const receipt = await db.receipts.forAction(payoutChangeId)

const ok = verifyEd25519(
  keys[receipt.kid],
  canonicalJson(receipt.payload),   // exactly the object above
  receipt.signature
)

if (!ok || receipt.payload.new_account_iban_hash !== hashOf(submittedIban)) {
  return reject('unsigned or mismatched payout change')
}

The second condition matters as much as the first. Verifying that a signature is valid is insufficient if the signature covers a different payload than the one being executed. The receipt has to be bound to the operation actually performed, or you have built an expensive way to log approvals.

The same pattern extends to the other account shape changes: adding an authenticator, adding an API credential, changing the registered business entity, and bulk editing listings above a value threshold. Notice that ordinary selling is untouched. Printing labels, answering messages, adjusting a price by two pounds, none of that needs a signature. The friction lands on the operations that convert an account into cash, which are rare for a legitimate seller and mandatory for an attacker.

What happens to the grey market if reputation belongs to the human?

Here is the part that is genuinely elegant, and it is a consequence rather than a feature.

Today the platform holds the reputation record, so the only way to acquire someone's reputation is to acquire their account. That is what makes the account valuable and what makes both the takeover and the grey market work.

Now suppose that as a seller fulfils orders, the platform issues them signed receipts: this enrolled human fulfilled this many orders in this category between these dates with this dispute rate. The seller holds those receipts in their own wallet. Their reputation is a portfolio of attestations about a human, verifiable by anyone against the issuing platform's published key, exactly as described in your five star rating is not yours.

Two things change. A seller who wants to open on a second marketplace can present evidence of their history instead of starting from zero, which addresses the cold start problem that drives honest people into the grey market. And an attacker who steals the account no longer steals the reputation, because the reputation attaches to a key they do not hold. The storefront becomes considerably less worth stealing.

This is worth stating precisely, because it is the strategic argument: binding reputation to the human does not police the grey market in accounts, it removes the asset that market trades in. You do not have to enforce a prohibition on transferring something that cannot usefully be transferred.

What about legitimate business sales and successions?

Businesses genuinely change hands. A seller retires and sells the operation. A partnership dissolves. An owner dies and a family member continues the shop. A brand is acquired. Any design that assumes a storefront has exactly one human behind it forever will be wrong in a way that punishes honest people, and marketplaces already handle these cases through account transfer processes with varying degrees of grace.

So the correct design is not to make transfer impossible. It is to make transfer explicit. A succession becomes a signed event: the outgoing human signs a transfer of the storefront to an incoming enrolled human, the platform records it, and the storefront's public history can distinguish between reputation earned by the previous operator and reputation earned since the handover. Buyers see that the shop changed hands in March, which is information they currently never get and would obviously want.

That is a better outcome than the status quo for everyone except the person who wanted the transfer hidden. The honest seller gets a legitimate exit with a transferable business. The buyer gets disclosure. The platform gets an auditable record instead of a policy it cannot enforce.

What this cannot do

Several limits, stated directly, because a control oversold is a control mistrusted.

It requires the platform to adopt it. A seller cannot unilaterally demand that a marketplace gate its payout endpoint. This is a channel play, and its adoption depends entirely on marketplaces and commerce platforms deciding the loss is worth a signature. Nothing here helps a buyer on a platform that has not adopted it.

It does not make sellers honest. A verified human with an enrolled device can sell counterfeit goods, take payment and ship nothing, and sign every payout change while doing it. This control addresses the case where the acting party is not the accountable party. It does nothing about a bad actor who is exactly who they claim to be, and that is a large fraction of marketplace fraud. Enforcement, buyer protection and returns policy remain necessary.

Enrolment is the trust bottleneck. Everything rests on the key having been bound to the right human at the start. If an attacker completes the original enrolment, every subsequent signature is theirs and perfectly valid. Signature based controls move the attack to onboarding, they do not remove it, which is why identity proofing at onboarding still matters and why we treat capture integrity separately in the camera is no longer evidence.

Compromised devices sign. The private key lives on a device. A fully compromised device with the seller present can be made to sign. The design raises the cost from stealing a session remotely to compromising a specific physical device, which is a very large increase and not an infinite one.

Portable reputation needs issuers. The reputation portability argument depends on platforms issuing signed receipts, and incumbent platforms have a clear commercial interest in reputation remaining locked to them. Realistically this begins with challenger platforms, aggregators and seller tooling rather than with the largest incumbents.

What to do this week

For a marketplace or commerce platform:

1. Enumerate every endpoint that changes where money goes or who can act: payout account, authenticator enrolment, API credential creation, business entity details, registered contact, user invitations. This list is usually shorter than teams expect and rarely written down anywhere.
2. Measure the interval between a payout change and the first subsequent order for accounts that were later confirmed compromised. That number is your actual exposure window and it is almost certainly not the number in your policy document.
3. Show buyers a neutral recency signal, such as whether the storefront's payout details or registered entity changed in the last thirty days. You already hold this. It is the single highest value disclosure available and it costs nothing.
4. Stop treating account shape changes as settings in your data model. Move them into the same risk tier as disbursement.
5. Pilot device bound signatures on the payout endpoint alone, for high volume sellers only. That is the smallest change that closes the largest hole, and it lets you measure enrolment friction against a real population.
6. Design your business succession flow now, before you need it, so that legitimate transfer has a supported path and does not get pushed into the grey market by your own policy.

For a seller:

1. Audit your account's authenticators and API credentials today and remove anything you do not recognise. Most sellers have never opened this screen.
2. Set a calendar reminder to check your payout destination weekly. It takes fifteen seconds and it is the difference between one settlement cycle of loss and three.
3. Ensure payout change notifications go to an address separate from your main seller account contact, so that a mailbox compromise does not silence the alarm.

You can see the signing flow in the signing demo, and the integration shape is documented in the developer docs.

Frequently asked questions

How do marketplace sellers prevent account takeover and payout theft? Require the seller's enrolled device signature on payout changes, authenticator enrolment and API credential creation, rather than relying on the login session. Signup verification proves who the seller was once. The payout endpoint is where the loss actually happens, and a stolen session satisfies every control that consumes the session.

Does the INFORM Consumers Act stop seller account takeover? No. It requires marketplaces to collect, verify and disclose information about certain high volume third party sellers, largely at onboarding and through ongoing certification. A marketplace can be fully compliant while an attacker who inherited a verified seller's session redirects that seller's payouts, because the information on file stays accurate. It just stops describing whoever is acting.

Why does checking seller ratings not protect buyers from this? Because the attacker selected the account for its ratings. Account age, order count, star rating and review depth are all genuinely earned and all fully inherited by whoever holds the session. Under takeover conditions, careful diligence surfaces exactly the signals the attacker acquired, which makes a cautious buyer more likely to order rather than less.

Can marketplace seller reputation be moved between platforms? Not today, by design. Platform policies prohibit account transfer and reputation cannot be exported, which is why aged accounts trade on a grey market. If platforms issued sellers signed receipts covering fulfilment history, a seller could present verifiable evidence of their record elsewhere, which addresses the cold start problem and simultaneously makes stolen storefronts far less valuable.

Do payout holds already solve this problem? They help and they do not close it. Holds delay settlement but not listing, so buyers still order and still lose money even when the diverted payout is blocked. Notifications reach channels the attacker may control, and re-verification steps that consume the existing session are satisfied by the attacker holding it.

What happens if a seller loses their enrolled device? They recover, which is the hardest part of any signature based design and deserves its own treatment. The correct approach re-establishes continuity with the same human rather than re-running identity proofing from documents, and any recovery path has to degrade to a staffed process. We cover the tradeoffs in detail separately.

Does this work for sellers who use agencies or staff? Yes, through scoped delegation rather than shared logins. The accountable seller signs a delegation naming what an agency or employee may do, with limits and an expiry, and their actions chain back to that authorisation. Shared credentials are the current answer and they destroy attribution entirely.

Sources

1. Federal Trade Commission, business guidance on the INFORM Consumers Act and what online marketplaces must collect, verify and disclose: ftc.gov
2. FBI Internet Crime Complaint Center, public service announcements including its November 2025 alert on account takeover fraud: ic3.gov/PSA
3. FBI Internet Crime Complaint Center, annual Internet Crime Report series: ic3.gov
4. NIST Special Publication 800-63B, Digital Identity Guidelines, on authenticator binding and session management: pages.nist.gov
5. W3C Web Authentication (WebAuthn) specification, on device bound credentials and assertion signatures: w3.org
6. Federal Trade Commission consumer guidance on shopping and marketplace scams: consumer.ftc.gov

Note on figures: platform specific seller takeover losses are not published by the major marketplaces, and we have deliberately not estimated them. Where this post refers to account takeover generally, the source is the FBI's own reporting. The absence of platform disclosure is itself worth noticing, since it means neither sellers nor regulators can size the problem independently.

The attacker did not steal a storefront. They rented four years of somebody else's good behaviour, and every buyer who checked carefully was steered by it.