Beyond the BIN: How Programmatic MCC Blocking Protects Fintech Margins

Every card transaction begins with a number. Buried in the first six to eight digits of any card's PAN is the Bank Identification Number, the BIN, a small string that identifies the issuing institution and card type. For years, the BIN was treated as the frontline of card fraud defence. If a transaction's BIN matched your programme parameters, it passed. The logic felt solid. It was not.

The fraud problem in card issuing has since moved well beyond the BIN. Today's exploits target the space between authorisation and settlement: the grey zone where a transaction is approved before anyone has seriously evaluated what type of merchant accepted it, or whether that merchant category should have been accessible to that cardholder at all. This gap costs African businesses alone an estimated $3.90 for every dollar lost to fraud, according to LexisNexis Risk Solutions' 2023 True Cost of Fraud Study. The study, which surveyed over 1,800 fraud management decision-makers across the EMEA region, also found that digital channels now account for 52% of overall fraud losses on the continent, surpassing physical fraud for the first time.

For fintech startups building card programmes on top of BIN sponsorship relationships or card issuing APIs, this structural shift creates a specific operational hazard. The same digital rails that make virtual and physical card issuance fast and scalable also make them attractive targets for a class of fraud that static, post-authorisation review was never designed to stop.

The answer, increasingly, is programmatic Merchant Category Code blocking: MCC blocking baked into the API layer, executed in real time, before a single dollar clears.

The Anatomy of the Problem

When a cardholder swipes a card or enters card details online, the acquiring bank sends an authorisation request that contains several data points. One of the most consequential is the MCC, a four-digit code assigned to every merchant by Visa, Mastercard, or Verve that describes the nature of their business. Code 7995 is betting and gambling. Code 6211 is securities dealers. Code 5912 is drug stores and pharmacies. There are hundreds of them, and together they form a taxonomy of commercial activity that most card issuers barely use in real time.

The traditional model treats MCC data as retrospective intelligence. A transaction processes, the MCC lands in the settlement data, and a compliance team or automated batch process reviews it after the fact. If something looks wrong, a dispute is opened, a chargeback is filed, and the issuer absorbs the loss while fighting to recover funds that have often already moved. For large banks with deep float and established chargeback relationships, this friction is an accepted cost of business. For a fintech startup running a lean card programme, it is an existential threat.

Virtual card fraud sharpens this problem further. The card-not-present environment, where a 16-digit number, an expiry date, and a CVV are all that separate a fraudster from a successful transaction, creates velocity risk that physical card programmes manage with friction. A stolen or synthetically generated virtual card credential can be tested across dozens of merchant categories in minutes. Without real-time category controls, the issuer has no mechanism to stop it at the point of authorisation. They can only watch the damage accumulate in settlement data.

Chargeback fraud compounds the injury. The 2026 Global eCommerce Payments and Fraud Report by the Merchant Risk Council, which surveyed over 1,200 merchants across 37 countries, found that the average fraud rate by order rose significantly from 3.0% in 2025 to 3.5% in 2026, even as the incidence of individual fraud attack types fell. The data clearly shows that fraud is concentrating. Fewer attacks are landing, but the ones that do are heavier. Manual transaction monitoring, the primary response for most early-stage card programmes, was not designed for concentrated, high-velocity exploits of this kind.

The same report noted that 62% of fraud management professionals say that reducing time spent on fraud management will be a moderate or major factor in how they invest over the next two to three years. Startups are not just looking for better fraud tools. They are looking for fraud tools that do not demand a team.

Why Static Models Fail

A static fraud model is a model that does not change in response to the transaction context it is evaluating. A basic velocity rule, for instance, might flag any card that attempts more than five transactions in a 10-minute window. This catches some things. It misses many others. From standard practice, a fraudster who understands velocity thresholds will stay beneath them deliberately, and spread their attempts across time and merchant types to avoid detection.

The deeper failure of static models is categorical. If a prepaid corporate card programme has no controls on merchant category, a card issued for travel expenses can be used at a cryptocurrency exchange. A card issued for payroll disbursements can be used at a gambling platform. The BIN says the card is valid. The velocity rules say the transaction is within normal range. The static model approves it. The fraud, the policy violation, the compliance risk… none of it surfaces until settlement.

For programmes operating under AML/CFT obligations, this is not merely a financial loss problem. The Financial Crimes Enforcement Network has documented extensively how illicit actors exploit the gaps between transaction execution and compliance review. FinCEN's 2019 advisory on convertible virtual currency abuse identified the exploitation of unmonitored transaction flows as a core enabler of money laundering, sanctions evasion, and fraud. The advisory explicitly called out the risks posed by financial institutions that fail to implement appropriate controls before transactions execute, not after.

Regulators do not give credit for catching fraud in settlement data. The standard is whether controls existed at the point of authorisation. Static models, by design, cannot meet that standard consistently.

The problem is not that fraud teams are failing. The MRC's 2026 report found that 80% of merchants cite data and technology effectiveness as an area of difficulty, and that four of the six most common fraud management challenges are directly tied to data access and tooling quality. It’s crystal clear that professionals are not losing because they lack attention or effort. They are losing because the tools they are working with were built for a different transaction environment.

The Problem Is Where You Look

The fraud environment facing card issuing programmes has outgrown the tools most startups reach for first. Catching problems in settlement data, filing chargebacks, and building manual review queues are responses to a failure that has already happened. The more durable answer is architectural: it lives in how the authorisation infrastructure is designed, and specifically in what decisions it is capable of making before a transaction clears. That architecture starts at the Merchant Category Code layer, and it starts at authorisation, not settlement.

This is the first instalment in a three-part series on programmatic card controls for fintech infrastructure. Read the second instalment, The MCC Blocking Layer, for a detailed look at how this architecture actually works.