A Suspicious Credit-Card Cancellation at FNB: What Happened and Why It Concerned Me

An unexpected card cancellation, an unsolicited replacement card and unusual support advice raised serious questions about process integrity and fraud controls. This article separates what I observed from what I could not establish.

Original incident date: 9 November 2024

Article type: Incident analysis / commentary

Executive summary

On 9 November 2024, I discovered that my FNB credit card had been cancelled as "lost" even though I had not reported it lost. A replacement card had been issued, and during a support interaction I was advised to activate that replacement even though I did not physically possess it.

Those events were sufficiently unusual that I asked for the matter to be escalated as a possible fraud or control failure.

I do not have evidence proving that an FNB employee attempted to steal money from my account. What I do have is a sequence of events that, in my view, deserved a documented investigation: an unexplained cancellation, a newly issued card, advice to activate a card I did not possess, and no clear explanation of who initiated the original cancellation.

The broader security lesson is simple: when normal banking systems are unreliable or confusing, customers can struggle to distinguish operational failure from fraud. That ambiguity creates risk.

What happened

I had been making a number of relatively large payments on my credit card. I then received an SMS saying that a new credit card had been issued on my account.

I initially ignored the message because replacement and renewal communications from banks are not always clear, and I had no immediate reason to believe my existing card had been cancelled.

Later, when I attempted another payment, the 3-D Secure verification process failed and I was instructed to contact the bank.

I contacted FNB through the secure chat function in the banking application. During that conversation I was eventually told that my credit card had been cancelled because it had supposedly been reported lost.

I had not reported the card lost.

The support agent then called me. I was told that the matter would have to be escalated to determine why the card had been cancelled. During that conversation I was also advised that I could activate the newly issued card and then cancel it again, despite the fact that I did not have that card in my possession.

I declined to do that.

Fortunately, I had a second card available and was able to activate it instead.

I explicitly told the support representative that I was concerned about possible fraud and wanted the incident escalated. I also asked to be copied on the escalation by email.

At the time I wrote the original article, I had not received the requested written escalation.

What I know

The following points are based on my direct experience:

These facts are concerning on their own. They do not require a theory about insider fraud to justify investigation.

What I do not know

There are several things I could not establish:

Those unknowns matter. In security analysis, an unexplained event should not automatically be converted into an allegation.

My hypothesis at the time

My concern was that a replacement-card process could potentially be abused if an attacker were able to trigger a replacement and persuade the legitimate customer to activate a card they did not possess.

That would be a serious control weakness if it were possible.

However, this remains a hypothesis, not a finding. The proper way to resolve it would be through the bank's audit trail: who initiated the cancellation, what authentication was used, where the card was sent, who accessed the account record, and what internal actions followed.

Why this matters beyond one account

The incident highlighted a broader problem I had experienced with banking support and transaction verification: unreliable processes become normalised.

When customers repeatedly encounter failed authentication prompts, delayed messages, inconsistent support channels or confusing system behaviour, they become conditioned to treat unusual events as ordinary technical problems.

That is dangerous.

A secure banking environment should make anomalous events stand out. Customers should be able to answer basic questions quickly:

If those questions cannot be answered reliably, the system is creating ambiguity that attackers can exploit.

What good control would look like

A mature card-management process should provide strong controls around high-risk events such as card cancellation, replacement, activation and delivery.

At a minimum, I would expect:

Conclusion

I originally wrote about this incident because I was angry and concerned. Those concerns remain legitimate, but the strongest version of the story is not "bank staff stole my money." I cannot establish that.

The stronger and more defensible conclusion is this:

A security-sensitive banking process behaved in a way I could not explain, and the support process did not give me enough evidence or assurance to understand why.

That is a control problem in its own right.

When financial institutions design systems that customers cannot reliably distinguish from fraudulent behaviour, they weaken one of the most important defences against fraud: the customer's ability to recognise when something is wrong.