The FCC has proposed requiring originating voice providers to collect and verify a customer’s name, physical address, government issued ID number and alternate contact numbers before turning up service, then hold those records for four years after the customer leaves. Reply comments closed on 27 July 2026. If you resell PBX seats or SIP trunks, this one lands on you rather than your carrier.
What the proposal actually asks for
The Further Notice of Proposed Rulemaking was adopted on 30 April 2026. It is a proposal, not a rule, and nothing in it is enforceable today. But the comment cycle has now run its course, which means the next document out of the Commission on this topic is likely to be an order rather than another question.
The structure is borrowed fairly openly from financial services. Collect identity at onboarding. Verify it is real. Re-verify when something looks wrong. Keep the paperwork long enough that an investigator arriving two years later can still reconstruct who was behind a given call.
What makes it awkward for telecom is the second step. Banks verify identity because they are moving money and have decades of tooling built for it. A voice provider signing up a customer at two in the morning through a self-service portal has a card authorisation and an email address, and that is usually the whole file.
Why the timing matters more than the text
Regulatory proposals sit dormant for years all the time, so the reasonable instinct is to file this under things to worry about later. Two details argue against that.
The first is that the Commission ran a related rulemaking on upstream provider vetting through its May meeting. Those two proceedings point the same direction, which is that identity obligations are being pushed toward the edges of the network rather than concentrated at the terminating carrier. When two proposals reinforce each other, they tend to move together.
The second is that the record retention clock runs backwards. A four year retention requirement finalised in 2027 does not only apply to customers you sign in 2027. It applies to the relationship, and the relationship may have started in 2024. Providers who start collecting identity data only when the rule takes effect will spend the first two years explaining gaps.
That asymmetry is the strongest practical argument for treating this as a now problem. Collecting identity early costs you a form field. Reconstructing it later costs you an audit.
The reseller layer is the actual target
Read the proposal as a piece of enforcement design and its shape becomes clearer. The Commission is not worried about a hospital group with a PBX. It is worried about the account that appeared last month, bought a block of numbers, ran forty thousand calls in nine days, and vanished before anyone answered a traceback.
Those accounts almost never sit directly on a carrier. They sit two or three layers down, inside somebody’s white label platform, signed up by a reseller who was measured on how fast they could onboard.
This is the uncomfortable part for anyone running a multi-tenant platform. Your resellers are your customers, and their customers are strangers to you. When a traceback arrives, it does not stop at the reseller. It carries on up to whoever holds the carrier relationship, and that is the name on the correspondence.
Plenty of platform operators already know this and have quietly decided the revenue is worth the exposure. That calculation changes if identity records become a documented obligation rather than a matter of judgement.
The number that scales badly
The proposal carries a base forfeiture of $2,500 per illegal call. On its own that figure sounds survivable. Against automated dialling volume it stops being survivable very quickly.
A single tenant running a modest campaign for a week can place tens of thousands of calls. You do not need a large fraction of those to be judged illegal before the arithmetic turns into something no reseller margin covers. The exposure is not really the fine on any one call. It is that voice traffic is the one product where a single bad customer generates violations at machine speed.
Toll fraud has the same property, which is why platforms that have already built spend controls and rate limits are further along here than they might realise. The plumbing that catches a compromised extension dialling premium numbers at 3am is the same plumbing that flags a new tenant whose volume does not match anything they told you at signup.
What a platform actually needs to store
Most PBX platforms model a tenant as a billing record with a name, a contact email and a plan. That is enough to invoice somebody and not much else.
Meeting the proposal as written means the tenant record needs to hold rather more, and needs to hold it in a form somebody can export under time pressure:
- Legal or trading name, separate from the display name on the account
- A physical address that has been checked against something, not just typed into a box
- A government issued identifier, stored encrypted, with access logged
- At least one alternate contact number that is not the number you provisioned
- The date each field was collected and the date it was last verified
- A retention timer that starts when the account closes, not when it opens
That last item is the one people get wrong. Deleting a tenant record on cancellation feels like good data hygiene and is exactly the behaviour the rule would penalise. The four year clock begins at the end of the relationship, so cancellation is the moment the record becomes most important rather than least.
Access logging on the identity fields is worth adding for a reason that has nothing to do with the FCC. You are now holding government ID numbers for every tenant on the platform, which makes your admin panel a considerably more attractive target than it was last quarter. The isolation and access rules that keep tenants apart matter more once each tenant record carries identity documents.
Where re-verification gets difficult
Collecting identity once is a form change. Re-verifying when red flags appear is a process, and processes need someone to own them.
The proposal does not enumerate what counts as a red flag, which is either sensible flexibility or an invitation to argue about it later, depending on your temperament. The obvious candidates are a traceback notice naming the tenant, a volume pattern that jumps well outside anything the account has done before, a payment method that fails and gets replaced by an unrelated one, and a sudden change of contact details shortly after signup.
None of those are hard to detect. A platform that already produces per-tenant call detail records has the data sitting there. What is usually missing is the step where detection turns into a human looking at an account and deciding whether to ask for documents again. That step is cheap to skip and expensive to have skipped.
Where ICTPBX sits on this
ICTPBX is a white label multi-tenant platform built on ICTCore and FreeSWITCH with an Angular front end, aimed at service providers and ISPs rather than single organisations. That positioning is why this proposal matters here more than it would for a system running one company’s phones.
Being self hosted helps with the parts of this that are about control. Tenant data lives in your database, on your infrastructure, under whatever retention policy you set, and you can add fields to a tenant record without waiting for a vendor roadmap. When an investigator asks for records covering a customer who left eighteen months ago, you are querying your own system rather than filing a support ticket with a cloud provider.
It does not help with the part that is about discipline. No platform can make a reseller ask for a passport. What a platform can do is refuse to provision numbers until the required fields are populated, which turns an optional process into a blocking one. That is a configuration decision and a slightly unpopular one, and it is the difference between having the records and having intended to collect them.
What to do in the next quarter
None of this depends on the rule being finalised, which is the useful part. Every step below is defensible on fraud grounds alone.
- Pull a list of every tenant on the platform and mark which ones you could identify to a regulator today. The number is usually lower than people expect.
- Add the identity fields to the tenant record now, even if you leave them optional at first. Schema changes are easier before there is a deadline attached.
- Make provisioning conditional on those fields for new signups. Existing tenants can be backfilled at renewal.
- Set retention to start at account closure and stop deleting cancelled tenants.
- Write down what your red flags are, even a rough list, and decide who reads the alerts.
- Tell your resellers what you will be asking for. They will hear it better now than in a compliance email six months from now.
The tenant audit in step one tends to be the moment this becomes real for people. Operators who believed they had a few hundred known customers routinely find a long tail of accounts that were signed up by a reseller who has since churned, and nobody has any idea who is behind them.
Frequently asked questions
Is the Know Your Customer rule in effect now?
No. It is a proposal adopted on 30 April 2026 for public comment. Reply comments closed on 27 July 2026 and no order has been issued, so there is no compliance date and no obligation today. Treat it as planning input.
Does this apply to us if we only host PBX seats and do not originate calls?
If your tenants place outbound calls that reach the public network through service you provide, you are in the originating chain even if a wholesale carrier does the actual handoff. The question to ask is whose name appears on a traceback response, not who owns the switch.
What counts as verifying an address?
The proposal does not prescribe a method, which is deliberate. Checking the address against a commercial data source, matching it to the billing address on the payment method, or requiring a document that shows it are all reasonable. Accepting whatever is typed into the form is not.
How do we handle resellers who refuse to collect this?
Ultimately by making provisioning conditional on it. A reseller who will not identify their customers is a reseller whose traffic you will be answering for, and that is a commercial decision rather than a technical one. Some platforms are choosing to price that risk in instead.
Do we need to keep records for tenants outside the United States?
The proposed rule reaches calls terminating on US networks, so international resellers sending traffic into the US are inside its scope. If your platform serves multiple regions, the practical answer is usually to apply one standard everywhere rather than maintain two onboarding flows.
Is four years the final retention period?
Four years is what the proposal specifies, and it is the figure to plan around. It could move in a final order. Building the retention timer as a configurable value rather than hard coding it costs nothing now and saves a migration later.