What UPI did for payments, a shared data layer could do for freight

UPI is a set of common rules that are managed by a neutral third party and allow applications to transfer money to bank accounts of customers of participating banks. It’s basic plumbing but some of the most impactful work that has been done for the Indian payments ecosystem over the last decade.

At the other end of the economy, in freight we see no equivalent model. Here, the shipper, carrier, warehouse, and broker each maintain their own records of a shipment in whatever format they prefer to. And they reconcile those records by means of phone, email, and even spreadsheets with each other. We don’t see a huge scope for improvement by a single product in the Indian logistics space, but rather a common sub-layer of infrastructure upon which all can compete.

What UPI changed

India’s digital payment activities existed largely in closed ecosystems of wallets, banks’ apps, etc., before UPI. A payment worked only if both sender and receiver were on the same wallet or both were on the same bank’s app. Each new pairing required a new integration or a workaround.

The same is true for UPI. Launched by NPCI (National Payments Corporation of India) in 2016 as an additional payment option, it instead turned out to be a shared interface for payment initiated by customers. The banks connect to it once, and all the applications connect to it once as well. So, now any application can do a payment to any bank without the latter and the former having to establish connections and do integrations for each other.

Three things worked well for the Indian payment industry. Firstly, the payment rails are neutral, run by an industry body, and not by a payment company. Secondly, the environment is open, so anyone can build a payment application within minutes and start offering payment solutions to all banks within a couple of days without having to negotiate with every single one of them individually. Thirdly, only the bare minimum is required to make a payment, while all the fancy stuff, such as interface, rewards, etc., can be built on top of this by the various companies offering payment solutions to their customers. As a result, competition is not taken away but is moved up a layer where it can be felt by the customers.

Freight is still in the pre-UPI world

Look at how a single load is recorded today. The shipper has a shipment record. The carrier has a trip record. The driver has a phone, the warehouse has a gate log, and the consignee has a delivery note. Each one is accurate on its own terms, and none is wired to the others by default.

So every relationship needs its own integration or, more often, its own habit. A large shipper might connect to its top ten carriers by API and manage the remaining hundreds by phone and WhatsApp. A small carrier serving five shippers maintains five different ways of reporting the same trip. The number of connections grows with every new participant, and the smallest operators are the ones left at the edges.

That is the same shape as pre-UPI payments. The shortage is not good software. It's common ground for the software to stand on. We wrote about the limits of seeing a shipment on its own in Visibility was step one, and the shared layer is the part that comes after.

What the rails would carry

Four kinds of information come up in nearly every freight relationship, and each is a candidate for a shared standard.

Shipment status. Picked up, in transit, at the gate, unloaded, delivered. If every participant used the same small set of events with the same meaning, "what counts as delivered" would stop being a negotiation, and each system could publish and read the same events.

Identity. Which vehicle, which driver, which vendor, and whether each one is who they say they are. Today every company verifies these separately and repeats the work. A shared way to establish and reference identity would let a check done once be relied on many times. This is the layer our identity verification technology sits in.

Documents. E-way bills, proof of delivery, invoices, and consignment notes. Many already exist digitally, but they live in separate places and get matched by hand. A common reference for each document, tied to the shipment it belongs to, would let a delivery receipt and an invoice find each other without someone in finance doing it.

Capacity. Which vehicles are free, where, and on what terms. This is the hardest of the four, because capacity is commercially sensitive. Even a standard way to express an offer, such as a 32-foot truck in Pune tomorrow morning, would help shippers and carriers find each other faster.

Notice what isn't on the list: pricing strategy, planning logic, customer relationships. As with UPI, the rails would carry the facts everyone needs to agree on and leave the judgment to the companies on top.

Why one company can't build it

Shared infrastructure is easy to describe and hard to start, because the obvious builders are the wrong ones. A platform run by one big shipper or carrier asks its rivals to hand over their data, and they hesitate.

Shipping offers the clearest recent example. Maersk and IBM launched TradeLens in 2018 as a shared data platform for the container industry, and in late 2022, they announced it would be discontinued. Maersk's stated reason was that the platform worked as technology but hadn't achieved the level of industry-wide collaboration it needed. A common reading, though not Maersk's own wording, is that competing carriers were wary of building on infrastructure run by their largest rival.

Shared data can work, but only if the layer is owned by nobody in particular, which is what NPCI gave UPI.

Standards come before software

The use of a barcode on a packet of biscuits is a great example of how an older technology of physical goods has been enabled by agreement. Manufacturers and retailers all over the world have agreed to use the same numbering standard for barcodes, which are maintained by a neutral non-profit organization called GS1. A manufacturer only has to put a barcode on a packet of biscuits once, and then all retailers can read it with their scanners, regardless of the make of the scanner or the checkout system. In this case, no company competes on the barcode. The very existence of the barcode makes all the rest cheaper.

There is no barcode for freight data yet. Primarily, the work of getting freight data online consists of agreements about events, fields, and identifiers. The coding of this data is much easier than the preceding work.

What already exists

The Unified Logistics Interface Platform (ULIP) launched by the government in 2022 is another major step. It is expected to help logistics companies leverage data from various government-enabled systems through a single interface. The existing system of e-way bills for goods movement can already be categorized as a common document for logistics enablement.

While it’s great to have foundations such as status events for goods movement on the private side of the relationship (such as the commercial documents and capacity offers exchanged between companies), these events need to be communicated as commercial documents (such as capacity offers) between a shipper’s software and a carrier’s software.

Where to begin

Start working on the status events and defining eight to ten status events, and define each of them in very simple terms, and start running them on a few lanes with a few shippers and a few carriers. And we will publish these definitions on an open platform, and everyone else can start adopting it and building on top of it, and if it works well, then we move on to the other documents, like the commercial documents and the capacity offers.

The first version of the layer will necessarily be inferior to current alternatives, but that is just fine. Initially the scope of UPI was also very limited, and over time the scope kept on increasing. What is important is that the layer is open and does not evoke any fear in anyone.

What changes when the rails exist

If the layer arrives, then a few things happen. None of them require one person to ‘win’ here. It would be cheap for small operators to join in such a scenario. Currently, a small carrier with a few vehicles has to be flexible to the ways of individual shippers. With a standardized layer, one integration with all relevant small operators would be enough to allow them to participate as well.

Your data will improve as well. Today, urban freight tools rely on the data that is available today. By sharing status and capacity information with each other, the same data can now be used for much more sophisticated planning.

The competition will move up to improve services around the shared layer for the payment gateway as well. The exception handling, experience, and planning capabilities of each vendor will improve to differentiate them from other vendors on the shared layer for the unified logistics interface platform.

Where Libera fits

Our position is simple. A transport management system that awards, tracks, and settles freight in one place, like Libera's freight transport management system, gets more useful as its counterparties exchange information in a common form. Its value grows with the quality of the data around it, so we would rather build on shared rails than guard a private one.

We'd also like to help shape those rails. The standards that last will come from people who run real freight every day and know which status events matter and which fields never get filled in. That's the experience we'd want to bring to the table.

The next leap is shared

In UPI, everyone agreed to a few simple things but could compete on everything else. With so many more moving parts in freight, the agreement will likely evolve slowly and get more complex. But evolution in this direction is probably inevitable. Companies that do well in the next phase of Indian logistics will not be those with the best proprietary system. Instead, they will be those best able to connect with everyone else’s system.