Skip to main content
MoonPay Enterprise supports two methods for onboarding business customers through KYB (Know Your Business) verification. Both follow the same onboarding lifecycle and collect the same underlying compliance data.

Hosted Link Flow

Create a Link identification and receive a URL. Your customer completes KYB verification in MoonPay Enterprise’s hosted interface. MoonPay Enterprise handles the entire collection, review, and approval process.

Programmatic Business API

Submit all KYB data directly via the API with a Business identification. You collect and provide company info, beneficiaries, documents, and the compliance questionnaire programmatically.
The simplest way to onboard a business customer. You create a Link identification and MoonPay Enterprise returns a URL where your customer completes the full KYB process through MoonPay Enterprise’s hosted interface. MoonPay Enterprise is fully responsible for collecting all required information, performing verification, and deciding on approval.
1

Create a business customer

POST /api/customers
The customer is created in SigningsRequired status under X-API-Version: 2026-08-01 or later, and in IdentificationRequired on earlier versions. See Create a new customer.
2

Present and sign the terms and conditions

Fetch the terms via GET /api/customers/{id}/required-signings and record acceptance via POST /api/customers/{id}/signings before creating the identification. The terms contain the data sharing agreement, so they come before KYB data collection.
3

Create a Link identification

POST /api/customers/{id}/identifications/v2
The response includes a url field. Pass this URL to your customer to begin the hosted KYB flow.
4

Customer completes hosted KYB

The customer opens the link and completes the flow in MoonPay Enterprise’s hosted interface, which collects company information, documents, beneficial ownership details, and the business questionnaire.Once the submission is complete, MoonPay Enterprise reviews the data, performs verification, and decides on approval. Track progress via webhooks or by polling the identification status.
5

Handle signings and activation

Once KYB is approved, MoonPay Enterprise checks that the terms have been signed. If not, the customer status is SigningsRequired: retrieve required signings, present them to the customer, and mark them as signed. See the onboarding lifecycle for details.

​
Programmatic Business API

For partners who collect KYB data within their own application, you can submit all business verification data directly via the API. This requires an outsourcing agreement with MoonPay Enterprise. You collect the company information, beneficial ownership details, identity documents, and the compliance questionnaire, then submit everything in a single API call.
1

Create a business customer

POST /api/customers
2

Present and sign the terms and conditions

Fetch the terms via GET /api/customers/{id}/required-signings and record acceptance via POST /api/customers/{id}/signings before creating the identification.
3

Create a Business identification

POST /api/customers/{id}/identifications/v2Submit the full KYB payload with type: "Business". Company identity, beneficiaries, and documents are nested under company_data (company fields sit under company_data.company_info). The company phone and the submitting device’s ip_address are top-level, and questionnaire carries a type discriminator (Generic for all company types except sole proprietorships, SoleProp for sole proprietorships). The example below shows a complete submission with one beneficial owner:
MoonPay Enterprise validates the submission synchronously. A complete submission is created as Processed and moves into verification. An incomplete submission — any country — is rejected with 400. See Incomplete Submissions. Track progress via webhooks or by polling the identification status.
Submit once. This endpoint is not an upsert, and every call that returns 201 creates a new identification record. Do not call it again to refresh status, or to correct a submission that was accepted. A 400 is the exception: nothing was created, so fixing the payload and submitting again is correct. See Resubmitting and Correcting a Submission.
4

Handle signings and activation

Same as the hosted flow. Once KYB is approved, MoonPay Enterprise checks that the terms have been signed. If not, the customer status is SigningsRequired: retrieve required signings, present them, and mark them as signed to activate the customer.

​
Incomplete Submissions

