Detecting Fake Courier NDR Attempts: How to Identify Doorstep Delivery Fraud

A Non-Delivery Report is a courier's assertion that a delivery was attempted and failed. For most sellers it is also the only record that the attempt happened at all. That asymmetry — the party whose performance is being measured is the sole author of the evidence — is what makes this leak durable. You are not auditing a delivery. You are auditing a claim about a delivery.

The common reasons logged are "customer not available", "address incomplete", "customer refused" and "customer asked to reschedule". Most are genuine. Some are not, and the two are indistinguishable from the status code alone.

Why False NDRs Happen

It is worth being precise about the mechanism, because the wrong mental model produces the wrong audit. This is rarely individual dishonesty. It is an incentive structure:

• Delivery staff are typically measured on shipments closed per day, not delivered per day. An NDR closes a shipment.
• COD orders take longer — cash handling, change, buyer hesitation at the door. Under a daily quota, low-value COD is the rational thing to defer.
• A deferred shipment must be dispositioned before the hub shuts. "Customer not available" is the lowest-friction disposition available.
• Nobody downstream verifies it, because the seller usually has no independent signal to verify it against.

The practical consequence: false NDRs cluster at the end of shift, on COD, in high-density pincodes, and they rise sharply when the network is at capacity. Those clusters are what you audit for — not individual dishonesty, which you cannot prove and should not allege.

The Four Detection Signals

None of these proves a false attempt on its own. Together they separate a queue worth escalating from ordinary delivery failure.

1. Dwell time between scans

A genuine attempt takes time: travel to the address, locate the unit, wait, call. When "Out for Delivery" and "Delivery Failed" are scanned within a few minutes of each other, the physical attempt could not have occurred as described. This is the single strongest signal because it relies only on the courier's own timestamps — data you already have and they cannot dispute.

2. Absence of telephony

Most courier contracts require a call before marking a customer unavailable. If your courier exposes call logs or IVR records via API, a failure marked "customer not available" with no call attempt is a direct contract breach, not an inference. Where call data is not exposed, the buyer's own report substitutes — which is why the confirmation message in the next section matters.

3. Geofence mismatch

If the scan carries GPS coordinates, compare them against the destination pincode centroid. A failure scanned several kilometres from the delivery address did not happen at the door. Treat this as corroborating rather than primary evidence: coordinates are often coarse, sometimes hub-stamped rather than door-stamped, and a mismatch alone is not conclusive.

4. Concentration by agent, hub and pincode

Individual NDRs tell you very little. Rates tell you a great deal. Compute the NDR rate per delivery agent, per hub and per pincode cluster, then look for outliers against the peer distribution rather than against an absolute threshold. An agent at three times the rate of every peer working the same pincodes is the finding — and it is a finding about a pattern, which is what a courier escalation can actually act on.

How Kepler Encodes These Signals

For reference, the fake-ndr-guard engine expresses the signals above as four distinct exceptions, which is useful if you are building the same checks yourself:

• NDR_FRAUDULENT_GPS_GEO_MISMATCH_CRITICAL — the failure scan carries GPS coordinates more than 1.5 km from the customer address.
• NDR_FAKE_IVR_SUB_SECOND_CALL_ATTEMPT_HIGH — a call was logged, but with a duration too short to have been a real attempt to reach anyone.
• NDR_BATCH_TIMESTAMP_SPOOFING_CRITICAL — a group of failures sharing implausibly identical timestamps, which is the signature of a batch disposition rather than individual attempts.
• NDR_MISSING_OTP_CONFIRMATION_ATTEMPT_WARNING — a failure logged with no OTP confirmation attempt recorded at all.

Note the severity split: GPS mismatch and batch spoofing are critical because they are hard to explain innocently, while a missing OTP attempt is only a warning — it is frequently a data-capture gap rather than evidence of anything.

A Worked Example

The freight figure is the easy one to compute and the less important one. A unit in RTO transit for 8–12 days is a unit unavailable for sale, and during a demand peak that opportunity cost usually exceeds the freight several times over.

Building the Audit From Your Own Export

You do not need a courier integration to start. A standard shipment export is enough if it carries these columns:

1. AWB / tracking number — the join key for everything else.
2. Scan history with timestamps — at minimum "out for delivery" and the failure scan. Without timestamps, signal 1 is unavailable and the audit loses most of its power.
3. NDR reason code — normalised, because couriers use different vocabularies for the same disposition.
4. Delivery agent or hub identifier — required for signal 4. Many exports omit it; ask for it explicitly, as it is usually available on request.
5. Destination pincode and, where present, scan coordinates.
6. Payment mode — COD versus prepaid, since the pattern differs sharply between them.

Compute a rolling baseline over at least 60 days before you start flagging. Without a baseline you cannot distinguish a genuine surge from a seasonal norm, and you will escalate noise to your courier — which is the fastest way to have your future escalations ignored.

What To Do With a Flagged NDR

Speed is the whole game here, because the economics change the moment the shipment enters the return leg.

1. Confirm with the buyer immediately, on the first NDR rather than the second. A short message asking whether anyone attempted delivery, sent within minutes, produces a timestamped buyer statement while the memory is fresh. This is your independent record — the thing you did not previously have.
2. Escalate the AWB while it is still at the delivery hub. A reattempt requested before the return leg begins is usually free; after it begins, the RTO charge is generally not reversible.
3. Escalate patterns, not incidents. A single disputed AWB gets a form reply. A list of 40 AWBs sharing one hub, with dwell times under four minutes and buyer statements attached, gets a conversation about the hub.
4. Record the outcome against the flag. Over a few weeks this tells you your own precision rate, which is what stops the audit from drifting into crying wolf.

The Limits Worth Stating

This audit establishes that a delivery attempt is inconsistent with the courier's own record. It does not establish intent, and you should not frame escalations as accusations of fraud against named individuals — it is both unprovable from this data and counterproductive with the partner whose cooperation you need. The defensible claim is narrower and stronger: these attempts do not match the timestamps, here is the buyer's account, please reattempt and review the hub.

Related Guides

• Courier SLA Breach & Late Delivery Guide: How to Claim 100% Freight Refunds on Delayed Shipments
• Configuring Shiprocket Multi-Courier Routing & Shipping Rate Rules: Operator Tutorial
• How to Audit Courier Weight Discrepancies: A Step-by-Step Practical Guide