Least Cost Routing and Interchange Fees: Card Payment Cost Architecture (2026)

A merchant that sells a 100 euro item on a card does not receive 100 euro. Somewhere between 0.2% and several percent disappears into a fee stack that most engineering teams never model, even though it is usually the second or third largest line in the cost of goods after logistics. The stack has three layers owned by three different parties, set by three different mechanisms, and only one of them is something your architecture can steer.

Least cost routing is the practice of sending each card transaction down the path with the lowest total fee, subject to the constraint that you must not lower the approval rate. It sounds like a simple lookup. In practice it depends on knowing the card’s identity, the network options on it, the acquirers you can reach, the fee schedule each one charges, and the probability that each will approve. This article treats it as a systems design problem: what the fees are, which rules shape them, how to model them, and how to build a routing layer and a reconciliation loop around them.

This is architecture analysis, not financial, legal or compliance advice. Fee levels and rulings change; verify them against the primary sources linked below before relying on them.

What this covers: the four-party fee stack, blended versus interchange-plus pricing, regulatory caps in the EU, UK and US, co-badged cards and the debit routing rules, Level 2 and Level 3 data, the routing engine design, a runnable cost model, settlement-file reconciliation and the failure modes that make a cheap route expensive.

Context and Background

Card payments run on what the industry calls the four-party model. The cardholder holds a card from an issuer, the merchant is signed up with an acquirer, and a card scheme such as Visa or Mastercard sits between the two banks and defines the rules, the messages and the settlement. Every card payment is a transfer of value from the issuer side to the acquirer side, and the merchant is paid net of the fees along the way.

Three charges stack up on each transaction. The interchange fee flows from the acquirer to the issuer and compensates the issuer for funding, fraud and rewards. Scheme fees, sometimes called assessments, flow from both banks to the network for access, authorization and clearing. The acquirer markup is the acquirer’s own margin and processing cost. The sum of the three is the merchant service charge, which is what appears on the merchant’s invoice in some form.

Interchange is by far the largest component, and it is not one number. Networks publish hundreds of interchange categories that vary by card type, region, entry mode, merchant category and the data supplied with the transaction. The same 100 euro basket can cost 0.2% or 2% depending on which category the transaction lands in, which is why the architecture matters. Our earlier articles on ISO 8583 versus ISO 20022 card messaging describe the authorization and clearing messages that carry the fields used to qualify a transaction for a category, and the piece on the card issuing processor architecture shows the same flow from the issuer side.

Regulators have intervened in interchange more than in almost any other price in retail finance. The European Union capped consumer card interchange in Regulation (EU) 2015/751, which entered into force on 9 December 2015. The United States capped debit interchange for large issuers through the Durbin Amendment and the Federal Reserve’s Regulation II. Credit card interchange in the US is not capped by statute and is instead shaped by network rules and antitrust litigation. Each regime changes which part of the stack your system can optimise.

The architectural consequence is that cost is not a property of the card or of the acquirer alone. It is a property of the tuple of card, route, data quality and contract. A routing layer that sees only the acquirer’s headline rate is optimising the wrong variable.

The Fee Stack: Where Each Basis Point Goes

Direct answer: a card payment’s cost is interchange (paid to the issuer, set by the scheme or by regulation), plus scheme fees (paid to the network), plus acquirer markup (negotiated). Only the markup is freely negotiable. Interchange and scheme fees are set by rule, so cost control comes from routing, data quality and pricing transparency rather than from haggling over them.

Figure 1: The four-party fee stack. Interchange flows to the issuer, scheme fees to the network and markup to the acquirer, with the merchant paid net.

The figure shows who receives which slice of the merchant’s discount. The merchant sends 100 and receives 100 minus the sum of three flows. The acquirer settles with the scheme net of what it owes the issuer, so the issuer’s interchange is in effect deducted from the acquirer’s payment and the scheme fees are billed separately. From the merchant’s side none of this is visible unless the pricing model exposes it.

Interchange: the dominant and least negotiable cost

