Marketplace Seller Verification: KYC, Beneficial Owners, and Sanctions

Recruiting a single seller costs weeks of a salesperson's time. Verification can wipe that effort out with two weeks of silence that nobody at your company knows about, because the process runs inside a system you cannot see into.

In implementation plans, verification sits as one line on a compliance checklist, somewhere between the terms of service and data protection. In reality it is the valve at the entrance to your recruitment funnel.

Usually you are not the one holding it.

Marketplace seller verification is four separate processes: payment verification, seller traceability, reporting data, and sanctions screening. Each one is forced by a different rule, each has a different owner, and your payment provider usually runs only the first.

Confusing them is behind most of the misunderstandings in a vendor meeting, because the vendor answers about one while you are asking about another.

This article breaks down:

• Which 4 verification streams does a marketplace owe?
• What actually gets checked, and who can check it?
• Which 4 gates does an unverified seller pass through?
• What happens when a seller changes its legal form?

Key insights

• Four streams, four owners. Your payment provider runs one of them, the other three stay with you, and nobody will say so until you ask.
• Public registers of beneficial owners closed to the general public after a 2022 EU court ruling, so you take that data from the seller and confirm it against documents.
• Sanctions screening never ends, because the lists change while the seller stays the same. It needs a queue and a person who works it.
• Never open the right to sell before the right to be paid. A seller with 100 completed orders and unfinished verification is owed money you cannot send.
• Verification attaches to the legal entity. If your data model welds the seller to that entity, every company conversion becomes a manual migration.

Why is marketplace seller verification 4 separate processes?

"Let's verify the seller" sounds like a single action. It is four independent processes with different owners, different triggers, and different consequences when you skip them.

Confusing them is behind most of the misunderstandings in meetings with a vendor. The vendor answers about one of them while you ask about another.

1. Payment verification: KYC and KYB

Forced by the fact that somebody is holding other people's money. The duty sits with the institution holding it: a marketplace on its own is usually not an obliged entity under the anti-money-laundering regime, until it steps inside the payment perimeter ("When You Need a Payment License to Run a Marketplace?").

This is the verification you have in mind when you say "KYC". It is also the only one of the four you do not really run yourself.

2. Seller traceability

EU platform law requires a marketplace to obtain the trader's details and to make an effort to assess whether those details are reliable and complete, using public registers or documents demanded from the seller. This one is your duty and you cannot buy it together with payments.

If the data is missing, the penalty is suspending your services to that seller until the gap is filled. The scope depends on whether your buyer is a consumer and on how large you are.

Confirm it with a lawyer, because the difference can be binary.

3. Reporting data

The platform reporting regime requires you to collect identification and tax data from the seller. The enforcement mechanism is unusual and worth remembering: after reminders that go unanswered, the platform is required to close the seller's account or withhold their payout.

A tax obligation therefore turns into a product requirement. Your system has to be able to block a transfer because of a missing field.

4. Sanctions screening

It is not part of any of the above. The ban on making funds available to sanctioned persons and entities applies to every company in the EU, whatever the industry and whatever the size.

It also covers making funds available indirectly, which reaches an entity that does not appear on any list itself but is controlled by somebody who does.

There is a fifth thing everybody calls verification although it is not one. That thing is the commercial assessment: whether you want this seller at all.

It is a business decision rather than a compliance one, and it gets mixed in with the other four only because it happens in the same week.

What actually gets checked in seller verification?

1. The entity

Whether the company exists, under which number, who represents it, and whether the address is real. The cheapest part, because business registers are usually available.

One caveat: a registration document has a limited shelf life, and an extract pulled three years ago proves nothing.

2. The people: the beneficial owners

This is where the process slows down. What matters here are the natural persons who genuinely control the company, whether through shares, through votes, or in some other way.

The line is a convention. In European practice it hovers around a quarter of the shares or the votes.

In higher-risk sectors it can sit lower, and indirect ownership is counted through the chain of companies. Confirm with a lawyer what the exact threshold is, how it is counted, and when "control" counts even without any shares, because this is moving ground and it differs between countries.

A practical consequence few people know about before launch: public registers of beneficial owners stopped being open to everybody. After a 2022 ruling by an EU court, general access was restricted, and full access stayed with the authorities and with obliged entities.

If you are not one of them, you cannot check beneficial owner data yourself in an open source. You take it from the seller and try to confirm it with documents.

This is the moment where a sole trader passes in a minute and a company with a foreign holding somewhere in the chain can sit stuck for weeks.

3. The payout account

It has to belong to the verified entity. An account in a different name, or in the name of a sister company, is the most common reason a seller "passed verification" and the first payout stops anyway.

