Telecom as a digital trust platform: SIM, device, number, identity, fraud

Where the conversation usually starts

If your operator were asked right now “what do you know about the customer that the bank does not”, what would the answer be? In most cases it boils down to “we have the SIM, the number, the account”. That is true, but it is the surface layer. Underneath sits what the operator has and the bank does not: a precise SIM-device pairing, the history of app reinstallations, the geographical movement pattern, the history of number changes, behaviour in roaming, the density of contacts with dealers and support.

This information has been sitting in operator systems for years and in most cases is not used. Internally it is applied to retention and churn. Externally — in interoperability with banks and payment systems — it is barely applied at all. And precisely here, after the 2026 regulatory change, concrete monetary meaning appears.

What changed in April 2026

The Central Bank of Uzbekistan introduced mandatory biometric verification for digital banking operations. According to the regulator’s official notice, from 4 December 2025 Face ID is required for new registration, password recovery and login from a different device in banks’ and payment organisations’ apps (cbu.uz). The stricter digital banking verification requirements came into force on 22 April 2026 (The Paypers).

This is not just “banks need biometrics”. It is a signal that the regulator is moving digital banking into a mode where every meaningful operation has to be confirmed by several trust signals. And here is where the fork opens for the operator.

Biometrics is one signal. It is expensive, slow, sometimes does not work (poor lighting, mask, headwear). On its own, biometrics is not enough to drive a transaction confidence score. Additional signals are needed. And those signals are with the operator.

Which signals the operator owns

SIM-device fingerprint. When a customer installs a banking app on the phone, it gains access to the SIM (where allowed), to the device IMEI, to the initial location point. These three parameters were always with the operator — it activated the SIM, knows on which device it was first used, knows the current network identification.

Number reputation. One number can be “a fresh SIM activated an hour ago at a dealer point”, or “a number with five years of history attached to a specific device on the same IMEI from activation”. These are fundamentally different situations from a risk score perspective. The bank does not know the difference. The operator does.

Roaming behaviour. If the customer is logging into the banking app from Uzbekistan now, but the SIM has been working in roaming abroad for the past two weeks — it is either travel, or a lost SIM in someone else’s hands. This does not determine fraud, but it is a signal for additional verification.

SIM swap detection. SIM swap is a classic attack vector on digital banking. If the SIM was replaced in the last 24-72 hours and a meaningful transaction is now being initiated, that is grounds for additional verification. The operator has this information at the moment it happens, but it is almost never relayed to the bank’s risk engine.

Number portability events. MNP works in Uzbekistan (mnp.uz), and operators treat it as a meaningful source of competition — Ucell, for example, offers free porting under specific tariff conditions between 26 March and 30 June 2026 (ucell.uz). From a trust layer perspective, a recent operator change is an event the bank wants to know about within 30-60 days afterwards.

Who needs this and what they will pay for

Before building a trust layer, it is worth understanding who the buyer is.

Banks will pay for low-cost additional signals for risk-based authentication. Each additional signal reduces false positives — transactions that get blocked on suspicion and unblocked after customer contact. Every false positive costs the bank in customer dissatisfaction, operational expense and trust. If the operator can supply the signal “this SIM with this IMEI has been working for 36 months from one geography without anomalies”, false positives drop by 5-15% based on similar markets.

Payment organisations in Uzbekistan operate through Click, Payme, Apelsin, Uzum and other platforms (Central Bank registry). Each of them faces the same fraud problems — fictitious accounts, account takeover, money muling. Additional signals from the operator reduce losses and compliance cost.

Marketplaces and e-commerce platforms — a less obvious but real buyer. Their fraud rate on new registrations is high. The signal “the number has existed for over a year and was used regularly” lets them auto-approve a portion of registrations that would otherwise need manual review.

Trust layer architecture

The operator’s trust platform is not a single product to “buy and install”. It is a stack of four layers.

The first layer — data collection. All events around the SIM, device, number and behaviour are gathered in real time. Some of these data are already collected (billing, OSS), some need to be explicitly captured (smartphone fingerprint at SIM activation, app installation events if the operator owns the app).

The second layer — feature engineering. Raw events become features. “SIM activated 24 hours ago” is a feature. “Last roaming session ended 3 days ago in country X” is another. The feature list must be stable and understandable for partners.

The third layer — scoring. Features assemble into a trust score or a set of atomic indicators. Two approaches. Hand the partner a set of atomic signals so they integrate them into their own risk engine. Or hand them a normalised aggregate score. The first approach is safer regulatorily; the second is more convenient for integration.

The fourth layer — distribution and settlement. The API through which partners request signals, the audit log, the settlement on volume of requests or risk-share models.

Regulation and consent

This is the main obstacle. Without explicit subscriber consent, the operator cannot share their data with third parties, not even commercially. The Uzbek personal data law requires a clear processing purpose and recorded consent.

A consent flow is required — a moment when the subscriber explicitly authorises the operator to use their signals in anti-fraud processes of banks and payment organisations. The consent must be revocable. There must be transparency — who and for what purpose requested signals.

Good news: most customers will give such consent if the benefit is obvious (faster bank verification, fewer blocks). Bad news: integrating consent management is a separate 3-6 month project minimum, and it must be in place before commercial integrations with partners launch.

When not to do this

If the operator does not have an actively maintained consent management platform, launching the trust layer is too early. Consent first.

If the operator does not have reliable fraud detection inside its own operations — for example, dealer sales happen without controls, identification at activation is formal — selling trust scores to banks is dishonest. If the operator cannot tell a fictitious activation from a real one, its signals to partners have limited value.

If the operator’s strategy includes launching its own wallet or a banking licence, positioning a trust layer as a service for competitors will be in conflict. The choice has to be made: either a trust layer for the market, or an own fintech product. Doing both simultaneously is hard.

If the team has no person for the trust officer role — the function responsible for signal quality, regulatory compliance and partner relationships — the product will lack ownership and degrade quickly.

Discussion points for the committee

Three questions worth answering honestly.

First: which of the signals we already hold could deliver value to partners right now? A list of 5-8 signals with concrete descriptions.

Second: what needs to happen in our consent management for sharing these signals to be regulatorily safe? Timeline and cost.

Third: which partner (one bank or one payment system) would agree to a pilot under “give us three signals and we will look at how they affect our false positives”? This is the cheapest form of market validation — not a presentation, but a real test integration.

If there are answers to these three questions, there is a real programme. If not, it is too early to build a product; first the diagnostic of capability.

How SamaraliSoft can help

Digital Trust & SIM/Device/Fraud Strategy — an analysis of which trust signals the operator owns right now, which are demanded by the market (banks, payment systems, e-commerce), what the trust layer architecture should look like without core replacement, how to address the consent question regulatorily, and what first partner pilot is realistic on a 6-month horizon. The output is a committee-ready programme, not a vendor presentation.

Related reading

• /en/insights/telecom-growth-after-connectivity/ — where the operator looks for growth in 2026-2035
• /en/architecture/telecom-around-core-architecture/ — building around the core
• /en/insights/telecom-sim-swap-banking-fraud/ — SIM swap and banking fraud
• /en/insights/telecom-number-reputation/ — number reputation as an asset

Sources

• Central Bank of Uzbekistan — biometric verification for digital banking
• The Paypers — stricter digital banking verification, April 2026
• Central Bank of Uzbekistan — registry of payment organisations
• MNP.UZ — number portability
• Ucell — MNP services