A monetization architect at a Tier 1 operator designs a win-back tariff. The target is a specific, valuable segment: long-tenured postpaid subscribers who have started to disengage, the ones a competitor’s port-out offer will catch next quarter. The retention team wants to reach them first with something unique which the network can now actually deliver, a time-boxed data pass on a premium slice, priced on how long the subscriber has been with the network. A ten-year customer flagged at-risk pays one rate. A newer one pays another. The offer expires in seventy-two hours so there is a reason to act.
The design is good. It uses the slice the network team already stood up, it targets margin the retention team can defend, and it prices on the things that make the offer feel personal: how long the subscriber has been with the network, how much they have used across services this cycle, and the premium slice they are consuming.
Then it reaches the charging system, and it stops.
The rating logic cannot see what the offer needs to price on. Tenure is the reachable one: it lives in the CRM, and most chargers can be integrated to consume a field like that, either at implementation or through a change request delivered over the years. The other two are the hard ones. The cross-service consumption counter is a value the charging system would have to derive and carry, not a field it already holds. The slice identifier arrives in the charging stream from the network, but the rating engine was never configured to price on it. These are inputs the pricing logic is simply not allowed to reference, and adding one is not a configuration change.
The obvious answer is to add the fields. That answer is the problem. Adding a new rateable attribute means a schema change, new rating templates, a regression cycle, and a slot on a vendor’s release calendar. The offer that took an afternoon to design now takes three quarters to price. By the time it could launch, the port-out window it was built for has closed. The work also carries a direct cost, since a rateable-attribute change is usually a chargeable request against the vendor rather than in-house configuration, and it competes for the same release slots as revenue assurance fixes and compliance work that cannot wait. So the offer does not launch, and the next ten like it never get scoped, because everyone already knows what the charging system will say.
The real bottleneck: a capable standard, a closed implementation
It is tempting to blame the standard. That would be wrong.
5G charging runs on the Converged Charging System, which exposes a service-based interface called Nchf from a network function called the CHF (Charging Function). When a subscriber uses data, the session management function sends charging-data requests to the CHF over Nchf, and the CHF applies rating and manages the balance. This architecture has been stable since 3GPP Release 15 and 16. This is settled architecture. The constraint lies elsewhere.
Slice charging is standardized too. The specifications carry the S-NSSAI, the identifier that names a specific network slice, into the charging record (TS 32.255, with slice management charging in TS 28.201 and 28.202). The mechanism to price the win-back offer’s premium slice already exists in the protocol.
Every 5G-Advanced release has added more rateable surfaces. Release 18 extended network-slice charging to cover wholesale and retail charging for slice roaming across the home and visited network, and added 5G LAN charging. Release 19 completed its freeze at the end of 2025. The standard keeps handing operators new things to charge for.
The gap sits below the standard, in the implementation.
Almost every charging system fixes the set of attributes that can drive a price at design time. The rating logic can only reference fields that were wired into the data model when the system was built or last released. This holds for legacy stacks, and it holds equally for modern cloud-native charging functions. Being containerized and running on Kubernetes changes how the software is deployed. By itself it does not open the schema. When the business needs to price on an attribute that is not in the model, someone writes code, and that code waits for a release.
A capable standard, delivered through a closed attribute set, produces exactly the stall the architect hit.
Why “AI plus no-code” doesn’t touch this
The market has a stock answer to slow offer creation, and it is a good one. Put a no-code design tool in front of the business, add AI to help with pricing, and let product teams build offers without engineering.
These are real capabilities from serious vendors. MATRIXX markets what it calls a “click-not-code” real-time charging and monetization platform; Amdocs acquired MATRIXX in late 2025 for a reported US$200M, and Omdia’s estimate puts the combined entity at roughly 23 percent of 5G charging and policy revenue, the largest share by revenue in that field. Netcracker, which now leads the combined BSS and charging business after NEC’s acquisition of CSG, markets dynamic charging of its own. The category is well funded and the products work.
Here is the limit, and it is structural rather than a knock on any one tool.
No-code lets a business user assemble an offer from attributes the system already exposes. The clicks compose logic over a menu of fields. If the field you need to price on is on that menu, the experience is genuinely fast. If it is absent, no amount of clicking conjures it. The business user meets the same wall the architect met, files the same engineering change, and waits for the same release.
The win-back tariff fails the same way in a beautiful UI as it does in an old one, because the UI was never the binding constraint. The set of attributes underneath it is.
A friendlier front end over a fixed attribute set is still a fixed attribute set. The interface improved. The thing that decides which offers are reachable did not move. That distinction is the whole game, and most “AI plus no-code” messaging talks about the interface.
The fix is architectural: open the attribute set
The way past this is a rating engine that does not freeze its inputs.
Totogi Charging-as-a-Service does that with a feature called Rate Anything. Rating logic is decoupled from the charging engine, so a price can reference any attribute keyed in the system. Any subscriber attribute held in the CRM, not a pre-integrated subset of it. Balances and custom usage counters. Fields carried in a network message, including the slice identifier. The provider context of an API call. If the value exists in the request or in the subscriber’s record, rating can price on it.
The win-back tariff becomes an afternoon of work again. Tenure is one CRM attribute among all of them, read without a new integration for that specific field. The cross-service counter is a value the system can derive and rate on. The slice identifier is an attribute in the charging stream, so the premium-slice price attaches to it. A product person authors the whole thing in Plan Design, Totogi’s visual tool for building and maintaining plans, and the plan deploys to the internal technical catalog. No schema change. No release ticket. A business change made by the business.
Why the architecture allows this is worth stating plainly, because it is the actual differentiator.
Charging-as-a-Service is serverless and multi-tenant, and its rating logic is not bolted to a fixed schema. Because pricing logic reads attributes at evaluation time instead of compiling against a predefined data model, adding a new rateable input becomes a matter of referencing it rather than rebuilding around it. A containerized charging function can be excellent engineering and still carry a fixed rateable-attribute set, because that constraint lives in the data model, not the deployment target. The difference that matters is serverless plus multi-tenant plus an open attribute set, and the open attribute set is the part competing architectures rarely provide.
Rate Anything is currently available through an Early Access environment, so customers can begin designing Rate Anything plans and preparing configurations ahead of broader rollout. The point holds at the rating layer on its own: what you can price on stops being decided at procurement.
What an open attribute set unlocks
Once rating can reference any attribute, the offers on today’s roadmap stop being release-gated. Several are worth naming.
Slice-aware pricing is the immediate one. Slicing has crossed from pilots into revenue. Ericsson reported 65 commercial slicing cases across 33 service providers in late 2025, and Vodafone Germany publishes standard slice pricing, including an enterprise campus slice around EUR 2,000 per month per site. When the S-NSSAI in the charging stream is a rateable attribute, an operator can price per slice, per tenant, and per subscriber tier without a data-model project behind each variant.
Network APIs are the next rateable surface, and they are here now. The GSMA Open Gateway program and the CAMARA project expose functions like Quality-on-Demand, SIM Swap, Number Verification, Device Status, and Location as standard APIs. Quality-on-Demand is the cleanest example: a request to boost a single session’s quality for a fixed window is a discrete, rateable machine transaction. MWC 2025 was the point where network APIs turned from a standards story into a monetization one. Pricing those events requires a rating engine that can charge on the context of an API call, which is exactly an attribute.
Lifecycle-aware tariffs, custom rating groups, counter-based promotions: each is an attribute problem, and each collapses to configuration once the attribute set is open.
One surface is still emerging, and it should be labeled that way. Ericsson’s industry research describes a shift toward autonomous agents that discover and invoke telecom services, and toward “trust-based charging” that prices authenticated identities, authorized delegations, and validated outcomes. Agent-initiated charging is not a shipping standard and should not be sold as one. It is the logical extension of the same principle. The rateable machine transaction of today is a network API call. The rateable machine transaction of tomorrow is one agent paying another. An operator whose rating engine already prices on arbitrary attributes is positioned for that surface without re-architecting for it.
The pattern is consistent. New revenue surfaces keep arriving as new attributes, and an open attribute set turns each one into a plan instead of a project.
Boundaries, and the point
Rate Anything solves one category of problem. It is honest to say what it leaves untouched.
Charging is a single layer of 5G monetization. Spectrum strategy, IMS and voice over New Radio, roaming agreements, and the harder parts of slice orchestration remain real work, and no rating feature makes them disappear. What an open attribute set removes is a specific, expensive form of friction: the delay between deciding to price on something and being allowed to. That delay has been miscast as a monetization problem for years, when it is really a data-model problem.
The velocity is measurable once the friction is gone. 2degrees in New Zealand has deployed more than 300 features and optimizations on Totogi Charging-as-a-Service since August 2024 with no downtime, the kind of cadence that only exists when offer changes are configuration rather than releases. The free tier, up to 250,000 subscribers, lets an operator test a real offer against real logic before committing.
For operators carrying legacy charging semantics into a migration, Totogi Ontology can map the old model’s meaning onto the new one and shorten the move. That is a migration accelerator, not the subject here.
The subject is what decides your offer catalog. Opensignal titled a recent report “Architecture deployed, monetisation pending,” which is a fair description of where 5G SA sits. The network is built. The offers are waiting on the charging layer. And at the charging layer, the attribute set, not the interface, decides which offers you are allowed to price.
About Totogi: Totogi Charging-as-a-Service is an AI-native, serverless, multi-tenant charging system built on the AWS public cloud. It rates and charges every 5G Standalone and 5G Advanced use case, from network slices to MVNO tenants to network-API events, at the speed and economics those services require. Learn more at totogi.com
