Why detection needs candidates, not an answer
Carrier detection is one of those problems that looks solved until it is deployed, and the failure mode is quiet.
Formats genuinely overlap. A thirteen character string ending in a country code fits the international postal convention and could belong to any of dozens of operators. A numeric string of a common length matches several couriers. A system returning one carrier for such a number is not detecting, it is guessing with a confident interface, and the customer gets a tracking page for the wrong company.
Building it properly means returning ranked candidates with the matched rule attached, so the calling application can ask the customer, try several, or apply its own priors about which carriers it actually uses. That design decision has to be made at collection, because a dataset that recorded only the first matching carrier cannot be repaired later.
The second reason to use this source is coverage of postal operators. Express couriers are documented in many places; national posts in smaller countries are documented in few, and those are exactly the carriers a cross-border e-commerce product struggles with.
The third is that this is reference data with a long shelf life. Formats change rarely, so a well built dataset stays useful for years rather than needing constant refresh.