Marketplace KYC and KYB
Marketplace KYC and KYB: What Platforms Need to Know About Seller Verification Marketplace seller verification tends to begin as a form. Name. Address. ID. Company number. Bank account. Submit. Then the marketplace expands. An individual seller appears in France. A corporation ap
Marketplace KYC and KYB: What Platforms Need to Know About Seller Verification
Marketplace seller verification tends to begin as a form.
Name. Address. ID. Company number. Bank account. Submit.
Then the marketplace expands.
An individual seller appears in France. A corporation appears in Singapore. A sole proprietor has no incorporation certificate. Another company is owned through three holding companies. A director has changed. A payout beneficiary does not match the seller's legal name. A payment provider asks for additional information. A seller that was approved six months ago changes owners. A registry returns one spelling while an uploaded document uses another.
At that point, the problem is no longer:
Which documents should our signup page ask for?
It is:
How should the platform determine what verification is appropriate for each seller, track the decision, handle exceptions, respond to changes, and prevent an unresolved verification problem from becoming a payout problem?
That is the real operational meaning of marketplace KYC and KYB.
KYC and KYB are related concepts, but neither should be treated as a universal document checklist. Marketplace seller verification varies with seller type, jurisdiction, payment flow, provider structure, regulatory obligations, and risk.
What are KYC and KYB?
In marketplace operations, KYC generally refers to controls used to identify and verify natural persons.
Depending on the marketplace and payment model, those people might include:
an individual seller;
an authorized representative of a company;
relevant owners or controllers;
other individuals that the applicable verification framework requires.
KYB, or Know Your Business, generally describes the corresponding process for a business or other legal entity.
That can involve establishing facts such as:
the entity's legal existence;
registered name;
registration identifier;
registered or operating address;
business activity;
authorized representatives;
ownership and control structure.
A business verification process can therefore contain both KYB of the legal entity and KYC of relevant natural persons behind or representing it.
The terms are useful operational shorthand. Actual laws and financial rules often use more specific terminology such as customer due diligence, identity verification, beneficial ownership, trader traceability, or ongoing monitoring rather than imposing something literally titled “marketplace KYB.” Current FATF standards, for example, use customer-due-diligence and beneficial-ownership concepts, while marketplace-specific rules such as the EU Digital Services Act use their own trader-traceability framework.
That distinction matters because:
Calling a workflow “KYC” does not tell you which legal rule, provider requirement, or marketplace policy created it.
KYC and KYB answer different questions
A useful conceptual comparison is:
Question
KYC
KYB
Who is being verified?
Natural person
Business/legal entity
Core question
Is this person who they claim to be?
Does this business exist, and what is its relevant ownership/control structure?
Potential subjects
Individual seller, representative, owner/controller
Company, partnership, other registered business
Typical evidence areas
Identity and identifying information
Registration, business details, ownership/control
Can the processes overlap?
Yes
Yes—business KYB can require verification of relevant people
This is a conceptual operating model, not a universal regulatory checklist.
Start with seller type, not the document list
A scalable verification workflow should determine:
What kind of seller is this?
before asking:
Which files should they upload?
Consider three seller structures:
Individual seller
There may be no separate incorporated company.
The relevant workflow can therefore center on the natural person plus whatever business, payment, tax, banking, or provider information applies to that operating model.
Sole proprietor
A sole proprietor may be a natural person operating a business without the same legal separation as a corporation.
Treating the seller automatically as either:
“individual only”
or:
“full corporation KYB”
can produce unnecessary friction or missing information.
Incorporated business
Now the platform may need to understand both:
the entity
and:
the natural people who own, control, or represent it, depending on the applicable framework.
The architecture should therefore use:
seller type → applicable policy → required data
rather than:
all sellers → same upload page.
What is a beneficial owner?
Business verification often goes beyond confirming that a company appears in a registry.
A company is a legal person.
Ownership and control ultimately lead to real people.
FATF's current glossary defines a beneficial owner of a legal person in terms of the natural person or persons who ultimately own or control it, including ultimate effective control; FATF also makes clear that an ultimate beneficial owner is a natural person.
Operationally, that means several roles should not automatically be treated as equivalent:
registered shareholder
≠
beneficial owner
≠
director
≠
authorized account representative.
One person may occupy several roles.
Or different people may occupy each one.
Do not hard-code one global beneficial-ownership threshold
This is a common marketplace architecture mistake.
A team learns that one payment provider or one national rule uses a particular ownership percentage and implements:
if ownership >= X%:
verify_person()
globally.
That can turn a jurisdiction-specific rule into an unsupported worldwide policy.
For example, the current U.S. FinCEN Customer Due Diligence Rule applies to defined categories of covered financial institutions, not marketplaces generally. Its framework has specific ownership and control concepts, and FinCEN modified aspects of how beneficial-owner information must be re-collected through exceptive relief issued in February 2026.
The lesson for a marketplace is not:
“Use the FinCEN rule.”
It is:
Never assume that a percentage or beneficial-owner test from one regulated framework is the universal definition your platform should use everywhere.
Make ownership rules configurable by the actual legal/payment-provider context.
When do marketplaces encounter KYC or KYB?
Seller verification can enter marketplace operations through several different paths.
That does not mean every path applies to every marketplace.
A platform may encounter verification requirements because:
A payment provider or acquirer requires seller information
Depending on how payments and payouts are structured, the provider responsible for onboarding or underwriting marketplace participants may require information about the seller, business, representatives, or relevant owners.
The marketplace itself is subject to a legal requirement
The specific rule depends on jurisdiction and operating model.
For example, Article 30 of the EU Digital Services Act imposes trader-traceability requirements on certain online platforms that allow consumers to conclude distance contracts with traders. It specifies categories of trader information and a requirement to make best efforts to assess reliability and completeness. That is a particular EU platform-law obligation—not a universal definition of marketplace KYC.
A seller needs access to a financial service
Opening a relevant payment or payout relationship can cause the financial institution or payment provider to perform its own customer due diligence.
The marketplace imposes additional risk controls
A platform can choose additional verification, within applicable law, because of fraud, seller risk, product category, transaction value, payout exposure, or trust-and-safety considerations.
Keep those reasons separate in the data model.
A useful field is:
verification_requirement_source
REGULATORY
PAYMENT_PROVIDER
ACQUIRER
MARKETPLACE_RISK
MARKETPLACE_POLICY
OTHER
Otherwise, requirements become impossible to audit later.
Seller verification is a lifecycle, not an onboarding event
The brief requires the marketplace verification lifecycle to continue beyond document upload.
A useful state machine is:
SELLER APPLICATION
↓
Determine seller type + jurisdiction + payment model
↓
Determine applicable verification policy
↓
INFORMATION COLLECTION
↓
AUTOMATED / MANUAL VERIFICATION
│
├── insufficient ──→ ADDITIONAL INFORMATION
│ ↓
│ RESUBMISSION
│ ↓
└─────────────────────────┘
↓
VERIFICATION DECISION
│
├── approved
├── restricted
├── rejected
└── manual review
↓
ACTIVATION / PAYOUT ELIGIBILITY
↓
ONGOING MONITORING / INFORMATION UPDATE
↓
REVERIFICATION OR RESTRICTION WHEN REQUIRED
Notice that approval is not the final state.
Seller state, verification state, and payout state are different
This is one of the most useful distinctions a marketplace can put into its architecture.
A seller can be:
active
while its verification state becomes:
additional information required.
A seller can be:
verified
while its payout state is:
restricted for another reason.
Or a platform may allow some seller activity before payout eligibility under its particular model.
Do not reduce all three dimensions to:
seller.status = ACTIVE
Instead maintain separate state where applicable:
seller_state
verification_state
payment_account_state
payout_state
For example:
seller_state = ACTIVE
verification_state = REVIEW_REQUIRED
payout_state = RESTRICTED
Now customer support can explain what is actually happening.
Why KYC/KYB can affect payouts
A buyer payment succeeding does not prove that the seller is eligible to receive a payout.
Those are different lifecycle stages.
Marketplace infrastructure may have successfully:
accepted the buyer payment
allocated the seller's economic entitlement
and:
recorded a seller balance
while the seller still lacks the verification status required for payout under the actual marketplace/provider arrangement.
Therefore:
seller entitlement ≠ payout eligibility.
The broader marketplace lifecycle in the brief deliberately places identity/business verification before later payout eligibility and payout delivery.
A hypothetical seller-verification example
A marketplace has a business seller:
Atlas Studio Ltd.
The seller submits:
company name;
registration identifier;
business address;
representative details;
ownership information;
payout account.
The business registry information verifies successfully.
But one relevant person's information cannot yet be verified under the marketplace/payment-provider policy.
The seller's states become:
business_record VERIFIED
representative VERIFIED
ownership_review PENDING
marketplace_seller CONDITIONALLY_ACTIVE
payout_eligibility RESTRICTED
Customers can therefore see a marketplace state that appears healthy while operations sees:
payout restriction due to incomplete verification.
The wrong architecture exposes only:
Seller approved = true
and later creates a mystery:
Why wasn't the seller paid?
The better architecture records which state blocked payout and why.
Verification failure should have reason codes
A seller should not encounter:
Verification failed. Contact support.
when the underlying problem is machine-readable.
Useful internal categories might include:
IDENTITY_INFORMATION_INCOMPLETE
IDENTITY_DOCUMENT_UNSUPPORTED
DOCUMENT_EXPIRED
DOCUMENT_UNREADABLE
BUSINESS_NOT_FOUND
BUSINESS_DETAILS_MISMATCH
OWNERSHIP_INFORMATION_INCOMPLETE
REPRESENTATIVE_AUTHORITY_UNCONFIRMED
ADDRESS_MISMATCH
ADDITIONAL_INFORMATION_REQUIRED
MANUAL_REVIEW_REQUIRED
PROVIDER_RESTRICTION
REGULATORY_RESTRICTION
UNKNOWN
Do not expose every internal compliance signal verbatim to sellers.
But give operations enough structured information to route the exception and give the seller an accurate next step where disclosure is appropriate.
Document collection and verification are not the same thing
A marketplace may possess a copy of a business certificate.
That means:
document received.
It does not automatically mean:
business verified.
Verification may use, depending on the applicable workflow:
document validation;
official registry information;
electronic identity data;
payment-provider sources;
other reliable data.
EU DSA trader-traceability rules provide one concrete example: Article 30 contemplates checking trader information using official online databases or reliable supporting documents rather than treating submission itself as conclusive verification.
The operating system should therefore distinguish:
COLLECTED
VERIFIED
UNVERIFIED
CONFLICT
EXPIRED
for important data elements.
International KYB is fundamentally a data-normalization problem
The phrase:
“Upload your incorporation certificate”
sounds global.
The underlying data is not.
As a marketplace expands, variation can appear in:
business entity types;
registration numbers;
identity-document formats;
local scripts;
company names;
registered-address structures;
business registries;
ownership records;
representative titles;
document languages;
date formats;
address evidence;
government identifiers.
The brief specifically requires international workflows to account for differences in accepted documents, company registries, identification formats, legal structures, and address standards.
That is why the scalable data model should store concepts such as:
legal entity name
rather than assuming:
Company Name Ltd.
and:
registration identifier
rather than assuming every country has the same company-number structure.
Registry infrastructure changes too
A marketplace cannot assume that country verification logic is static.
The UK's Companies House regime is a current example. Mandatory identity verification for directors and people with significant control began on November 18, 2025, and Companies House was publishing implementation statistics throughout 2026.
That does not create a universal marketplace requirement.
It demonstrates something operationally important:
Official identity and business-information systems themselves evolve.
Country logic should therefore be versioned.
Treat country requirements as policy configuration
Avoid code like:
if seller_country == "X":
require_document_A()
require_document_B()
scattered through ten services.
A stronger model looks like:
seller_profile
↓
policy_engine
↓
country
seller_type
legal_entity_type
payment_provider
payout_route
risk_tier
↓
required_information_set
↓
verification_workflow
Now a rule can change without rewriting the entire onboarding experience.
Screening is a separate control from identity verification
A seller can prove:
“I am this person.”
That does not answer every compliance or risk question.
Depending on the applicable framework, another stage may assess whether the individual or entity appears on sanctions or other relevant watchlists.
Those are different controls:
identity verification
asks:
Who is this?
while:
screening
asks:
Does this verified identity match a person/entity that triggers another compliance action?
For U.S.-relevant sanctions obligations, for example, OFAC maintains its own current sanctions-list service and updates designated-person information continually. Marketplace obligations depend on jurisdiction and transaction context, so OFAC should not be presented as a global marketplace screening rule.
Verification does not necessarily end at onboarding
Seller information changes.
A company can:
change name;
change address;
replace representatives;
change beneficial owners;
change business activity;
change payout account;
restructure;
enter a new market.
The payment-provider relationship can change too.
The marketplace therefore needs a way to respond when information that supported the original verification is no longer reliable.
This principle appears in formal financial due-diligence frameworks as well: FinCEN's current CDD material includes ongoing monitoring and risk-based information updates for the financial institutions within that rule's scope.
Do not turn that specific U.S. framework into a universal marketplace re-verification schedule.
Instead design for events that can trigger re-evaluation.
Build verification triggers, not only expiration dates
Possible triggers—depending on the marketplace's actual obligations and provider model—include:
OWNERSHIP_CHANGED
REPRESENTATIVE_CHANGED
LEGAL_NAME_CHANGED
REGISTERED_ADDRESS_CHANGED
PAYOUT_ACCOUNT_CHANGED
PAYMENT_PROVIDER_REQUEST
MATERIAL_RISK_CHANGE
PERIODIC_REVIEW_DUE
DOCUMENT_EXPIRED
DATA_SOURCE_CONFLICT
REGULATORY_POLICY_CHANGED
The point is not that every seller must experience every trigger.
The point is that the marketplace should be able to express them.
What breaks at 50,000 sellers?
At 50 sellers, one compliance analyst can remember that:
Seller 23 needs another certificate.
At 50,000 sellers, memory becomes infrastructure.
The brief identifies the scale failure modes directly: manual queues, incomplete information, repeated document submissions, inconsistent seller communication, fragmented systems, and support workload.
The operational problems compound.
Manual review becomes a queue-management problem
Manual review is not automatically bad.
Undefined manual review is.
Every exception should have:
reason
owner
priority
age
required next action
seller communication state
and:
resolution status.
Measure:
verification manual-intervention rate
and:
manual-review queue age.
Resubmissions become a feedback problem
If 20% of one seller cohort repeatedly submits unacceptable documents, the problem might not be seller quality.
It might be:
unclear instructions;
wrong localization;
unsupported document assumptions;
data-entry formatting;
poor upload UX;
provider requirement not explained.
Measure resubmission by:
country
seller type
document/data requirement
verification provider
and:
failure reason.
Do not invent a universal acceptable resubmission rate.
Seller communication becomes part of compliance operations
A weak message says:
Verification failed.
A useful message—where appropriate and permitted—says:
We need additional information to complete verification. Your payout eligibility remains restricted until the requested information has been reviewed.
Seller communication should distinguish:
information needed
from:
verification rejected
from:
temporary manual review
from:
payout restricted.
Those states have very different operational consequences.
Support must not invent the verification reason
Seller-support agents need controlled visibility into:
verification status;
requested next action;
payout impact;
date of latest seller submission;
whether review is automated or manual;
whether escalation is available.
They should not need to interpret raw compliance-provider output or guess why a payout stopped.
Design the marketplace around verification state
A scalable marketplace should answer these questions without engineering investigation:
What exactly is incomplete?
Not:
seller verification
but:
business-registration verification, for example.
Which participant made the decision?
Was it:
marketplace policy;
payment provider;
acquiring partner;
another verified source?
Can the seller resolve it?
What information is needed?
Can the marketplace override it?
Often different controls will have different escalation/override rules.
What does it block?
seller activation?
payment acceptance?
payout?
only a specific payout route?
When will it be reviewed again?
If another event is required, make that state explicit.
A Marketplace Seller Verification State Model
A practical implementation can maintain several related states.
Dimension
Example states
Seller lifecycle
Applicant / Active / Suspended / Closed
Identity verification
Not required / Pending / Verified / More information / Failed
Business verification
Not applicable / Pending / Verified / More information / Failed
Ownership verification
Not applicable / Pending / Verified / Review
Screening/risk
Clear / Review / Restricted
Payment account
Not created / Pending / Active / Restricted
Payout eligibility
Ineligible / Pending / Eligible / Restricted
Information freshness
Current / Update required / Review due
Do not expose all of these to sellers exactly as written.
Internally, however, they prevent the ambiguous state:
“Seller active, but money won't move.”
What should marketplaces measure?
The most useful marketplace KYC/KYB metrics are operational rather than vanity metrics.
Seller verification completion rate
Completed verification journeys
÷
eligible seller verification journeys.
Define what “completed” means.
Verification success rate
Sellers reaching the merchant-defined verified state
÷
sellers receiving a verification decision.
Separate abandonment from rejection.
Median and percentile verification time
Measure from a clearly defined starting event to a clearly defined decision event.
Track P50/P90 or another appropriate distribution rather than only the average.
Straight-through verification rate
Seller cases resolved without manual intervention
÷
eligible verification cases.
A high value is not automatically desirable if controls become weaker, so pair it with quality and exception measures.
Manual review rate
Cases requiring human review
÷
eligible cases.
Segment by country, entity type, provider and reason.
Information resubmission rate
Cases requiring seller resubmission
÷
cases entering verification.
Again, segment by cause.
Payout restriction due to verification
Sellers whose payout state is currently restricted for a verification-related reason.
Measure both:
count
and:
seller payable balance/value affected, where appropriate.
Reverification volume
Sellers entering an update/review workflow after initial approval.
This becomes increasingly important as the seller base matures.
Seller-support contacts related to verification
A rising support rate can reveal poor state visibility or poor instructions even when the underlying verification engine works correctly.
Questions to ask a payment provider
A marketplace evaluating infrastructure should ask operational questions, not simply:
“Do you support KYC?”
Ask:
Which seller/entity types and countries can you support?
Which party determines the required verification information?
Which data is required by country and seller type?
How are beneficial owners/controllers handled?
Can requirements be retrieved dynamically through an API or hosted onboarding flow?
What verification states and reason codes are exposed?
Are state changes delivered through webhooks/events?
Can seller activation and payout eligibility be controlled independently?
What happens when a seller changes ownership or payout information?
Which events trigger re-verification?
How are manual-review exceptions represented?
Who communicates requests for additional information to the seller?
Which payout functions are restricted while verification is incomplete?
How are seller IDs mapped to payment accounts, balances and payouts?
What information can the platform retain or display to its own operations team?
What happens to seller/payment data if the marketplace changes providers?
Those questions reveal architecture.
A checkbox labeled:
KYC supported
does not.
These public materials support a narrow statement:
They do not by themselves establish:
one universal Marketplace KYC/KYB workflow;
country coverage for seller verification;
exact seller document requirements;
beneficial-owner thresholds for every seller type;
sanctions/PEP screening functionality for marketplace sellers;
seller re-verification rules;
payout restrictions by seller verification state;
automatic registry checks;
marketplace-level manual-review tooling.
Marketplace KYC and KYB is a workflow problem
A marketplace verification system has not scaled because it can upload passports.
It has scaled when it can answer, for every seller:
Who or what are we verifying?
Which policy applies?
Why does that policy apply?
What information is missing?
Which evidence supports the result?
Who made the decision?
Can the seller transact?
Can the seller be paid?
What happens when their information changes?
What happens when verification fails?
Can support explain the next step without asking engineering?
At 50 sellers, exceptions can live in people's heads.
At 50,000 sellers, exceptions become the system.
The marketplace therefore needs more than KYC and KYB checks.
It needs a seller-verification operating model in which country rules, seller types, beneficial ownership, payment-provider requirements, seller state, payout eligibility, exceptions, evidence, and ongoing updates remain connected.
That is the difference between a verification form that works at launch and verification infrastructure that still works when the marketplace scales.
This article provides general information and does not constitute legal, regulatory, compliance, financial, tax, accounting, or commercial advice. Marketplace operators should verify the laws, payment-provider requirements, acquiring arrangements, sanctions obligations, identity and beneficial-ownership requirements, payout restrictions, and seller-verification rules applicable to their specific jurisdictions, business model and money flow with qualified advisers and the relevant providers and authorities.
🙂 🙂 🙂 🙂 🙂 🙂 🙂
A. Concise interpretation of the editorial brief
Merchant problem: A marketplace needs to onboard and pay sellers but encounters overlapping language around KYC, KYB, beneficial ownership, payment-provider underwriting, identity verification, sanctions controls, and jurisdiction-specific requirements.
Evidence anchor: KYC and KYB are related verification processes, but marketplace seller verification is not one universal checklist. The information required depends on seller type, jurisdiction, payment flow, payment partner, regulatory structure, and risk profile.
Editorial position: The difficult part is not collecting documents. It is operating a verification system that can decide which information is required for which seller, handle exceptions, keep information current, and coordinate verification status with seller activation and payout eligibility.
Critical distinction: Keep four sources of requirements separate:
legal/regulatory obligations;
payment-provider/acquirer requirements;
marketplace risk controls;
operating best practices.
The brief explicitly prohibits presenting one set of KYC/KYB requirements as universally applicable to every marketplace.
Lifecycle stage: Seller onboarding → identity/business verification → activation → seller balance → payout eligibility → ongoing monitoring/reverification.
Merchant decision: What information must we collect and verify for this seller, who decides whether it is sufficient, what happens when verification is incomplete, and which seller/payment/payout states must change when new information arrives?
Selected operating model: A Marketplace Seller Verification State Machine, supported by a Seller-Type Verification Matrix and exception-queue metrics.
SEO / EDITORIAL / PRODUCTION NOTES — NOT PART OF THE ARTICLE
Recommended SEO title
Marketplace KYC and KYB: Seller Verification Explained
Meta title
Marketplace KYC & KYB: Seller Verification Guide
H1
Marketplace KYC and KYB: What Platforms Need to Know About Seller Verification
Keep the brief's H1.
Meta description
Learn how marketplace KYC and KYB work, how individual and business seller verification differ, why beneficial ownership matters, how verification affects payouts, and what breaks at scale.
Suggested URL slug
/marketplace-kyc-kyb/
Suggested full architecture:
/solve/operations-that-dont-scale/marketplace-payout-operations/marketplace-kyc-kyb/
marketplace KYC
Secondary keywords
marketplace KYB
KYC for marketplaces
KYB for marketplaces
seller KYC
seller KYB
marketplace seller verification
merchant KYC marketplace
business verification marketplace
marketplace compliance sellers
These are the targets assigned by the brief.
Long-tail opportunities
what is KYC for marketplace sellers
difference between marketplace KYC and KYB
do marketplaces need KYC for sellers
marketplace beneficial owner verification
KYC before seller payout
why marketplace seller verification failed
KYB individual vs business seller
marketplace seller payout verification
ongoing KYC for marketplace sellers
seller verification across countries
Related semantic entities
seller
platform
marketplace payments
identity verification
business verification
beneficial owner
ultimate beneficial owner
company registry
customer due diligence
payment provider
acquirer
seller balance
payout eligibility
sanctions screening
seller onboarding
ongoing monitoring
payout restriction
seller account
verification status
Merchant of Record
Recommended excerpt
Marketplace KYC and KYB are not one universal seller-verification checklist. Individual and business sellers can require different information, beneficial ownership can introduce additional natural-person verification, and payment-provider or legal requirements can vary by jurisdiction and money flow. Scalable marketplaces therefore need a verification state machine that connects seller information, exceptions, approval, ongoing updates and payout eligibility.
Featured-answer block
Marketplace KYC generally refers to identifying and verifying individual sellers or relevant natural persons, while marketplace KYB generally refers to verifying a seller business, its legal existence and relevant ownership or control. A business seller can require both KYB for the entity and KYC for relevant people. Exact requirements depend on jurisdiction, seller type, payment flow, provider and regulatory model; there is no single universal marketplace checklist.
FAQ section
What is marketplace KYC?
Marketplace KYC generally refers to identity-verification and related due-diligence controls applied to individual sellers or other relevant natural persons in a marketplace payment relationship. The exact process and legal basis vary by operating model and jurisdiction.
What is marketplace KYB?
Marketplace KYB generally refers to verification of a seller business, potentially including legal existence, registration information, business details, authorized representatives and relevant ownership/control information.
What is the difference between KYC and KYB?
KYC primarily concerns natural persons. KYB primarily concerns businesses or other legal entities. They frequently interact because verification of a company can require information about natural persons who own, control or represent it.
Do marketplaces need KYC for every seller?
There is no universal rule saying every marketplace globally must perform the same KYC process for every seller. Requirements depend on jurisdiction, marketplace model, seller type, payment flow and provider/acquirer structure.
What information is collected during seller verification?
It can include individual identity information, business registration details, addresses, representatives, ownership/control information, payout information and supporting evidence. The actual information set should be determined by the applicable verification framework rather than copied from a generic checklist.
What is a beneficial owner in marketplace KYB?
FATF defines beneficial ownership of a legal person around the natural person or persons who ultimately own or control that entity. Specific legal tests and ownership thresholds depend on the relevant regime.
Why can a seller's payout be blocked after onboarding?
Because seller activation, verification status and payout eligibility can be separate states. A platform or payment provider may require additional verification or another condition before payout under the applicable arrangement.
Does KYC/KYB end after onboarding?
Not necessarily. Seller details, ownership, representatives and payout information can change, and some regulatory or provider frameworks involve ongoing monitoring or updated information. A marketplace should therefore design for re-verification and information-refresh events rather than assuming approval is permanent.
Suggested internal links
The cluster map assigns this article the following direct relationships.
Contextual anchor
Destination
Boundary
complete seller activation workflow
Seller Onboarding
Owns onboarding beyond verification
how verified sellers receive funds internationally
International Seller Payouts
Owns payout corridors/rails
who carries financial responsibility
Merchant Liability in Marketplaces
Owns liability
whether another commercial model changes responsibilities
Merchant of Record for Marketplaces
Owns MoR operating model
Also link the cluster pillar Marketplace Payments Explained once near the lifecycle discussion.
Recommended visual 1 — Seller Verification State Machine
APPLICATION
↓
CLASSIFY SELLER
person / business / structure
↓
APPLY POLICY
jurisdiction + payment flow + provider
↓
COLLECT INFORMATION
↓
VERIFY
├── verified
├── more information
├── manual review
├── restricted
└── failed
↓
SELLER ACTIVATION
↓
PAYOUT ELIGIBILITY
↓
ONGOING UPDATE / REVERIFICATION
Alt text:
Marketplace KYC and KYB seller verification lifecycle showing seller classification, policy selection, information collection, verification, exception review, activation, payout eligibility and ongoing reverification.
Recommended visual 2 — Individual seller vs business seller
INDIVIDUAL SELLER
│
└──→ identity / person verification
↓
payout eligibility
BUSINESS SELLER
│
├──→ business / entity verification
│
├──→ ownership / control analysis
│
└──→ relevant natural-person verification
↓
payout eligibility
Add:
Illustrative framework — actual requirements vary by jurisdiction/provider.
Recommended visual 3 — Four sources of verification requirements
SELLER VERIFICATION POLICY
LEGAL / REGULATORY ───────┐
│
PAYMENT PROVIDER ─────────┼──→ Required information
│ + verification action
MARKETPLACE RISK ─────────┤ + payout effect
│
OPERATING POLICY ─────────┘
Headline:
Know why you are collecting each field.
Recommended visual 4 — Seller state ≠ payout state
SELLER
Active
│
├── Verification: additional information required
│
└── Payout: restricted
$8,400 seller balance
≠
$8,400 payout eligible
Use an explicitly hypothetical amount.
Operational scorecard
Recommended metrics:
Metric
Purpose
Seller verification completion rate
Funnel health
Verification success rate
Decision outcome
Median/P90 verification time
Speed and outliers
Straight-through verification rate
Automation
Manual intervention rate
Operational burden
Resubmission rate
Seller friction/data-quality issue
Manual queue age
Compliance operations backlog
Verification support-contact rate
Communication quality
Verification-restricted seller count
Operational exposure
Value blocked by verification state
Financial significance
Reverification volume
Ongoing workload
Time to resolve payout restriction
Seller experience
Unknown/error-state rate
Data-model quality
No industry benchmark should be added without reliable evidence.
Authoritative external sources
FATF should be the primary global conceptual reference for beneficial ownership, customer due diligence and risk-based AML/CFT standards. Its current glossary and recommendations are especially useful for separating beneficial ownership from direct legal ownership.
FinCEN is useful as a jurisdiction-specific example of why sellers should not be subjected to a copied global rule: the U.S. CDD Rule applies to specified covered financial institutions and its beneficial-ownership mechanics have been updated through 2026 guidance and relief.
EUR-Lex / EU Digital Services Act is valuable for distinguishing AML/KYC terminology from marketplace-specific trader traceability. Article 30 imposes defined trader-information and reliability-assessment obligations within its own scope.
Companies House provides a current example of how official business/identity-verification infrastructure changes over time; UK director and PSC identity-verification requirements entered their mandatory phase in November 2025.
OFAC is an appropriate U.S. primary source if sanctions screening is discussed for a U.S.-relevant workflow. Its Sanctions List Service is the current source for official list data.
Optional structured data
Use:
Article
BreadcrumbList
Google's current Search documentation, updated in 2026, continues to list Article and Breadcrumb among supported structured-data types. Breadcrumb markup can describe the article's site-hierarchy position; valid markup still does not guarantee a rich-result appearance.
Proposed author and reviewers
Author: Marketplace payments / compliance-operations specialist.
Primary reviewer: Payments-compliance specialist with marketplace onboarding experience.
Legal/regulatory reviewer: Counsel or compliance reviewer familiar with the jurisdictions actually discussed.
Operational reviewer: Marketplace seller-operations lead.
Payments reviewer: Marketplace payment/payout specialist.
Do not imply these reviews have occurred until named reviewers complete them.
Key claims to fact-check immediately before publication
Legal/regulatory
Verify:
which marketplace/trader rules apply to the intended jurisdictions;
whether the platform itself has KYC/CDD obligations;
whether obligations arise instead through its payment provider/acquirer;
seller versus consumer classification;
sanctions obligations;
applicable ongoing-monitoring requirements;
current beneficial-ownership rules;
current DSA scope/exemptions if cited.
Beneficial ownership
Verify:
applicable definition;
ownership/control test;
thresholds;
exemptions;
entity types;
treatment of indirect ownership;
control persons;
required natural-person verification.
Do not publish one global percentage.
Seller identity/business information
Verify:
required fields;
accepted evidence;
supported languages/scripts;
registry sources;
expiry rules;
electronic identity support;
data-retention requirements;
mismatch handling.
Payout consequences
Verify:
whether verification gates activation, payment acceptance, balance availability or payout;
whether a seller can accumulate a balance while restricted;
whether restrictions differ by payout route;
what happens to funds when re-verification fails.
Ongoing verification
Verify:
trigger events;
periodic review if applicable;
ownership-change workflow;
representative-change workflow;
payout-account-change workflow;
provider-driven review;
suspension/restriction behavior.
Amber-flag claims
Avoid:
“All marketplaces must KYC every seller.”
Too broad.
“Marketplace KYB always requires documents X, Y and Z.”
No universal checklist.
“25% ownership is the global UBO standard.”
Incorrect universalization.
“KYC is for people; KYB is for companies, and that's the whole process.”
Too simplistic because company verification can require person-level verification.
“A registry match proves a business is safe.”
Business existence and risk/compliance assessment are different questions.
“Verification is complete forever after onboarding.”
Not safe.
“KYC approval means payouts are automatically enabled.”
Not necessarily.
“Payout restriction means seller verification failed.”
Other payout controls may exist.
“Sanctions screening is KYC.”
Related control, different question.
“The platform is always legally responsible for seller verification.”
Depends on the legal/payment operating model.
“The PSP handles all compliance.”
Unsupported and often an oversimplification.
“Merchant of Record eliminates seller-verification responsibility.”
No universal rule.
Not established.
Do not use that legacy support content as a universal/current marketplace rule without internal verification.
collects business and relevant beneficial-owner/representative information for its own merchant-account relationships;
may request additional merchant information during the relationship and requires account information to remain current under the public Terms reviewed;
publicly documents Bridge OAuth marketplace/vendor project infrastructure, including commission configuration and a sample vendor compliance_status.
seller KYC;
seller KYB;
beneficial-owner verification;
hosted seller onboarding;
API-based seller verification;
country/entity-specific requirement discovery;
registry verification;
document verification;
sanctions screening;
PEP screening;
seller risk scoring;
manual review;
reason codes;
seller-facing additional-information requests;
verification webhooks;
re-verification;
payout gating;
seller-level payout holds;
seller-bank-account verification;
marketplace compliance dashboards;
seller verification reporting;
data retention/access;
exact country coverage;
exact supported seller/entity types.
Need help narrowing down payment options?
Answer a few questions about your business and compare the capabilities that matter to you.
Explore matching options ↗