Short answer
A provider can change what it charges you without changing your contract, by quietly altering how the agreed terms get applied. A new fee type starts appearing. A transaction you always ran now resolves to a pricier tier. A rate steps up on a transaction profile that did not change. You catch it by comparing the terms in effect this period against the terms in effect last period, at the level of the individual transaction, rather than only checking each charge against a contract you assume is fixed. The contract is the thing that drifted. Detecting that drift is a different job from detecting a charge that broke a known rule, and it needs its own checks.
Why a schedule change is a different detection problem
Most fee detection assumes a fixed baseline. You know the contract, you reconstruct the expected charge for each transaction, and you flag any charge that does not match one of the known discrepancy types. That works when the terms hold still and only the charges misbehave.
A quiet schedule change breaks that assumption. Here the terms themselves moved, so a charge can match the new, worse terms perfectly and still be wrong against the deal you actually agreed to. Checking each charge against the current schedule will not catch it, because the current schedule is the problem. The only way to see it is to treat the schedule as something that can change, and to watch for the change.
That is the shift. Ordinary detection asks whether a charge broke the rules. Change detection asks whether the rules moved.
The effective-rate trap
A schedule change usually announces itself as a rising effective rate. Your blended cost ticks up, and it feels like proof that something changed. Treat that feeling carefully. A rising effective rate is a reason to look, and it is not evidence of anything on its own. The blend moves for a dozen innocent reasons: your transaction mix shifted, a bigger share ran on a costlier method, volumes moved between regions. Any of those raises the effective rate without a single term changing.
So use the effective-rate move as a trigger, never as the finding. When the blend rises, that is the signal to go down to the transactions and ask which specific terms drifted. The answer to that question is where the evidence lives. The effective rate only tells you to start looking.
The four change signatures
A schedule change shows up in the data as one of a few recognisable shapes. These examples are illustrative, meant to show the shape of each signature rather than to state a real rate.
A fee type that never appeared before
The clearest signature. A line item shows up on transactions that never carried it: a new surcharge, a new handling fee, a new network cost passed through. The tell is a fee category with a start date. Group your fees by type and look for a type whose first-ever occurrence is recent. A fee that did not exist last quarter and does now is a schedule change rather than a one-off error.
A transaction type reclassified to a pricier tier
Subtler, because the fee looks familiar. The same kind of transaction you always ran is now being priced under a different, costlier category than before. Nothing on the transaction changed, but its assigned tier did. The tell is a shift in which pricing bucket a stable transaction profile lands in. Compare how a representative transaction was classified this period against how the identical profile was classified last period. A move to a worse tier, with the transaction unchanged, is a reclassification.
A rate stepped up on a fixed profile
The rate for a specific, unchanging transaction profile simply increased. Not a drift over many months, but a step: last period this profile priced at one rate, this period at a higher one. The tell is a discontinuity on a fixed profile. Hold the transaction profile constant, plot its rate by period, and look for a step. Because the profile is fixed, the step cannot be explained by your own mix, which is what makes it a term change.
A threshold quietly narrowed
The rule stayed, but its boundary moved. A volume band that used to earn a lower rate now starts higher, or a discount that used to apply now needs more to qualify. The tell is the same activity earning a worse rate than it did, at a boundary you did not renegotiate. Compare the thresholds that governed your pricing this period against the ones that governed it before.
The change signatures at a glance
| Signature | What moved | The tell in the data | How you check |
|---|---|---|---|
| New fee type | A charge category that did not exist | A fee type with a recent first-ever occurrence | Group fees by type, find recent first appearances |
| Tier reclassification | The category a transaction is priced under | A stable transaction profile now in a costlier bucket | Compare this period's classification of a fixed profile to last period's |
| Stepped rate | The rate on a fixed profile | A discontinuity, not a gradual drift | Hold the profile constant, plot rate by period, find the step |
| Narrowed threshold | The boundary of a pricing rule | The same activity earning a worse rate at an unchanged boundary | Compare the thresholds in effect period over period |
How you actually catch it
The method behind all four is the same. You cannot detect a change against a single snapshot of the terms, because a snapshot has nothing to compare to. You need the terms as a versioned thing: what the schedule said last period, what it says this period, resolved down to how each transaction is actually priced. Then you compare period over period at transaction grain and read the differences.
This is why a schedule change slips past ordinary reconciliation. A monthly reconciliation checks this month's charges against this month's understanding of the terms, so a term that changed under you is invisible to it. The change only appears when you hold two periods side by side and ask what moved. Run that comparison continuously and a schedule change surfaces in the period it happens, while there is still time to raise it.
From a detected change to evidence
Finding the change is the start. Turning it into something a provider will act on is the same standard as any credible fee-dispute evidence: it has to be deterministic, traceable, per-transaction, and reproducible. For a schedule change, that means naming the exact term that moved, showing the before and the after with the dated versions that hold each, and pointing to the transactions priced under the new term. A dated before-and-after on a specific term, reproducible against the provider's own records, is hard to wave away. An effective-rate chart is not.
That is the job Bluefyn is built for. Bluefyn reconstructs the contract into an expected charge for every transaction, and because it holds the contract as versioned terms, it surfaces when those terms drift from one period to the next and flags the change for you to act on. It analyzes transaction and provider data. It never moves, holds, or custodies funds. It shows you the schedule changed, with the proof attached. What you do with that, you decide.
Frequently asked questions
How do I know if my payment provider changed my fee schedule?
You compare the terms in effect this period against the terms in effect last period, resolved to how each transaction is actually priced, rather than only checking charges against a schedule you assume is fixed. Look for four signatures: a fee type that never appeared before, a transaction type now priced under a costlier tier, a rate that stepped up on an unchanged transaction profile, and a pricing threshold that quietly narrowed. Each is a way the agreed terms can move without a formal contract change.
Isn't a rising effective rate proof my fees went up?
No. A rising blended effective rate is a reason to investigate, not proof of anything. The blend can rise because your own transaction mix shifted, more volume ran on a costlier method, or activity moved between regions, all without a single term changing. Use the effective-rate move as the trigger to go down to the transactions and find which specific terms drifted. The evidence is in the term-level change, never in the blended number.
How is this different from ordinary fee-leakage detection?
Ordinary fee-leakage detection tests each charge against a known, fixed contract and flags charges that break the rules. Change detection asks whether the rules themselves moved. A charge can match the new schedule perfectly and still be wrong against the deal you agreed to, so checking against the current schedule cannot catch it. Change detection compares the terms period over period, which is a separate check from comparing a charge to a contract you assume is holding still.
Why doesn't monthly reconciliation catch a schedule change?
Because a monthly reconciliation checks this month's charges against this month's understanding of the terms. If a term changed under you, both sides of that check already reflect the new term, so nothing looks wrong. The change is only visible when you hold two periods side by side and ask what moved between them. That period-over-period comparison, run at transaction grain, is what a single-period reconciliation never performs.
What proof does a provider accept for a schedule change?
The same standard as any credible overcharge claim: deterministic, traceable to the specific term, at the transaction level, and reproducible against the provider's own records. For a schedule change that means the exact term that moved, the dated before-and-after versions, and the transactions priced under the new term. A reproducible before-and-after on a named term is hard to dismiss. A chart of your effective rate rising is not, because the provider can attribute it to your own mix.
