Least-Cost Routing Logic in Multi-Rail Payment Networks
How the Durbin Amendment created opportunities merchants are still learning to capture.
None of this exists without the Durbin Amendment. Passed as part of Dodd-Frank in 2010, Durbin capped debit interchange for regulated issuers (banks over $10 billion in assets) at 21 cents plus 0.05% of the transaction. The cap alone would have been notable, but what made it structurally important sat right next to it: every debit card had to work on at least two unaffiliated networks, genuinely separate networks rather than, say, Visa plus a Visa subsidiary. That single requirement is the reason merchants have anything to route between at all.
Durbin also barred networks and issuers from overriding the merchant's routing choice, flipping a prior arrangement in which the issuer picked the rail and the merchant simply paid whatever that cost. At least for regulated banks, the merchant now controls that decision.
Small banks got carved out entirely, and this is where most routing pitches quietly fall apart. Issuers under $10 billion in assets aren't subject to the interchange cap, and their debit costs run closer to 0.8% to 1.0% plus 15 cents, numbers that look a lot more like credit card economics than capped debit. A merchant's routing engine can be as sophisticated as it wants; if the card came from a small community bank, Durbin savings mostly don't apply. Anyone promising uniform routing savings across a merchant's entire card mix is skipping this part, on purpose or by accident, and either way the number on the statement won't match the pitch.
For over a decade the rule sat frozen in the card-present world before catching up with how people actually shop now. In July 2023, the Fed's extension requiring online debit transactions, card-not-present transactions, to carry the same dual-network requirement took effect. On paper, that's a win for merchants running e-commerce volume. In practice, having the legal right to route CNP volume to a non-Visa/Mastercard network means little if the acquirer hasn't built the plumbing to do it. That plumbing takes real engineering time, sometimes years, and plenty of acquirers simply haven't finished the job. More on that gap later.
Then 2025 brought a complication worth sitting with: the Fifth Circuit vacated portions of Regulation II in August of that year. The ruling is stayed pending appeal, so the interchange cap and routing requirements stay in effect while the litigation plays out, but the appeal's outcome could reshape the framework merchants currently plan around. The regulatory floor created the savings opportunity in the first place; the technical and legal ceilings above it decide how much of that opportunity a merchant can actually reach. Durbin opened the door, and the shape of the room past it is still being litigated.
The money at stake before and after routing optimization
Durbin was estimated to save merchants around $9 billion a year when it took effect. That's the regulatory floor, and getting anywhere near it is on the merchant, which is why most of the work described in this piece exists: the floor and the ceiling are two very different numbers.
On the debit side specifically, CMSPI estimates U.S. merchants have pulled over $1 billion in annual savings out of debit routing alone. That's a real sum, and it's also unevenly distributed: some merchants are capturing a healthy share of that pool, and plenty are capturing none of it, sitting on a routing setup that hasn't changed since the integration was completed.
Federal Reserve data shows covered issuers absorb roughly 4.1 cents per transaction in authorization, clearing, and settlement costs, across more than 100.7 billion U.S. debit and prepaid transactions in 2023. Multiply a tiny per-transaction difference by a number with eleven digits and the sums stop looking small. The real question for any given merchant is how much of that pool the setup is actually reaching, and whether anyone on the finance team checked lately, or just assumed the integration handled it.
What a routing engine evaluates before selecting a rail
Before a routing engine compares a single cost, it answers a simpler and more boring question first: which rails are even legally and technically valid for this transaction? Eligibility comes before cost, and that order isn't negotiable. Eligibility checks need to be deterministic and auditable, because routing a transaction to a rail it wasn't eligible for is a worse outcome than routing it to an expensive but valid one. In regulated fintech, what a payment instruction is allowed to do gets constrained by more than whether the technical connection exists.
Once eligibility clears, the engine weighs a longer list of variables than most people assume: the interchange rate for that specific card type and ticket size, network fees layered separately on top, the signature-versus-PIN cost crossover point that shifts with transaction amount, whether the issuer is a regulated bank or falls under the small-bank carve-out, whether the card is present or the sale is happening online, and settlement timing that matters more to some merchants than others.
The differences show up clearest in examples. A $200 domestic consumer debit payment gets routed to whichever card network offers the best mix of authorization rate and interchange tier for that transaction. A $5,000 B2B invoice from a domestic vendor routes to ACH, because wire and card rails are needlessly expensive for that use case. A $500 contractor payment heading to the Philippines might route to a stablecoin rail if the recipient's wallet supports it, falling back to a traditional remittance provider if it doesn't. Three transactions, three different rails, one goal: the lowest total cost for a payment that actually succeeds.
Here's the part worth sitting with: at low ticket sizes, flat per-transaction fees dominate the math, so shaving a few cents off a fee matters enormously at volume. At high ticket sizes, the percentage-based interchange rate takes over, and a fraction of a percent swings real money. A well-built routing engine treats these as genuinely different problems, applying different logic across different price points, and that's exactly where static, one-size-fits-all routing setups fall apart first. Routing card-present debit to the PIN/EFT network over signature debit can save somewhere between 0.5% and 1.5% per transaction, though where in that range a merchant lands depends on every variable above.
The rails available in a modern multi-rail network and what each costs
Visa and Mastercard together handle the majority of U.S. credit card volume, and that dominance buys real value: chargeback protections, fraud liability shifts, universal consumer recognition. It also comes at the highest interchange cost in the stack, which is exactly why routing logic exists to go around it whenever a cheaper eligible rail is on the table. Treating card networks as the default rail rather than the expensive one is probably the single most common mistake in how merchants think about this, and it's worth saying plainly: card networks work better as the fallback than as the starting assumption.
Wire transfers sit at the other end of the value equation. Reliable and fast for large sums, though expensive: senders pay somewhere between $25 and $65 per transfer. Wires almost never show up as an LCR target; they're the rail used when speed and certainty matter more than cost, full stop.
ACH usually wins on cost for domestic B2B payments and payroll. The tradeoff is speed: standard ACH clears in one to two business days, a real cost in float and cash flow even if it never shows up as a line item on an invoice.
Real-time rails have grown fast enough that the numbers are worth pausing on. The Clearing House's RTP network crossed $1.3 trillion in payments during 2025, up 428% from the year before, averaging 1.3 million payments daily across more than 1,000 participating institutions. FedNow has grown to roughly 1,600 participating institutions. RTP supports payments up to $10 million; FedNow caps out at $500,000 by default. For merchants where settlement timing itself carries a cost, early payment discounts from suppliers, float management, that gap between the two ceilings is the whole reason to route one way over the other.
Stablecoins are the newest entrant here, and the one worth watching rather than betting the routing stack on just yet. B2B stablecoin volume hit $390 billion in 2025, up 733% year over year. That's a treasury-operations and cross-border-contractor-payments story more than a consumer retail one, and the relevance sits in settlement speed measured in seconds, something wires and ACH simply can't touch.
What this adds up to for routing logic: the option set has expanded well past the old signature-versus-PIN debit question. Each rail's cost, speed, and eligibility profile differs enough that no single lookup table handles the decision anymore. A merchant running 2015-era routing logic on a 2025 rail map is leaving money on the table.
How routing logic has evolved from static rules to machine learning
Static rule-based routing is where nearly every system started, and plenty still live there, mostly because nobody got around to updating it. The logic reads like a flowchart: if the card was issued in Germany, route to Acquirer A; if the amount exceeds some threshold, route to Acquirer B instead. It's simple, predictable, easy to audit, easy to explain to a compliance team, and it delivers a modest improvement in authorization rates over no routing logic at all. Its limits show up in what it can't adapt to, because a static rule never notices that one issuer's authorization rate drops every day between 2 and 4 a.m. Nobody wrote a rule for that, and a fixed flowchart won't write one on its own.
Static rules are a weak default for any merchant running meaningful CNP volume, full stop. They were built for a world with fewer rails and slower issuer behavior; that world is gone.
Machine-learning-based routing closes the gap by weighing every available signal at once and predicting the best route per transaction instead of following a fixed branch. ML-based routing modules examine historical transaction data in milliseconds, adding meaningful authorization improvement on top of whatever the existing rule-based system was already delivering. Purpose-built AI agents for payments teams have emerged that capture a large number of data points per transaction. The engine, in effect, went from reading a flowchart to running a live statistical model on every attempt.
Separate from routing choice but closely related: failover logic. If a processor comes back with a soft decline, a temporary issuer-side error rather than an outright rejection, the orchestration layer can retry the same transaction through a different processor before ever telling the merchant it failed. That's a safety net stitched underneath the routing decision, distinct from routing optimization in the interchange sense, but the two compound each other in practice: a transaction that fails over successfully still needs the right rail chosen on the retry.
Put it together and merchants report a meaningful immediate lift in authorization rates after switching on intelligent routing, with further gains compounding as the system builds up transaction history to learn from. The bigger story underneath all of this: routing behaves like a model that keeps training on live data, a setting that keeps shifting rather than one configured once during integration and forgotten. A routing setup left untouched for two years isn't neutral; it's actively falling behind whatever it could be doing.
What the Australian RBA data reveals about real-world LCR adoption and savings
Australia's central bank publishes the most rigorous independent dataset on how LCR performs once it leaves the whiteboard and meets actual merchants. It's central-bank-produced, merchant-level, and updated through 2024, about as close to ground truth as this topic gets.
The headline finding: merchants with LCR turned on pay close to 20% less to accept debit card transactions than merchants without it. That figure moves around by merchant size and pricing plan, but the direction holds across the sample, which is what makes a stat trustworthy rather than cherry-picked.
Card-present adoption climbed steadily. Half of Australian merchants had LCR switched on for in-person transactions in June 2022; by the end of 2024 that had risen to 76%. Real progress, worth noting, but it also means close to a quarter of merchants still haven't flipped the switch on the easier of the two use cases.
Card-not-present tells a rougher story, and this is where the data stops being an abstraction and starts naming names. Fat Zebra had the capability available for 100% of merchants and enabled for 100% of them, a clean sweep. Stripe made it available to 100% but only 76% had it turned on. Adyen offered it to 100% of merchants and just 26% were using it. Commonwealth Bank had it available to only 54% of merchants, with 10% enabled. ANZ Worldline sat at 2% available and 2% enabled, offering the capability in name only.
That spread is the whole lesson in one table, and the lesson is blunt: a feature announced in a press release is a different thing from a feature running on a merchant account. Availability sits far ahead of adoption almost everywhere in the sample, and even when a merchant wants to route CNP volume to a cheaper rail, and even when the rule exists on paper, savings only show up if the acquirer actually built the connection. Most acquirers in this sample hadn't, not fully. Implementation sophistication varies too: most payment service providers run something closer to a fixed default, routing everything to eftpos because it's cheaper on average, or routing by transaction size alone. True multi-variable optimization, the kind described earlier in this piece, remains the exception even in a market this far along.
For U.S. merchants watching the CNP extension take effect after July 2023, the Australian numbers read less like a coincidence and more like a preview. The extension created the legal right to route CNP debit to alternate networks. The Australian data shows, with actual figures rather than speculation, the wide gap that can separate a legal right from a working capability. That gap is exactly where savings quietly disappear.
Why a merchant's ability to capture LCR savings depends on their acquirer and processor setup
Everything above funnels into one bottleneck: the acquirer. A routing engine, however sophisticated, can only pick from rails the acquirer has actually connected and switched on for that specific merchant account. All the machine-learning models and eligibility logic in the world don't matter if the underlying connection to an EFT network doesn't exist on the processor's end. Working through the layers above, this looks like the single most overlooked point in the whole subject, and it explains why two merchants running the "same" routing setup can see completely different numbers on their statements. If there's one thing worth remembering from this whole piece, it's that the acquirer relationship matters more than the sophistication of the routing logic sitting on top of it. Merchants who shop for routing software before checking what their acquirer has actually built are solving the problem backwards.
On the U.S. debit side, card-present routing to PIN/EFT networks is mature technology at this point, and the 0.5% to 1.5% per-transaction savings mentioned earlier are genuinely available. They're just not automatic; someone has to configure them on purpose. Card-not-present routing is the harder case, requiring technical development that a meaningful share of acquirers haven't finished, and the Australian breakdown above puts real numbers behind a dynamic that plays out the same way in the U.S. market, just without a central bank publishing the receipts.
Tokenization adds another wrinkle specific to CNP. A network token issued by Visa or Mastercard doesn't automatically unlock routing to an alternate EFT network; the acquirer needs separate token infrastructure built for those networks specifically. Skip that step and the routing engine has nothing to route to, no matter how well the rest of the stack is built.
Pricing structure might matter more than any technical variable on this list, and it's the one merchants check last, if they check it at all. Interchange-plus pricing passes the actual routing outcome through to the merchant, so when the engine finds a cheaper rail, that savings shows up on the statement. Flat-rate or blended pricing absorbs the routing benefit into the acquirer's margin instead: the acquirer might be routing every transaction optimally behind the scenes, and the merchant would never see a cent of it, because the price was fixed before routing ever happened. A merchant on blended pricing asking for better routing is, in effect, asking the acquirer to do more work for the same fee. Ask, then, not just whether an acquirer supports LCR, but whether the merchant's own pricing plan lets any of that savings actually reach them, or just reach the acquirer.
Which leaves a short, practical list worth putting to any processor directly: which EFT networks are actually live for card-present transactions on this account, has CNP routing to non-Visa/Mastercard networks been built and switched on, and does the pricing plan run interchange-plus, or something flatter that quietly keeps the difference. Working back through everything above, the regulatory floor from Durbin created the opportunity. Whether a given merchant stands anywhere near it comes down to those three answers, not to the law itself.