Interchange is set per category, as a percentage of the transaction plus sometimes a fixed amount. The rate depends on the card (consumer or commercial, debit or credit, standard or premium), the region (domestic, intra-regional or inter-regional), the channel (card present, card not present, recurring), the merchant category and any data-quality qualifiers. In regulated markets the consumer debit and credit categories are capped by law and the unregulated ones, commercial cards and cross-border transactions with non-EEA cards, remain high.

The worked example below uses invented but plausible rates to show the shape. These are illustrative numbers, not any scheme’s actual published rates.

Component (illustrative)	Consumer debit EEA	Consumer credit EEA	Premium commercial, inter-regional
Interchange	0.20%	0.30%	1.90% plus fixed fee
Scheme fees	about 0.03% to 0.10%	about 0.03% to 0.10%	about 0.10% to 0.30%
Acquirer markup	0.10% to 0.40%	0.10% to 0.40%	0.20% to 0.60%

The point of the table is the spread. On a consumer EEA card the regulated interchange is small enough that the acquirer markup and scheme fees can equal or exceed it. On an inter-regional commercial card interchange dominates and the markup is a rounding error. A single blended rate hides both facts.

Scheme fees: many small line items

Scheme fees are a long list of per-transaction and percentage charges: authorization, clearing, cross-border, currency conversion, tokenization, fraud monitoring, assessments on volume. Each scheme publishes a fee guide to members, and acquirers pass these through or fold them into the markup depending on the pricing model. Because the line items are numerous and change twice a year in most scheme cycles, scheme fee drift is a standard cause of reconciliation breaks. A routing layer cannot choose its way out of them, but it can model them, for example by noticing that a token-based credential or a particular network changes the fixed per-authorization charge.

Acquirer markup: the one number you negotiate

The markup is the acquirer’s margin plus its processing cost: authorization routing, fraud screening, settlement, chargeback handling, scheme compliance and the risk reserve against merchant default. It is expressed as a percentage plus a per-transaction fee and it can be tiered by volume, by card type or by region. Markup is where multi-acquirer strategies bite, because a second acquirer with a lower markup in one corridor changes the optimal route for that corridor even when interchange is identical.

Understanding the three layers separately is what makes the pricing models comparable, which is the next topic.

Blended Pricing versus Interchange-Plus: What You Can Actually See

Direct answer: blended pricing charges one flat rate across card types, so the acquirer keeps the spread between that rate and the real cost. Interchange-plus pricing, also written IC+ or IC++, passes interchange and scheme fees through at cost and adds an explicit markup. IC+ is more transparent and is the only model in which least cost routing savings reach the merchant.

Under blended pricing a merchant pays something like 1.5% plus a fixed fee on everything. The acquirer absorbs the variation: a cheap domestic debit card subsidises an expensive foreign commercial card. This is simple to budget and nearly impossible to optimise, because lowering the true cost of a transaction by routing it better does not change the invoice. The saving is retained by the acquirer, who has no incentive to share it.

Under interchange-plus pricing the invoice separates the lines. One variant, usually called IC+, bundles the interchange and scheme fees into a pass-through and adds one markup. The other, IC++, itemises interchange, scheme fees and markup separately. IC++ is the form that lets a finance team verify each line against the published interchange schedule and the scheme fee guide.

In the European Union, Article 9 of the Interchange Fee Regulation requires acquirers to offer and charge merchant service charges individually specified by card category and brand, unless the merchant requests blended charges in writing, and to state interchange and scheme fees per category and brand in the contract. The official text on legislation.gov.uk shows this Article as retained in UK law; the EU version has the same unblending principle. The practical meaning is that a European merchant has a legal right to unblended pricing, and a payment team should ask for it before asking for a routing engine.

Model	What the merchant sees	Who keeps routing savings	Fits when
Blended flat rate	One percentage plus fixed fee	Acquirer	Low volume, simple budget
Tiered (qualified, mid, non-qualified)	Three or so buckets	Mostly acquirer	Legacy US contracts
IC+	Pass-through plus one markup	Merchant	Mid volume, some visibility
IC++	Interchange, scheme, markup separate	Merchant	High volume, audited cost