A Business submission must be complete to be accepted, in every country: when required company documents are missing, the request is rejected with 400 and must be resubmitted with the missing item — nothing is created. Complete submissions are created as Processed directly.
A 201 response means the submission was complete and accepted for verification. An incomplete submission never creates a record — it’s rejected with 400 instead. Check status on the returned identification: Processed means MoonPay Enterprise has everything it needs.
Sandbox approves business submissions at creation regardless of completeness. The reject-on-incomplete behavior occurs in production only.
A submission is rejected with 400 when:
  • A required document group is missing for the company’s region — including for a related company in the ownership structure. See Company Documents and, for US companies, Automatic Verification for US Companies.
  • The registration document is missing, for a sole proprietorship.
  • A beneficiary of a non-sole-proprietorship US company provides a DriverLicense, NationalId, ResidencePermit, or DigitalDriversLicense that isn’t US-issued (Passport is accepted from any country for these beneficiaries). DigitalDriversLicense is Brazil-issued only, so it’s never accepted for these beneficiaries.
These validations always reject the request with 400, regardless of country:
  • More than 4 company documents
  • A document that is not valid base64, exceeds 3 MB, or has an invalid country code
  • A document the verification provider cannot process, such as a corrupted file. The response includes the rejection detail. Fix the file before retrying. One exception: an error naming a blocked duplicate upload means the file is fine and a retry succeeds.
  • No root-level beneficiary holds the Director role, for any company other than a sole proprietorship — in every country, not just US. This is checked independently of the US attestation requirement below. See structure_invalid.
  • No root-level beneficiary owns 25% or more, and (if so) no root-level beneficiary owns 10% or more either, for any company other than a sole proprietorship — in every country. Together with the previous rule, this is why a Business submission can’t have zero beneficiaries, or only beneficiaries with no disclosed ownership at all. A beneficiary whose only role is Representative doesn’t count toward this — Iron never independently verifies a Representative-only beneficiary’s identity, so their disclosed share_percentage can’t count as ownership evidence. See structure_invalid.
  • A share_percentage outside 0-100, or combined shares of beneficiaries counted as qualifying owners (any UltimateBeneficialOwner, or any other beneficiary who isn’t Representative-only) above 100 for any company in the structure
  • A beneficiary whose only role is UltimateBeneficialOwner and whose share_percentage doesn’t meet the disclosure threshold for their company (or nested company): 25% if any beneficiary at that level owns 25% or more, otherwise 10% if any beneficiary there owns 10% or more, otherwise nobody at that level qualifies. Such a beneficiary has no other role to be reported under instead. A beneficiary below the threshold that also holds another role (for example Director) is accepted, but submitted without the UltimateBeneficialOwner tag. See ubo_share_below_threshold.
  • A missing tax_identification_number for a Director or UltimateBeneficialOwner person beneficiary, in any country, or for the proprietor of a sole proprietorship. The error identifies the beneficiary by its zero-based index in the beneficiaries array.
  • A ResidencePermit identity document, unless it’s US-issued and the beneficiary is at a US company
  • A DigitalDriversLicense identity document, unless it’s Brazil-issued
  • Invalid attestation data: more than one attesting party, an attesting party without the Director role or nested below the root, a missing or future attested_at, or beneficial-ownership data the generated CDD certification cannot render. See Company Documents.
400 responses on this endpoint return the reason as a plain string:

​
Resubmitting and Correcting a Submission

POST /api/customers/{id}/identifications/v2 is not an upsert. Every call creates a new identification record, and the newest record drives the customer’s status. Calling it a second time while the first is in flight resets the customer to IdentificationRequired and stops the older identification counting, even if it is approved later.
Once a submission is accepted, never re-call this endpoint to correct it, to add a missing document, or to check status. Each accepted call adds another identification to the customer, and a customer carrying several competing identifications needs manual reconciliation by MoonPay Enterprise before onboarding can finish.
Whether a second call is correct depends on what the first one returned. A 400 created nothing, so submitting again is the fix. A 201 created a record, so submitting again creates a competing one.
An Idempotency-Key does not protect you here. MoonPay Enterprise stores successful responses only, so a retry after an error runs the submission again, and a retry with a fresh UUID creates a second record either way. See Idempotency. The rule above is the control that prevents duplicates.

