KYC, KYB, and source of funds: payment verification explained

A payment service asks for identification. A business application requests ownership information. Later, an otherwise ordinary client payment needs an invoice or an explanation of where the money came from.

These requests can feel repetitive until you separate the questions being answered.

KYC, business verification, and transaction review help a provider understand who is using the service and how it is being used. Completing one check does not necessarily answer every question about a business, a payment, or a destination.

This guide explains the concepts and how to respond to legitimate requests. Requirements vary by jurisdiction, provider, customer, and product; it is not a universal compliance checklist or a promise of approval.

What do KYC and KYB mean?

KYC commonly means “know your customer.” In customer-facing language it often refers to identity verification, although customer due diligence can include understanding the relationship and activity as well.

KYB commonly means “know your business.” It describes checks concerning a business customer, including its identity, activities, authorised representatives, and relevant ownership or control information.

The precise terminology is not identical everywhere. The Financial Action Task Force sets international standards covering customer due diligence and related measures, which jurisdictions implement through their own frameworks. FATF standards should not be presented as one directly applicable worldwide onboarding form. FATF: The Recommendations.

Ask the provider what its request is intended to establish and which documents or information it accepts.

Separate the questions behind the checks

Check	Main question	What it does not automatically establish
Individual identity	Who is this person?	Eligibility for every financial product
Business identity	What legal entity is applying?	That every activity or corridor is permitted
Ownership and control	Which people ultimately own or control the relevant entity?	That one contact person is the only relevant person
Authority	Can this person act for the customer?	Ownership of every proposed payout destination
Source of funds	What underlying activity produced the relevant money?	The origin of the person’s entire wealth
Transaction review	Does this payment fit the supported, understood activity?	Blanket approval of future payments

Understanding the distinction makes a response more useful. An incorporation document may establish the company name but not explain the source of a particular client payment.

Why a business application asks about people

A legal entity can have shareholders, directors, authorised representatives, and people exercising control. Those roles can overlap, but they are not interchangeable.

Beneficial-ownership checks look beyond the company label to relevant natural persons under the applicable framework. FATF’s guidance discusses transparency and identifying beneficial owners of legal persons. FATF: Beneficial ownership of legal persons.

Do not assume a universal percentage threshold or that only the person completing the form matters. The provider should specify the information required for the actual ownership structure and jurisdiction.

If another company owns the applicant, the structure may need explanation through additional layers. Provide accurate records rather than simplifying away an owner to fit the form.

Legal name, trading name, and addresses can answer different questions

A business may trade under a brand while contracting under a different legal name. It may have a registered address and an operating location that are not the same.

Enter each field according to its definition. Do not substitute an incorporation address for the actual operating address merely because it is easier to document.

If information differs between records, explain the legitimate reason and provide the requested evidence. A recent move, name change, or updated ownership record may require clarification.

Keep profile information current after approval. An old record can make a later payment harder to understand even if the original application was accurate.

Source of funds is more than the sending bank’s name

Source of funds concerns the underlying origin of money relevant to the transaction or relationship. Saying “it came from my bank account” may identify the immediate transfer path without explaining how the money was earned or obtained.

Source of wealth is a broader question about how a person’s overall wealth arose. AUSTRAC’s public guidance distinguishes these concepts in the Australian regulatory context. The distinction is helpful, while the legal requirements remain jurisdiction-specific. AUSTRAC: Proof of source of funds and wealth.

For a freelancer, relevant evidence might connect a client contract, invoice, and payment. For a seller, it might connect marketplace sales and a payout statement. The provider decides what evidence is needed and acceptable for the case.

Build an evidence chain for the actual payment

Consider a fictional agency receiving EUR 8,000 from a client. A useful explanation could identify the contracting parties, the project, the invoice, and the payer’s payment record.

If the payer’s legal name differs from the client’s trading brand, explain that relationship with appropriate evidence. If a marketplace aggregates many orders into one payout, provide the relevant payout report rather than describing it as one ordinary customer invoice.

Keep the amounts and currencies consistent. If fees or conversion explain a difference, identify the relevant records instead of altering the invoice to match the final bank credit.

The reconciliation guide shows how to preserve this chain for normal operations as well as investigations.