The tiered model deserves a warning. Buckets such as qualified, mid-qualified and non-qualified are defined by the acquirer, not by the networks, and the acquirer decides which real interchange categories fall into which bucket. A transaction that earns a low interchange rate can be billed in the mid bucket if the acquirer’s mapping says so. The only defence is reconciling the invoice against the underlying network categories, which is exactly the loop described later.

A rough break-even helps. Suppose a merchant processes 20 million euro a month at a blended 1.30%, which costs 260,000 euro. If the true weighted average cost is interchange 0.55%, scheme fees 0.08% and the acquirer would accept a 0.20% markup, the IC++ total is 0.83% or 166,000 euro. These numbers are invented to show arithmetic. The saving of 94,000 euro is available only because pricing exposed the components, and routing improvements would add to it rather than being absorbed. If the merchant’s mix is dominated by cheap EEA debit, the gap widens; if it is dominated by premium commercial cards, it narrows.

Regulatory Caps: EU, UK and US

Direct answer: the EU caps consumer debit interchange at 0.2% and consumer credit at 0.3% of the transaction value, the UK retained the 0.2% debit cap for domestic UK transactions, and the US caps debit interchange for issuers over 10 billion dollars in assets through Regulation II. Credit interchange is uncapped in the US, and several rules are in flux as of this writing.

Figure 2: How regulation shapes the cost surface. Capped consumer categories sit beside uncapped commercial, cross-border and US credit categories, and routing choice only exists where more than one network is enabled.

European Union

Regulation (EU) 2015/751 capped interchange for consumer cards at 0.2% of the transaction value for debit and 0.3% for credit. Member states could set lower caps, and the Regulation covers transactions where both the issuer and acquirer are in the Union. The caps do not cover commercial cards, and they do not cover transactions with cards issued outside the EEA, which is why those remain the expensive categories. The Regulation also separated the payment card scheme from processing entities and prohibits rules that stop an issuer placing more than one brand or application on a card. The 0.2% debit figure appears in Article 3, as reproduced in the UK-adapted text on legislation.gov.uk, and the 0.3% credit figure is the Article 4 value; confirm both against the consolidated EUR-Lex text.

United Kingdom

After Brexit the UK retained the Regulation as domestic law with a 0.2% cap for UK debit card transactions, with the Treasury given powers to adjust. The Payment Systems Regulator ran a market review of UK-EEA cross-border interchange fees. According to the PSR’s own page, last updated October 2025, its final report found weak competitive pressure on Mastercard and Visa that let them raise these fees to an unduly high level, with an estimated cost to UK businesses of 150 to 200 million pounds a year. The PSR decided not to proceed with an interim cap because of litigation over its powers, and said it would set a long-term cap only after completing a methodology consultation. So at the time I checked, no cross-border cap had been set. Read the PSR market review page for the current position.

United States

The Durbin Amendment limits debit interchange for issuers with 10 billion dollars or more in assets, and exempts smaller issuers, reloadable prepaid and government-administered programmes. Under the Federal Reserve’s rule the maximum per transaction is 21 cents plus 0.05% of the value, plus a one-cent fraud-prevention adjustment for issuers that meet the standards. On a 50 dollar transaction that is 21 cents plus 2.5 cents plus 1 cent, or 24.5 cents, consistent with commentary that quotes this example.

Three things are in motion, and they should change how you design, not what you ship today. First, in October 2023 the Fed proposed lowering the cap to 14.4 cents plus 0.04% plus a 1.3 cent fraud adjustment; the Fed’s own page lists the proposal and I found no evidence it had been finalised. Second, on 6 August 2025 the US District Court for the District of North Dakota in Corner Post, Inc. v. Board of Governors vacated Regulation II’s fee standard as contrary to the statute, but stayed its own vacatur pending appeal, so the 21 cent cap still applies. Law-firm and trade-press summaries report the appeal went to the Eighth Circuit; sources I read differ on the oral argument date (February or May 2026) and I found no reported decision. Third, a revised Visa and Mastercard merchant class settlement received preliminary approval from Judge Brian Cogan on 9 June 2026, reported to cut interchange by 0.1 percentage point for five years, cap standard consumer card rates at 1.25% for eight years and loosen Honor All Cards and surcharging rules. It is preliminary, objectors plan challenges, and I did not read the order itself.

