Anti-scam layer: how the operator can actually protect the customer from fraud

Scale of the problem

By indirect observation phone fraud cases in the region are rising significantly. Several common patterns:

“Call from the bank”. The fraudster claims to be a bank agent, talks about suspicious transactions, gets the customer’s card details or OTP.

“Law enforcement officer”. The fraudster claims to be an investigator or tax inspector, threatens, demands an “urgent transfer” to a “safe account”.

“Relative in trouble”. The fraudster claims to be a relative in an emergency, demands an urgent transfer.

“Romance scam”. A long phone and text engagement to build trust, ending with a transfer request.

“Job scam”. A job offer with upfront payment for “training” or “materials”.

Each of these patterns leaves traces in the operator’s network — patterns in call metadata, texts, usage. Detect these patterns before they reach the customer and fraud can be prevented far more effectively than through post-incident education.

What the operator does today

In most regional operators anti-scam protection is fragmented and largely reactive.

Customer complaints. The customer complains — the number goes on a blacklist. Slow and partial.

Manual investigation. The security team investigates suspicious patterns, reacts to incidents. Manually intensive.

Education campaigns. The operator sends SMS and push: “do not share your data”, “banks do not call asking for this”. Useful but marginal — the customer gets so many communications that education is easily ignored.

Cooperation with the regulator. When the regulator asks for specific numbers to be blocked, the operator complies.

What is usually missing — proactive real-time pattern detection with automated blocking or customer alerts.

What a proactive anti-scam layer means

A real anti-scam layer rests on four components.

Pattern detection. Real-time analytics over call metadata to recognise known patterns. For example, a number calling hundreds of customers in a short time with brief conversations — fraud distribution. Or a number that just received a SIM and within an hour makes mass calls with template scripts — fraud setup.

Blocking at network level. Once a pattern is identified, the operator blocks calls from that number before they reach the customer. At network level, with no customer action.

Real-time alerts. If a pattern is ambiguous but suspicious, the customer gets a warning at call time (“this call has fraud indicators, we recommend not sharing personal data”) or immediately afterwards.

Cross-operator cooperation. Fraudsters quickly switch SIMs across operators. Defence effectiveness rises sharply when multiple operators share signals in real time.

These four together create a protective layer that meaningfully changes the customer experience.

What often becomes a barrier

Technically:

Real-time analytics over all calls is a serious infrastructure load. Many operators do not have the capacity in real time.

ML models for pattern detection require labelled data — known fraud cases. The base usually exists but is not collected systematically.

Operationally:

Blocking numbers is an operational risk. A wrongly blocked legitimate number generates a customer complaint and a potential legal issue. The threshold has to be conservative.

Customer education versus network blocking. Education positions “the customer should protect themselves”. Blocking positions “the operator protects the customer”. Different customer promises with different operational discipline.

Regulatorily:

Right to block. The regulator may have a view on the conditions under which the operator can block. Without regulatory clarity the operator can land in a grey zone.

Cooperation between operators. Sharing signals between competitors requires a cooperative agreement.

What a working anti-scam looks like

A hybrid approach — automation and review. Automated blocking for clear-cut cases, manual review for ambiguous ones. A balance between effectiveness and error risk.

Customer notification. The customer sees “you received a fraud attempt and we blocked it”. This builds a sense of protection and educates the customer.

Cross-operator signals. Agreements with the regulator and other operators on a shared anti-scam database.

Regular updates. Fraud patterns evolve. Detection rules have to be updated at least every 1-2 months.

In-the-moment customer education. Not “general SMS, do not do X”, but “you just received a call we blocked as fraud — here is what it was”. Contextual education is more effective.

A realistic 18-month plan

Months 1-6. Foundation. Audit current anti-scam capability. Build a labelled dataset of known fraud patterns. Initial ML models. Cooperation negotiations with other operators and the regulator.

Months 7-12. Pilot. Deploy detection in read-only mode. Does not block, generates alerts. Threshold calibration.

Months 13-18. Active blocking. Deploy in production for clear-cut cases. Manual review for borderline. Customer notification flow. Cross-operator signal sharing if an agreement is reached.

By month 18 the operator has a working anti-scam layer that protects the customer in real time and measurably reduces fraud incidents.

What often goes wrong

Threshold set too aggressive. Legitimate traffic gets blocked, customer complaints rise, the programme retreats.

Threshold set too conservative. Real fraud is not blocked, the programme looks cosmetic.

Cross-operator cooperation does not materialise. Without it each operator addresses only its part and fraud migrates between networks.

Regulator not engaged. After 6-12 months the regulator may impose restrictions that retroactively break the programme.

No customer notification. The programme protects the customer, but the customer does not know. The trust effect is lost.

Detection without regular updates. Within 6 months the model goes stale on new patterns and effectiveness drops.

When not to launch now

If a real-time analytics technical foundation does not exist, foundation build is 9-12 months. Without it detection does not work.

If cooperation with other operators is in principle impossible (politics, competition), effectiveness is limited to one operator’s scope.

If the regulator is not ready for an operator-as-blocker model, the programme is in a legal-risk zone.

If customer support cannot absorb additional complaints from false positives, the programme creates operational chaos.

If C-level is not ready to take on the reputational risk if something goes wrong, the programme stays on paper.

Discussion points for the committee

What is the scale of fraud incidents in the operator’s base today? If unknown — diagnostic from there.

What is the technical capability for real-time analytics? What is the gap?

Is the regulator ready to engage? Who owns that dialogue?

Cooperation with other operators — realistic? If not, what scope is possible?

What 18-month investment commit is needed and is it there?

How SamaraliSoft can help

Anti-Scam Architecture & Operating Model — analysis of current capability, design of pattern detection methodology with labelled dataset preparation, regulatory engagement plan, cross-operator cooperation framework, customer notification flow design, and a phased rollout with a read-only mode pilot for 6-9 months before active blocking.

Related reading

• /en/solutions/telecom-trust-platform-cornerstone/ — trust platform in detail
• /en/insights/telecom-sim-swap-banking-fraud/ — SIM swap and banking fraud
• /en/insights/telecom-number-reputation/ — number reputation
• /en/insights/telecom-youth-segments-payments/ — biometrics and UX

Sources

• Central Bank of Uzbekistan — biometric verification for digital banking
• The Paypers — digital banking verification UZ
• Ministry of Digital Technologies — telecom infrastructure
• Digital Government Portal — digital infrastructure UZ
• UzDaily — telecom market