Merchant Metrics Dictionary

A · Basic info (operations — Fabric)

GMV / revenue / card & channel mix / onboarding time on settled transactions. Filtered by the selected period (3m / 6m / 12m / YTD) on snapshot_date.

Headline KPIs /api/merchant/ops-summary

Metric	Definition	Source / formula	Status
GMV	Total settled transaction amount in the period	SUM(fact[order_amount])	⚠
Fee income	Fee revenue incl. VAT (payee + payer fees)	SUM(fact[total_fee_income_incl_vat]) also _excl_vat, interchange_fee	✓
Transactions	Count of successful transactions (1 row = 1 txn)	COUNTROWS(fact)	✓
Active merchants	Distinct merchants with a transaction in the period	DISTINCTCOUNT(fact[merchant_id])	✓
TAT signup→onboard	Avg days from sign-up to onboarding	measure [Avg Days Sign Up to Onboarding] = AVG(fact[days_signup_to_onboarding])	⚠
TAT onboard→1st txn	Avg days from onboarding to first transaction	measure [Avg Days Onboarding to First Txn] = AVG(fact[days_onboarding_to_first_txn])	⚠

⚠ GMV is dominated by settlement accounts (Remittance / PPC / Fuze) — should settlement-type accounts be excluded to reflect real merchants? ⓘ The two TAT measures are currently averaged per transaction row (weights large merchants) — should they be per merchant instead? To confirm.

Trends /api/merchant/ops-trend

Metric	Definition	Source / formula	Status
GMV by month	Monthly GMV trend	SUM(order_amount) group by dim_lkup_date[year_month_num]	✓
Fee by month	Monthly fee-revenue trend	SUM(total_fee_income_incl_vat) group by year_month	✓

Breakdowns (GMV by …) /api/merchant/ops-breakdown

Dimension	Definition / values	Source column	Status
Acquisition	Onboarding channel: PORTAL / BASIS / AGENT / BOTIM / Referred	fact[acquired_via] ≈ TiDB create_source	✓
Card brand	Card scheme: VISA / MASTERCARD / Wallet / VAM TopUp / ITC / N A	fact[card_brand]	⚠
Payment method	Payment method	fact[payment_method]	✓
Merchant category	Merchant main category	fact[merchant_main_category] also sub_category / mcc / merchant_type_category	✓
Product	Product	fact[product_name] (+product_code)	✓
Pay channel	Payment channel	fact[calculated_pay_channel] also calculated_terminal_type / channel_type	✓

⚠ Card brand is mostly N/A (wallet / top-up / settlement rails, not card) — flag or exclude separately?

Top merchants /api/merchant/ops-top

Column	Definition	Source
Merchant / MID	Merchant name / merchant id	fact[merchant_name] / [merchant_id]
Source	Onboarding channel	fact[acquired_via]
GMV / Fee / Txns	Period totals; top-N by GMV desc	TOPN(N, …, SUM(order_amount) DESC)

📎 Fields present in the model but not yet on the dashboard (add on request): card_type / card_level / card_bin / card_area / bank_area, interchange_fee, referrer_mid/name, the rates dim dim_lkup_merchant_rates (FIX_RATE / MIN·MAX·FIX_CHARGE / validity), and the merchant & product hierarchies grp_1..5.

B · Bad merchants (risk — TiDB)

Bad merchant = the union of four family definitions. A merchant is “bad” on a day if it trips any active definition. Counts across definitions are always de-duplicated by merchant (never summed). Default period 60 days, up to yesterday (today excluded).

Definitions (4 families · 7 variants) /api/merchant/bad-trend · bad-table

Family / variant	Definition	Source table / SQL predicate	Observed level	Status
Risk · all	Merchants with any valid risk/fraud case that day	aml.t_risk_case WHERE status='Valid'	median 6/day	default
Risk · chargeback	Chargeback cases only (fraud + service)	… AND case_type LIKE '%Chargeback fraud/service%'	median 2/day	caution
High-reject · count	≥10 declined transactions that day (absolute)	acquireii.t_acquire_order HAVING reject_count ≥ 10	median 79/day	caution · volume-biased
High-reject · rate	Reject rate ≥50% on ≥20 transactions that day	HAVING txns ≥ 20 AND reject/txns ≥ 0.5	median 7/day	default · recommended
App-rejected · status	Onboarding creation-order final status = REJECTED	merchant.t_merchant_creation_order WHERE status='REJECTED'	median 1/day	default
App-rejected · audit	A review step returned REJECT (per step)	merchant.t_audit_history WHERE result='REJECT' (join creation_order)	median 2/day	caution
Disabled	Merchants moved to DISABLED that day	merchant.t_merchant_status_history WHERE merchant_status='DISABLED'	5 total / 90d	default