The design lesson is that fee tables must be data, versioned and effective-dated, never constants. A court ruling or a settlement can move a rate on a date your code did not anticipate.

Debit routing and network exclusivity

Regulation II has a second half that matters to routing. Issuers and networks may not restrict a debit transaction to fewer than two unaffiliated networks, and may not inhibit a merchant from routing over any network the issuer has enabled. A 2022 amendment clarified that this applies to card-not-present transactions, with a compliance date of 1 July 2023. The court’s vacatur concerned the fee standard, and secondary sources say the routing rules were not struck. For a US merchant this means that many debit cards carry a global brand and at least one other debit network, and the merchant can choose between them. That choice is the US form of least cost routing.

Co-Badging and Least-Cost Routing in Practice

Direct answer: a co-badged card carries two payment applications, usually a global scheme and a domestic or regional debit scheme, so the same card can be routed down either. Least cost routing picks the application with the lowest total fee that the merchant is allowed to choose, and it only works where regulation or scheme rules preserve merchant choice.

Article 8 of the EU Regulation prohibits scheme rules that stop an issuer placing two or more brands on a card, requires non-discriminatory routing and technical rules, and says issuers, acquirers and processors must not add mechanisms that restrict which brand the payer or payee can use. Payees may set a default priority by an automatic mechanism but the payer can override it. Read the text on legislation.gov.uk for exact wording. The two rights are different: the cardholder may choose at the terminal, and the merchant may set the default.

The routing decision therefore has two inputs. The first is what applications the card exposes, which comes from the BIN range metadata, the EMV application selection at a terminal, or a token’s network list online. The second is the fee for each, which comes from the contracts. Interchange on a domestic debit scheme can be lower or higher than on the global brand’s regulated rate, and scheme fees differ. A rule that always picks the domestic debit scheme can be wrong when the global brand’s scheme fee is negligible and its authorization rate is higher.

The sequence below shows an online decision for a co-badged card.

Figure 3: Sequence for a co-badged card. The router resolves the BIN, prices each eligible application, applies approval-rate guardrails, then authorizes and falls back if declined.

Three details separate a good implementation from a naive one. The router must treat the BIN table as a refreshable dataset and expect stale entries, since BIN ranges are reassigned and new co-badge arrangements appear. It must apply the cardholder’s explicit choice when one was made, because overriding it breaks the Regulation and the user’s expectation. And it must record the decision and its inputs on the transaction so the finance team can later compare the predicted fee to the settled fee.

For cards with a network token, the same logic extends to the credential itself. A token provisioned for one network cannot be sent unchanged to another, and token-based flows can carry different scheme fees and different authorization rates. Our piece on network tokenization architecture covers why a routing layer must know which networks a stored credential is provisioned for before it offers them as candidates.

Level 2 and Level 3 Data: Qualifying for Cheaper Interchange

Direct answer: for commercial, purchasing and corporate cards, supplying extra data fields with the transaction can qualify it for a lower interchange category. Level 2 data adds fields such as tax amount and customer reference. Level 3 adds line-item detail. The saving depends on the scheme’s current programme, so treat it as a data-quality feature with a measurable payoff, not a constant.

Interchange categories for business cards often contain a “large ticket”, “purchasing card” or “data-rich” tier with a lower rate than the standard commercial tier, available only when the clearing record carries the extra fields and meets format rules. Level 2 typically means a sales tax amount, a tax-exempt indicator and a customer or order reference. Level 3 typically adds product codes, descriptions, quantities, unit costs and freight and duty amounts. The exact fields, thresholds and rates differ between Visa and Mastercard and change over time; consult the current scheme interchange programme guide before building to a field list.

For an engineer this is a data pipeline problem. The checkout system knows the line items, but the clearing file is generated downstream by the acquirer or processor. If the field is dropped, truncated or mis-formatted anywhere on the path, the transaction downgrades silently to the standard category and the merchant simply pays more, with no error. The fix is to treat qualification as a testable property:

