The wholesale partner you cannot verify: interconnect and settlement identity
Wholesale telecom runs on bilateral trust between parties who have never met, transacting instructions worth millions through channels that would not pass a retail bank's control review. This one is filed under experimental frontier, because the data to size it is not public and this article will not pretend otherwise.
Can a carrier verify the wholesale partner that just sent it an instruction?
Rarely, at the level that matters. Interconnect and settlement run on email, portals and long-standing relationships. Instructions that change routing, rating or remittance details arrive from a partner's mailbox, and the receiving carrier verifies the relationship rather than the instruction.
- Instruction authority in wholesale is organisational and relationship-based. Individual authorisation is not represented in any artefact both parties can verify.
- Disputes are resolved commercially rather than evidentially, which suits the larger party.
- This is a Grade C proposal: the mechanism is sound, the prevalence data is commercially sensitive and unpublished, and the article says so rather than estimating.
Part of Telecom and subscriber identity
Why this is filed as frontier
Most of the analysis in this series rests on public primary sources — regulator alerts, enforcement actions, published loss data. Wholesale telecom has almost none of that. Carriers do not publish dispute volumes, settlement leakage or fraud losses, because those figures are commercially sensitive in negotiations with the very counterparties who would read them.
So the honest position is: the structural weakness is describable and the mechanism is transferable from adjacent domains, but the size of the problem is asserted by practitioners rather than measured. Treat the rest of this as a proposal to be tested, not a finding.
The structure, described
Two carriers interconnect under a bilateral agreement. Over its life, operational instructions flow between them: route changes, capacity adjustments, traffic redirection, dispute adjustments to settlement statements, credit notes, blocking of suspect destinations.
Each instruction is sent by an individual at one carrier to an individual at the other, typically by email, sometimes through a partner portal. Authority is established by an authorised-contact list exchanged at contract signature and updated by correspondence.
| Artefact | What it establishes | What it cannot |
|---|---|---|
| Bilateral agreement | Organisational relationship and commercial terms | Who may issue a given instruction today |
| Authorised contact list | Names at the time of exchange | Whether that person still holds the role |
| Email instruction | That a message arrived | That the named person sent it |
| Portal action | That an account performed it | Which human was behind the account |
Where this becomes expensive
Three scenarios, all of which practitioners describe and none of which is publicly quantified:
- Disputed settlement adjustments. One party asserts an adjustment was agreed; the other has no record. Resolution is negotiation, and negotiation favours the party with more leverage rather than the party that is right.
- Fraudulent route or destination changes. An instruction that opens traffic to a high-cost destination, later disclaimed.
- Stale authority. An instruction accepted from someone who left the counterparty months earlier, whose email continued to function.
The instruction receipt
The mechanism is identical to the cross-boundary designs used elsewhere in regulated industries, and its transferability is the strongest argument for it.
- Each carrier publishes signed authority delegations: named individuals, instruction classes, value ceilings where applicable, expiry.
- An instruction is a canonical statement signed by an authorised individual.
- The receiving carrier verifies the signature and the delegation offline, before acting.
- Both parties retain the receipt. A dispute resolves against a shared artefact rather than against two sets of records.
No systems integration is required, which matters in a domain where counterparties number in the hundreds and none of them will build to another's API.
How to test whether this is worth anything
The falsification condition should be stated before a pilot, not after. Run signed instructions with one interconnect partner for two quarters and measure:
- Dispute count and value, against the same partner's prior four quarters.
- Time to resolve a dispute, which is the cost that shows up first.
- Instructions received from individuals not on a current delegation — the stale-authority rate, which nobody currently measures.
- Operational friction reported by both sides' commercial teams.
If the stale-authority rate is near zero and dispute resolution time does not move, the proposal has failed its own test and should be dropped. That outcome is entirely possible and this article does not predict otherwise.
Why the industry has not done this
Not because it is technically hard. Because wholesale relationships are managed by commercial teams for whom the current ambiguity is occasionally useful, and because the party with more leverage in a dispute has no incentive to introduce evidence.
That is a candid assessment rather than a cynical one, and it predicts where adoption would start: with the smaller party in an asymmetric relationship, who benefits most from a shared record.
Which wholesale instructions are worth binding
| Instruction | Consequence |
|---|---|
| Routing change | Traffic and revenue moves |
| Rate amendment | Margin moves silently |
| Remittance detail change | Settlement funds redirect |
| Dispute settlement | A credit is issued |
Objections and honest limits
“Our partners are long-standing and known.” Which is exactly what makes a compromised partner mailbox effective. Familiarity is the attacker's asset here, not yours.
“Reconciliation catches it.” At period end, after settlement. In wholesale that is weeks, and the counterparty relationship makes recovery a commercial negotiation rather than a recall.
Binding wholesale instructions
- Identify the consequential instruction set. Usually four types, not the whole correspondence.
- Require a signature from a named individual at the partner. Enrolled once, at contracting.
- Bind the instruction contents. Rates, routes and remittance details, not a reference.
- Verify without contacting the partner. So the check happens every time rather than on suspicion.
Terms used here
- Interconnect
- The commercial and technical arrangement by which carriers exchange traffic.
- Settlement
- Periodic reconciliation and payment between carriers for exchanged traffic.
- Remittance detail
- The banking information settlement funds are paid to — the field with the most direct consequence.
Frequently asked questions
Why is this graded lower than the rest of the series? Because the evidence base is closed. The mechanism is well established elsewhere; the prevalence and cost in this domain are not publicly measurable, and estimating them would be inventing data.
Would industry associations be a better route? Possibly. Association-level adoption would solve the network problem faster than bilateral pilots, and the fraud working groups already exist.
Does this address roaming fraud? Only the instruction layer. The large roaming fraud categories concern traffic and usage rather than instruction authority, and this proposal does not touch them.
What would change your assessment? Published dispute and stale-authority data from any carrier willing to share it, or a pilot showing movement in resolution time.
Why is a long-standing relationship a weakness here? Because familiarity is what makes a compromised partner mailbox effective. The instruction looks exactly like every legitimate one.
Which instructions matter most? Remittance detail changes, then rate amendments, routing changes and dispute settlements.
Why does reconciliation not catch it? It catches it at period end, after settlement, when recovery is a commercial negotiation rather than a recall.
Where this fits in Manav
Manav puts the authorising party back in the loop for the changes that matter, with a signature bound to the specific change and verifiable by a counterparty without calling you.