Expect requirements to depend on the product and route

A provider can assess residence, business activity, customer type, payer type, destination, currency, asset, network, and transaction purpose.

Receiving details, local bank payouts, stablecoin transfers, and custody where offered can have different conditions. Approval for one does not imply unrestricted access to all the others.

A country listed as supported may still have route-specific or regional limitations. Review the actual product guidance and the options approved for your profile.

For Ostro, consult the country directory and use the options shown in your workspace. The directory provides context; it is not an individual eligibility decision.

Why a provider may ask again after onboarding

Customer information and payment activity can change. A new destination, different business activity, changed ownership, or transaction requiring clarification may prompt another request.

Ongoing review is a separate process from the initial application. It does not necessarily mean the original approval was an error or that the customer has done something wrong.

Ask what information is outstanding and which transaction or profile field it concerns. Respond through the relevant case rather than creating multiple accounts or unrelated support threads.

Do not split payments, misstate locations, or disguise the purpose to avoid review. That can undermine the accuracy of the information and breach the provider’s rules.

Submit documents through the approved channel

Use the provider’s known application, hosted verification flow, or secure upload method. Verify unexpected requests before following a link or sending personal documents.

Provide readable, current, complete documents in the requested format. If a translation or additional page is needed, ask what the provider accepts rather than guessing.

Do not edit substantive information, fabricate statements, or combine unrelated documents into a misleading record. If a record is outdated or incorrect, explain the issue and obtain the appropriate correction.

Avoid uploading credentials, authentication codes, private keys, or recovery phrases. They are not identity or source-of-funds documents.

Ask about privacy and retention when needed

A legitimate verification process should have an applicable privacy notice and an identifiable service relationship. Read who processes the information, the purposes described, and the available contact channels.

If the request seems broader than necessary, ask for clarification about the required scope. Do not redact fields the provider explicitly needs without agreeing an acceptable alternative, because the result may be unusable.

Keep your own copies securely according to appropriate business and legal requirements. Avoid distributing sensitive records across project chats or sharing them with a client merely because the client is waiting for payment instructions.

For Ostro privacy questions, use the published privacy policy and its contact details.

Interpret verification statuses carefully

“Submitted” means information has been provided. “In review” indicates an assessment is still underway. “Approved” or “verified” should be understood in the scope of the specific product and provider.

Do not promise a client receiving details or a payout option before it is actually enabled. A successful identity step may be followed by business, eligibility, or route checks.

If a request is declined or an option is unavailable, use the provider’s explanation and review process where offered. Support may not be able to disclose every detail or override the relevant restrictions.

Keep the distinction between application status and transaction status clear when asking for help. They can be blocked for different reasons and require different evidence.

Keep your internal vendor process separate

A business paying suppliers still needs its own commercial records: what was purchased, who approved it, which entity is owed, and which destination is authorised.

A supplier’s financial-provider approval does not replace that process. Conversely, your vendor approval does not compel a financial provider to accept the payment.

Use the international vendor-onboarding guide to connect the business relationship and payment instructions without duplicating a provider’s sensitive verification process unnecessarily.

How this fits Ostro’s payment model

Ostro’s workflow includes customer onboarding, identity verification, eligibility and sanctions checks, monitoring, records, and compliance escalation. Payment processing, conversion, custody where applicable, and settlement are provided through licensed financial partners.

Available receiving details and payout choices remain subject to eligibility, jurisdiction, compliance review, supported routes, and partner availability. This guide does not promise a fixed approval time or universal access after one check.

Use the Help Center for product-specific guidance and the approved verification process for submitting information.

Frequently asked questions

Does verified identity mean every payment will be accepted?

No. Transaction purpose, parties, route, destination, and other applicable conditions can require separate review.

Is source of funds the same as source of wealth?

No. The first concerns the underlying origin of relevant funds; the second is broader. The provider should explain which question it needs answered.

Can I use a personal account for a company’s application?

Do not substitute a different legal customer to bypass business verification. Use the account type and entity appropriate to the real activity and provider rules.

Can support guarantee approval if I provide every document?

No. Complete documents help the assessment, but approval depends on the actual eligibility and review outcome.