Carry structured line-item data through the payment request, not as free text.
Validate field presence, length and numeric formats before submission, using the processor’s documented schema.
Compare the interchange category returned in settlement reporting to the one you expected, and alert on downgrades.
Segment cost by card type, because only business and purchasing cards benefit.

A consumer-heavy merchant gets almost nothing from Level 3. A B2B seller with a large share of commercial cards can get a real reduction, but the saving applies only to the portion of volume that is a commercial card and passes validation. An illustrative case: 5 million euro a month of commercial card volume, a hypothetical 0.4 percentage point difference between standard and data-rich categories, gives 20,000 euro a month, and a downgrade rate of 15% from data errors would hand back 3,000 of it. The numbers are invented; the model is the point, because it tells you whether to invest in the data pipeline.

Payment Orchestration: Designing the Routing Layer

Direct answer: a payment orchestration layer sits between checkout and one or more acquirers, and applies a rules engine to choose the route per transaction using cost, approval-rate and availability signals. It cascades to a second route on soft declines or outages, and records every decision so the outcome can be audited and the rules tuned.

Our article on smart order routing engine architecture covers a related problem in securities markets: score venues, split flow, handle partial failures. Payment routing has the same skeleton with different objectives. The inputs are the card, the amount, the currency, the channel and the merchant’s contracts. The outputs are a chosen route, an ordered fallback list and a record of why.

Figure 4: A payment orchestration layer. A rules engine consults a versioned fee table and a rolling approval-rate store, dispatches to acquirer connectors and feeds settled costs back from reconciliation.

Rules engine: static policy first, scoring second

Start with deterministic rules that encode constraints you cannot violate: honour the cardholder’s chosen application, do not route to an acquirer that does not support the currency, respect data residency, do not send a token to a network it is not provisioned for. Only after those constraints cut the candidate set should cost and approval rate rank what remains. Mixing constraints into a scoring function makes the system hard to explain and hard to audit when a regulator asks why a payment was routed as it was.

Within the remaining candidates a simple objective works well: expected net cost equals the fee for that route plus the cost of a failure multiplied by the probability of failure. If a route costs 0.10 euro less on a 100 euro transaction but has a 2 percentage point lower approval rate, the expected loss is 2% of the margin on a 100 euro sale. For a merchant earning a 30% gross margin that is 0.60 euro, so the cheaper route is more expensive in expectation. This is the central trade-off, and it is why least cost routing that ignores approval rate is a trap. The margin figures are illustrative.

Cascading and retries

When an authorization fails you have to decide whether to try another route. Hard declines, such as stolen card or invalid account, should never cascade, since retrying is useless and may breach scheme rules on repeated attempts. Soft declines, such as issuer unavailable or do-not-honour for generic reasons, are candidates. Each scheme publishes decline-code and retry guidance, and some impose limits and fees on excessive retries, so cascading logic must be bounded and checked against current rules. Cascading to a different acquirer for the same card is also not free: the second attempt may incur a second authorization fee, and a duplicated authorization on the cardholder’s account must be reversed. Use idempotency keys and an explicit reversal on the first route before a second attempt, as with the patterns in our retries and circuit breaker guide.

Fee tables as versioned data

The fee service holds, for each acquirer and network, effective-dated rows keyed by card type, region, channel and qualifier, with a markup component and a pass-through component. When the scheme publishes a new interchange file or a regulatory change lands, a new version becomes effective on a date, and a transaction is priced against the version in force at its authorization time. Keep the previous versions for reconciliation, since a transaction authorized on one date may clear on another.

Approval-rate store

Approval rates are noisy and conditional. Keep rolling windows by segment (acquirer, BIN range, issuer country, amount band, channel), with enough volume per segment before a rate is trusted. A route should not be demoted on 12 declines out of 40. Use a shrinkage estimate: blend the segment rate with the parent segment’s rate in proportion to the sample size. And hold out a small exploration share of traffic on the less preferred route, otherwise the store never learns when a route improves.

Cost Model in Code

