MyazaTrust

Business verification (KYB)
Build with

KYB (Know Your Business) verifies a company instead of a person. It looks the business up in the official company registry by registration number and — optionally — collects company documents, compliance declarations, and runs customer due diligence (CDD) on the people who own or control it (directors, beneficial owners, the applicant).

Available in 48 countries — see Supported countries.

KYB is enabled per organization. If business verification isn't switched on for your account, ask Myaza to enable it.

How to run a KYB verification
Build with

A live business verification requires a published KYB workflow — the workflow defines what you verify (country, product, application steps, and the decision graph). You run it exactly like individual KYC, two ways:

  1. Embed — mount an SDK with the KYB workflow's workflowId. The SDK collects the registration number (and any application steps you configured) and submits.
  2. Hosted link — send the workflow's hosted link; the business completes it in the browser, no integration.

Build the workflow under Dashboard → Workflows (choose Business when creating it) and start from a template: Standard KYB, KYB + AML screening, or Enhanced KYB with declarations.

Products
Build with

Each verification runs a product — what gets looked up:

ProductAvailabilityInput
businessEvery supported countryRegistration number
business-taxNigeriaRegistration number (returns the business + its tax ID)
business-taxidNigeriaRegistration number
business-tinNigeriaTIN

The default is business — a registry lookup by registration number.

The application (optional layers)
Build with

A registry lookup proves a business exists — it doesn't prove the submitter controls it. A KYB workflow can therefore collect a full application; each layer is a toggle in the builder:

  • Company profile — registered address, business email, phone, website.
  • Company documents — certificate of incorporation, MEMART, proof of address, etc., OCR-read and cross-checked against the registry record.
  • Key people (CDD) — the directors and beneficial owners (UBOs) discovered from the registry are screened (sanctions / PEP / adverse media) and can be required to complete their own KYC via a per-person invite link.
  • Applicant verification — the person filling in the form verifies their own identity in-flow and declares their role.
  • Declarations — a compliance questionnaire (source of funds, expected volume, …).

The decision graph can wait for the key people's due diligence before approving — see Decisioning.

The result
Build with

The business result arrives on your backend by webhook, the same way KYC results do. A business event's data carries a subjectType of "business", a business object, and a null userData:

json
{
  "subjectType": "business",
  "status": "verified",
  "country": "NG",
  "business": {
    "product": "business",
    "registrationNumber": "RC0000000",
    "businessName": "ACME LIMITED",
    "record": { "companyStatus": "active", "registrationDate": "2018-04-01", "…": "…" }
  },
  "userData": null
}
  • status is verified when the registry returns a match, or not_found (reason code business_not_found) when the registration number isn't in the registry.
  • record is an org-safe extract of the registry data (company particulars, share ownership, key personnel) — never the raw provider payload.
  • The onboarding decision (approve / decline / review) — including any key-people gate — arrives separately in a workflow.run.completed event. The business verification's own status is terminal the moment the registry lookup finishes; the decision can still be pending on the people.

Decisioning fields
Build with

Business runs expose business.* fields to decisioning: business.companyStatus, business.nameMatch, business.addressMatch, business.ageYears, business.keyPersonnelCount, business.hasForeignPersonnel — plus the key-people roll-up (keyPeople.anyFlagged, keyPeople.kycComplete, keyPeople.kycFailed, …).

Next steps
Build with