Who hands out TAC codes, and why no database is complete

Every phone model that wants to attach to a cellular network needs a Type Allocation Code. It is the first eight digits of every IMEI the model will ever carry, and it is the reason a fifteen-digit number can be turned back into "Samsung Galaxy S24 Ultra" at all.

TACs are not chosen by manufacturers. They are allocated, through a chain that is worth understanding if you depend on the resulting data — because the shape of the chain explains the shape of the gaps.

The allocation chain

The GSMA sits at the top of the scheme as the global administrator of the IMEI numbering space. Beneath it, a small set of reporting bodies handle applications regionally and issue codes out of the ranges delegated to them. A manufacturer bringing a new model to market applies through one of these bodies, declares the device, and receives a TAC — or several, if the model ships in variants that need to be distinguished.

Two consequences fall straight out of that structure. First, allocation happens before launch: a TAC can exist in the register weeks or months before anyone can buy the phone. Second, the declaration is made by the manufacturer, in whatever detail the process requires — which is not necessarily the detail a buyback platform or a repair shop wishes it had.

Why one model can hold many TACs

The tidy mental model — one phone, one TAC — falls apart quickly in practice. A single commercial model routinely spans several codes:

• Regional radio variants. A handset sold in Europe and one sold in North America may carry different band support and be registered separately.
• Carrier-specific builds, particularly in markets where operators commission their own SKUs.
• Manufacturing at more than one site or under more than one entity.
• Simple exhaustion — six digits of serial gives a million units per TAC, and popular models outsell that.

Where the gaps come from

No TAC database is complete, and any provider claiming otherwise is either misinformed or selling something. The gaps have specific, structural causes:

1. Lag. A code allocated today reaches downstream databases when it reaches them. Newly launched devices are the most common miss.
2. Sparse declarations. What the manufacturer declared is the ceiling on what anyone downstream can know. If the submission was thin, every database built on it is thin in the same place.
3. Long-tail hardware. Industrial modems, telematics units, obscure regional brands and white-label devices are numerous, low-volume, and poorly documented.
4. Withdrawn or reassigned allocations, which leave codes that resolve to something no longer accurate.

What this means for integration

If your product depends on TAC lookups, design for the miss rather than treating it as an exception. Concretely:

• Distinguish "not found" from "error". A well-formed IMEI whose TAC is not on file is a normal outcome, not a failure — handle it as data, not as an exception path.
• Never block a business process on a lookup alone. An intake flow that refuses a genuine trade-in because a two-week-old handset is not yet in the register is worse than one that falls back to manual entry.
• Cache by TAC, not by full IMEI. Everything a register can tell you is a property of the first eight digits; caching on all fifteen multiplies your storage by a million and buys nothing.
• Re-resolve unknowns periodically. Today's gap is often next month's record, and a one-off failure that is never retried becomes permanent bad data in your own system.

The last point is the one most often skipped. A register grows; a cache that only ever writes on first miss does not.