The sketch below prices candidate routes for a transaction and ranks them by expected net cost. Every number in the fee table is invented for illustration; nothing here is a real scheme rate.

from dataclasses import dataclass

@dataclass
class Route:
    name: str
    interchange_pct: float      # e.g. 0.002 for 0.20%
    interchange_fixed: float    # currency units
    scheme_pct: float
    scheme_fixed: float
    markup_pct: float
    markup_fixed: float
    approval_rate: float        # rolling estimate in [0, 1]

def fee(route: Route, amount: float) -> float:
    pct = route.interchange_pct + route.scheme_pct + route.markup_pct
    fixed = route.interchange_fixed + route.scheme_fixed + route.markup_fixed
    return amount * pct + fixed

def expected_net_cost(route: Route, amount: float, margin_pct: float) -> float:
    """Fee when approved plus margin lost when declined (no recovery assumed)."""
    p = route.approval_rate
    lost_margin = (1.0 - p) * amount * margin_pct
    return p * fee(route, amount) + lost_margin

routes = [
    Route("global_brand_acq_A", 0.0020, 0.00, 0.0008, 0.020, 0.0020, 0.05, 0.915),
    Route("domestic_debit_acq_A", 0.0020, 0.00, 0.0003, 0.010, 0.0015, 0.04, 0.905),
    Route("global_brand_acq_B", 0.0020, 0.00, 0.0008, 0.020, 0.0012, 0.03, 0.912),
]

def rank(routes, amount, margin_pct=0.30):
    return sorted(routes, key=lambda r: expected_net_cost(r, amount, margin_pct))

for amt in (20.0, 100.0, 400.0):
    best = rank(routes, amt)[0]
    print(f"amount={amt:>6.2f} best={best.name} fee={fee(best, amt):.3f} "
          f"expected_cost={expected_net_cost(best, amt, 0.30):.3f}")

Running the sketch with these invented inputs shows the effect that matters. At small amounts the fixed components dominate, so the route with lower per-transaction fees wins. At larger amounts the percentage terms and the approval-rate gap take over, and a cheaper but less reliable route loses. The ranking is not stable across amounts, which is why a static “always route to acquirer B” rule leaves money on the table in both directions.

Two practical notes on the model. First, the lost_margin term assumes a declined customer is lost; if the checkout retries successfully on another route, replace it with the probability that the cascade recovers. Second, this is a per-transaction calculation. At scale you also have volume tiers: sending more to one acquirer may unlock a lower markup band, so a global optimiser sometimes accepts a slightly worse per-transaction route to hit a tier. Model that as a monthly constraint rather than inside the hot path.

Reconciling Settlement Files to Fee Schedules

Direct answer: reconciliation compares what you predicted a transaction would cost, from the fee table at authorization, with what the acquirer actually charged, from the settlement and interchange reporting files. Differences are classified by cause: wrong category, fee table drift, scheme fee changes, data downgrades or acquirer error. Without this loop, routing optimisation runs on assumptions.

The inputs are three datasets. The first is your own authorization log with the decision record from the router: the chosen route, the predicted fee and the version of the fee table. The second is the acquirer’s settlement report, usually a daily file at transaction level listing the amount, the card brand, the interchange category and fee, scheme fees and the markup. The third is the invoice or monthly statement. Formats are proprietary and vary from CSV to fixed-width, so a normalising ingestion step is the unglamorous core of the system.

Join on a stable identifier. Authorization IDs, acquirer reference numbers and network transaction IDs (the trace identifier a scheme assigns) are common keys, and no single one is reliable across all acquirers, so keep a mapping table and fall back to a composite of amount, timestamp window and last four digits of the card with care for collisions. Only then compare predicted to settled fee, line by line, and bucket the delta.

Typical delta causes are worth coding as explicit classes rather than a single “variance” number:

Category mismatch. The transaction settled in a more expensive interchange category than predicted, often because of missing qualifier data, a late capture or a wrong merchant category code.
Table drift. The fee table was stale, a scheme update landed or a regulatory change shifted a rate and the router priced with the old version.
Scheme fee line items. Fixed charges for tokens, cross-border or currency conversion that the model did not include.
Timing. Authorized on one date, cleared on a later date, with a different fee version in force or a different currency rate.
Acquirer error. A charge inconsistent with the contract, which only IC++ transparency lets you detect.