​
Example Scenarios

The following examples show the company_data.beneficiaries array for common ownership structures. All other fields (company_data.company_info, company_data.documents, questionnaire) remain the same as the full example above. The person objects below are abbreviated: a real submission also carries identity, tax_identification_number, and proof_of_address per beneficiary, as in the full example.
A company with a majority shareholder/director and a minority UBO:
When a legal entity owns or controls the company, give it the Shareholder role and pass a business beneficiary_info: an object with a single company_data field. It carries the full data for that entity: its company_info, its own beneficiaries, and its own documents. The natural persons who are UBOs through the corporate chain appear inside the nested entity:
Each corporate owner carries its own company_data.documents and beneficiaries. The same document groups and beneficiary requirements apply at every level of the structure. The natural persons who ultimately own 25%+ through the chain must appear as UBOs.

​
Business API Field Reference

The request envelope has four top-level fields beyond type:
These fields live under company_data.company_info.
The company_data.beneficiaries array contains one or more CompanyBeneficiary objects representing UBOs, directors, representatives, or corporate shareholders. Each business level holds up to 5 beneficiaries and at most one business beneficiary, and businesses nest at most two levels below the root company. The Director role is only valid on person beneficiaries, and each nested business beneficiary must include at least one person with the Director role. Requests outside these bounds are rejected with 400.

​
CompanyBeneficiary

The beneficiary_info field takes one of two shapes: PersonBeneficiaryInfo for an individual, or BusinessBeneficiaryInfo for a corporate owner, which carries a nested company_data. Unlike questionnaire, this object has no type discriminator: MoonPay Enterprise detects the variant from the fields you send.

​
PersonBeneficiaryInfo

Used when the beneficial owner is a natural person.

​
BeneficiaryIdentity

The identity object on a person beneficiary.

​
BusinessBeneficiaryInfo

Used when a beneficial owner is a legal entity (corporate shareholder). It carries a full company_data with the same shape as the top level, so the same information is collected at every level of the corporate structure.
Each corporate owner carries its own company_data.documents and beneficiaries. The same document groups and beneficiary requirements apply at every level of the structure. The natural persons who ultimately own 25%+ through the chain must appear as UBOs.

​
BirthPlace

​
Address

The company_data.documents array contains up to 4 CompanyDocParams objects. Each document is uploaded as a base64-encoded file. Structurally optional at submission, but an incomplete set for the company’s region is rejected with 400. See Company Documents for the groups required per region.

​
CompanyDocParams

​
Upload requirements

  • Maximum file size: 3 MB per document (after base64 decoding)
  • Maximum 4 documents per company. The limit applies separately to the root company and to each nested business beneficiary. More than 4 is rejected with 400.
  • Encoding: standard base64 (no data:application/pdf;base64, prefix)
  • Supported formats: PDF, JPEG, PNG

​
Document types

The BusinessQuestionnaire object is a required compliance questionnaire structured into three sections. Each section collects specific regulatory information about the business. Set type to Generic for all company types except sole proprietorships, or SoleProp for sole proprietorships.

​
business_details

