Verinode
Open Verinode

The privacy boundary: k-anonymity, aggregate-only views, and entity models

Accounts > TPAs is where Verinode HQ rolls up every third-party administrator (TPA) your franchisees deal with into network-level rows: how much is billed and collected, how fast each TPA pays, wha…

10 min read·Updated July 14, 2026
On this page

What this page is

Accounts > TPAs is where Verinode HQ rolls up every third-party administrator (TPA) your franchisees deal with into network-level rows: how much is billed and collected, how fast each TPA pays, what it charges to administer a claim, and how hard it pushes back on supplements. It answers "how is this TPA treating our network," not "how is one specific franchisee doing with this TPA." That second question belongs to the franchisee whose business it is, not to HQ, and this article is entirely about the line that keeps it that way.

HQ is not a job-management, CRM, or accounting tool, and the TPAs page never turns into one. Franchisees own their own business data. HQ only ever sees what a nightly network rollup has already aggregated, and even those aggregated rows are withheld the moment showing them would let HQ work out, by elimination, which single franchisee sits behind a number. This article covers exactly where that line sits on the TPAs page and inside a TPA's own detail view: what gets hidden outright, what gets shown only as a network total, and what changes depending on the kind of network you run.

Where to find it

Open Accounts from the HQ sidebar. It lands on the Carriers pill at hq.verinode.ai/carriers; click the TPAs pill (of the Carriers · TPAs · Commercial strip) to reach hq.verinode.ai/tpas, the page this article covers. Clicking any TPA tile, in any row, opens the TPA detail overlay on top of the page. The same TPA also has a permanent address at /franchise/tpas/[canonical_entity_id], a standalone page that renders a lighter version of the same detail outside the click-through flow.

Note

None of this touches the Verinode Score shown at the top of a TPA's detail view. That score comes from Verinode's operator-rated catalog, is computed once across every operator on the whole platform, and is never gated by your own network's size. Everything below is about numbers your own franchisees generated, billing, payment timing, fees, and supplement pushback.

The k-anonymity guard: why some TPAs never show up

Every TPA row on this page starts life in a nightly network rollup, one row per TPA, counting how many of your franchisees have routed a claim through it (franchisees_serving_count). A TPA served by exactly one franchisee is a special case: showing that TPA's numbers to HQ would tell HQ exactly which franchisee they came from, just by process of elimination, no matter how the row is labeled. So Verinode suppresses it. A TPA only earns a visible row, tile, or ranking slot once more than one franchisee in your network has routed claims through it. This is the textbook minimum threshold for protecting a small cohort from identification by elimination, and same_entity networks bypass it entirely, since there is no separate business to protect when HQ already owns the data.

This guard applies uniformly across every ranked list on the TPAs page: Slowest Payers, Broadest Network Footprint, Heaviest Pushback, and the full All TPAs list. A single-franchisee TPA does not appear in any of them. It is not greyed out or blurred, it is simply absent, the same way it would be missing from any list scoped to "TPAs two or more of your locations have dealt with."

What HQ still sees. The Network TPAs hero at the top of the page counts every suppressed TPA without ever naming it. Its summary line ends with a trailing note, "N hidden as single-franchisee," whenever the count of suppressed TPAs is greater than zero. The network totals above that line, total TPAs, total jobs, billed and collected dollars, the average admin fee, and the network-weighted average days-to-pay, are computed across every TPA your franchisees have, including the suppressed ones. Suppression never shrinks the network total. It only ever removes the ability to see which TPA a number belongs to, once showing that TPA's identity would leak a single franchisee's business.

If you land on a suppressed TPA by direct link. A suppressed TPA can still be reached by URL, a bookmark, a link shared before it dropped below the threshold, a link pasted into a report or a digest email. The detail overlay does not error out. It opens, shows the TPA's name and Verinode Score (those are never gated), and in place of every dollar figure shows this exact text:

Aggregate-only view. This TPA is currently served by fewer than 2 franchisees in your network. Per-TPA metrics are suppressed to protect operator privacy.

The standalone /franchise/tpas/[canonical_entity_id] route shows a slightly longer version of the same message, with the parenthetical "(single-franchisee identification risk)" appended. Either way, no billed amount, no days-to-pay, no collection rate, no fee figure, no supplement pushback, and no per-franchisee list render underneath. As soon as a second franchisee starts routing claims through that TPA, the guard lifts on its own and the full detail view appears at the next nightly refresh, nothing to configure on your end.

Tip

If a TPA you know your network uses never shows up on the page, in a Slack digest link, or when you search for it, the most likely reason is this guard, not a data gap. Check with your other locations. Once two or more of them have routed claims through that TPA, it surfaces on the next overnight run.

The entity-model fork: whose data can be named

Not every HQ network is the same shape, and Verinode treats two shapes differently. Your network's entity model decides which one applies, and it is set once at the network level, not per franchisee or per TPA:

  • Same entity: a single-owner, multi-location business, an enterprise buyer or a PE-backed platform that owns its locations outright. HQ is the business here. There is nothing to anonymize because HQ already owns the underlying data.
  • Independent operators: the default, and the safer posture. This covers franchises, associations, and buying groups where each location is an independently owned business that happens to share a network. HQ sees the network's aggregate performance, never one member's private numbers, because HQ is not that member's owner.

