You changed your terms. What is your system still charging?

On 21 September 2026, New Zealand’s Financial Markets Authority issued a public warning to TSB Bank. For six years, from 30 November 2017 to 20 November 2023, TSB charged a 25-cent fee on some business cheque transactions that its own terms and conditions said should be free. More than 7,300 business customers were affected, and the bank refunded $1.73 million¹.

The terms were changed in November 2017 to clarify fees. The update left certain transactions out of the fee list. The bank’s systems kept charging for them¹.

What made this a rule past its date, not a bug?

Nothing in the system broke. The fee was once correct. Some earlier version of the terms said those transactions cost 25 cents, and someone built that into the system. In 2017 the reason for the charge ended. The rule did not.

Nobody was asked “does this still apply?” at the moment the terms changed, because the people who edit terms and the people who maintain billing logic do not share a checklist. TSB found the fault itself in August 2023 and switched the charge off in November 2023¹.

What did it cost beyond the refund?

The refund was $1,425,127 in fees, $10,404 in interest and charges, and $299,269 as compensation for the use of customers’ money¹. The regulator also weighed how long the overcharging lasted and the delays in reporting it and completing the refunds, and chose a public warning over further action¹.

The FMA’s comment sums up the exposure: “TSB’s customers had no practical way to check these fees for themselves, and the overcharging went on for six years”¹. Fees of 25 cents do not show up on anyone’s radar. That is why they last.

Which five questions can you run this week?

Pick the last three times your terms, tariff, fee schedule or policy changed. For each change, ask:

1. What did the old version charge, allow or promise that the new one does not? Write the difference as a list, not a summary.
2. Which rule in the system implemented each item on that list? Search the code, the config and the price tables for the fee, the threshold or the label.
3. Was that rule changed or retired on the same day? Check the date it last changed against the date the terms changed.
4. Who owns that rule today? A name, not a team. If the person who built it has left, ask who took over the area.
5. When is it next due for review? If the answer is “never”, the rule is already past its date.

Any rule where question 3 comes back “no” is a candidate for the same finding TSB received.

Where does a rule like this get caught?

Most companies catch it by accident: a customer queries a line on a statement, an internal audit samples a fee, or someone leaves and a successor reads the code. TSB’s own account is that it found the fault internally¹. It took six years.

How does AppThentic handle rules past their date?

om reads the rule in the system: what it charges, to which transactions, and since when. It also reads the terms you load as a source. Where they disagree, the rule is marked Disputed, with both sources side by side, until its owner settles it. When the reason for an approved rule changes, the rule becomes Stale and its owner is asked again. See When the system breaks a promise.

Every approved rule in Organization Memory also carries a review date set by its owner. om lists each rule past that date with its owner, its source and what it does today, and asks the owner one question: keep, change or retire? Keep sets a new review date. Change goes through change impact. Retire is recorded with who decided and when, and goes to the developer who owns the code. When the owner has gone, the question goes to whoever took over the area, with the original reason in the original owner’s words. See Rules past their date.

Leaders see every rule past its date, by area, with how long it has been overdue and who owns the answer.

What is the lesson for a company that is not a bank?

A terms change is a decision. A decision has consequences in code, and the code does not read the terms. The gap between the day a promise changes and the day the system follows is the part you control. At TSB it was six years.

To see this on your own systems, book a walkthrough.

Sources