Metrics

Metric	Definition	Formula / denominator	Status
Count	Distinct bad merchants per day (union of active definitions, de-duped)	COUNT(DISTINCT merchant_id) / day	✓
Bad rate %	Share of bad merchants — each family uses its own denominator	see denominators below	⚠
↳ risk denom	Merchants transacting that day (≥1 txn)	DISTINCT partner_id · acquire_order (~782/day)
↳ high-reject denom	Merchants with ≥20 txns that day (matches the rate floor)	≥20 txn/day merchants (~209/day)
↳ app-rejected denom	Applications submitted that day · 7-day rolling (small-denominator stability)	DISTINCT merchant_mid · creation_order (~5/day)
↳ disabled denom	Enabled merchant stock	COUNT · t_merchant WHERE status='ENABLED' (~5710)

⚠ Bad rate is disabled while a compare-by dimension is active (rate-by-dimension needs per-dimension denominators — phase 2).

Dimensions: compare / filter / locate

Dimension	Use	Source column	Values
Bad family	Compare (split lines)	computed	risk / high-reject / app-rejected / disabled
Acquisition source	Compare + filter	t_merchant[create_source]	PORTAL / BASIS / AGENT / BOTIM
Legal type	Compare + filter	t_merchant[biz_org_structure]	LLC / SOLE_P / FZC / FZE / CIVIL_C…
Category (MCC)	Compare + filter	t_merchant[category]	5411 / 4722 / 5812… (ISO MCC)
Current status	Filter	t_merchant[status]	ENABLED / CREATED / DISABLED
Risk case type	Filter (risk only)	t_risk_case[case_type]	Chargeback fraud/service · fraud report…
Merchant (identity)	Search + drill	mid (exact) / name·business_name (contains)	—

Drill-down table · columns

Column	Definition	Source
Merchant	Merchant name (falls back to business_name)	t_merchant[name → business_name]
Families hit	Bad families tripped in the period (colored pills)	computed
Bad days	Number of days the merchant tripped any active definition (repeat-offender sort)	COUNT(DISTINCT date)
Last bad date	Most recent day tripped	MAX(date)
Source·Legal·Status	Merchant attributes; “Unknown” when not joinable	t_merchant.* (LEFT JOIN)

C · Open questions (take these to confirm)

⚠ Definitions that need owner sign-off

High-reject “reject” definition: currently status ≠ 'SETTLED' (includes in-flight/processing orders, inflating recent days). Suggest an explicit failed/declined status set — please provide the full t_acquire_order.status enum.
High-reject threshold: default reject rate ≥50% and ≥20 txns/day (≈7 merchants/day). Are the % and volume floor agreed?
Risk definition: default status='Valid' (all valid cases incl. all fraud reports) vs chargeback-only. Which is the default?
App-rejected: order final status REJECTED vs audit-step REJECT? The two overlap and some merchants have no t_merchant profile (→ Unknown).
Default active definitions: risk_all · hireject_rate · app_rejected_status · disabled (one per family). Agreed?
TAT averaging (Basic): per transaction row or per merchant?
GMV: exclude settlement-type accounts (Remittance/PPC/Fuze…)? List Card brand N/A separately?

Join keys (linking the two sources): risk / app-rejected / disabled use merchant_id·merchant_mid; high-reject uses partner_id (= mid). Channel taxonomies align: TiDB create_source ≈ Fabric acquired_via.

Source boundary: the Fabric fact holds successful transactions only (no rejects/risk) → use Fabric for the operations side; the risk side (reject rate / risk / disabled) must come from TiDB.

Merchant Metrics Dictionary · for definition sign-off · figures live to 2026-08-24 · draft v1