Industry classification and operational information about the company.industry_type values: Agriculture, Automotive, BankingAndFinancialServices, ConstructionAndRealEstate, CryptocurrencyAndBlockchain, CryptocurrencyMining, DecentralisedFinance, NftPlatforms, CryptoPaymentProcessors, CryptoWalletProviders, CryptoExchanges, CryptoCustodyServices, EcommerceAndOnlineMarketplaces, EducationAndTraining, EnergyAndUtilities, EntertainmentAndMedia, GamingAndEsports, HealthcareAndPharmaceuticals, HospitalityAndTourism, InformationTechnologyAndSoftware, Insurance, LegalAndProfessionalServices, LogisticsAndTransportation, ManufacturingAndIndustrial, MetaversePlatforms, MiningAndNaturalResources, NonProfitAndCharitable, RetailAndWholesaleTrade, Telecommunications, VentureCapitalAndPrivateEquity, CasinosAndGambling, MoneyServiceBusinesses, SocialMediaAndNetworking, CrowdfundingPlatforms, RegTech, Otherindustry_type is deprecated but still accepted indefinitely. industry is the modern replacement, exposing Sumsub’s full industry taxonomy (~151 values, mirroring Sumsub’s own classification) in place of the 36 broad categories above, and is required from API version 2026-08-01 onward — before that version it stays optional and industry_type alone is sufficient. If a submission includes both fields, industry takes precedence and industry_type is ignored.estimated_annual_revenue values:

​
planned_activities

Information about the company’s intended account use and expected transaction patterns.purpose_and_intended_use values: ReceivingBusinessIncome, BusinessPurchasesAndExpenses, EmployeeAndContractorPayouts, EcommerceSales, TreasuryManagement, PaymentIntermediary, Investments, TaxPlanning, AssetProtection, Otherestimated_monthly_volume values:estimated_monthly_transactions values:

​
source_of_funds

Information about where the company’s funds originate.source_of_funds values: BusinessRevenue, ShareholderFunds, VcPrivateEquity, AssetSale, IcoProceeds, CryptoActivityProceeds, LoanProceeds, Other

​
Standard KYB Requirements

​
Company Information

  • Country
  • Company name
  • Registration number
  • Company registration address
  • Company operations address
  • Type of entity
  • Date of registration
  • Website
  • Company email
  • Tax ID

​
Company Documents

Company documents fall into four groups. Which groups the root company needs depends on where it’s registered and its type. A nested business beneficiary (a Shareholder that’s a legal entity) always needs just two groups — Company Details and Ownership Structure — regardless of where it’s registered or what the root company needs. A submission missing a required group is rejected with 400, in every country, and must be resubmitted with the missing item. See Incomplete Submissions.
Every US company submission (except sole proprietorships) must designate one root person beneficiary holding the Director role as the attesting party: set attesting_party: true and attested_at on them, after presenting the collected beneficial-ownership information to them for confirmation. MoonPay Enterprise generates a CDD certification (31 CFR 1010.230) from the submitted data and files it, satisfying the Ownership Structure group without a separately uploaded document. This is mandatory, not optional — a submission missing an attesting party, or one that cannot produce the certification (missing share_percentage on a beneficiary the certification must list, no SSN or tax/identity number for a listed US person, or more than two levels of beneficiaries), is rejected with 400. The certification’s ownership section lists whichever beneficiaries own 25% or more; if nobody does, it falls back to listing whoever owns 10% or more instead. Every company must have at least one beneficiary meeting one of those two thresholds — see the qualifying-owner requirement below.

​
Automatic Verification for US Companies

Eligible US companies (except sole proprietorships) are checked automatically against official company records as part of verification. When MoonPay Enterprise can confirm the company this way, the Company Details document isn’t required — the automatic match satisfies it. This happens without any extra input from you; we still recommend sending the Company Details document anyway, since it’s the fastest way to speed up review if automatic verification isn’t possible for a given company. The CDD attestation above is still required either way, whether or not automatic verification succeeds.
Accepted document types:
  • Incorporation certificate (IncorporationCert)
  • Excerpt from a state company registry (StateRegistry)
  • Certificate of good standing (GoodStandingCert)
Accepted document types:
  • Shareholder registry (ShareholderRegistry)
  • Statement of information (InformationStatement)
  • Trust agreement (TrustAgreement)
  • Certificate of incumbency (IncumbencyCert)
