10.515 min read

Partner & Wholesale BSS

Not all revenue in a telco comes from directly serving end customers. A significant portion — often 20-40% for major operators — flows through wholesale and partner channels. Wholesale BSS deals with selling network capacity, services, and infrastructure to other operators and service providers. Partner BSS manages the commercial relationships with resellers, MVNOs, system integrators, and other third parties who sell the operator's services under their own or co-branded offerings.

These models introduce unique BSS challenges: who owns the customer relationship? How is revenue shared? Who manages SLAs? How do catalogs overlap? This section explores the wholesale and partner ecosystem, the processes required to support it, and the BSS capabilities that differentiate retail-only operators from those with mature wholesale and partner operations.

Why Wholesale and Partner Models Matter

Network monetisation: Operators invest billions in infrastructure — wholesale allows them to monetise spare capacity that would otherwise generate zero return
Market reach: Partners and MVNOs can reach customer segments (ethnic communities, enterprise niches, IoT verticals) that the host operator cannot efficiently serve directly
Regulatory compliance: In many markets, regulators mandate wholesale access to incumbent infrastructure (local loop unbundling, bitstream access, mobile roaming)
Ecosystem enablement: The shift to platform-based models (TM Forum ODA, Open APIs) means operators increasingly act as "platforms" that partners build upon
Revenue diversification: Wholesale revenue provides a stable, high-volume, low-touch revenue stream that complements volatile consumer and enterprise segments

Wholesale Is Not Just "Selling Minutes"

Modern wholesale goes far beyond traditional voice interconnect. It includes bitstream access (providing broadband infrastructure for other ISPs), Ethernet and wavelength services for enterprise partners, MVNO hosting (providing full mobile network to virtual operators), IoT connectivity platforms, cloud interconnect, and API-based service exposure. The BSS requirements for each of these are materially different.

Wholesale, Retail & MVNO Models

Beginner

Retail Model

The operator sells services directly to end customers under its own brand. The operator owns the entire customer lifecycle — acquisition, service delivery, billing, support, and retention.

In a pure retail model, the BSS stack serves a single entity (the operator) selling to end customers. Catalog, billing, CRM, and order management are all oriented around the direct customer relationship. This is the simplest BSS model, but it limits market reach to what the operator can directly serve.

Beginner

Wholesale Model

The operator sells raw network capacity, connectivity, or service building blocks to other operators or service providers at wholesale (bulk, discounted) rates. The wholesale customer is another business, not an end consumer.

Wholesale BSS must handle B2B2X relationships — the operator (B1) sells to a wholesale customer (B2) who in turn serves end users (X). The wholesale BSS manages the B1-to-B2 relationship: wholesale catalog, wholesale pricing, inter-operator billing, and wholesale SLAs. The operator typically has no visibility into or relationship with the end user (X).

Intermediate

MVNO Model

A Mobile Virtual Network Operator (MVNO) uses the host operator's radio and core network to offer mobile services under its own brand. The MVNO owns the customer relationship; the host provides the infrastructure.

MVNO hosting sits between retail and wholesale. The host operator provides network access, but the degree of BSS involvement varies by MVNO type. A "thin" MVNO uses the host's BSS (billing, provisioning, CRM) with cosmetic branding. A "thick" MVNO runs its own BSS stack and interfaces with the host purely at the network/wholesale level. The host operator's wholesale BSS must support rating, charging, and settlement for MVNO traffic, often with complex revenue-sharing formulas.

Intermediate

Partner/Reseller Model

A partner or reseller sells the operator's services (often bundled with their own value-added services) to end customers. The commercial relationship may be white-label, co-branded, or referral-based.

Partner models create a spectrum of BSS complexity. At the simplest end, a referral partner passes leads to the operator and earns a commission — minimal BSS impact. At the complex end, a white-label partner has its own catalog, branded portal, first-line support, and billing — requiring the operator's BSS to manage partner catalogs, shared fulfillment, revenue sharing, and multi-level support workflows.

Partner Onboarding Process

Onboarding a new wholesale customer, MVNO, or reseller partner is a significant operational undertaking. Unlike onboarding a retail customer (which can be fully automated), partner onboarding involves commercial negotiation, legal contracting, technical integration, catalog configuration, and testing — often spanning weeks or months.

Partner Onboarding Lifecycle

Commercial Qualification

CRM / Partner Management

