Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
Gateway settlement files apply a single deducted MDR per transaction without showing the merchant the card BIN or the product tier that justified the slab. Standard consumer-tier credit cards get auto-routed to the 3% premium slab whenever the BIN classifier flags them as signature, infinite, rewards, commercial, Amex, or Diners — and the merchant has no per-transaction visibility to challenge it. On a credit-heavy hospitality, OTA, or luxury-retail merchant, the misrouted share routinely sits at 5-20 percentage points of credit volume, accumulating silently every settlement cycle.
BIN-tier reconciliation joins each settlement-file transaction to a BIN-product mapping (acquirer-provided CSV or third-party BIN database), recomputes the expected slab per transaction using the merchant's contracted rate card keyed on network plus product tier, and raises a CARD_TIER_MISMATCH variance when the actual slab deducted exceeds the expected slab. A 90-day rolling audit window matches the typical gateway retrospective-adjustment cut-off, and a per-BIN volume ranking surfaces the highest-recovery BINs first.
BIN-tier rule per network (Visa / Mastercard / RuPay / Amex / Diners) mapping issuer BIN to product tier (consumer / premium-signature-infinite / rewards / commercial / corporate); CARD_TIER_MISMATCH variance class with a 5-bps slab-delta tolerance to suppress rounding noise; refund-MDR retention flag and 90-day rolling recovery window for retrospective gateway disputes; GST-credit-note matcher to GSTR-2B for the 18% reversal line.
A per-BIN misrouting report ranking BINs by recoverable amount, a CFO-facing card-tier mix dashboard (consumer vs premium vs commercial vs Amex/Diners share month-on-month), a dispute-pack export per gateway with BIN evidence and expected-vs-actual slab calculation for retrospective adjustment requests, and a GST-credit-note reconciliation schedule against GSTR-2B.
A luxury hotel chain running ₹3.5 crore monthly credit-card GMV across its city properties sees a single line item on the gateway statement: “MDR — Credit Card — ₹X”. The CFO has a contracted rate card with 2% on standard consumer credit, 3% on premium and Amex / Diners, and 3% on commercial cards. The gateway has applied the slabs without per-transaction itemisation. The CFO does not know what share of the credit-card volume was actually billed at 3% versus 2%, and the front-office settlement reconciler matches the gross deducted MDR to the settlement net and signs off.
A BIN-by-BIN audit of the same chain’s 90-day settlement file routinely surfaces that 35% of credit volume has been billed at the 3% slab — but the actual card-tier mix is 18% premium (signature / infinite), 70% standard, and 12% commercial. The 17 percentage-point gap is consumer cards routed to the premium slab. At ₹3.5 crore monthly credit GMV that is ₹59.5 lakh of monthly volume mispriced by 1 percentage point — ₹59,500 a month, ₹7.14 lakh annually, plus 18% GST that has flowed through the books unchallenged.
This article walks through the BIN tier logic, the detection workflow, and the recovery sequence.
Quick-Reference: Premium Card MDR Slabs in India
| Aspect | Detail |
|---|---|
| Credit-card MDR cap (regulatory) | None — uncapped, contractually negotiated |
| Consumer credit MDR (Visa / Mastercard, domestic, published) | 1.4% to 2.5% — gateways typically list ~2% |
| Premium credit slab (signature / infinite / rewards / commercial) | 2.5% to 3% — gateways uniformly publish 3% |
| Amex / Diners domestic slab | 2.95% to 3.5% — gateways uniformly publish 3% |
| International card slab | 2.69% to 3.5% plus forex conversion |
| Relevant RBI circular | DPSS.CO.PD No.1633 / 02.14.003 / 2017-18 (caps debit only) |
| Card-tier evidence required | Issuer BIN (first 6-8 digits) plus network product code |
| GST on MDR | 18% on the fee only (not on transaction value); separate line |
| Refund-MDR retention | MDR is industry-wide non-refundable on refunds — applies to mis-tier too |
| Retrospective dispute window | Typically 90 days (gateway-dependent) |
What Drives the Premium Slab in the First Place?
Card-network interchange — the fee paid by the acquiring bank to the issuing bank — is not a single number. Each network publishes a schedule by product tier: a Visa Classic consumer card carries a lower interchange than a Visa Signature card, which carries a lower interchange than a Visa Infinite, which carries a lower interchange than a Visa Commercial / Corporate card. Mastercard runs a parallel hierarchy (Standard → World → World Elite → Commercial). American Express and Diners Club operate closed-loop networks with their own product tiers and a generally higher cost basis — which is why every published gateway rate card (Razorpay, PayU, Cashfree) folds Amex and Diners into the same 3% bucket as premium and commercial Visa / Mastercard, even though the cost drivers are technically different.
The merchant sees only the gateway’s all-in MDR — a single percentage applied per transaction. The gateway’s classifier reads the BIN, matches it against the network’s product schedule, and routes to whichever slab in the merchant’s rate card applies. There is nothing fraudulent about the routing — it is the contracted behaviour. What is contractually murky is the lack of per-transaction transparency: most gateway settlement files do not expose the BIN or the product tier that justified the slab, so the merchant cannot independently verify whether a standard rewards card has been correctly classified or has been over-classified into the premium bucket.
This invisibility is the central audit problem. The Reserve Bank of India’s MDR rationalisation framework caps non-RuPay debit-card MDR at 0.40% / 0.90% but explicitly leaves credit-card MDR uncapped and negotiated, on the policy view that credit-card acceptance is discretionary. The flip side of that policy choice is that the only defence against mis-classification is the merchant’s own contract discipline and BIN-level audit.
Where Does the Misrouting Concentrate?
Three failure modes show up repeatedly on credit-heavy merchants — hospitality chains, online travel agencies, luxury retail, premium D2C, fine dining aggregators.
Mode 1 — rewards cards routed to premium. A standard consumer credit card with a co-branded rewards programme (HDFC Regalia, Axis Magnus, SBI Card Elite, ICICI Sapphiro) carries a “Signature” or “Infinite” suffix on the network product code. The gateway classifier reads the suffix and routes to the 3% slab, even though the merchant’s contracted premium rate may have been intended only for the genuinely higher-interchange product tiers. Resolution depends on the contract language: a rate card that says “Premium / Signature / Infinite — 3%” technically permits this routing; a rate card that says “Premium / Commercial — 3%; rewards consumer cards at standard slab” does not.
Mode 2 — commercial-tier auto-flagging on consumer cards. A consumer card issued by an issuer whose BIN range overlaps with that issuer’s commercial product line gets routed to the 3% slab when the gateway’s BIN classifier reads the BIN range rather than the specific BIN. This is the most easily recoverable variance — the BIN evidence flatly contradicts the commercial classification.
Mode 3 — Amex / Diners blended back in. A merchant on a flat 2% blended quote (“we’ll charge you 2% on everything”) rarely realises that Amex and Diners genuinely cost 3% to the gateway. When the gateway eventually itemises by network in a renegotiation, the prior blended period included an unannounced cross-subsidy from the merchant’s other volume to the Amex / Diners share. This is less a misrouting and more a pricing-opacity issue, but it surfaces in the same audit.
Detection: A 90-Day BIN-by-BIN Audit Routine
The detection workflow has six steps that any controller or CFO office can run with the gateway’s CSV export plus a BIN database. The output of each step feeds the next.
- Pull the 90-day settlement file with per-transaction BIN (first 6-8 digits). Most gateways will provide BINs on written request even when the default file truncates them. Razorpay exposes BINs in the
card.iinfield in the API response; PayU has a similarbinfield in the settlement webhook; Cashfree exposes it in the order-payments API. Pull the file withpayment_method,card_network,card_type,bin,transaction_amount,mdr_deducted,gst_deducted,transaction_date. - Join to a BIN-product mapping. The cleanest source is the acquirer-provided BIN CSV (issuer name, network, product tier, scope domestic / international). A third-party BIN database is acceptable if the acquirer mapping is unavailable. The mapping should resolve every BIN to one of: consumer, premium-signature, premium-infinite, rewards-co-branded, commercial, corporate, prepaid, Amex, Diners.
- Apply the merchant’s contracted rate card. Read the rate card by network plus product tier. Compute the expected MDR per transaction. The expected slab is the contracted rate for the BIN’s product tier — not a guess and not a blended rate.
- Compute variance. Where actual MDR deducted exceeds expected MDR by more than a 5-bps tolerance (to suppress floating-point rounding), raise a
CARD_TIER_MISMATCHvariance with the per-transaction delta. - Rank by BIN volume. Group variances by BIN and rank by recoverable amount. The top 10 BINs typically account for 70-80% of the recoverable pool — those are the dispute targets.
- Build the dispute pack. Per BIN, export a CSV with transaction IDs, dates, amounts, BIN evidence (product tier from the mapping), expected slab, actual slab, delta MDR, delta GST. Attach the BIN-database citation and the contracted rate card excerpt. Submit to the gateway’s merchant-support team as a single retrospective-adjustment request.
The discipline that turns this from a one-off into a repeatable monthly control is automating steps 1-4 in the reconciliation engine itself. A rate-card rule keyed on network plus product tier, a BIN mapping refreshed quarterly from the acquirer feed, and a CARD_TIER_MISMATCH variance class with a configurable tolerance — that is the entire mechanism. Manual quarterly audits catch the obvious cases; automated per-transaction checks catch the cases that obvious audits miss.
Model the BIN-tier audit recovery for your merchant volume
Enter your monthly credit-card GMV, your card-tier mix (consumer / premium / commercial / Amex), and the share you suspect is misrouted to the premium slab. The calculator returns the monthly leakage, the 90-day recovery target, and the annualised effective-rate impact so you can scope a BIN audit before commissioning it.
Open the MDR Effective-Rate Calculator →Worked Example: A Luxury Hotel Chain BIN Audit
Consider a luxury hotel chain operating six city properties in Bengaluru, Mumbai, Delhi, Goa, Jaipur, and Udaipur. Monthly credit-card GMV runs at ₹3.5 crore. The chain’s contracted rate card with its payment gateway specifies:
- Standard consumer credit (Visa / Mastercard domestic) — 2%
- Premium signature / infinite — 3%
- Commercial / corporate — 3%
- Amex / Diners domestic — 3%
The chain’s CFO commissions a BIN-level audit on a 90-day settlement file (₹10.5 crore of credit GMV). The audit applies the workflow above and produces the following card-tier breakdown.
| Card tier | Audit BIN-evidenced share | Expected slab | Audit-derived volume share | Actual slab applied (gateway) |
|---|---|---|---|---|
| Consumer credit (Visa / Mastercard, standard) | 70% | 2% | 53% | 2% |
| Premium signature / infinite (Visa / Mastercard) | 18% | 3% | 18% | 3% |
| Commercial / corporate (Visa / Mastercard) | 12% | 3% | 12% | 3% |
| Consumer credit misrouted to premium | — | — | 17% | 3% (incorrect) |
The gateway billed 35% of credit volume at the 3% slab — but the BIN evidence supports only 18% premium plus 12% commercial = 30% at the 3% slab. The 17 percentage-point gap between gateway-billed-3% and BIN-evidenced-3% sits on cards that the rate card says belong at 2%.
The arithmetic that follows is the recovery calculation.
Monthly misrouted volume: ₹3.5 crore × 17% = ₹59.5 lakh.
Slab delta: 3% − 2% = 1 percentage point.
Monthly MDR over-billed: ₹59.5 lakh × 1% = ₹59,500.
Monthly GST over-recovered as ITC (already in books): ₹59,500 × 18% = ₹10,710.
90-day recoverable MDR: ₹59,500 × 3 = ₹1,78,500.
Annualised recovery target: ₹59,500 × 12 = ₹7,14,000.
When the gateway processes the retrospective adjustment, the credit note covers the ₹1.78 lakh MDR delta plus ₹32,130 GST. The GST credit note reduces the chain’s ITC in the period it is issued — a GSTR-2B reconciliation event the finance team handles via the normal credit-note workflow. The net economic recovery to the chain is ₹1.78 lakh for the 90-day window, with a similar amount expected per quarter on a clean go-forward run once the BIN audit becomes a monthly control.
The further finding — and this is where the audit pays for itself ten times over — is that the chain’s card-tier mix has been stable for years, so the same 17 percentage-point misrouting has almost certainly been running for the prior 18-24 months. The chain cannot recover beyond the gateway’s 90-day dispute window, but it can switch off the future leakage from the moment the audit closes, locking in the ₹7.14 lakh annual run-rate prospectively. That run-rate compounds against the chain’s broader payment-cost line.
Reconciliation Discipline: Making This a Monthly Control
A BIN audit run once is a recovery exercise. A BIN audit run every month is a control. The conversion takes three elements.
A BIN mapping refreshed quarterly. Card issuers launch new products on a rolling basis; the BIN ranges expand. A quarterly refresh of the acquirer-provided BIN CSV keeps the mapping aligned with the actual card-issuance reality. Stale mappings under-detect — a card launched after the last refresh ends up in the default consumer bucket regardless of its true tier.
An expected-slab rule keyed on the contract. The reconciliation engine should hold the merchant’s rate card as a structured object — network plus product tier plus scope (domestic / international) — and compute the expected MDR per transaction from that object. When the contract changes (annual renegotiation, gateway switch, promo-rate window expiry), the rate card object changes once, and every subsequent month’s reconciliation picks up the new baseline automatically.
A variance class with a non-zero tolerance. Card networks publish interchange in basis points, and rounding produces sub-bps deltas that should not be raised as variances. A 5-bps tolerance on the slab delta filters out rounding noise without missing the structural misrouting case (where the delta is 100 bps or more). Variances above the tolerance accumulate into the monthly dispute pack and feed the next gateway-support conversation.
The output that the CFO actually wants from this control is two things: a monthly card-tier mix dashboard showing the share of credit volume in each tier (so the CFO can validate the mix matches the merchant’s expected customer profile), and a recoverable-amount running total by gateway and by month (so the dispute-and-adjustment cadence with the gateway has a fact base). Everything else — the per-transaction variances, the BIN evidence, the rate-card lookups — is engine plumbing.
Continue Reading in This Cluster
- MDR fee reconciliation against contracted gateway rates — the parent workflow this BIN audit sits inside.
- RuPay debit vs Visa / Mastercard debit MDR comparison — the network-tier logic on the debit side, where the RBI cap binds.
- PPI / wallet-on-UPI interchange detection — the same rail-split discipline applied to the UPI parent bucket.
- Merchant fees cluster hub — the full eight-pattern leakage framework for Indian payment gateways.
- Payment gateway reconciliation money page — TransactIG’s gateway reconciliation surface.