Freight fraud and AI carrier vetting: what your onboarding records reveal

What does AI carrier vetting actually check?#

AI carrier vetting checks whether the carrier asking for a load is who it claims to be, and whether anything in its profile has changed in a way that signals double brokering, identity theft or payment fraud. It compares many signals at once instead of relying on a single authority lookup.

Typical signals include operating authority status and how recently it was granted or reinstated, whether the insurance certificate matches the filing on record, whether the email domain and phone number match the carrier's historical contacts, equipment and lane claims that fit its history, and recent changes to the remit-to account. Fraud usually appears as a mismatch between two of these, not as a single red flag.

Rules catch the obvious cases. Models are being built to catch the subtle ones, such as a real carrier's identity used from a new email address, which is why the record of how your team reviewed borderline cases matters.

The vetting record checklist#

A complete vetting record shows what was checked, what was found, who decided and what happened afterward. Compare your onboarding platform, TMS carrier profiles and compliance inbox against the records in the table.

The order of events matters as much as the records. A remit-to change shortly after a first load, requested from a new email domain, reads very differently from the same change after years of clean service. Keep timestamps on every row so the sequence can be rebuilt.

Why outcomes make vetting records worth keeping#

Outcomes turn a vetting record from a checklist into a lesson. A flag that led to rejection, a flag that was overridden and ended in a clean delivery, and an approval that later proved fraudulent each teach a model something different.

Many brokerages keep the approval and lose the rest. The rejection reason sits in someone's inbox, the override is never explained, and the double-brokering discovery months later is recorded only in a claims file with no link back to the onboarding decision. Linking those moments by carrier and load is the most useful cleanup step a compliance team can take.

False positives deserve particular care. Legitimate small carriers are often flagged because they are new, changed dispatch services or switched factoring companies. A record of how your team cleared them helps a model avoid blocking good capacity.

What must stay private#

Vetting records contain bank details, tax identifiers and accusations, so parts of the file stay private even when the decision history is shared. The items in the list below are usually excluded outright.

For what remains, the common approach is to replace carrier identities with consistent tokens, keep the sequence of signals and decisions, and lag the history so it does not reveal how current controls work. A decision rule that works for most compliance teams: if a field would help someone impersonate a carrier or get past today's checks, it stays out.

• 1Bank account and remit-to details, including factoring company assignments.
• 2Tax identification numbers and signatures from W-9 forms and carrier agreements.
• 3Personal phone numbers, driver license images and owner-operator home addresses.
• 4Internal blocklists that name carriers as fraudulent, since an unproven allegation about a named business carries legal risk.
• 5Files shared with insurers or law enforcement during a theft or fraud investigation.
• 6Current detection rules and thresholds, which would help a bad actor if they leaked.

Your decisions versus vendor and public data#

Your own review notes and decisions are usually the part of a vetting history you control, while vendor scores and public data come with conditions. Separate the sources before using or licensing onboarding records.

Public data deserves a note of its own. Authority and insurance status change over time, so a lookup run today does not show what your team saw on the day it approved a carrier. Store each snapshot with its date, or the record cannot explain the decision.

Illustrative: a 3PL rebuilds its vetting log after a payment diversion#

Illustrative: Lakeshore Logistics Group, a fictional asset-light 3PL, onboards carriers through a third-party onboarding platform and keeps carrier profiles in its TMS. A carrier's remit-to account is changed after an email that appears to come from the carrier's dispatcher, and a payment goes to the wrong account.

The review finds that accounts payable approved the change with no link to the carrier profile and no callback to the number on file. Lakeshore now logs every contact and bank change on the carrier profile with the verification method and approver, and it backfills earlier changes from AP and email records where it can.

When the COO later reviews which records could inform outside AI work, the team separates its own decisions and load outcomes from the platform's scores, which stay out of scope under the vendor terms. Bank details and the investigation file are excluded entirely.

How SourceX approaches vetting histories#

SourceX treats carrier vetting history as a sensitive record family that moves through every stage of the SourceX five-step transaction, from Supply and Rights through Preparation and Approval to Delivery. Nothing is shared in the first assessment; the fit check asks only which systems hold onboarding records and how decisions are logged.

In the Rights step, vendor terms and carrier agreements decide what is in scope. The SourceX Evidence Packet then records which sources were included, how carrier identities were tokenized and that your company approved the release.