Most transaction-monitoring teams do not suffer from too few alerts; they suffer from too many irrelevant ones. Fixed rules — an amount ceiling, an unusual hour, an unfamiliar destination — produce a daily list longer than any analyst can review, and new fraud patterns pass through exactly that noise.

What separates a machine-learning model from a fixed rule is the reference it measures against. A rule compares every transaction to a predetermined threshold; a model compares it to the normal behaviour of that particular customer. A withdrawal that is entirely ordinary on one account is a clear deviation on another. Shifting the reference both lowers the number of false alerts and surfaces genuine cases earlier.

Three applications that pay off first

• Real-time fraud detection: scoring each transaction against that customer's behavioural pattern before the transfer becomes final.
• Credit scoring: adding transaction history and repayment behaviour to traditional criteria, especially for applicants with no formal credit file.
• Automated response: taking routine questions — balance, instalment status, account-opening documents — off the call centre so staff reach the complex cases.

Why decision speed is now a financial issue

As instant payment spreads, the gap between a transaction being made and the money becoming unrecoverable has shrunk to seconds. A system that delivers the suspicious list the next morning produces a report, not prevention. The same logic holds in lending: an application that sits in a review queue for two weeks has usually reached a competitor before it reaches your decision. The core value here is not automation but a shorter distance between the event and the decision.

The narrow line between a right alert and a nuisance

Every fraud system makes two kinds of error and both cost real money: the fraudulent transaction that slips through, and the good customer whose card is blocked for nothing. Setting a threshold means choosing deliberately between the two, not driving either to zero. The practical route is a tiered response: let low-risk cases through with a second-factor confirmation, send higher-risk ones to an analyst, and reserve a full block for the top tier. Track two measures side by side — the share of genuine cases caught and the share of innocent customers disturbed — because improving one at the expense of the other is not an improvement.

Why it matters for Iranian SMEs

Iran's payment market runs on a high volume of small transactions, and that volume is precisely what makes manual review impossible, while also supplying the data a model needs. For a smaller institution the important point is that this data is not somewhere else: it is already recorded in your core system and only needs organising. Starting requires no large budget; it requires one defined process, clean data, and a manager with the authority to decide.

A 90-day route to start

• Days 1–30: pick one channel and place last year's confirmed fraud cases next to ordinary transactions; without those labelled examples no model has anything to learn from. Record the baseline at the same time: current losses and the daily alert count.
• Days 31–60: run the model in shadow mode, scoring in parallel with the current system without stopping any transaction. Compare the two outputs weekly.
• Days 61–90: if the model performed better in shadow, enable it for a small share of traffic and keep the final decision with an analyst. If it did not, review data quality and the problem definition rather than enlarging the model.

Frequent mistakes

• Going live without a shadow period; the first noisy error destroys internal trust for months.
• Judging the model on overall accuracy alone; where almost every transaction is legitimate, a model that calls everything legitimate also scores high.
• Delegating credit rejections to a model when the reason for rejection cannot be explained to the applicant.
• Training once on old data and leaving it there; fraud patterns change and a model without retraining decays.

Three actions for this quarter

• Identify the costliest fraud type of the past year and start with that single type.
• Consolidate confirmed fraud cases into one table; that asset is worth more than any tool you buy.
• Record two numbers before you start: monthly losses and the number of alerts that go unreviewed.

Frequently asked questions

• What if we do not have enough recorded fraud cases?
  You can begin with anomaly-detection methods, which measure deviation from normal behaviour instead of relying on labelled examples; but start recording analyst verdicts from day one, because those become next year's training data.
• Does the model have to explain its decision?
  In lending, yes, and that is a professional obligation rather than a technical preference; a rejection must have a statable reason. In fraud detection, explainability matters for analyst review but the bar is lower.
• Does the data have to leave our core system?
  No. Training and serving a model on internal infrastructure is entirely feasible, and for customer financial data that is usually the right choice.

Takeaway

In finance and banking, AI does not solve a new problem; it solves the permanent ones — fraud losses, default risk, the support queue — at a scale manual review cannot reach. The institutions that got results early were not the ones that spent most; they chose one defined process, recorded its baseline, and kept the final decision with a person.

Glossary

• False alert: a legitimate transaction flagged as suspicious, costing analyst time and customer goodwill.
• Anomaly detection: an approach that flags deviation from normal behaviour instead of recognising a known fraud pattern.
• Shadow mode: running a new model alongside the live system without letting it affect real decisions.
• Credit score: a number estimating the likelihood that an applicant repays on time.
• Default: a borrower's failure to meet a repayment obligation.
• Baseline: the recorded value of a metric before a change, so improvement can be measured.