How Flexibl Detects Interchange Downgrades

The standard answer to how you find interchange downgrades is that you read the interchange detail report. For a single merchant that is enough. Someone pulls the report, sees the non-qualified line items, and knows what they are looking at.

It stops working the moment you are a platform. The report is not the constraint. A downgrade is only visible as a comparison, and across thousands of sub-merchants that comparison has to be cut narrowly enough to show anything at all. The real question is what you compare against, how fast you find out, and what you do with a finding once you have one.

What does detecting an interchange downgrade actually mean?

Detection in most software means catching an error. A downgrade produces no error. The transaction is authorized, cleared, settled and paid. The network does not reject it. It rates it at the punitive end of the schedule and passes it through, and nothing says anything went wrong.

So detecting a downgrade is not exception handling. It is comparison. You take the interchange program the transaction was actually rated into, which is in the settlement record, and compare it against the program it should have qualified for. That second half is not in the record. It comes from the network’s published rules and rate tables, and from what the network knows about the merchant, starting with the category code it was boarded under.

That is the mechanical core, and it is why the work is heavier than reading a report. For one transaction the comparison is straightforward. For a portfolio it happens a few million times.

Worth saying what this piece is not about. Processor contract drift is a different cost found a different way, because there you hold the contract and the comparison runs against a document you signed. Interchange has no such document. The rules belong to the network.

Every transaction, as it settles

We analyse interchange at settlement. The rate is not something anyone forecasts in advance, because it is decided at clearing, and once it is decided it gets paid. Nothing about that transaction is recoverable.

What changes is resolution. Instead of waiting for a batch, a volume threshold, or someone noticing a margin problem, every transaction is examined as it settles and carries its own rating. It is identified as downgraded at that point, not inferred later from an aggregate that finally moved.

That matters because of the next transaction, not the one you just lost. If the cause is fixable, every similar transaction after the fix rates correctly.

Then comes the part that does not reduce to a checklist. Isolating a downgrade is one job. Finding the cause is another, and the cause is not always in the transaction. Sometimes it is: the verification data that was passed or not passed, the enhanced data on a commercial card, how the clearing record was built. Often it sits outside it, in the category code the merchant was boarded under, the transaction volume, how the merchant is sized, or whether the card was tokenized. Which of those applies depends on the vertical, the integration and the provider in the chain.

That is also why two merchants downgrading under the same label can be downgrading for different reasons. The label tells you the rating that was applied, not what caused it. A pattern across the portfolio gives you a hypothesis, and validation on that merchant’s own data is what turns it into a cause you can act on.

A downgrade is a penalty. An optimisation is not.

These get filed together under interchange optimization and they are two different jobs.

A downgrade means something failed. The network still processes the transaction and prices it at the worst end of the grid because a requirement was not met. There is a fault, and somebody owns it.

An optimisation is not a penalty. Nothing failed, the transaction rated exactly as it should have, and a better rate exists that the platform has not reached. That is a cost-benefit question, not evidence anything is broken.

Only one of the two says something in the setup stopped working, which is why the distinction matters when you go looking for causes. Sorting findings into one bucket or the other comes first, because the two lead to completely different work: a downgrade sends you looking for what failed and who owns it, an optimisation sends you to a cost-benefit question about reaching a programme you are not on.

Why does a downgrade have to be caught before it moves your margin?

Because by the time it moves your margin, it is no longer small.

A platform above thousands of merchants has a blended cost of payments that is stable by construction. Normal merchants mask abnormal ones, so a downgrade affecting one slice of volume does not register in the portfolio number. The margin looks fine and nobody has a reason to look.

Here is where that becomes expensive. Suppose a platform opens a new market. Nobody anticipated the share of foreign cards it would bring, the configuration was never set up for them, and those transactions start downgrading. Or commercial card data is not passing correctly and business card volume rates into standard. Either way the slice is small at first, portfolio margin is still positive, and nothing is visible at the level anyone is watching.

But the acquisition strategy is working, so the slice is growing. By the time the margin line drifts far enough to notice, the cost problem is the size of the new market rather than the size of a pilot.

Catching that at one percent of volume rather than fifteen is what early detection means here. Not predicting the rate on a transaction. Seeing a pattern while it is still too small to reach the number you report. That only works at a cut fine enough to show it: per merchant, per interchange plan, per card type, per region, not at the portfolio average designed to smooth exactly this.