The output of reconciliation is not a report. It feeds back into the fee service as corrections to the mapping, into the data pipeline as qualification fixes and into the acquirer relationship as claims. A variance threshold, such as flagging any day where realised cost deviates from predicted by more than a small fraction of a percentage point, turns it into an alert rather than a monthly surprise.

A small piece of tooling pays for itself early. The function below computes the predicted-versus-settled delta per category from two normalised frames:

import pandas as pd

def cost_variance(auth: pd.DataFrame, settled: pd.DataFrame) -> pd.DataFrame:
    """auth: txn_id, predicted_fee, expected_category
       settled: txn_id, actual_fee, actual_category"""
    m = auth.merge(settled, on="txn_id", how="inner", validate="one_to_one")
    m["delta"] = m["actual_fee"] - m["predicted_fee"]
    m["category_changed"] = m["expected_category"] != m["actual_category"]
    out = (m.groupby(["expected_category", "actual_category"])
             .agg(txns=("txn_id", "count"),
                  total_delta=("delta", "sum"),
                  avg_delta=("delta", "mean"))
             .reset_index()
             .sort_values("total_delta", ascending=False))
    return out

# Unmatched rows are as informative as matched ones:
# auth minus settled = not yet cleared or dropped; settled minus auth = unknown spend.

The diagnostic is the cross-tab. If transactions you expected in a data-rich category land in the standard one, you have a qualification defect and a dollar figure for it. If everything shifted by a constant amount on one date, you have a fee table version problem.

Trade-offs, Gotchas, and What Goes Wrong

Least cost routing is easy to oversell, and several of its failure modes are quiet. Treat the following as a pre-mortem.

Optimising the wrong variable. Cost savings of a few basis points are easily erased by a one point approval-rate drop. A route that is cheaper by 0.05% on a 100 euro sale saves 5 cents. A route that declines one more sale in a hundred costs the margin on that sale. The cost model above makes the exchange rate explicit; use it, and measure authorization rate by segment before and after any change, with a holdout.

Merchant choice is a regulated right, not a free lever. In the EU the cardholder’s choice at the terminal and the merchant’s default are both protected. A router that silently overrides a cardholder’s choice to save a few cents risks breaching Article 8. Capture which party chose the application and log it.

Stale fee and BIN data. Interchange and scheme fee schedules change on scheme calendars, BIN ranges change continuously, and a court or regulator can move a rate. A router is only as good as its freshest table. Version, effective-date and monitor them, and alert on unknown BINs rather than defaulting to a route.

Cascading can raise cost and risk. A second attempt may generate a second authorization fee, a duplicate hold on the cardholder’s funds, and in some scheme programmes a penalty for excessive retries. Do not cascade on hard declines, limit attempts, and reverse the first authorization before sending the second where the rules require it.

Blended contracts hide the savings. If you are on a flat rate, routing improvements flow to the acquirer. Renegotiate pricing before building the router, or you build a cost-saving engine for someone else.

Volume commitments. Multi-acquirer strategies often collide with tiered pricing and minimum volume commitments. Splitting traffic can lose a discount band that outweighs the routing gain. Model the monthly constraint, not just the per-transaction cost.

Regulation in flux. The US debit cap is under litigation and a replacement rule could change the cost ordering of networks. The merchant settlement is preliminary. The UK cross-border review has not yet set a cap. Build the system to absorb a rate table change on any day, and avoid encoding today’s ranking as a constant.

Latency and availability. An extra BIN lookup, fee computation and rules evaluation sits in the authorization path. Keep the data local and cached, set a hard time budget, and fall back to a safe default route if the engine times out. Optimisation must degrade to the plain path, never to a failure.

Explainability. When a fee dispute or a regulator’s question arrives, you need the reason a transaction took a route, including the rule version and fee table version. Log the decision record, not just the outcome.

Practical Recommendations

