A Merchant Category Code (MCC) is a four-digit numeric identifier assigned to a merchant by their acquiring bank or payment facilitator at the point of onboarding. Standardised under ISO 18245, the code classifies the principal trade activity of the business — grocery retail, restaurant, airline, ATM — and travels with every card authorisation message across the network. Downstream, MCCs determine interchange rates, enable spend-control logic in card programmes, feed regulatory reporting obligations, and inform anti-money-laundering transaction monitoring. This article examines the structure, assignment process, interchange relationship, and how modern fintechs leverage MCC logic at programme level.
A Merchant Category Code is a four-digit integer in the range 0742–9950 that classifies the predominant goods or services sold by a merchant accepting payment cards. The authoritative standard is ISO 18245:2003 (Retail financial services — Merchant category codes for retail and service enterprises), which maps each code to a plain-language description and a broad industry group. Visa and Mastercard each publish their own implementation manuals — the Visa Merchant Data Standards Manual and the Mastercard Transaction Processing Rules, respectively — that build on ISO 18245 while adding scheme-proprietary codes and interchange tier assignments. Because the two networks derived their lists from the same ISO base, the vast majority of codes are identical across schemes, though minor divergences exist and practitioners should always verify scheme-specific documentation for edge cases.
MCC is frequently confused with related identifiers. It is distinct from the Standard Industrial Classification (SIC) code used in US corporate filings, the NACE code used for EU statistical classification, and the merchant's own internal category. Whereas SIC and NACE describe a legal entity's primary economic activity for reporting purposes, MCC describes the transaction-level category as seen by the payment network, and a single legal entity may operate under multiple MCCs if it maintains separate merchant IDs for distinct business lines — for example, an airport operator might hold one MCC for duty-free retail (5309) and a separate MCC for car-parking (7523).
Commonly referenced examples illustrate the breadth of the taxonomy. 5411 covers grocery stores and supermarkets; 5812 covers eating places and restaurants; 6011 identifies automated cash disbursements and ATM withdrawals; 5541 is service stations; 7995 covers betting, casino gaming chips and off-track betting; 9406 is government-licensed on-line casinos. Codes in the 6000-series generally relate to financial services — a detail that is particularly consequential for AML monitoring, as will be discussed in section 04. The MCC does not encode transaction size, currency, or counterparty identity; it encodes only the merchant type, making it a blunt but universally available signal in authorisation data.
Assignment. The MCC lifecycle begins when a merchant applies to accept card payments. The acquiring bank or payment facilitator is responsible under both Visa and Mastercard rules for assigning a code that accurately reflects the merchant's primary business. In practice, the acquirer's underwriting team reviews the merchant's registration documents, website, and submitted business description, then maps the activity to the most specific matching code. If no precise code exists, the catch-all 7399 (business services, not elsewhere classified) or 5999 (miscellaneous and specialty retail) may be used, though schemes discourage their overuse. Once assigned, the MCC is stored in the acquirer's merchant master file and embedded in the DE-18 field of each ISO 8583 authorisation message. Acquirers may request a reclassification from the relevant card scheme if business activities change materially.
Authorisation flow. When a cardholder presents their card, the terminal constructs an ISO 8583 authorisation request that includes the MCC alongside the transaction amount, terminal ID, and merchant identifier. This message travels through the acquirer's processor to the card network switch, which routes it to the card issuer for an accept/decline decision. The issuer's authorisation engine receives the MCC and can apply any number of MCC-based rules before responding — a corporate card programme might block all transactions at MCCs 5813 (bars, cocktail lounges) and 7995 (gambling), for instance. The MCC also travels in the clearing and settlement records that determine the interchange rate the acquirer owes the issuer.
Interchange determination. Both Visa and Mastercard publish interchange rate tables structured around a combination of card product type, entry mode, and MCC. Certain MCCs qualify for preferential rates: government services (MCCs 9xxx), utilities (4900), and supermarkets (5411) often attract reduced interchange in EU regulated interchange frameworks. Conversely, quasi-cash MCCs — notably 6010 (manual cash disbursements), 6011 (ATM), and 7995 (gambling) — typically attract higher interchange and may also trigger cash-advance fee treatment on consumer credit cards, impacting the effective cost to both cardholder and merchant.
Fraud and data quality. Misclassification — whether accidental or deliberate — is a persistent issue. A gambling operator incorrectly registered under a retail MCC circumvents issuer-side blocking controls and evades the higher interchange applicable to gambling transactions. Card schemes conduct periodic MCC audits and can levy fines against acquirers for persistent misclassification. Issuers and programme managers performing their own transaction monitoring should be alert to statistical anomalies such as very high average ticket sizes at otherwise low-value MCCs, which can indicate miscoding or transaction laundering.
EU Interchange Fee Regulation (IFR) — Regulation (EU) 2015/751. The IFR caps consumer debit interchange at 0.2 % and consumer credit interchange at 0.3 % of transaction value for domestic and cross-border transactions within the EEA. These caps apply at the MCC-agnostic level for standard consumer cards, but the IFR also permits MCC-specific exemptions and differential treatment for commercial cards and three-party schemes. Acquirers and processors must be able to report interchange by MCC category to demonstrate compliance, making accurate MCC assignment a regulatory data-quality obligation, not merely a commercial one.
PSD2 — Directive (EU) 2015/2366. Under PSD2's strong customer authentication (SCA) requirements, certain MCC categories are eligible for transaction risk analysis (TRA) exemptions or low-value exemptions. Issuers applying SCA exemptions must log the MCC of each exempted transaction, and the EBA's regulatory technical standards (RTS on SCA, published in Commission Delegated Regulation (EU) 2018/389) reference merchant category as a factor in fraud rate monitoring thresholds.
AML / CFT. FATF Recommendation 10 and EU AMLD5 / AMLD6 require payment institutions to apply enhanced due diligence (EDD) and ongoing transaction monitoring proportionate to risk. MCCs are a primary input into rule-based transaction monitoring systems: codes associated with gambling (7995, 9406), money services businesses (6099), and pawnbrokers (5933) are commonly designated as higher-risk categories requiring escalated review or customer notification. In the UK, the FCA's guidance on financial crime expects authorised payment institutions to maintain MCC-level monitoring logic. Firms offering white-label card programmes must ensure their programme management agreements clearly allocate responsibility for MCC-based monitoring between the BIN sponsor and the programme manager.
US context. In the United States, the Durbin Amendment (Dodd-Frank Act, §1075) caps debit interchange for covered issuers and similarly references merchant category logic in its network exclusivity provisions. The IRS uses MCC 5999 and related codes to determine Form 1099-K reporting thresholds for payment settlement entities.
Modern card issuing platforms expose MCC-level spend controls as a first-class feature, and fintechs have developed sophisticated programme architectures around them. The following use cases represent the most commercially significant applications.
Expense and corporate cards. Businesses deploying corporate expense cards typically configure an MCC allowlist or blocklist per card or card group. A software company might permit SaaS subscriptions (MCCs 5734, 7372), airlines (4511), hotels (3500-series), and restaurants (5812), whilst blocking fuel stations (5541), gambling (7995), and general merchandise stores (5310–5311). This policy enforcement happens in real time at the issuer's authorisation engine, so finance teams receive clean data without manual receipt reconciliation. Velocity limits can also be overlaid per MCC — for example, a £100 per-transaction cap at restaurants — giving programme managers granular cost control.
Gift and prepaid cards. Closed-loop gift card programmes routinely restrict cards to a single merchant or merchant group, but open-loop prepaid cards issued on Visa or Mastercard rails use MCC restrictions to define programme scope. A wellness benefit card might be limited to pharmacies (5912), gyms (7941), and health food stores (5499). Without MCC controls, open-loop cards would be functionally equivalent to general spending cards, defeating the purpose of the benefit and potentially creating tax complications for employers.
Rewards and cashback programmes. Interchange income is the economic engine behind cashback programmes, and MCC-differentiated interchange rates directly determine whether a rewards tier is economically viable. Programme managers model expected interchange yield by forecasting the spend distribution across MCCs in their target user base. A travel card that earns 3× points on airlines (MCC 4511) is underwritten by the higher interchange that airline transactions typically attract compared with grocery spend.
Crypto and stablecoin-funded cards. For cards funded from cryptocurrency or stablecoin wallets — where on-the-fly conversion occurs at the point of sale — MCC data is critical for two additional reasons. First, certain MCCs (quasi-cash, 6051) may trigger different conversion logic or be explicitly prohibited by the conversion provider's terms. Second, for tax reporting purposes in jurisdictions that treat crypto disposal as a taxable event, the MCC-coded transaction record provides the most granular audit trail of the spending category. Programmes built on white-label crypto card infrastructure must therefore retain MCC data in cardholder transaction histories.
AML transaction monitoring. Beyond the regulatory baseline, sophisticated programme managers build MCC-based behavioural scoring. A cardholder who predominantly spends at grocery and transport MCCs but suddenly executes a series of transactions at MCC 6011 (ATM) or 7995 (gambling) triggers a pattern-change alert. Linking MCC data with BaaS ledger records and IBAN inflow data creates a multi-dimensional monitoring view that is substantially more effective than amount-based rules alone.
Codego's card issuing infrastructure exposes MCC controls natively through its self-service programme configuration portal, giving programme managers point-and-click access to allowlists, blocklists, and per-MCC velocity limits without requiring custom API development. Because Codego holds BIN sponsorship arrangements with both Visa and Mastercard, programme managers benefit from access to both networks' MCC tables within a single integration — critical for programmes where interchange optimisation across schemes is a commercial priority.
For expense card and gift card deployments, MCC policy changes propagate to the authorisation engine in real time; there is no batch-window delay. Codego's crypto card programmes include explicit quasi-cash MCC handling, ensuring stablecoin-funded transactions at cash-adjacent MCCs are routed through the correct conversion and compliance pathways. Transaction data returned via webhook and reporting APIs includes the raw MCC field, enabling clients to build downstream monitoring and analytics without relying on category mapping performed elsewhere.
Codego's Banking-as-a-Service layer combines card transaction data — including MCC — with IBAN ledger movements and SEPA Instant payment records into a unified transaction history, providing the multi-dimensional view that effective AML monitoring requires. Programmes can be live in approximately 15 days — virtual cards on day one, physical cards by day 15 — with Apple Pay and Google Pay provisioning available within 24 hours of card issuance. To discuss MCC programme requirements, visit Codego's onboarding intake or explore the full core banking capability overview.