Prototype · October 2026
Telecom revenue assurance: find the leak overnight, prove it, fix the cause, and let a person sign.
A business plan for Pakistan’s cellular market looked at eight ways an operator could earn more from the network it already has, and recommended starting with the one that needs no new spectrum and no mass 5G adoption: software that reconciles what the network carried against what was charged, billed, settled and paid, with AI doing the repetitive work around it. This is a working prototype of that product — the nightly match, the cases it raises, an AI care desk, and the fraud API the plan proposes as stage two — on an invented operator. It runs in your browser, and the guided run performs every step for real as it explains it.
The market
More value from the network that is already built.
Pakistan’s operators already cover most of the population and most of their sites carry 4G. Growth from adding subscribers is slowing, and the plan’s question is the commercial one: which proven model can an operator introduce at an acceptable cost, with a clear paying customer, measurable financial benefit and a viable regulatory path?
Its answer for a first product is the least glamorous one. Billing, charging, dealer commissions, wallet settlements, interconnect and enterprise orders all run on different systems, and money leaks in the gaps between them — a tariff migration that stops rating one APN, a commission paid on recharges later reversed, an IoT order that went live without a billing account. A recurring leakage-detection service can show its value in a single stream, inside 90 days, without waiting for 5G.
Eight ideas
Eight ways to earn more from the network; three worth testing first.
The plan screens each one on initial capital, revenue potential and the main thing that could go wrong. Revenue assurance and AI automation come first because they need records and access, not infrastructure; network fraud APIs follow once operators and regulators are on board.
| Idea | Paying customer | Initial capital | Main execution risk |
|---|---|---|---|
| Telecom-backed fraud-prevention APIsstage two | Banks, fintechs, e-commerce | Low–medium | Cross-operator integration and adoption |
| AI customer-service and back-office automationin the demo | Operators, utilities, large businesses | Low–medium | Data quality and integration |
| Fleet, fuel and cold-chain IoT | Logistics, distributors, retailers | Medium | Hardware support and customer acquisition |
| Tower and network energy optimisation | Operators, tower companies | Medium | Proving savings reliably |
| SME digital-services marketplace | Small businesses and professionals | Low–medium | Retention and product-market fit |
| Managed cybersecurity | SMEs, banks, enterprises | Medium | Security liability and trust |
| Automated revenue assurancein the demo | Operators and digital service providers | Low–medium | Access to records and false positives |
| Managed enterprise connectivity | Factories, hospitals, campuses | Medium–high | Deployment and service-level obligations |
The loop
A reconciliation report says something is off. This closes the loop.
Match, explain, recommend, assign, decide, measure — with complaints feeding the match, a second signature above the limit, and an audit line under every step.
What it adds
One platform, two modules, one rule: a person decides.
Module A finds and proves the leakage. Module B does the repetitive work around it, on the case desk and the customer desk.
One case per cause, not per record.
Fifty-three million records go into the nightly match and almost all of them match on their own. The leftovers are grouped by what caused them — a dropped APN mapping, a campaign file loaded twice — so the analyst gets four cases, not fourteen thousand lines.
Ranked by what it costs to wait.
A case is ranked by what has already been lost plus thirty more days of the leak, times how sure the engine is. A leak still running at Rs 268,000 a day outranks a larger one that has already stopped.
Explained, not asserted.
The evidence from each system sits side by side, and the signals behind the score carry weights that add up to it. Module B drafts a plain-language brief from that evidence and nothing else.
Fix the cause, then recover what is owed.
The recommendation puts stopping the leak first and checks the contract before anyone is back-billed — flat-rate customers owe nothing. Not everything flagged is recoverable, and the case says so.
A person decides; above a limit, two do.
The platform never posts an adjustment, bills, credits or claws back. The analyst decides with a written reason; anything above the approval limit waits for the Finance Controller.
Complaints are evidence too.
The care desk answers routine questions from the subscriber’s own records, folds a thousand outage calls into one network ticket, and turns complaints that share one charging cause into a revenue-assurance case — so every affected customer is credited, not only those who called.
It counts its own mistakes.
A false alarm needs a reason and is counted by kind. Raising the confidence threshold names, on screen, the suspicions that would drop out of the queue.
Auditable by construction.
Every step writes an append-only line: what the engine flagged, what the analyst decided, who approved and what followed. Internal Audit sees everything and can change nothing.
The guided run
It explains itself, by doing it.
Twenty-six steps: last night’s match across six streams; an unrated corporate APN taken, chased with Charging IT, fixed at the cause and back-billed only where the contract allows, with the Finance Controller’s signature; an interconnect false alarm dismissed and the threshold tuned; the care desk turning 37 complaints into a credit for 9,800 customers; and a bank asking the network about a SIM swap. Every step performs the real action, and it reads itself aloud unless you turn that off.
Module B and stage two
The customer desk, and the network answering a bank.
Proof
A pilot measured in confirmed money, not in alerts.
The plan is blunt about it: the principal risk is not writing the software but getting data access, passing security review and winning a paid pilot. So the pilot measures what a finance director would sign — against a baseline measured first.
- Confirmed discrepanciesValue of leakage an analyst confirmed, by stream
- Recovered or stoppedBack-billed, clawed back or credited, plus leakage stopped going forward
- False alarmsDismissed ÷ closed, by kind — and a sample of the automatic matches checked by hand
- Time to resolveMedian days from detection to a signed decision, against the measured baseline
- Contacts resolved without an agentOnly low-risk intents, from approved records; refunds and SIM replacements excluded
Roadmap
Ninety days, one stream, then a decision.
Market validation
Interviews with 10–15 finance, billing, revenue-assurance and operations decision-makers; three costly problems identified; preliminary technical and regulatory assessments; willingness to pay estimated.
Design and commercial validation
One primary idea and one alternative. A pilot sponsor and technology partner, an agreed MVP, data access and success criteria, and an approved compliance checklist.
Pilot and decision
This demo rebuilt on one reconciliation stream with the operator’s own records, run alongside the existing process. Confirmed discrepancies, time saved and false alarms measured; then expand, redesign or stop.
Architecture
How it would be built.
Read-only first
Secure ingestion of network, charging, billing, settlement and partner files. Existing systems stay the systems of record; the platform writes nothing back but cases.
Rules, then scoring
Deterministic matching — tolerance, time window, known patterns such as split sessions and retried top-ups — does the bulk. A scoring model ranks what is left, and every threshold is configuration with a logged approver.
Module B on approved data only
The assistant drafts briefs and replies from the case evidence and the subscriber’s own records. It cannot issue refunds, credits or SIM replacements, and a person can see what it was given.
Separate products, shared engine
Revenue assurance, care automation and the fraud API share the workflow, audit and reporting — not data or roles. A bank calling the API never sees subscriber records.
Standard APIs for stage two
SIM-swap and number-verification endpoints follow the GSMA Open Gateway / CAMARA definitions, behind consent and client credentials, metered per call.
In-country, auditable hosting
Deployable inside the operator’s own environment, with tamper-evident logs, role-based access and the reporting a pilot evaluation needs.
Regulation
Compliance in the design, not after it.
Using a mobile network does not make a service authorised. Before capital is committed, the exact product, licence, data flows and commercial structure need a written assessment from Pakistani telecom counsel, and where needed, clarification from PTA or SBP.
PTA authorisation
Whether a service sits inside the operator’s licence or needs additional approval or a licensed partner.
Subscriber information
Verification, confidentiality, security and lawful-access requirements on SIM and subscriber data.
Financial services
SBP requirements wherever a product touches wallets, payments or branchless banking — the fraud API’s buyers are regulated.
Consumer protection
Transparent credits and back-billing, consent, complaints and disclosures — which is why the demo credits every affected customer.
Scope
What this is, and what it is not.
- It is a prototype built from a business plan for the Pakistani telecom market, not a deployed or commissioned system, and it is not affiliated with any operator, bank or wallet.
- Kohsar Mobile, Margalla Bank and Ravi Pay are invented. Every subscriber, account, partner, amount and person in the demo is fictional.
- It holds no data: state lives in the visitor’s browser and never leaves it.
- Pilot measures are proposed, not results. The scorecard’s baselines are invented for the demo; a real pilot measures them first. The Module B figure is the plan’s own illustrative arithmetic, editable on screen.
- The API exchanges follow the published CAMARA shapes in outline; nothing in the demo talks to a network.
Sources for the figures above
- Pakistan’s IT and telecom sectors in FY2024-25, Economic Survey — MEA Tech Watch
- Pakistan’s telecom sector hits 200 million subscribers, Rs1 trillion revenue in FY2024-25 (PTA annual report) — MEA Tech Watch, January 2026
- PTA targets 2,000 5G sites per mobile operator by 2028 — APP
- Pakistan’s 5G reaches 1.3 million users across 23 cities — ProPakistani, August 2026
- GSMA Open Gateway — GSMA
- CAMARA project (SIM Swap, Number Verification APIs) — Linux Foundation