4. Sanctions: the one thing that never ends

The entity, its representatives, and its beneficial owners all go through screening against the lists. Two properties of that process are counterintuitive.

First, the lists change and the seller does not: somebody clean in January can be sanctioned in March, so a single screening at entry is out of date by definition. Second, screening by name produces mostly false hits.

In practice, the large majority of alerts come down to a coincidence of surnames, a transliteration, or a common name. Screening is therefore a process with a queue and a person who works it.

Without that person, the alerts either get ignored or block sellers at random.

Whose interface does the seller see, and what does that cost you?

Take a seller we will keep for the rest of this article: 100 orders a month at €1,000 each, commission 12%. That is €100,000 of turnover, €12,000 of revenue for you and €88,000 owed to the seller.

There are three arrangements, and they differ in who looks the seller in the eye.

1. In the payment provider's interface

The seller gets a link, leaves your panel, uploads documents somewhere else, and comes back with a status. The cheapest option and the most common one.

It costs you two things: the user experience stops being yours, and you see a status rather than a process. So to the question "where exactly am I stuck?" your onboarding person answers "I don't know, I'll check."

2. Embedded in your own panel

The form and the documents sit with you, the decision sits with the provider. More expensive to integrate and clearly better to operate, because the seller enters the data once instead of three times in three systems.

This is the first cost to drop out of scope during an implementation, and the reason given is that what matters is getting the seller registered at all. It comes back as a permanent overhead on support.

3. Run by you

Necessary for streams 2, 3 and 4. Impossible for the payment stream, unless you are a regulated institution yourself.

Do the math on the delay before you write it off as a detail. One week of that seller sitting stuck is €3,000 of commission you will not earn.

Twenty sellers in the queue with a three-week slip is €180,000 of commission postponed or lost. Postponed if they hold on, lost if they give up.

In the implementations we have seen, verifying a company takes anywhere from a few days to a few weeks, depending on the ownership structure and the country. Calculate your own on your own data, because this is one of the few implementation metrics you can measure from day one.

Which 4 gates does an unverified seller pass through?

Verification is four independent gates, and you settle each one on its own.

1. May create an account and enter data. Always yes.
2. May build a catalog and offers. Usually yes. It shortens the time to the first sale, and the risk is limited: if the seller drops out, you lose their work.
3. May sell. This gate has to stay closed, because an order from a customer creates an obligation you have no way to settle.
4. May receive money. This one closes itself, because there is nowhere to send the transfer.

The rule is worth writing down in a single sentence: never open the third gate before the fourth. A seller who has sold 100 orders with verification unfinished is owed €88,000 that you cannot pay out, and their customers already have the goods.

The relationship then opens with the line "you have been selling for a month, but we cannot pay you," and where reporting data is missing, withholding the payout is sometimes your obligation.

And the thing most projects overlook: statuses have to be able to move backwards. A registration document expires, a beneficial owner changes, a sanctions list is updated.

A verified seller can return to "needs completion" without making a single move. Systems modeled only in the forward direction, from "new" to "verified", have no way to handle that.

They end in a spreadsheet maintained by hand.

What happens when a seller changes its legal form?

The most underrated item in the whole subject. A seller converts a sole proprietorship into a company, changes its tax number, merges with somebody or gets acquired.

The mechanism is unforgiving: verification is attached to the legal entity, and the brand, the store, and the owner have nothing to do with it. A new entity is a new customer.

That means a new verification, a new contract, and a new bank account. Repeating the procedure is the easy part.

The problem is that most platforms model the seller as a single object welded to the entity. A change of legal form then means an account from zero, and with it zero sales history, lost ratings, a lost right to edit product pages, and a catalog to build from scratch.

In practice, this is one of the most painful operational problems of a mature marketplace.

Then comes the money question: €88,000 of receivables stays with an entity that has ceased to exist. Who signs off on the transfer, to which account and on what basis?

That is a legal call rather than a system one, and it is better written into the contract than invented in emergency mode.

There is one decision to make before launch: whether, in your data model, the legal entity is an object separate from the store. If it is, a conversion means you swap the entity, carry the history across, and lose only the time it takes to verify again.

If it is not, migrating a seller will be a manual project every single time. This is a concrete question to put to the platform vendor, and the answer is binary.

How do the 4 verification streams compare?

What does marketplace seller verification decide?

1. Choosing a payment provider is choosing your recruitment funnel

It decides which types of entity and which countries can be verified at all, how long that takes, and what the seller sees. The question "do you handle sole traders and entities from outside the EU" usually gets asked six months too late.

2. Changing providers means verifying your entire base again

