eKYB in Practice: How Apivom's MERSIS API Turns Business Verification into a Single API Call

Every B2B relationship starts with the same quiet question: is this company who it says it is? Banks ask it before opening an account, marketplaces ask it before paying out a seller, distributors ask it before extending credit to a new dealer, and software vendors ask it before provisioning a tenant. The discipline that answers the question is called Know Your Business (KYB) — and when the answer comes from an authoritative registry over an API instead of a scanned PDF, it becomes eKYB.

In Türkiye the authoritative registry is MERSIS, the Central Registry System operated by the Ministry of Trade. This article explains what eKYB is, why verifying a Turkish company is harder than it looks, and what concretely changes when the lookup runs through Apivom Atlas and its MERSIS company-card API.

What Is eKYB (Electronic Know Your Business)?

KYB is the corporate counterpart of KYC. Where KYC verifies a natural person — identity, address, sanctions exposure — KYB verifies a legal entity:

• Existence and status — is the company registered, active, dissolved, or in liquidation?
• Identity — legal title, registry number, registry office, tax identification.
• Location and activity — registered address, declared field of activity (NACE codes), capital.
• Control — partners, shareholders, board members, authorised representatives.
• Risk signals — bankruptcy or concordat proceedings, branch structure, recent registry announcements.

Traditional KYB collects this as documents: a trade registry gazette excerpt, a signature circular, a tax certificate, a stamped activity certificate. Someone uploads them, someone else reads them, and both hope nothing changed since the PDF was printed.

eKYB replaces the document chase with a machine-readable query against the primary source. The customer enters a tax number, your backend asks the registry, and the answer arrives as structured JSON that your onboarding workflow can evaluate in milliseconds. The value is not only speed: structured data can be re-checked, diffed, and audited, which paper never can.

Why Verifying a Turkish Company Is Harder Than It Looks

Teams that have only worked with EU or US registries usually underestimate the Turkish landscape. A few realities shape every eKYB design:

Two identifiers, two purposes. Companies carry a 10-digit tax number (VKN) issued by the Revenue Administration and a 16-digit MERSIS number issued by the trade registry. Customers know their tax number; the registry speaks MERSIS. A usable eKYB flow must accept the first and resolve the second.

Sole proprietors are people. A sole proprietorship (şahıs işletmesi) is registered under the owner's national identity number, and one person may run several businesses. A query by that number can legitimately return more than one registry record. Code that assumes "one tax number, one company" will silently drop data.

Branches are separate records. Large retailers, logistics firms, and dealer networks register dozens of branches (şube), each with its own MERSIS number and activity. Verifying the head office tells you nothing about the branch that actually signed the order.

The gazette is the legal truth. Changes of address, capital, directors, or legal status become binding when announced in the Türkiye Trade Registry Gazette. A serious due-diligence file still needs the latest announcement — ideally as the original document, not a transcription.

Freshness matters more than coverage. Registry data changes daily. A verification done at onboarding is a snapshot; credit and compliance teams need a cheap way to re-verify at renewal, at payout, or when a risk model asks for it.

What the Apivom MERSIS API Actually Returns

Apivom resells the official TOBB Company Card (MERSIS) data set through Atlas, the same API gateway that already fronts dozens of upstream services for Apivom customers. Instead of a single monolithic record, the API exposes four company-card depth levels plus a branch card, so you request exactly the depth your decision needs:

Level	What you get	Typical decision
Card 1 — Basic	Legal title, MERSIS number, registry office, registration status	"Does this company exist and is it active?"
Card 2 — Address, capital & NACE	Card 1 + structured address, capital detail, NACE activity codes	Address matching, activity-fit checks, segmentation
Card 3 — Partners, board & representatives	Cards 1–2 + partners, active board members, authorised representatives, auditors	Beneficial-ownership and signatory checks
Card 4 — Full record	Cards 1–3 + bankruptcy/concordat status, up to 50 branches, the latest Trade Registry Gazette announcement as a PDF	Credit limits, high-value contracts, audit files
Branch card	Branch-level record by MERSIS number, including the head-office link	Verifying the entity that actually transacts

Queries are made by tax number (or the MERSIS number for branches), and the response follows the current TOBB contract in which the head-office section is an array — the sole-proprietor case is handled correctly instead of being an edge case your team discovers in production. The full request and response shapes are documented publicly in the Atlas Portal MERSIS guide.

Seven Concrete Benefits of Running eKYB Through Apivom Atlas

1. One contract, one key, no upstream onboarding

Getting direct access to Turkish registry web services means a commercial agreement, a technical integration against a legacy specification, and ongoing contract management. With Atlas you receive a per-tenant API key from the self-service portal, call a clean REST endpoint over HTTPS, and start verifying the same day. The key is rotatable, hashed at rest, and scoped to your organisation only.

