SIM swap, device change and banking fraud: where telecom becomes part of fintech security

A regulatory window

Since 22 April 2026 most operations in banking and payment apps in Uzbekistan require biometric Face ID verification — for registration, password recovery, login from a new device (thepaypers.com), (cbu.uz). A meaningful tightening in the overall fraud-defence chain in digital finance.

Biometrics close one class of risk — falsification or theft of authentication data. Open remains another attack vector tied directly to what the operator owns: the SIM and the device.

If an attacker gains control over the victim’s SIM (through social engineering of operator staff, document forgery, an insider in the dealer network), they get access to the OTP code and to a range of banking operations. If an attacker can “appear” as a new device of the customer, parts of the bank’s security treat it as the customer logging in from a different phone.

These two vectors — SIM swap and device change — become the main attack points in fintech security. And these two vectors are controlled by the operator directly, not by the bank. Which means the operator stops being “connectivity” and becomes part of the trust perimeter for the country’s whole digital finance system.

Where this creates a commercial opportunity

The operator can plug into fintech security in several different ways, each with its own value level.

First, signals about SIM events go to the bank or payment organisation in real time. A SIM swap occurred — the bank sees it in the moment, not 24 hours later. On that signal the bank can temporarily raise the verification level for transactions in the first 48-72 hours after the swap.

Second, the operator can provide a device verification token. When the customer tries to log into the banking app from a new device, the bank can request via API the operator’s confirmation: “this device is bound to this customer’s verified SIM and is actively used”. Stronger than the bank’s internal new-device check.

Third, the operator can run a number reputation database. Each number has history — long-running, recently swapped, recently new SIM, signals of fraud activity. A reputation database is value for every downstream partner (banks, payment services, e-commerce).

Each of the three is a separate commercial opportunity with revenue potential.

What needs to be ready to enter the niche

This is not “just open an API”. Several serious preconditions.

Real-time tracking of SIM and device events. When a SIM swap happens, the event must be visible in the operator’s system in real time, not in next-day batch load. This requires event-driven architecture in the operations layer.

Anti-fraud discipline in the dealer network. If SIM swaps go through corrupt dealers (historically a problem in the region), any signal the operator sends to the bank can be compromised. The dealer network must have fraud controls — pattern recognition, blacklist of users repeatedly attempting swaps, audit trail.

Contracts with banking partners. Not just a technical integration — commercial agreements. The bank pays for the signal or token, and pricing requires a long negotiation.

Privacy and regulatory framework. What does the operator have the right to share with the bank without separate customer consent? A legal and regulatory question, and without resolving it the partnership does not scale.

Operational SLA. A bank cannot work with a signal arriving with unpredictable delay. Delivery SLA is a critical condition.

What often becomes a barrier

No event-driven architecture in core operations. Many operators run on batch-driven cores, and transformation to event-driven takes 12-18 months. Without that, real-time signals are not possible.

Dealer network as a weak link. If SIM swap is easy through a corrupt dealer, all upstream signals are undermined. Cleaning the dealer network takes time and is politically hard.

Slow banking partners. Integration with one bank takes 6-12 months. With an ecosystem — years. Not a fast business.

Regulatory vacuum. The regulator may not be ready for the operator-as-verifier model. A regulatory definition of “what the operator may verify” is unclear.

Internal opposition. Security inside the operator often sees exposing data to external partners as a risk. Without executive support API opening does not happen.

A realistic roadmap into the niche

Not a short project. From zero to a working trust platform — 18-24 months.

First 6 months. Foundation. Audit current SIM/device tracking. Identify gaps in real-time. Audit the dealer network for fraud risks. Engagement with the regulator on the framework.

Months 7-12. Pilot. One banking partner, one use case (for example, the SIM swap signal). Build the infrastructure, integration, SLA. Measurement that the signal really reduces fraud at the partner.

Months 13-18. Use-case expansion. Device verification token. Number reputation. Additional partners.

Months 19-24. A sustainable trust platform. Several use cases, several partners, regulatory clarity, a defensible commercial model.

By two years in the operator is positioned as a trust authority in the country, not “one of the connectivity options”. This changes valuation, the negotiation position with regulator and partners, future opportunity.

When not to enter the niche

If event-driven technical foundation does not exist and building it will take 12+ months — foundation first, trust platform second.

If the dealer network has substantial historically unaddressed fraud risks, the banking partner will be wary of any signals. Network cleanup first.

If the banking partner landscape is unfriendly (banks see the operator as a digital threat, not collaborator), negotiations will take longer than available.

If the regulator is not ready for the operator-as-verifier model, a 12-18 month preliminary regulatory effort is required.

If the operator has its own fintech ambitions (launching a wallet, competing with banks), there is a conflict of interest. A trust platform requires neutrality.

Discussion points for the committee

What is the current real-time SIM event tracking capability? And device events?

What share of fraud incidents in the operator’s base (SIM swap, dealer fraud) is known and tracked?

Is the operator ready to position itself as a neutral trust authority across banks? Or is there a conflict of interest with own fintech?

What is the regulatory framework? What steps are needed for clarity that the operator may share signals?

What 18-24 month investment commitment is needed and is it there?

How SamaraliSoft can help

Telecom Trust Platform & Banking Integration — analysis of the operator’s current capability for trust services, design of the trust platform architecture, regulatory and commercial framework for banking partnerships, anti-fraud controls in the dealer network, and a phased rollout with a pilot at 1-2 partner banks over 12-18 months.

Related reading

• /en/solutions/telecom-trust-platform-cornerstone/ — operator as a trust layer
• /en/insights/telecom-youth-segments-payments/ — biometrics and UX
• /en/architecture/telecom-around-core-architecture/ — event-driven architecture
• /en/insights/telecom-dealer-quality-score/ — dealer network and fraud

Sources

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