New networks start on independent operators and have to be explicitly moved to same entity. This fork changes four things on the TPAs page and inside a TPA's detail view, each a little differently:

  1. 1Franchisee display names. Anywhere a franchisee or location name would render next to a number, per-franchisee participation, per-location supplement pushback, per-location line-item cuts, per-location rate terms, same-entity networks see the real name. Independent-operators networks see a stable anonymized label instead, formatted as Franchisee #XXXX, built from a short suffix of that franchisee's internal ID so the same franchisee always gets the same label across the page without ever surfacing their actual business name.
  2. 2Per-location supplement pushback. The "Pushback by location" list inside a TPA's detail view, which breaks supplement denials out location by location, only renders real rows for same-entity networks. For independent-operators networks, the whole list is replaced with one disclosure line: "Per-location supplement detail is shown only for networks that own their locations' data. Your network sees the aggregate above." The aggregate figures above it, denial rate, cut dollars, average response time, still show, because those are network totals, not one member's private data.
  3. 3Per-location line-item cuts. The same fork applies one level deeper, inside "What [TPA] cuts across your network." Each canonical line item's per-location breakdown, showing whether a denial pattern is systematic across the network or isolated to a few locations, is populated only for same-entity networks. Independent-operators networks get an equivalent disclosure line instead: per-location line detail is shown only for networks that own their locations' data.
  4. 4Per-location program rate terms. On the "Program rates" section of a TPA's own page, the "By location" list breaking out each franchisee's accepted discount, admin fee, referral fee, or flat fee for that TPA only renders for same-entity networks. Independent-operators networks see: "Per-location rate detail is off for association and cooperative networks. Members keep their own pricing private. Only the network aggregate is shown." The network average, the reporting-location count, and the industry comparison above that list are unaffected either way.

What does not change. The per-franchisee participation list on a TPA's detail view, which franchisees route claims through this TPA, their job counts, billed and collected dollars, days-to-pay, and fee terms, still renders a row per contributing franchisee in both entity models, as long as the TPA itself has cleared the k-anonymity guard above. The only difference is whether that row is labeled with a real name or an anonymized Franchisee #XXXX tag. That participation list is the one place per-franchisee dollar figures do reach HQ at all, and it is still gated on the TPA having enough franchisees serving it that no single row could be reverse-engineered back to one business by elimination.

Note

The word Verinode uses for your network's members changes with the shape of the network too: a franchise's members are "franchisees," an association's or buying group's are "members," and a same-entity network's are "locations." You will see whichever term fits your network across HQ, not just on the TPAs page.

Where these two guards actually show up

The k-anonymity guard and the entity-model fork are two separate mechanisms, and it helps to keep them straight. The k-anonymity guard decides whether a TPA appears at all. The entity-model fork decides, for a TPA that does appear, whether its per-location breakdowns can carry a name. A TPA can clear the first gate and still have every one of its per-location lists replaced with an aggregate-only disclosure, that is the ordinary experience for any independent-operators network, which is most franchise systems and associations.

Concretely, across the TPAs page and a TPA's own detail view:

  • Hero, Slowest Payers, Broadest Network Footprint, Heaviest Pushback, All TPAs. Governed by the k-anonymity guard only. A TPA either clears it and appears everywhere, or fails it and appears nowhere, with the hero's hidden count as the only trace it left behind.
  • The four-KPI lockup (billed, days-to-pay, collection rate, avg fee) and the Jobs rows. Governed by the k-anonymity guard only. These are network totals for the one TPA you opened, they show once the TPA clears the guard, in both entity models.
  • Per-franchisee participation list. Governed by the k-anonymity guard (must clear it to render at all) plus the entity-model fork (real name versus anonymized label).
  • Per-location supplement pushback, per-location line-item cuts, per-location rate terms. Governed by the k-anonymity guard (must clear it to render at all) plus the entity-model fork, but here the fork is a hard on/off, not just a naming choice. Independent-operators networks never see these three lists at all, regardless of how many franchisees serve the TPA. Only the network aggregate above each list is shown.

Reading the hidden-count note on the hero

The Network TPAs hero at the top of the page carries the visible trace of the k-anonymity guard. Its summary line ends with a trailing clause, "N hidden as single-franchisee," whenever one or more TPAs have been suppressed. This is the only place the guard's effect is surfaced as a number, and it is deliberately vague about which TPA or which franchisee it refers to. A rising hidden count usually means the network is early, or its franchisees are spread across many TPAs organically rather than concentrated on a shared handful. As franchisees increasingly route claims through the same TPAs, the hidden count falls and more rows populate the ranked lists below the hero on their own, with nothing to configure.

Best-practice example

Say your network works with a dozen TPAs, three of which only one franchisee currently routes claims through. Open Accounts > TPAs. The hero reads 12 TPAs total, with the note "3 hidden as single-franchisee" at the end of its summary line, so leadership knows the visible rows below are a filtered set, not the network's complete TPA catalog. Slowest Payers, Broadest Network Footprint, Heaviest Pushback, and All TPAs each show only the nine TPAs that clear the guard. Opening one of those nine, the one with the highest denial rate, shows the network-wide numbers, the industry comparison, and the line-item breakdown of what it cuts hardest. If this is a same-entity network, the per-location breakdown underneath shows the cuts concentrated at two locations rather than spread network-wide, pointing at a coaching conversation rather than a TPA-relationship conversation. If this is an independent-operators network, HQ sees the identical aggregate numbers and the identical line-item read, but stops there: it takes the pattern to the affected franchisees directly rather than naming which one is driving it, because that call belongs to the members, not to HQ.

Related articles

Data sources

Data sources

  1. 1.Nightly network rollup of franchisee-recorded TPA jobs, billing, and payment timing. Your network's franchisees.
  2. 2.Supplement submission, denial, and line-item pushback rollup. Your network's franchisees.
  3. 3.Program rate terms recorded by each franchisee. Your network's franchisees.
  4. 4.Your network's entity-model setting (the network data.entity_model). Verinode HQ configuration.
Was this helpful?