CargoGuard launches anti-fraud visibility platform targeting $30bn double-brokering losses

The Analysis

A freight fraud platform launched on 26 August out of Memphis, aimed at brokers, third party logistics providers and shippers, and the number attached to it is three hundred billion dollars a year in losses from double brokering and cargo theft, with theft up fifty seven percent year on year. I am not going to argue with the size of the problem. I am going to argue with the way that number gets used, because three hundred billion is an industry figure with an undisclosed denominator, and an industry figure is not a budget line for your company. Before you buy anything, you need your own base rate, and most operations I have seen cannot produce it in under a week.

Here is how I would model it. Think of this class of system as a classifier sitting in front of a queue. Every load arrives, the classifier scores it, and the ones above a threshold get pulled into a review queue where a human decides whether to release or hold. That is the whole architecture, and it has exactly the properties any classifier has: it has a recall, meaning what share of genuinely fraudulent loads it catches, and it has a precision, meaning what share of the things it flags turn out to be real. Vendors talk about recall because it sounds like protection. Buyers live with precision, because precision is what fills the review queue and eats the ops team.

The base rate is what makes this problem unusual, and it is the reason I want to start with measurement rather than procurement. Double brokering and cargo theft are, on any individual load, rare. Rare events are hard to detect, and a classifier that is ninety nine percent accurate on a population where the true rate is five hundredths of one percent will still produce far more false alarms than true ones. That is not a criticism of any particular product, it is arithmetic. It also means the tuning decision is yours, not the vendor's, and the right setting depends on a number only you have: what a fraud event actually costs you, and what a false alarm actually costs you.

Let me set out what this kind of platform claims to do, in the terms the launch described, and then separate the parts I can evaluate from the parts I cannot. Three components: anti spoof satellite positioning, so a device cannot simply report a location it is not at; instant driver identity verification at the point of pickup; and an application programming interface into the transport management system you already run, so that the check happens inside the booking flow rather than in a separate screen. The stated purpose is interception before the load moves. That is the right place in the process to intervene, and I will say why in a moment, because timing is the single biggest determinant of whether any of this is worth money.

Why before pickup matters more than anything else on the feature list. Once a carrier who has no intention of delivering it has the freight, your leverage collapses. You are no longer deciding whether to hand over goods, you are chasing goods, and recovery rates on loaded and departed trucks are poor by every account I have seen. So the entire economic value of this class of tool sits in a window of minutes to hours between booking and gate-out. That window is the service level you should be buying, and it is measurable: how long does it take from a load being tendered to the system returning a usable decision, and what share of loads get that decision before the truck arrives?

Now the arithmetic, with every input flagged as an assumption. Assume a mid sized brokerage handling fifty thousand loads a year. Assume the average load value is forty thousand dollars. Assume the true incidence of a fraud event, double brokering or theft, on your book is five hundredths of one percent. That is twenty five events a year, and at forty thousand dollars each that is one million dollars of annual loss. Assume your gross margin is one hundred and fifty dollars a load, so seven point five million dollars of gross profit. One million is about thirteen percent of gross profit. If those assumptions resemble your book, this is not a rounding error, it is a strategy problem.

Assume the platform prices at three dollars per load, which is a plausible order of magnitude for per load visibility pricing and is my assumption, not a quote. Fifty thousand loads is one hundred and fifty thousand dollars a year. Payback requires the tool to prevent more than one hundred and fifty thousand dollars of loss, and at forty thousand dollars per event that is three point seven five events, call it four. Four out of twenty five is a sixteen percent interception rate. Below sixteen percent detection on your own book, the tool loses money at that price. That is the number I would take into a negotiation, because it converts a fear based purchase into an arithmetic one.

Now price the false alarms, because this is where I expect to disagree with how most teams set the threshold. Assume a human review takes eight minutes and the loaded cost of that person is sixty dollars an hour, so eight dollars per alert. Assume a false alarm holds a legitimate driver for twenty five minutes and triggers a detention claim at fifty dollars an hour, roughly twenty one dollars. At ten percent precision, catching four real events requires forty alerts. Forty alerts at eight dollars is three hundred and twenty dollars of review time, plus thirty six false alarms at twenty one dollars is seven hundred and fifty six dollars. Total around one thousand one hundred dollars against one hundred and sixty thousand dollars of avoided loss.