That is the most concrete exit cost in this architecture ("When You Need a Payment License to Run a Marketplace?"). It is also the argument for collecting verification data on your own side, even when somebody else makes the decision.

3. Verification is the payout gate, so verification debt shows up as money you cannot pay out

("How Marketplace Seller Payouts Work: Cycles, Holds, and Reserves"). It also shows up as a reporting obligation implemented in the form of an automatic block on a transfer.

4. You start storing identity documents

ID cards, register extracts, and beneficial owner data. That pulls in retention and access limits inside your own company.

When somebody from support opens a seller's account, do they see the bank account number and the scans? The answer "they see everything" is a bad one, and it is cheap to fix only before launch.

5. The contract has to give you the right to demand current documents and the right to suspend

Without it, at the first sanctions alert you have a duty to act and no contractual basis for acting.

How do you check seller verification with a vendor? 8 questions

Eight questions before you sign. Write the answers down.

They predict your recruitment time better than any presentation.

1. Who carries out the verification, in whose interface, and what is the median duration? Not the average. The median and the tail.
2. Which types of entity and which countries do you support? Sole traders, foundations, companies from outside the EU?
3. What exactly do we see of the process? Can our onboarding person tell a seller which document is missing, or only that it is "in progress"?
4. Does data entered once feed every system, or does the seller fill in the same thing twice?
5. Can the platform block a payout automatically because of a missing field? And does it tell that apart from a manual block?
6. Can a verification status move backwards, and what happens to active offers when it does?
7. Is the legal entity an object separate from the store? Which is to say: what happens when a company converts.
8. Who works the hits from sanctions screening, and where does the record of the decision live?

Which mistakes do operators make about marketplace seller verification?

1. Treating verification as a compliance item rather than a funnel stage

Nobody measures it, so nobody knows that sellers drop out exactly there. Start with a single number: the median time from registration to the first sale the seller is allowed to make.

2. Opening sales before verification is closed

Usually not a decision, just an oversight. It ends with an obligation toward the seller that you have no way to settle.

3. Sanctions screening once, at entry

It gives you a document for the audit and zero protection, because the lists change without the seller doing anything.

4. Assuming the payment provider covers all four streams

It covers one. The rest stays on your side, and nobody will tell you so until you ask.

5. Welding the seller to the legal entity in the data model

A cheap decision at the start that costs you history, ratings, and catalog at every company conversion.

What do you still have to settle yourself about seller verification?

This is a map of mechanisms, not a legal opinion. We deliberately give no thresholds, no dates on which rules take effect, and no lists of documents.

Those numbers change faster than this guide does, and the EU anti-money-laundering framework is being rebuilt right now.

Confirm four things with a lawyer, for your country, your model, and your year: which verification duties fall on you and which fall on the payment provider; which threshold and which definition of a beneficial owner apply to you; how to build sanctions screening so that it is a defense rather than an entry in a log; and how to word the right to suspend and to demand documents so that you can use it without a dispute.

We also do not settle when a seller should not be let onto the platform at all for commercial reasons. That is a separate decision and a separate subject.

Summary: What does seller verification actually gate?

It gates your recruitment funnel at the front and your payouts at the back. Measure one number from day one: the median time from registration to the first sale a seller is allowed to make.

Everything else in this chapter is a way of moving that number.

Ask a vendor the binary question: is the legal entity an object separate from the store? Talk to a marketplace expert if you want the eight questions sharpened before the demo.

Frequently asked questions on marketplace seller verification

What is KYC on a marketplace?

KYC and KYB are the payment stream of verification, forced by somebody holding money that belongs to other people. The duty sits with the institution holding those funds, so a marketplace usually does not run it, until the platform steps inside the payment perimeter itself.

It is also only one of the four streams a marketplace owes.

Who verifies sellers: the marketplace or the payment provider?

Both, on different streams. The provider handles payment verification.

Seller traceability, reporting data, and sanctions screening stay with the platform, and no payment contract covers them. Collecting the verification data on your own side is also what makes changing providers survivable.

How long does marketplace seller verification take?

From minutes for a sole trader to weeks for a company with a foreign holding in the ownership chain. Ask a vendor for the median and the tail rather than the average.

On a seller doing €100,000 a month at 12%, every week of silence is €3,000 of commission you do not earn.

Sources

• Regulation (EU) 2022/2065 (Digital Services Act) - traceability of traders and the duty to assess whether their details are reliable
• Directive (EU) 2021/514 (DAC7) - platform reporting obligations, including closing an account or withholding a payout
• CJEU C-37/20 and C-601/20 (2022) - the ruling that restricted general public access to beneficial ownership registers
• EU Sanctions Map - the consolidated list of sanctioned persons and entities