Blog
A paper collage of a shop, two proprietors and the exposed roots of a large tree.

September 14, 20265 min readАдминистратор

Merchant onboarding: resolving contradictions in KYB

A practical way to request, review and refresh merchant documents without treating one provider’s checklist as universal law.

A merchant presents three names: one on the website, another in the register and a third on the payout details. Sometimes the business structure explains them. Sometimes the application is wrong. The number of uploaded documents does not tell the reviewer which explanation applies. Verification becomes useful when every request resolves a specific contradiction.

Useful onboarding starts with questions, then identifies evidence that answers them. This article proposes an operational framework; the actual requirements must come from applicable law, the payment provider and the business model.

Separate the business from the people behind it

In everyday payment operations, KYB describes checking a business, while KYC often describes checking the relevant individuals. These labels do not create a single global document list. FATF’s recommendations are international standards implemented through national measures adapted to local circumstances. FATF explains that distinction.

Build the review around four questions: Does the entity exist? Who controls it? Who may act for it? What commercial activity will the payment service support? An incorporation record may help with the first question; it does not, on its own, answer the other three.

Ownership and authority also differ. A person signing a contract might be an authorised manager without owning the company. FATF’s glossary defines beneficial ownership by reference to the natural persons who ultimately own or control a customer. Avoid treating a company listed as shareholder as the end of that inquiry. See the FATF definition.

Give each request a purpose

  • Entity evidence: identify the legal name, registration reference and relevant registry.
  • Ownership evidence: explain the ownership chain and the people whose verification the applicable rules require.
  • Authority evidence: establish why the representative can act for this entity.
  • Business evidence: describe products, fulfilment, customer locations and the role of any other sellers.
  • Payout evidence: resolve who owns the proposed destination and whether it fits the approved contractual arrangement.

This is a question map, not a demand to collect every possible document. Stripe, for example, publishes verification requirements that depend on the connected account’s configuration, including country and business type. Its implementation is an illustration, not a substitute for another provider’s instructions. Stripe’s verification guidance.

Resolve a seller’s mismatch

In this hypothetical case, the website uses a trading name, the application uses the legal company name, and the payout request names another business. The first two may be consistent if the trading relationship is explained. The third requires a specific answer before activation.

A useful follow-up says: “Please explain the relationship between the applicant and the proposed payout recipient, and provide the evidence requested in our secure portal.” It identifies the unresolved issue without implying wrongdoing or offering ways around a requirement. The reviewer records the answer, the checked source and the reason for the final decision.

Do not make sales staff improvise exceptions in private chats. A documented escalation path lets someone with the right responsibility decide whether the arrangement is supported. If it is not, the result should be a clear explanation rather than an endless series of document requests.

Distinguish incomplete evidence from conflicting evidence. An unreadable page and two current records naming different owners need different follow-up questions. Record which problem remains unresolved rather than requesting another unspecified document.

Design a review people can complete

Tell applicants which pages are needed, accepted formats, how to correct an error and where sensitive evidence belongs. Show whether the case is awaiting documents, under review or ready for activation. These states reduce repeat submissions and prevent support from promising approval prematurely.

Give the applicant one accountable contact. That person need not approve the case personally, but should know who owns the question and which clarification is actually needed, especially when sales, support and risk all participate.

Approval needs a defined scope

Summarise the approved activity in a short operating profile: which entity sells which goods, to whom, through which channels, and which entity receives settlement. This is a working model for the team rather than a substitute for the contract. If sales adds a different business line next month, the profile makes the change visible.

Identify events that require reconsideration, such as a new payout recipient, owner, website or fulfilment model. Applicable rules determine the exact list and mandatory checks. The operational recommendation is simpler: material changes should reach an accountable reviewer rather than silently overwrite a CRM field. Preserve the previous value, new value and decision basis within the approved retention policy.

A file that survives the reviewer’s holiday

Give a colleague a completed application without a verbal briefing. They should be able to distinguish applicant statements, externally verified facts and the reviewer’s judgement. Everything looks fine, spoke to the founder merges these layers and transfers poorly between shifts. Record what was established, which source supports it and which question remains open.

Document exceptions to the internal workflow separately: who may approve them, why the case is acceptable and what restriction addresses the remaining risk. This does not permit bypassing law or provider requirements. Commercial pressure for a quick launch should be visible, not a hidden basis for approval. Measure onboarding time alongside repeated information requests: a fast first email means little if the applicant is then asked three times for the same document.

Close the file with a short answer: which entity and activity were approved, which sources support the decision, and which change triggers review again. The remaining pages should help reconstruct that answer.

Sources

  1. 1.fatf-gafi.org/en/publications/Fatfrecommendations/Fatf-recommendations.html
  2. 2.fatf-gafi.org/en/pages/fatf-glossary.html
  3. 3.docs.stripe.com/connect/required-verification-information

Comments · 0

No comments yet — be the first.

Log in · log in to leave a comment.