Push precision down to two percent, which is a genuinely bad classifier, and the picture barely moves. Catching four real events now needs two hundred alerts: sixteen hundred dollars of review time plus one hundred and ninety six false alarms at twenty one dollars, about four thousand one hundred dollars. Call it five thousand seven hundred dollars against one hundred and sixty thousand dollars saved. The conclusion is uncomfortable for anyone who likes tidy rules: in this cost structure, false alarms are cheap and misses are ruinous, so the threshold should be tuned hard toward recall. A team that tunes for a clean queue is optimising the wrong variable.

That conclusion is conditional, and I want to state the condition explicitly, because it flips. It depends on the loss per event being large relative to the cost of an alert. If your book is mostly low value short haul freight, say four thousand dollars a load rather than forty thousand, then twenty five events is one hundred thousand dollars of loss, four prevented events is sixteen thousand dollars, and five thousand seven hundred dollars of alert cost starts to matter a great deal. Same tool, same precision, opposite answer. This is why you cannot inherit anybody's threshold, including mine, and why the first deliverable in this project is not a purchase order.

The first deliverable is a twelve month fraud ledger, built from your own records, and most organisations do not have one. For every confirmed event in the last year: the load, the value, the lane, how the carrier was sourced, where in the process the problem surfaced, whether it appeared after gate-out or before, how much was recovered, and how much was written off. Without that ledger you cannot state your base rate, and without a base rate you cannot compute the sixteen percent threshold, and without that threshold every proposal you read is unfalsifiable. Build it before you take a single demo, and expect it to take two to three weeks of unglamorous work.

Then run the platform in shadow mode before it touches a live decision. Four to six weeks with the system scoring every load, alerts going to your team for review, and no automated holds. Shadow mode does two things a pilot cannot. It gives you the precision and recall numbers on your own book rather than on a vendor's curated sample, and it tells you what the alert volume does to your operation on a Monday morning. It also forces the labelling discipline you will need forever: somebody has to write down, per alert, whether it was real, and that judgement has to be made by a person who does not also own the decision to buy the tool.

The evaluation set deserves a hard rule. Do not accept vendor measured recall measured on vendor labelled data. That is not cynicism, it is standard practice: a classifier tested on the sample it was tuned against will always look good. Hand over your ledger, blinded, with dates and lanes but without your outcome labels, and ask for scores back. Then you label. This is the single step most buyers skip and the one that most changes the answer. If a vendor will not participate in a blind test on your data, you have learned something important about the product at no cost.

Coverage is the quiet killer in this category, and it hides inside the integration claim. Application programming interface integration with your transport management system sounds complete, and then you discover it only syncs loads booked through one module, or only loads above a value floor, or only full truckload and not less than truckload. If the system watches sixty percent of your book, every rate you compute is a rate over sixty percent, and a sixteen percent interception rate over sixty percent coverage is nine point six percent over the whole book, which may be below payback. Ask for coverage as a denominator on every report: loads scored divided by loads tendered, reported weekly.

Measure the components separately, because three features in one platform will not fail together. For anti spoof positioning, run a red team: have someone attempt a location relay or a device swap on a controlled load and record whether the system flags it, and measure position error at the ninety fifth percentile in metres so you know what normal looks like before you trust an anomaly. For driver identity verification, measure the ninety fifth percentile time to complete a check, because a check that takes four minutes at the gate is a different operational animal from one that takes forty seconds, and measure whether the check actually catches a substituted driver in your own test.

For the integration, measure sync latency at the ninety fifth percentile in minutes and field completeness as a percentage: order number, carrier identity, equipment, driver, pickup window. A score computed on incomplete fields is worse than no score, because it looks like a decision. And measure availability of the service itself, with a written service level, plus what happens when it is down. If identity verification becomes the only way to release a load and the service goes dark on a Friday evening, you have built a single point of failure into the gate. There must be a documented fallback and somebody accountable for invoking it.

Now the queue arithmetic on the review team, because this is the constraint that decides how far toward recall you may actually tune, and it is the one nobody models. Treat the alert stream as arrivals and your reviewers as servers. Assume a peak of twelve alerts an hour and one reviewer clearing eight an hour at a sustainable pace, with review quality degrading badly above that. Twelve over eight is one point five, so two reviewers, running at seventy five percent utilisation, which is survivable. Now assume you tune the threshold down to chase every last event and alerts rise to eighteen an hour. Two reviewers at eight an hour gives sixteen, which is below arrival rate, and a queue with arrivals above capacity does not stabilise, it grows until the shift ends and then it grows into the next shift. The lesson is not that recall is bad. It is that recall is bounded by your staffing, so budget reviewers before you tune.

