A practitioner’s guide to designing fraud prevention that acts before the transaction settles.
Logistics fraud is quiet. It does not announce itself. While many frauds immediately reveal themselves, such as phishing emails or ATM scams, logistics fraud is part of operational noise, and thus it can even go up to millions before it is detected by a human auditor. Thus, it requires proactive fraud prevention, which cannot rely on manual processes to evaluate huge volumes of incoming data from multiple locations.
The best way to detect fraud is to have a system that is continuously evaluating risk, assigning scores to all your partners and all your transactions, and then intervening automatically before any money changes hands. We have built such a system at Libera, an AI-powered supply chain platform that we at ElasticRun have developed over the last decade. The system has been designed as a layer beneath your various supply chain operations, from procurement, workforce management and transportation and helps prevent various kinds of logistics fraud in real time.
Nowhere is this more visible than inside a freight transportation management system, where the same identity signal has to travel cleanly through four distinct stages of a shipment’s life: the vendor onboarding decision at procurement, the route and vehicle assignment at planning, the individual driver who actually shows up to move the freight, and the invoice that eventually gets paid against that trip. A gap at any one of those four points is enough for the rest of the system to be verifying the wrong thing.
What follows is a detailed guide to building a fraud prevention system, including the design decisions and pitfalls to avoid, and an overview of the architecture required to move from risk scoring reports to active fraud prevention.
Start with identity and make it continuous
Most organizations treat identity verification of suppliers and business partners as a one-off process for the purpose of onboarding them to do business with. As long as the required documentation has been provided to verify the identity of the supplier and their business, the issue of identity is considered to have been resolved. However, in reality, there are several reasons why this approach is grossly inadequate for the purposes of fraud prevention in supplier verification.
One may onboard a legitimate partner, but they may start committing fraud within weeks or even months. An already verified partner’s identity can be cloned or impersonated by another person or legal entity. Coordination of fraud across different entities can happen by all of them sharing the same identity attributes, such as the same bank account number, device fingerprint, or contact number.
Effective identity verification therefore has to be a continuous layer, not a checkpoint, and in a freight operation it has to run at every stage a shipment passes through, not just once at signup. This is precisely what Libera’s Identity Verification technology is built to do, and it’s worth walking through where it actually plugs into a freight TMS rather than treating it as a single standalone feature:
Where identity verification and workforce technology plug into a freight TMS
This is the part most fraud prevention architectures leave unspecified, and it is where the design either holds or fails. Below is exactly where Libera’s Identity Verification technology and Workforce Ecosystem Technology connect into the transport management system, stage by stage.
At procurement, identity verification is what makes a transporter onboarding decision trustworthy in the first place. Document validation from tax ID and banking details re-runs on a periodic basis rather than only at signup, and biometric deduplication across the full vendor population catches the duplicate and ghost-vendor registrations that a compressed onboarding process routinely misses. A bid only gets evaluated on cost and service level once the platform has confirmed the entity submitting it actually is who it claims to be and continues to be for as long as the contract runs.
At planning, that verified identity has to extend down to the individual driver and vehicle being assigned to a route, not just the transporter company holding the contract. A vendor can be entirely legitimate at the corporate level while the specific driver dispatched on a given trip is unverified, uninsured, or operating under someone else’s credentials. Planning logic that treats “the vendor is verified” as equivalent to “the driver on this trip is verified” is exactly the gap that lets impersonation and credential-sharing slip through further down the chain.
At driver onboarding specifically, in-field liveness verification closes the gap that document checks alone cannot. A driver’s registration document can be entirely genuine while the person actually operating the vehicle on a given day is not the person those documents describe, such as a credential transfer, a shared login, a stand-in driver covering an unregistered shift. Real-time facial recognition and liveness detection confirm, at every shift or transaction, that the person operating is the same person originally verified, closing the exact gap between onboarding and ongoing behaviour that most fraud in the field actually exploits.
At invoice settlement, identity verification becomes the final gate before money moves. A trip’s proof-of-delivery and the invoice generated against it are only as trustworthy as the identity of the driver who completed that delivery. If the liveness check at delivery doesn’t match the verified driver on record for that trip, the settlement shouldn’t clear automatically; rather, it should route to review, the same way a financial anomaly would, because an identity mismatch at the point of delivery is itself a fraud indicator, not a separate administrative issue.
What really matters across all four of these points is the same question, asked continuously rather than once: are they still who they claim to be, and are they behaving consistently with that identity every time a transaction actually happens?
Input Metrics: What to measure and why
Most critical to creating a fraud prevention system is the selection of appropriate metrics to capture behavioural anomalies. A sophisticated model fed with poor inputs is likely to perform worse than a simple model fed with good metrics. Working with logistics and supply chain partners, we have found that behavioural and identity signals together form the core of effective fraud prevention.
Input metrics should fall into four categories, testing respectively for identity and document fraud, behavioural and transaction fraud, network relationships between supply chain members, and financial misconduct.
Identity and document metrics test for mismatches between a supplier’s declared identity attributes and third-party validated sources, the presence of shared attributes across supposedly independent suppliers (the same tax ID, bank account, or contact number), and recently registered suppliers claiming a long trading history.
Behaviour and transaction metrics are often simple statistics about how a partner actually operates, like spikes in COD rejections on particular days of the week or procurement prices that deviate from a rolling average for that partner’s goods category.
Network and relationship metrics detect suppliers sharing bank accounts or registered addresses, device fingerprints shared between nominally independent entities, or suppliers claiming brand relationships with no verified distribution agreement behind them.
Financial metrics track credit concentration, where a supplier for whom you represent 80–90% of declared revenue is an unusual dependency worth investigating and advance payment requests that are anomalous relative to completed work.
Most input metrics are not useful in their raw form. They need to be made time-aware and hence more meaningful. For each input metric we compute the current period value and also a longer-window rolling average. We also compute the change vs. the previous period and a Z-score vs. the average of segment peers (e.g., all other partners of the same type and of similar age). Thus, a COD rejection rate that is currently high but decreasing is viewed very differently from one that is increasing.
Workforce Ecosystem Technology uses a similar discipline to score risk for every vendor and delivery associate. The score is dynamic and continually updated and based on the same behavioural and identity metrics as described above. But it is updated in real-time based on their attendance, shift adherence, and productivity on a daily basis. A score is not assigned at onboarding and then never looked at again. Because that score is computed in the same platform that does the planning and dispatching of the freight, it can act as an input to the allocation of work to partners rather than simply a report. Thus, a deteriorating score means that a partner is not eligible for as much work.
Handle class imbalance before you build any model
Most organisations rely on a standard definition of fraud for their detection systems. That is to say, they have assumed that sufficient labelled data exists for the different forms of fraud to train a supervised classification model. Yet, in the vast majority of organisations, confirmed cases of fraud will represent a tiny percentage of total partners, and many will have been flagged by an auditor with a ‘suspicion of’ rather than a proven ‘case of ‘. As such, the vast majority of cases used for training a model will in fact have been ‘assumed’ by a human. Consequently, such a model will replicate the same basic human intuitions regarding what constitutes fraud that were used for the initial labelling.
To create a robust framework for fighting supplier fraud, it is necessary to use two layers of analysis: an unsupervised anomaly detection layer, followed by a supervised re-ranking layer. For the unsupervised anomaly detection layer, it is recommended to use isolation forests, a type of unsupervised decision tree, and to train them on partner-specific datasets (i.e., for each partner, create a dataset of all of their supplier transactions). This type of analysis will reveal novel instances of supplier fraud that have not been seen before and therefore cannot be included in a labelled dataset for a supervised learning model. The supervised re-ranking layer should use heavily positive-class-weighted loss functions where confirmed labels exist and weak additional proxy signals like audit-settlement deductions, cause-based terminations, and escalation-ticket history to expand the number of positive-class instances covered by labelled data.
Track precision and recall instead of usual measures like accuracy. As an example, if you have a 2% fraud rate among your partners, a model that would flag every partner as low risk would have 98% accuracy but would prevent no fraud.
Risk tiers and the intervention layer
Risk scores in dashboards are not enough to prevent fraud. A risk score needs to be supported by an intervention layer, in which the partners are bucketed into risk tiers, based on empirically derived score boundaries. These boundaries should reflect the ranges in which the audit confirmation rates for your historical data points have clustered.
A three-tier approach can be reasonable here. Partners that have a score above 70 are considered high risk, so invoices are not paid until all required documentation is provided; payment is blocked until verified; and escalated to senior reviewers (with possible suspension of partner above 95). In the mid-risk tier (40-70), all document verification for a partner is done via additional means, and all relevant information is flagged on the operations dashboard, with the individual metric values all provided as well. In the low-risk tier (below 40), all partners are treated as normal (i.e., scores are updated for each transaction).
When a partner crosses a tier threshold, that event should be published to a message queue consumed by downstream systems from invoice approval workflows, onboarding services, operations dashboards, and payment gateways. The intervention must be automated and immediate. A risk alert that requires a human to manually locate it and decide what to do will consistently lag behind fraud that is moving in real time. This is exactly how the risk layer connects into Libera’s transportation and procurement workflows: a vendor crossing a risk threshold doesn’t just generate an alert somewhere; it can hold an invoice, flag a bid for additional review, or route to a senior approver automatically, because the risk engine and the transaction systems it protects were designed as one connected platform rather than a scoring model bolted onto operations after the fact.
It’s also really important to allow the people who are using the system to temporarily silence individual metrics for legitimate reasons with an optional reason code. Also important to set an expiry date for this to be audited. Although you don’t want to suppress the underlying score, you do want to flag the metrics up that caused the spike to have been reviewed and to be expected on the snooze. For example, a recently successful supplier will trigger a sales anomaly around their first major contract for legitimate reasons. You need to be able to snooze this for a time period for legitimate reasons.
Three things most teams get wrong
When scoring partners individually for fraud risk, large-scale organised fraud is rarely detected. Often, a single partner may have a low individual score yet be part of a large, organised fraud ring. Network analysis of shared partner attributes in a graph representation should form a core part of the risk scoring function.
Raw scores are practically useless outside of an analytical report. This is especially true when there are open alerts in the operator’s queue. Provide the underlying metrics that caused the score, indicate if the scores are going up or down, and provide the Z-scores against the rest of the segment’s scores. Without this the team will simply dismiss the alerts over time, eroding confidence in the system.
Don’t underestimate a fraudulent party’s ability to adapt. A static rules-based system can be reverse-engineered within weeks. Use dynamic behavioural indicators, rotate the metric set periodically, and avoid exposing threshold values in any dispute with a partner.
Where to start
Start by identifying the relevant input metrics. Then invest time in good feature engineering, segment definition, and data quality. Build the simplest model to score against the indicators that you have identified to correlate with confirmed loss events in your own data. Iteratively refine it to achieve better results.
Rather than trying to deploy identity verification as a standalone product, map out where identity verification is currently consumed within your freight workflow (onboard a transporter, assign a driver to a trip, verify proof of delivery, and verify payment of invoice for a completed trip). Close these four consumption points one at a time to ensure that fraud prevention is done as an operationally capable function and not as a report that is produced after a loss has occurred.
While your end goal for fraud prevention may be to implement an ‘infallible’ system to prevent all potential cases of fraudulent behaviour, the practical reality is that there are instances that will get through. What you should be striving for is to ensure that committing fraud becomes highly expensive and very quickly exposed, meaning that the legitimate party’s behaviour becomes the more rational option.
Risk prevention needs to be treated as an operational capability that is continuously maintained and fine-tuned as opposed to something that produces a report after a loss has occurred.
About the Author:
Sheetal Kumar Ajamera is Senior Principal Architect at Libera, where he leads the engineering behind the platform’s freight procurement, planning, execution, and invoicing modules. He has spent his career architecting large-scale supply chain and ERP systems, with a focus on turning fragmented logistics processes into connected, data-driven platforms. At Libera, his work centres on the AI agents that power real-time rate benchmarking, load optimisation, and billing reconciliation for shippers across India.
Connect with Sheetal on LinkedIn