Assess the prospective partner's business model, market segment, expected volumes, and creditworthiness. Determine the partnership type (wholesale, MVNO, reseller, referral) and the applicable commercial framework. Regulatory checks may be required (e.g., verifying the partner holds necessary telecom licences).

Contract Negotiation & Execution

Contract Management

Negotiate wholesale pricing, revenue sharing terms, SLA commitments, liability boundaries, and data protection obligations. Define the commercial catalog (which products/services the partner can sell), geographic scope, and volume commitments. Execute the partner agreement.

Partner Entity Setup

Party Management / CRM

Create the partner as a Party in the BSS (TMF632). Configure the partner account hierarchy, billing accounts, payment terms, and tax treatment. Assign the partner to a partner segment and tier. Set up partner users with appropriate portal access and role-based permissions.

Catalog & Pricing Configuration

Product Catalog / Pricing Engine

Configure the partner-specific catalog: which Product Offerings are available, at what wholesale prices, with what configuration options. This may involve creating partner-specific offerings derived from the master catalog, or simply enabling existing offerings with partner-specific pricing rules and discount structures.

Technical Integration

Integration Platform / API Gateway

Establish API connectivity between the operator's BSS/OSS and the partner's systems. This typically includes ordering APIs (TMF622), trouble ticketing (TMF621), inventory queries (TMF638/639), and billing data exchange (TMF678). For MVNOs, network-level integration (interconnect, roaming, number porting) is also required.

Testing & Certification

Test Environment

Execute end-to-end testing of the partner integration: order submission, fulfillment, billing, trouble ticket flow, and SLA reporting. Verify that the partner can successfully order, provision, and manage services through their allocated catalog. Resolve integration defects and retest.

Go-Live & Operational Handover

All Systems (Production)

Activate the partner in production. Enable live ordering and billing. Assign a partner account manager for ongoing relationship management. Begin SLA monitoring and reporting. Schedule the first billing cycle reconciliation review.

Revenue sharing is the commercial mechanism that determines how money flows between the operator and its partners. In a wholesale model, the operator bills the wholesale customer directly for consumed services. In a partner/reseller model, the end customer may pay the partner (who then settles with the operator) or pay the operator (who then pays the partner a commission). The BSS must support all these financial flows accurately.

Inter-Operator Billing / Settlement

The process of calculating, reconciling, and settling financial obligations between two operators or between an operator and a partner. This involves exchanging usage data (CDRs, event records), applying agreed rate cards, calculating net positions, generating settlement statements, and processing payments. In traditional voice interconnect, this is handled by "interconnect billing" systems. In modern wholesale, it extends to data services, cloud, and API-based transactions.

TMF632 — Party Management API

TMF632 provides a standardized API for managing parties (individuals and organisations) and their roles. In the partner/wholesale context, TMF632 is used to create and manage partner organisations, define partner roles (reseller, MVNO, wholesale customer, referral partner), and manage the relationships between parties. Key resources include Organization, Individual, PartyRole, and PartyRelationship. TMF632 is foundational — it provides the party context that other APIs (ordering, billing, SLA) reference.

TMF678 — Customer Bill Management API

TMF678 provides APIs for managing billing accounts and presenting bills/invoices. In wholesale and partner scenarios, TMF678 supports generating wholesale invoices for partner consumption, presenting settlement statements, managing billing disputes, and providing billing data exports for reconciliation. The API supports multiple bill formats and delivery channels, which is essential when different partners require different billing integration approaches.

Wholesale billing: Operator meters partner consumption (circuits, bandwidth, voice minutes, data) and invoices the partner at wholesale rates. Settlement is typically monthly with payment terms of 30-60 days.
Revenue share (commission): Partner sells to end customer and collects payment. Operator receives a share of the revenue. BSS must calculate the operator's share based on agreed formulas (percentage of revenue, flat per-transaction fee, or tiered commission).
Revenue share (margin): Operator invoices end customer directly. Partner receives a margin (commission) for originating the sale and/or providing ongoing support. BSS manages both the customer billing and partner payout.
Settlement and reconciliation: Both parties independently calculate what is owed. Discrepancies (which are common due to timing differences, CDR mismatches, and rounding) must be identified and resolved through a formal reconciliation process.

Retail vs Wholesale vs Partner: Detailed Comparison

BSS Comparison Across Commercial Models