2. You pay for data, not for attempts

The commercial model is prepaid and per query. Two rules make it predictable: a query that returns no company is never charged, and a repeat of the same query is served from the gateway cache free of charge — the response tells you explicitly whether it was cached. When you genuinely need fresh data, a single force flag bypasses the cache and performs a charged live lookup. Your finance team sees a prepaid balance and a ledger, not a surprise invoice.

3. Depth on demand

Because the data is tiered, an onboarding form can run Card 1 for everyone, Card 3 only for accounts above a credit threshold, and Card 4 only when a contract is about to be signed. You are no longer forced to buy the full record to answer a yes/no question — and a verification step that used to be "too expensive to run on every lead" becomes routine.

4. Official provenance, machine-readable

Every field originates from the trade registry via TOBB, the organisation mandated to distribute the company-card data set. The response arrives as JSON with a consistent envelope — upstream status, charge information, cache flag — so the same code path handles success, "not found", and insufficient-balance outcomes without parsing free text.

5. Control and signatory visibility

Card 3 answers the questions that regulators and credit committees actually ask: who the partners are, who sits on the board, who is authorised to sign, and who audits the books. For Know-Your-Business programmes that feed an anti-money-laundering workflow, this is the structured input that replaces a manually transcribed signature circular.

6. Branch and insolvency awareness

Card 4 surfaces bankruptcy and concordat status alongside up to 50 branches and the most recent gazette announcement as an original PDF. The branch card then lets you verify the specific location that placed an order or requested credit — a distinction that matters in distribution, logistics, and franchising.

7. Observability your compliance team can show an auditor

The Atlas Portal records usage and system logs per key, exposes a balance endpoint you can poll before a bulk run, and ships a Try-it console for testing payloads without writing code. There is even a machine-readable llms.txt guide so your AI coding assistant can integrate the API from the official description instead of guessing.

Where eKYB Pays Off First

B2B customer onboarding. A software vendor or distributor verifies legal existence and activity before creating an account, then enriches the CRM record with the registry title, address, and NACE code. Teams running Apivom Iris use this to stop duplicate accounts and to segment customers by declared activity instead of by guesswork.

Dealer and partner networks. Vendors managing hundreds of resellers re-verify partner status at each programme renewal. Automated Card 1 checks across the whole network cost a fraction of a single manual review.

Marketplace and fintech payouts. Platforms that pay out to Turkish sellers verify the payee entity and its authorised representatives before releasing funds, and re-run the check when bank details change.

Supplier due diligence. Procurement teams pull the full record — including insolvency status and the latest gazette — before signing a framework agreement, and store the gazette PDF in the vendor file.

Credit decisions. Capital detail, board composition, branch count, and concordat flags become features in a credit model, refreshed on demand rather than once a year.

Cross-border counterparts. The same Atlas key can validate an EU trading partner's VAT number through the VIES integration, so a single compliance service covers both the Turkish registry and European VAT validation.

A Reference eKYB Flow

A practical implementation rarely needs more than five steps:

1. Capture the tax number on your onboarding form and validate its format client-side.
2. Run Card 1 from your backend with your Atlas API key. Reject or route to manual review if no record exists or the status is not active. Remember to iterate the head-office array.
3. Escalate by risk. Above a configurable threshold, run Card 3 to capture partners and signatories; before contract signature, run Card 4 and archive the gazette PDF.
4. Persist the evidence. Store the response, the timestamp, and the cache flag with the customer record — this is your audit trail.
5. Schedule re-verification. Re-run Card 1 at renewal or on a risk trigger. Unchanged queries hit the cache and cost nothing; use the force flag when the business event demands fresh data.

The whole flow is stateless from your side: no credentials to upstream services, no SOAP clients, no gazette scraping. Atlas handles authentication, retries, error mapping, and metering.

Getting Started

1. Open the Atlas Portal and create an organisation.
2. Top up the prepaid balance and generate an API key.
3. Use the Try-it console or the public MERSIS documentation to send your first Card 1 query.
4. Wire the call into your onboarding backend — never from the browser — and persist the evidence.

For a walkthrough tailored to your workflow, the MERSIS integration page and the Atlas MERSIS product page are the right starting points.

Conclusion

eKYB is not a compliance checkbox; it is the moment your business decides whether to trust a counterparty with credit, access, or money. Apivom's MERSIS API turns that moment into one authenticated call that returns official registry data at the depth you choose, charges only for data you actually receive, and leaves an audit trail your compliance team can defend. Verify once, re-verify cheaply, and let your onboarding move at the speed of your sales team.