Summary

  • The Integrated Public Number Database, or IPND, stores public telephone numbers and related customer information used by authorized services including emergency calls and emergency alerts.
  • ACMA found 30,014 occasions when Aussie Broadband did not provide required new or updated records on time between 5 November 2021 and 11 May 2022. That is a regulatory count of occasions linked to carriage services, not 30,014 identified people.
  • A software problem stopped returned error files from being pushed through for review. ACMA found at least 168 same-day download failures, while a separate reconciliation control had been inactive for about 14 months.
  • The durable control is a closed loop: observe a live service change, send the record, receive and work the error response, compare the carrier's full set with the central ledger, and prove the correction.

What the IPND does—and what it does not do

Most people rarely think about the data behind a telephone number. A number feels like a direct line to a person or business. Operationally, however, a carrier also needs records that describe who provides the service, whether it is connected, the customer's name and address, and whether the number is listed.

Australia centralizes this public-number customer data in the IPND. ACMA's investigation report says the database is used for critical purposes by the emergency call service, the emergency alert system, national-security agencies and law enforcement. Authorized users can also use it for permitted research and number directories.

The IPND is not the telephone network. It does not carry a voice call, determine whether a mobile radio is connected or send an alert by itself. It is a ledger that supplies information to operational systems and authorized people. That distinction matters: a database row cannot replace a working service, but a working service does not make an incorrect database row harmless.

Consider a simple example. A household disconnects a fixed voice service and moves. If the carrier's live billing and network systems know that change but the central record still shows the old address, the network and the ledger describe different realities. An emergency user may depend on accurate information even though the database did not cause the original service event.

What ACMA counted

ACMA examined information associated with Aussie Broadband services between 5 November 2021 and 11 May 2022. It found 30,014 occasions on which required public-number customer data was not supplied by the required time.

The first component was 24,090 occasions when no required record had been provided: 12,413 concerned VoIP services and 11,677 concerned mobile services. The second component was 5,924 occasions when an existing record was not updated after something changed: 5,413 VoIP services and 511 mobile services. The report says 5,000 of those update failures involved disconnected services.

The delays ranged from about two days to about 186 days. Aussie Broadband supplied the missing and updated data between 11 and 24 May 2022 after completing a reconciliation against the IPND.

These figures need careful labels. ACMA found 30,014 contraventions of the statutory service-provider rule and also 30,014 contraventions of clause 4.2.1 of the IPND Code. Those are two legal classifications of the same underlying 30,014 occasions; they are not 60,028 additional customers.

The report also found 5,924 contraventions of the accuracy obligation in clause 4.2.16. That figure overlaps the 5,924 update failures already included within 30,014. Adding every legal finding together would create a number that does not represent unique people, records or services.

The missing half of an upload

Sending a data file is only the first half of a reliable exchange. The receiving system also needs to say which records were accepted and which had problems. ACMA's report says an error file was automatically generated whenever an uploaded file contained errors, and the IPND Manager made that response available in the provider's download area within hours.

A technical issue in Aussie Broadband's error-reporting software meant those files were not pushed through for review and action from 5 November 2021 until at least 22 April 2022. Because the company uploaded data daily, ACMA found at least 168 occasions when corresponding error information was not downloaded on the day required by the code.

This does not prove 168 emergency incidents or 168 affected customers. It identifies at least 168 broken feedback opportunities. The important operational point is that an outbound upload without an observed return receipt can look successful while rejected or incomplete records remain unresolved.

A mature interface therefore tracks two states. The first is “sent.” The second is “accepted, or rejected and repaired.” A dashboard showing only file transmission can be green while the actual data quality is red.

Why the six-month reconciliation mattered

Error files catch problems that a receiving system recognizes in an individual upload. They cannot detect every difference between two large systems. That requires a periodic comparison of the carrier's records with the central database.

The IPND Code required a data provider to obtain an extract of its records at least once every six months for reconciliation. Information from the IPND Manager showed that Aussie Broadband had not obtained an extract since 4 February 2021. ACMA found a gap from 5 February 2021 until at least 23 April 2022—about 14 months—during which at least two extracts should have been obtained.

The report recorded two contraventions of that obligation. Again, “two” is a legal count of missed six-monthly controls, not a count of all mismatched records that may have existed during the period.

The later reconciliation was consequential: ACMA says the missing and updated records were supplied between 11 and 24 May 2022 after the comparison was completed. A periodic full-set check is therefore not ceremonial paperwork. It is the control that can expose drift which daily messages and their local assumptions have missed.

A ledger needs evidence from the running service

Public-number records have the same basic governance problem as other network-resource registries. The ledger should accurately record identity, status and responsibility, but it should not be confused with the thing it describes.

The reality layer begins in the carrier's running systems. A connection, disconnection, address change or listing-status change occurs. That event should produce an owned data update. The transfer should produce a receipt. Any returned error should enter a visible queue with a deadline and accountable operator. Periodically, the carrier should compare its full live inventory with the central ledger and resolve every unexplained difference.

None of those steps requires treating the register as sovereign over the phone network. The network establishes whether a service exists and works. The register preserves the evidence that authorized public systems need. Reliable operations keep the two views reconciled.

What the regulatory action means

ACMA's publication records that Aussie Broadband paid an AUD 213,120 infringement notice in relation to the IPND service-provider rule. ACMA also directed the company to comply with the IPND Code, including the duties to provide and update records, download error information and obtain reconciliation extracts.

The payment and direction are regulatory outcomes, not evidence that a particular person missed an alert or that every record error produced public harm. The investigation describes potential risk because the data supports critical services. Reporting should preserve that boundary instead of turning a control failure into an unproven emergency story.

The direction also clarifies the forward-looking requirement. A carrier cannot solve this class of problem merely by correcting a historical batch. It must keep the recurring process working: uploads, feedback, correction and reconciliation.

A practical closed-loop control

For a carrier, the control can be made visible as one chain:

  1. Capture every connection, disconnection, address, contact and listing-status change from the live service system.
  2. Generate the required IPND transaction by the next business-day deadline.
  3. Record a durable upload receipt and the exact records included.
  4. Download every returned error file and assign each error to an accountable queue.
  5. Correct hard and soft errors within their required windows and prove the replacement record was accepted.
  6. Obtain scheduled full extracts, compare them against the carrier's inventory and investigate every mismatch.
  7. Test the process during software failures, access changes and staff absence.

The first and fourth steps are especially easy to separate organizationally. One team may own outbound feeds while another owns data quality. If no single control joins them, both teams can believe their part succeeded.

Leadership reporting should therefore show more than a percentage of files sent. It should show unacknowledged uploads, undownloaded error files, the age of open errors, the date of the last completed reconciliation, unmatched record counts and whether a trained alternate can run the process.

The durable lesson

A database used by emergency systems does not become trustworthy merely because it exists or receives daily uploads. Trust comes from a feedback loop that measures whether the receiving system accepted the data and whether the complete ledger still matches the carrier's running reality.

The Aussie Broadband findings show four layers of that loop: timely event capture, accurate transmission, active error handling and scheduled full reconciliation. Weakness in one layer can let drift persist even when the other systems appear busy.

The register remains a ledger, not the network. But when people use that ledger for public safety, accuracy and continuity are operational obligations. The accountable outcome is simple to state and demanding to maintain: live service, submitted record, returned evidence and reconciled database must agree.

Sources