How Did My Bank Know It Wasn’t Me?

What travels when you tap, insert or type your card?

What can make a payment look unusual?

Why can the bank block a payment that really was yours?

The bank is balancing two costly mistakes. Approving fraud can lose money and expose a customer. Blocking a genuine purchase can embarrass and frustrate the customer.

The system therefore uses thresholds. A low-risk payment may pass immediately. A medium-risk payment may trigger an OTP. A very high-risk payment may be declined.

This is not proof that the bank “knows” who is holding the card. It is a risk decision made from limited evidence.

What actually happens after you tap your card?

You see a beep and wait for the word Approved. Behind that moment, the payment terminal packages the amount, merchant, time and card details into a secure request. That request travels to the merchant's payment provider, through the card network and toward the bank that issued your card.

The bank checks whether the card is valid, whether enough funds or credit are available, whether the transaction breaks a rule and whether the behaviour resembles previous activity. The response then travels all the way back. The shop does not directly take money from your account at the moment of the beep; it receives permission to continue with the payment process.

One unusual clue may be harmless; several together may change the decision

Buying petrol in Cape Town after buying groceries nearby is ordinary. Buying an expensive television in another country five minutes later may be impossible according to distance and time. A large amount is not automatically fraud, and a foreign purchase is not automatically fraud. The concern often comes from the combination.

The system does not see a person standing at a till — it sees a structured record

When the payment request reaches the bank, software turns it into fields that computers can compare. Think of it as one new row arriving in a very large table.

Developers first teach the system clear rules

Some fraud checks are ordinary programming rules written by software developers and risk specialists. A rule is an instruction that says: when a particular condition is true, add risk, request verification or stop the transaction.

riskScore = 0;

if (amount > customerAverageAmount * 5)
    riskScore += 20;

if (isNewDevice)
    riskScore += 15;

if (distanceFromLastPurchase > 1000 && minutesSinceLastPurchase < 30)
    riskScore += 40;

if (failedAttemptsInLastTenMinutes >= 3)
    riskScore += 30;

if (riskScore >= 60)
    decision = "Decline or verify";

This is not the bank's real code. Real systems contain far more checks, safeguards and exceptions. But the principle is accurate: developers convert business knowledge into conditions the software can execute in milliseconds.

The rules also need context. A R20,000 purchase may be unusual for one account but completely normal for another. The programmer therefore does not simply write if amount is high, decline. The rule often compares the new amount with the customer's own history, the merchant type and other signals.

The system creates new measurements called features

The raw transaction says “R2,450 at 02:17.” By itself, that is not enough. Software calculates additional values that make the pattern easier to recognise. In machine learning these calculated clues are often called features.

This is where databases and programming work together. The application receives the new transaction, queries recent history, performs calculations and passes a compact set of clues to the decision engine.

A machine-learning model looks for combinations too complex to write as individual rules

Rules are powerful, but criminals change behaviour. Developers cannot manually write every possible combination. Machine learning helps by studying large collections of past transactions that were later confirmed as genuine or fraudulent.

During training, the model is shown examples and learns which combinations often appear before fraud. It may discover that a new device is usually harmless, but a new device combined with a late-night purchase, rapid retries and a high-risk merchant is much more concerning.

The model does not normally return the sentence “This is definitely fraud.” It returns a probability or risk score. For example, the system may estimate that the transaction is much more similar to previous fraud than to the customer's usual behaviour.

Many small signals become one risk score

Imagine the transaction begins at zero. Different parts of the system then contribute evidence.

The exact numbers and methods vary by institution. The point is that the decision is usually based on accumulated evidence rather than one dramatic clue.

Several software components cooperate before the card machine finishes beeping

This is software architecture in action. Different programs have different jobs, but they exchange information through carefully designed messages and application programming interfaces. Speed matters, but reliability matters just as much: the system must not approve the same request twice, lose the audit trail or expose sensitive card data.

The final truth may arrive hours or days later

At the moment of payment, the system only makes a prediction. Later, the customer may confirm “Yes, that was me” or report fraud. Investigators may also identify a compromised merchant or a group of linked transactions.

Those outcomes become feedback. Data teams use confirmed examples to test rules, retrain models and adjust thresholds. Developers then release updated software through controlled testing because a small change can affect millions of genuine payments.

This learning loop explains why fraud detection is not a single piece of AI. It is an entire system involving programmers, databases, cybersecurity specialists, data engineers, machine-learning models, operations teams and human investigators.

Why can a genuine payment still be declined?

No detection system sees the full story. The bank may know that the transaction is unusual but not that you have just landed in another country, bought a new phone or decided to make a once-off expensive purchase. It must make a quick decision using incomplete information.

That creates a trade-off. If the bank is too relaxed, fraud passes through. If it is too strict, genuine customers are interrupted. Extra verification—such as an app approval, one-time PIN or call—is a way of asking for one more strong clue before deciding.

One answer opens another door

The system you have just followed depends on other systems. Choose the next hidden story.

If location can help a bank detect fraud, how does your phone know where you are?

The same location clues that can protect a payment also help navigation services estimate movement, traffic and arrival times.