Share the ship's position freely and guard the next cargo

Shippers ask carriers for more data every year, and carriers usually respond in one of two ways. Some refuse almost everything, on the general ground that operational data is confidential. Others agree to each request as it arrives, through whichever manager the customer happens to know best. I think both responses protect the wrong things. My position is that a carrier should share freely the data that is already public or harmless, should refuse absolutely the data that would let one customer infer another's business, and should write its data-sharing agreements around the questions a shipper is allowed to answer rather than the tables it is allowed to see.

What the transponder already tells everyone

Every laker on the Great Lakes broadcasts its position, course and speed through its automatic identification system transponder, a safety requirement. Public tracking websites collect those broadcasts, and anyone with a browser can watch our vessels move. When I returned to Morvaise in 2017, a shipper asking for the positions of our vessels was told that fleet data was confidential. The shipper then looked the vessel up on a public site, which was slower for everyone and made us look evasive about something we could not have hidden.

The same was true of much else. Lock transit times are observable by anyone watching the canal. Our arrival windows are, by design, sent to terminals that are not our customers. Draught limits and water levels are published. Treating all of it as confidential spent our credibility on secrets we did not possess.

We now give each shipper, through its own portal access, the position and arrival window of every vessel carrying its cargo, the loading and discharge records for that cargo, its weight certificates and its emissions statements, refreshed as our systems update. None of that cost us anything we could have kept. It cut telephone calls to our operations centre by about a third in the first season.

The inference no shipper should be able to draw

What needs protection is different, and it rarely sits in a single table. A laker discharging ore at a steel mill will next sail somewhere: perhaps to load grain for an exporter, perhaps salt for a distributor. If the steel mill can see the vessel's full rotation, it learns that we carry for the grain exporter, roughly how much and when. Over a season it can build a picture of our customer base, our capacity commitments and the freight market more widely. Some of the companies we carry for compete with one another. Some negotiate with us partly on their view of our spare capacity.

None of the individual data points is sensitive. The vessel's next port is public once it arrives there. The inference is the problem, and it is produced by combining records over time. That is why I stopped asking which fields were confidential and started asking what a shipper could conclude from what we gave it.

The answer produced three rules. A shipper sees a vessel only while it is carrying, or sailing to load, that shipper's cargo; the view opens when the vessel is fixed for the cargo and closes at discharge. Nothing about the next fixture, other customers' tonnage or a vessel's season plan is shared through any channel. And aggregated data, such as fleet calibration or average lock delays, is published only at a level where no single customer's volume can be worked out.

The third rule matters more than it seems. In 2024 a grain customer asked for our total tonnage by commodity on its route, to benchmark its own share. On that route we carried for only two shippers, so the total, less the customer's own tonnage, would have revealed the other's volume exactly. We declined and offered the figure at a broader level.

Write the agreement around questions, not tables

Most data-sharing agreements I have seen in logistics list the data a customer may receive: a schedule of fields, feeds and frequencies. That is useful to engineers and inadequate as a control. A list of fields cannot show what can be inferred by combining them, and it invites the customer to ask for one more field, which always seems harmless on its own.

Our agreement, which thirty-four shippers now use, begins with the questions a shipper may use our data to answer. Where is my cargo? When will it arrive? What did it weigh? What emissions belong to it? How reliable are the carrier's forecasts? The schedule of fields follows from those questions. Any new request is tested against them, and requests that would answer a question about someone else's business are refused whatever form they take. The agreement also says that our data may not be resold, or combined with other carriers' data to profile our fleet. That clause took longest to negotiate.

The harder part was internal. Before the agreement, a helpful operations manager could email a shipper a spreadsheet of the season's voyages, and several had. We now route every request outside the schedule to my team. We did not treat the earlier spreadsheets as misconduct, because people had been trying to serve customers with no rule to follow. But we did trace where they had gone, and asked two customers to delete files they should never have received.

There are costs. Some shippers wanted the full rotation so they could plan their own logistics around our capacity, and saw the refusal as unhelpful. One commercial colleague believes it cost us a contract with a grain company that wanted a fleet-wide view. The questions-based approach also demands judgement whenever a new kind of request arrives, which is slower than consulting a list.

I still think it is the right design. Carriers hold some of the most revealing commercial data in a supply chain, and much of it becomes revealing only in combination. A carrier that guards its public data and leaks its inferences has its priorities reversed. Share what anyone could see. Refuse what would let one customer read another's business. And when a request is new, ask what question it is meant to answer before asking whether the fields look sensitive.