It is also why this is an ongoing job rather than a project. A review tells you what is wrong on the day you run it. Portfolios do not hold still: merchants are added, card mix moves, a market opens, an integration changes, and any of those can start a downgrade that stays invisible for months. The work is not finding the problems that are already large. It is watching for the ones that are not yet.

How the analysis runs, and who built the method

The framework is not ours. Interchange analysts have been building and refining these methods for decades, and they work. The constraint was never the quality of the analysis. It was the size of the job: millions of rows across thousands of merchants, each needing its own aggregation before a single conclusion is available. Done properly on one account, that is real analyst time before anyone has an answer.

Which is why interchange analysis has always been run the way expensive things get run. On the largest accounts, where the volume justifies the hours. Once a quarter, or once, when somebody already suspects a problem. Almost never on the mid-sized merchant whose foreign card volume started downgrading last month.

What changed is the operational cost of the work. Preparation and calculation, where most of the hours went, now cost a fraction of what they did, and when that number falls far enough the analysis stops being something you ration. It becomes something you run across every merchant, every month.

The sequence we encoded is the one a good analyst already follows. Prepare the data first: aggregate by interchange plan, by merchant, by network, by everything a solid interchange analysis rests on. Nothing useful happens before that step is done properly. Then triage, then investigate the cause.

What AI changes is throughput, not method. A payments specialist still validates whether a finding is real and whether it should be acted on. The analyst does not disappear. They stop spending the week on aggregation and spend it on the findings.

Recognition buys something else. Because these failure modes repeat across platforms, a downgrade rarely arrives as a blank question. It comes with a probable cause attached and a rough size, because the same shape has been seen before. That is what makes prioritisation possible at all, since you cannot sequence findings by impact unless you can estimate the impact before doing the work to confirm it. It stays a hypothesis until it is validated on that merchant’s own data.

Priority goes to impact. Findings with real cost behind them get worked first, because a fix always costs something and that cost has to stay well under what it returns. The rest stays on the list. A platform that wants its interchange fully clean will work through the small items eventually. It is a question of sequence, not of what counts as a finding.

The constraint nobody puts on the vendor checklist

Detection at settlement assumes the data arrives. That is not a given.

One platform we work with had an abnormally high downgrade volume with real cost behind it. The cause sat with the provider, the fix was straightforward, and it shipped in early July. Then the loop stalls, because that platform receives its data monthly on a lag. July’s data arrived in mid-September. The fix worked and a large share of the downgrades disappeared, but confirming it took six weeks longer than building it did.

No analysis changes that, and it is not universal. Where a provider exposes settlement data through an API, a fix can be confirmed in the next cycle. Where it arrives as monthly files on a lag, confirmation waits, and the difference belongs to the provider rather than to the analysis.

The ceiling is the data, not the tooling. Which makes one thing a strategic choice most platforms never treat as one: how close to the transaction your payment partners deliver your data. It is rarely on the list when a provider is selected, and it becomes visible the first time you try to prove a fix worked.

What this comes down to

Interchange arrives. It was always going to arrive, and once it has, it gets paid. Nothing recovers a transaction that already settled. The only thing you can change is whether the next one like it rates correctly, and how long it takes you to find out that it did not.

So the question worth putting to a portfolio is not what interchange cost last month. It is how small a problem you can see, and how quickly you can see it.

At Flexibl we sit between the data and the finished analysis: the part that decides what a downgrade means, who owns the cause, and whether it is worth moving now or later.

If you want to see your own portfolio at per-merchant, per-plan resolution, book a walkthrough.

FAQ

How do you detect an interchange downgrade? By comparing the interchange program a transaction was rated into, which appears in the settlement record, against the programme it should have qualified for, which comes from the network’s published rules and from how the merchant is set up. A downgraded transaction settles normally, so detection is comparison rather than exception handling.

Can interchange downgrades be detected in real time? They can be identified as soon as the transaction settles, provided the settlement data is available that quickly. Interchange is not predicted before the transaction is rated. Where a provider delivers data monthly on a lag, the delay in the data sets the limit, not the analysis.

Why don’t interchange downgrades show up in a platform’s margin? A portfolio blends thousands of merchants, so a downgraded slice is masked by the volume around it. The cost becomes visible when it is cut per merchant, per interchange plan and per card type, early enough to act before a growing pattern reaches the blended number.

What is the difference between a downgrade and an interchange optimisation? A downgrade means a requirement was not met and the network rated the transaction at a worse rate. An optimisation means nothing failed and a better rate is available but has not been reached, usually depending on programme enrollment or provider support. The first is a fault with an owner, the second is a cost-benefit decision.