Sequence the work by return on effort. The largest and cheapest gains normally come from pricing transparency and data quality, with routing logic as the third step.

First, get the contract into a form you can audit. Ask for IC++ or at least unblended pricing, with interchange and scheme fees itemised by category and brand, which the EU framework already entitles European merchants to request. Second, build the reconciliation loop, since it tells you whether your fee model is true and where leakage sits. Third, fix data qualification for commercial cards if your mix includes them. Only then add a rules engine to choose between networks or acquirers, starting with the constraints, then expected-cost ranking, then a small exploration share.

Keep the hot path simple. Fee tables should be pushed to the router as immutable versions, evaluated locally and logged. Approval-rate statistics should be updated asynchronously and bounded in influence. And plan for a handful of rate changes a year as normal operations, not incidents.

Checklist

[ ] Pricing is IC+ or IC++ with itemised interchange, scheme fees and markup.
[ ] Fee tables are versioned and effective-dated, with a documented source for each rate.
[ ] BIN and network-availability data refresh automatically, with an alert for unknown ranges.
[ ] The router logs chosen route, alternatives, rule version, fee table version and who chose the application.
[ ] Hard declines never cascade; soft-decline cascades are capped and reversal-safe.
[ ] Approval rate is measured per segment with a holdout before any cost-driven change.
[ ] Reconciliation compares predicted and settled fees daily and classifies the delta.
[ ] Level 2 and Level 3 fields are validated before submission for commercial card volume.
[ ] Regulatory changes (Regulation II litigation, UK cross-border review, settlement terms) are on a watch list with owners.
[ ] The engine has a time budget and a safe default route.

Frequently Asked Questions

What is least cost routing in card payments?

Least cost routing is choosing, for each card transaction, the network or acquirer path with the lowest total fee, subject to constraints such as cardholder choice, token compatibility and approval rate. It applies where a card carries more than one network, as with co-badged cards, or where a merchant can reach several acquirers. It saves money only when pricing is itemised, since under blended pricing the acquirer keeps the difference.

What is the difference between interchange fees and scheme fees?

Interchange fees are paid by the acquirer to the issuer and compensate the issuer for funding, fraud and card benefits. Scheme fees are paid to the card network, such as Visa or Mastercard, for access, authorization, clearing and related services. Interchange is usually the larger amount and is capped for consumer cards in the EU, UK and for large US debit issuers. Scheme fees are published in network fee guides and change periodically.

Is interchange-plus pricing always cheaper than blended pricing?

No. Interchange-plus passes through the real cost plus a visible markup, so it is cheaper when your card mix is dominated by low-cost categories such as regulated consumer debit, and can be dearer when the mix is mostly expensive categories and the blended rate was set low. Its advantage is transparency, which lets you verify charges and capture routing savings. Compare the two on your own transaction mix before choosing.

Does the Durbin Amendment still cap US debit interchange in 2026?

According to the sources I reviewed, yes, the cap of 21 cents plus 0.05% of the transaction, with a one-cent fraud adjustment, remained in force. A North Dakota federal court vacated the Fed’s fee standard in August 2025 but stayed its ruling pending appeal to the Eighth Circuit, and I found no reported appellate decision. A Fed proposal to lower the cap in 2023 was not finalised. Verify the current status before relying on it.

Can merchants route co-badged cards to the cheaper network?

In many cases, yes, but with limits. In the EU, Article 8 of the Interchange Fee Regulation protects both the cardholder’s choice of brand and the merchant’s right to set a default priority, with the payer able to override it. In the US, Regulation II requires at least two unaffiliated debit networks per card and bars restricting merchant routing. Check that the route you choose does not override a cardholder’s explicit selection.

How do Level 3 data fields reduce card acquiring costs?

For commercial and purchasing cards, providing Level 2 fields such as tax amount and Level 3 line-item detail can qualify a transaction for a lower interchange category than the standard commercial rate. The saving applies only to eligible card types and depends on the network’s current programme. Because missing or badly formatted fields silently downgrade the category, validate the data and compare the settled category against the expected one.

Interchange Fees and Least-Cost Routing: Card Payment Cost Architecture (2026)