The document must list all shareholders with their ownership percentages (totaling 100%), be dated within the last 12 months, and signed by a director unless publicly available.KYC checks: Each UBO with 25%+ ownership and all company directors must complete KYC (Proof of ID) and be individually approved before onboarding. If there is no UBO who owns 25%+, all UBOs with 10%+ ownership must be verified.KYB checks: Apply to all legal entities in the ownership chain. For each additional entity, the same information is required unless ownership can be verified through open sources.
Accepted document types (any that contains information about appointed directors):
  • Director registry (DirectorsRegistry)
  • Trust agreement (TrustAgreement)
  • Statement of information (InformationStatement)
  • Certificate of incumbency (IncumbencyCert)

​
Business Questionnaire

Upload Source of Funds document is only required for Euro 3rd party payout.

​
Associated Parties

Example: Business Customer → owned by Company A → John Smith owns Company A → Company A is Shareholder, John Smith is UBO.

​
Required Information by Party Type

  • First name
  • Last name
  • Middle name
  • Date of birth
  • Email
  • Contact number
  • Nationality
  • Percentage of ownership
  • Tax ID: SSN for US persons, otherwise a national TIN. Always required, in any country — including for a sole proprietor.
  • Address details
Proof of address is not currently required for any person beneficiary, in any country. It’s validated (base64, size) when provided, but a missing one never blocks the submission.

​
Identity Verification / Liveness Check

For business customers, there are typically 2-3 types of people to identify, depending on whether an authorized representative is appointed:
Accepted identity documents are Passport, NationalId, DriverLicense, ResidencePermit, and DigitalDriversLicense. A ResidencePermit is rejected unless it’s US-issued and the beneficiary is at a US company. A DigitalDriversLicense is rejected unless it’s Brazil-issued. Beneficiaries of non-sole-proprietorship US companies additionally need DriverLicense, NationalId, or ResidencePermit to be US-issued (Passport is accepted from any country): any other combination is rejected with 400, not held pending.

​
Sole Proprietor Onboarding

Sole proprietors use the same onboarding paths as any other business. Pass company_type: "SoleProprietorship" to the Hosted Link flow or the Programmatic Business API. The Hosted Link flow automatically adapts its UI to the smaller sole-proprietor data set. The Programmatic API uses the same wire schema as any business: by convention, the proprietor is submitted as a single beneficiary with the UltimateBeneficialOwner role at 100% share. For sole proprietors, set questionnaire.type to "SoleProp". This is a simplified variant of the business questionnaire with fewer required fields.
Sole proprietorships need one company document: the incorporation certificate (IncorporationCert). Proof of address is not required for the proprietor, in any country. A sole proprietorship missing the incorporation certificate is rejected with 400, in any country. See Incomplete Submissions.
The hosted sole-proprietor flow walks the customer through four verification steps:
1

Company data

  • Country
  • Company name
  • Incorporated on
  • Registration number
  • Website
  • Custom field: Doing Business As
2

Questionnaire

Sole Proprietor Information (sets questionnaire.type to "SoleProp").
3

Company documents

  • Certificate of incorporation or registration
4

Associated parties (UBOs)

The proprietor as a single UBO:
  • First name
  • Last name
  • Date of birth
  • Email
  • Phone
  • TIN

​
Enhanced KYB Due Diligence

Business customer risk is defined through a customer risk rating process, calculating the risk score based on different factors: geography, industry, use of product, expected activities, legal form, etc.

​
Appendix

​
Prohibited Industries

The following business activities are prohibited from using MoonPay Enterprise’s services to ensure alignment with regulatory expectations and MoonPay Enterprise’s risk appetite.
  • Foreign Correspondent Banking
  • Chemical
  • Defense/Military
  • Multi-Level Marketing
  • Tobacco/Nicotine/Vapes
  • Cannabis
  • Weapons/Knives/Guns
  • Bail Bondsman / Bailiff Services
  • Nutraceuticals
  • Car Dealership
  • Pharmaceutical
  • Diamond Industry
  • Nominee Shareholder / Bearer Share Entities
  • Adult Entertainment
  • Dating Services
  • Gems Or Precious Metals Dealership
  • Sexual Services
  • Antiques And Collectibles
  • Pre-Paid Cards
  • Exotic Animals
  • Private Military Or Security
  • Cash-Funded Remittances
  • Jewelry Or Watches
  • FX Trading
  • Binary Options
  • Credit Services