Dimension	Retail (Direct)	Wholesale	Partner / Reseller
Customer Ownership	Operator owns the end-customer relationship directly	Operator has no relationship with end users; wholesale customer is the "customer"	Varies: partner may own customer (white-label) or operator may own (referral)
Catalog Ownership	Single catalog managed by operator for end customers	Separate wholesale catalog with wholesale-specific offerings and pricing	Partner-specific catalog derived from master catalog with partner pricing overlays
Billing Model	Operator bills end customer directly (postpaid or prepaid)	Operator bills wholesale customer for bulk consumption; wholesale customer bills their end users	Depends on model: operator bills end customer (with partner commission) or partner bills end customer (with operator settlement)
SLA Responsibility	Operator provides SLA directly to end customer	Operator provides wholesale SLA to wholesale customer; wholesale customer defines their own retail SLA to end users	Operator provides SLA to partner; partner may pass through or define their own retail SLA
Revenue Model	Full retail revenue retained by operator	Wholesale revenue (lower margin, higher volume) paid by wholesale customer	Revenue shared between operator and partner per contractual formula
Sales Channel	Operator's own channels (web, retail, call centre)	B2B sales team; wholesale portal; API-based ordering	Partner's own channels, co-branded portals, or operator channels with partner attribution
Ordering Process	Standard retail order flow through COM	Wholesale ordering via API (TMF622) or wholesale portal; simplified validation	Partner submits orders via partner portal or API; orders validated against partner catalog and entitlements
Customer Support	Operator provides all support tiers	Operator provides wholesale support (typically L2/L3 only); wholesale customer provides L1 to their end users	Partner provides L1 support; operator provides L2/L3 escalation support
Fulfillment	Operator fulfills directly to end customer premises	Operator fulfills to wholesale customer's point of interconnect or end user (depending on service type)	Operator fulfills, but partner may coordinate end-customer scheduling and access
Pricing Flexibility	Standard retail price list with promotions	Negotiated wholesale rate cards; volume commitments; bespoke pricing for large deals	Partner receives wholesale/discounted pricing; sets own retail price to end customer
Data Ownership	Operator owns all customer, usage, and service data	Operator owns wholesale customer data and network usage data; wholesale customer owns their end-user data	Shared: operator owns service/network data; partner owns customer relationship data; data sharing governed by contract
Regulatory Position	Operator holds all licences and regulatory obligations	Both parties may hold licences; operator provides regulated access; wholesale customer has own regulatory obligations	Operator typically holds licences; partner may operate under operator's licence or hold own authorisation

Source-of-Record for Partner & Wholesale Entities

Partner & Wholesale Source-of-Record

Entity	System of Record	System of Engagement	System of Reference	Notes
Partner Organisation	Party Management (TMF632)	CRM (relationship management)	Partner Portal (self-service)	The partner entity, its roles, and organisational hierarchy are managed in Party Management.
Partner Contract	Contract Management System	CRM (negotiation)	Partner Portal (viewing)	Commercial terms, revenue share formulas, and SLA commitments live in the contract system.
Partner/Wholesale Catalog	Product Catalog (TMF620)	Partner Portal (browsing)	—	Partner-specific offerings and pricing are managed as catalog entities with partner-scoped visibility rules.
Wholesale Order	COM (TMF622)	Partner Portal / Partner API	Partner Catalog	Orders submitted by partners are managed in COM with partner attribution for revenue tracking.
Settlement Statement	Billing / Settlement System	Partner Portal (viewing)	Partner Contract (rate cards)	Settlement calculations and statements are owned by the billing/settlement system.
Partner Usage / CDRs	Mediation / Rating Engine	Network (raw event generation)	Billing (rated usage)	Usage records attributed to partners are mediated and rated per the partner-specific rate card.

Section 10.5 Key Takeaways

Wholesale and partner revenue can represent 20-40% of a major operator's total revenue — it requires dedicated BSS capabilities, not afterthoughts
Wholesale, MVNO, and partner models each have distinct BSS requirements for catalog, billing, ordering, and support
Partner onboarding is a multi-week process spanning commercial qualification, contract execution, catalog configuration, technical integration, and testing
Revenue sharing models range from simple commission to complex inter-operator settlement with reconciliation processes
TMF632 (Party Management) is foundational for partner BSS — it defines the partner entity and its roles that all other systems reference
The key BSS differentiator across models is customer ownership — who owns the end-customer relationship determines catalog, billing, and support boundaries
Clear source-of-record ownership is even more critical in partner scenarios where data is shared across organisational boundaries

Partner & Wholesale BSS