Consent wallet for telcos: what changes in consent management after 2026

Regulatory background

In Uzbekistan the personal data law (ZRU-547) and related acts gradually tighten requirements on obtaining, storing and revoking consent for data processing. With biometric requirements for digital banking from April 2026 and growing regulator attention to digital trust (cbu.uz), telcos can expect to have to demonstrate a more structured approach to consent management.

In most operators today consent management is fragmented. Marketing communication consent lives in one system, consent for data use in credit scoring in another, consent for data sharing with partners — nowhere systematically. When the customer wants to revoke consent it requires reaching out in several places and is often only partially executed.

A consent wallet is the concept where all customer consents live in a single place, the customer sees them and can manage them in one click. This is increasingly an expectation not only of the regulator but of the customer.

What a consent wallet means structurally

A consent wallet is a single layer in which:

All permissions the customer has given the operator and partners are listed. Not “I agree to the terms of service”, but specifically: marketing on channel X, data use in credit scoring, data sharing with partner Y for scenario Z.

Each permission is managed separately. The customer can revoke one and keep the rest.

Each permission has a timestamp and context. When given, under what conditions, for what period.

An audit trail for every change. Who changed it and when (the customer, through the app, through retail, or another legitimate channel).

Visible to the customer in real time. Through the operator’s app, through the web portal.

Without any one of these components it is not a consent wallet but a more structured consent page.

Four approaches for the operator

Build in-house. Fully internal consent wallet. Under operator control, customisable.

When it fits. The operator has strong technical capability and plans long-term independence from vendors. The data architecture can support consent wallet integration with downstream systems.

When it does not. Technical capability is limited; the build will take 18-24 months and delivery risk is high.

Cost. High upfront, medium in operations. 18-24 months of development.

Use a platform. An external consent management platform vendor. Integrates with existing operator systems.

When it fits. Speed-to-market is critical, the operator prefers proven solutions, in-house development capacity is limited.

When it does not. Vendor lock-in is unacceptable. Data residency requirements are strictly local.

Cost. Medium upfront (licence fees), medium in operations.

Simplified model. Basic consent management without a full wallet — just clean consents in the standard app, without unified visibility.

When it fits. Regulatory requirements are still moderate. Data sharing volume is limited.

When it does not. When the regulator starts requiring full traceability — the model becomes obsolete.

Cost. Low upfront, medium in operations.

No proactive build. Continue with the current state, react to regulatory requirements as they appear.

When it fits. The operator has no long-term stake in data-driven products and compliance is minimal.

When it does not. When the regulator moves to enforcement — the reactive cost is higher than a proactive build.

Cost. Low upfront, potentially very high reactively (fines, expedited build).

Comparing the four

Criterion	Build in-house	Platform	Simplified	Wait
Speed to market	18-24 months	6-12 months	3-6 months	0
Customisation	high	medium	low	n/a
Vendor lock-in	low	high	medium	n/a
Compliance reach	maximum	good	medium	minimum
Total 5-year cost	medium	medium-high	low	potentially very high
Risk under tightening	low	medium	high	critical

When to choose what

Build in-house. The operator is large, has a long-term data strategy, wants independence from vendors. A serious investment, justified only at large data activity. For a regional operator with mid-revenue, rarely the right answer.

Platform. Often the reasonable choice — speed-to-market is good, vendor is proven, custom logic is possible. The main question is choosing a vendor with long-term presence in the country.

Simplified. Fits as a first step for an operator just beginning consent management work, with a plan to upgrade to full wallet over 12-24 months.

Wait. The riskiest variant. May look thrifty now, but reactive cost when the regulator moves to enforcement is usually 5-10x the proactive build.

What real implementation requires

Independent of the choice, working consent management has several practical requirements.

Clear UX for the customer. Not an “agree to all” table, but a structured view with clear options. Most customers do not read legal text — UX has to make the choice easy and meaningful.

Granular controls. Not “consent to marketing” as one blanket, but “SMS marketing”, “email marketing”, “in-app push”, “partner offers”. Granularity gives the customer real control.

Default opt-out for new categories. If the operator adds a new use of data, the customer must explicitly opt-in, not be carried in automatically.

Real-time enforcement. If the customer revokes consent, it applies within hours, not weeks. Otherwise compliance is illusory.

Confirmation of revocation. After revoking, the operator confirms to the customer that it is in effect — what changed, from when.

When not to launch a big consent project

If the operator has just passed a major regulatory milestone and is in a moratorium on big projects, adding consent wallet now is wrong timing.

If the data foundation is fragmented — consent data in one system, usage in another, no linkage — consent wallet will be cosmetic.

If the 12-18 month budget is constrained, in-house build is deferred to better timing.

If the regulator does not signal a clear timeline for tightening, urgency may be overstated.

If the organisation has no owner for privacy and data governance, the project will not be able to align stakeholders.

Discussion points for the committee

What 5 types of consent do we have today and where are they stored? If the answer is “in different places” — that is the problem.

What is the regulatory roadmap for consent? What is the regulator filing and on what timeline?

Who owns consent management as a function? If several different teams — there is conflict.

In-house build, platform, simplified — what fits the operator’s structure?

What is the horizon for the full wallet? 12, 18, 24 months?

How SamaraliSoft can help

Consent Management Strategy & Implementation — analysis of the current state of consent management, regulatory landscape assessment, decision framework across the four approaches with unit economics, design of the target operating model and UX, vendor evaluation if the platform path is chosen, and a phased rollout over 12-18 months.

Related reading

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

Sources

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