​
Business Ownership and Constitutional Documents

To comply with MoonPay Enterprise’s KYB requirements, all businesses must provide clear, official documentation that reliably verifies their complete ownership structure, ultimate beneficial owners (UBOs), controlling individuals, and confirms the existence and ongoing operations of the legal entity. If the entity does not have individual beneficial shareholders, we will need to confirm the individuals who significantly control the entity instead, such as its directors and officers. Supported entity types:
  • Sole Proprietorships
  • Partnerships
  • LLCs & Corporations
  • Trusts
  • Nonprofits
  • DAOs
  • Cooperatives

​
Required Documentation per Entity Type

  • Official sole proprietorship license or registration document clearly naming the sole proprietor and confirming active operation
  • Recent tax filings or official government-issued documents linking the proprietor to business operations
  • Partnership agreements officially certified or notarized, detailing partners and ownership shares
  • Officially issued partnership registration certificates clearly listing partners and their shares
  • Articles of Incorporation or Articles of Organization issued by the official business registry, clearly listing shareholders/members
  • Official shareholder/membership register or certified extracts from commercial registries clearly indicating owners and ownership percentages
  • Share certificates officially verified or notarized
  • Recent audited financial statements (for publicly traded or regulated entities), confirming the company’s operations and ownership
  • Official trust deed or certificate clearly identifying trustees, settlors, protectors (if applicable), and beneficiaries
  • Notarized trustee affidavit clearly verifying trustee identity, roles, and authorities
  • Official formation documents (e.g., Articles of Incorporation) clearly listing controlling individuals (e.g., directors or board members)
  • Government-issued or officially filed annual reports or governance documents confirming ongoing operations and key individuals
  • Official governance documents or independently audited membership agreements clearly outlining membership, control mechanisms, and operational status
  • Official formation documents clearly identifying cooperative members
  • Independently certified membership ledgers or agreements clearly indicating members and voting rights

​
Document Verification Standards

All provided documents must be issued by an official governmental authority and, where applicable, certified by a notary public, lawyer, auditor, or similar independent professional, with Apostille certification where applicable.
  • Must be officially issued by governmental authorities
  • Must be verifiable online through an official registry or database (if not possible, must be independently certified)
  • Apostille certification or equivalent legalization required where applicable
  • Self-generated or internally-produced documents are NOT acceptable
  • Must clearly display the full legal name and registration code of the business entity
  • If ownership structure involves more than two layers, a clear organizational chart with ownership percentages is required
  • Must be recent (issued within the past three months)
  • Documents not in English must include certified translations

​
Requirements for Regulated Entities

Entities that operate under regulatory supervision must provide additional documentation to confirm their licensing status and compliance with AML/CFT regulations.

​
Regulatory Licenses and Authorizations

A valid license or authorization issued by the relevant financial regulator or supervisory authority permitting the entity to conduct its business activities. If the license or authorization is not publicly accessible online, it must be certified by the issuing authority or a notary public.

​
AML/CFT Policy and Procedures

A copy of the entity’s internal AML/CFT policy, outlining its approach to:
  • Customer due diligence (CDD) and enhanced due diligence (EDD)
  • Transaction monitoring processes
  • Suspicious activity reporting procedures
  • Sanctions screening and PEP checks
  • The policy must be approved by senior management and aligned with the applicable jurisdiction’s AML laws and regulations
  • Licenses and authorizations must be verifiable online (if not, must be certified by the issuing authority, a notary public, or a licensed legal/audit professional)
  • The submitted AML/CFT policy must be an officially approved internal document (not a draft or template)