Master data is the other quiet dependency, and it sits underneath every rate this system reports. If your carrier records contain duplicate entities under slightly different names, outdated authority numbers, or several entries for what is in practice one operator, then the identity check is being compared against a corrupted reference set and your interception metrics are measuring the wrong population. Clean it before go live: deduplicate carriers, standardise the identifier you match on, and record how many records you merged, because that count is a leading indicator of how much of your early alert volume is noise rather than signal.

The randomised comparison is the part that makes this defensible, and it is easy to run if you plan it. After shadow mode, enable automated holds on half your capacity and leave the other half on your existing process, randomising by lane or by carrier pool rather than by individual load, so that one shipment is never split across two treatments. Eight weeks, then swap. The metrics you compare are confirmed fraud events per thousand loads and dollars of loss per thousand loads, not alerts generated. If you make alert count a key performance indicator, the team will lower the threshold until the queue is full, and you will have bought activity rather than protection.

Watch the contract terms that sit behind the technology, because a hold is a commercial act against a carrier who may be entirely legitimate. What does your carrier agreement say about detention, about refusal at the gate, about who bears the cost when a compliant driver is held on a false positive? A wrongful hold on a good carrier costs you the relationship, and small carriers talk to each other. Budget for a dispute process, set a maximum hold time in writing, and track wrongful holds per thousand holds as a metric with its own threshold, because it is the cost you will actually be asked to justify.

Data and compliance questions belong in the same review. Driver identity data is personal information, positioning data is a movement record, and both have retention and access rules that vary by jurisdiction and by who is in the cab. Establish who owns the data, how long it is kept, who can query it, whether it is used to train anybody's model, and what happens to it if you terminate. Then ask the question people forget: if a claim is litigated in eighteen months, can you still produce the record in a form a counterparty will accept? A retention policy that answers no turns an investment in detection into an evidentiary dead end.

There is a cheaper baseline, and you should build it before you evaluate anything commercial, because it becomes the control arm and it costs almost nothing. Most of the signal in this category is rule shaped and already sitting in your own system: carrier authority age, address and contact details that match known intermediary patterns, email domain inconsistent with the company name, the same equipment appearing in two places the same day, a pickup window changed more than once, a rate accepted unusually fast on a high value lane. Run those rules against your twelve month ledger and see what they catch. If your own rules catch a decent share, the question becomes what the incremental detection is worth.

Segmentation is the alternative that most often beats a blanket deployment, and it follows directly from the arithmetic. Because loss scales with load value and fraud concentrates where sourcing is loosest, put the strongest controls where the exposure is: dual factor verification and a hard hold on the top value decile, on lanes with thin carrier supply, and on spot quotes from carrier pools you have not used before. Leave the low value, known carrier, contracted lanes on the light process. This is the same lesson as any queue: you do not give every item the same service level, you give the expensive ones the scrutiny.

Here is the calendar. By the end of September, finish the twelve month fraud ledger with base rate, dollars per event and the stage at which each event surfaced. By the end of October, complete four to six weeks of shadow mode with precision and recall measured on your own book and a blind test against your blinded ledger. By mid December, start the randomised comparison, eight weeks with holds enabled on half of capacity, then swap. By the end of February, decide: if confirmed fraud interception is below thirty percent of the ledger events, or precision sits below eight percent, or coverage falls below ninety percent of loads tendered, do not renew, and say why in writing.

One last thing about that three hundred billion and the fifty seven percent. Both are industry level figures, and neither tells you your own rate. The fifty seven percent is a year on year change against an undisclosed base, so a fifty seven percent rise on a small number is still a small number, and a fifty seven percent rise on a large number is a crisis; you cannot tell which from the announcement. Use them to justify attention, not to justify a budget. Quantify first, then optimise. If your book says sixteen percent detection pays for the tool, buy it and hold the vendor to that number on your data. If your book says it does not, the most valuable thing you did this quarter was the ledger.

↑ Back to the key points

— By Ravi Chandran