Did Not Arrive (DNA) Claim

What a DNA claim really changes

A Did Not Arrive claim is not just a refund label. Its security significance comes from how the claim is evaluated, whether the merchant can bind evidence to the transaction, delivery event, and customer context, and whether the workflow can withstand pressure at scale without turning disputed orders into avoidable losses.

In practice, the claim creates a decision point between customer service, fraud review, fulfilment evidence, and payment operations. If those signals are fragmented, the organisation may treat a weak claim as credible or delay a valid one until recovery options narrow.

Evidence binding and workflow integrity

The core control problem is evidence quality, not the wording of the dispute. A strong DNA process ties order records, shipment milestones, address data, carrier status, and customer communications into a single reviewable case so that the final decision is traceable.

That is why identity assurance and access controls can matter indirectly in this workflow: staff should only see and change the evidence needed for their role, and the case record should preserve who reviewed what and when. Where case handling is inconsistent, the organisation can create its own loss path even without any external attack.

For broader control design, this is the same kind of traceability problem that underpins NIST SP 800-53 Rev 5 Security and Privacy Controls, especially access control, audit, and configuration discipline.

Operational pressure and dispute handling

DNA claims also expose process capacity. High-volume disputes can overwhelm manual review, encourage rubber-stamping, or push teams to accept incomplete evidence just to clear queues. That creates a quality problem even when the underlying shipping data is sound.

Well-run organisations therefore separate fast triage from final adjudication, so easy cases can move quickly while edge cases receive deeper scrutiny. That distinction matters because the claim is often a timing race: the longer a case stays unresolved, the more expensive it becomes to recover goods, funds, or customer trust.

Why the term matters for merchants and operations teams

DNA is a useful shorthand because it surfaces a recurring business tension: customers need a simple way to report non-receipt, while merchants need defensible proof before issuing credit or replacement. The term is therefore operational, not merely linguistic.

Merchants that treat all DNA claims as equivalent often miss the real distinctions, such as carrier scan gaps, porch theft, address mismatch, repeat claimant behaviour, or a genuine logistics failure. The best workflows classify those scenarios separately so the response matches the actual cause rather than the complaint label.

Risk and Threat Considerations

DNA claims create direct financial exposure when weak evidence, delayed reviews, or inconsistent decision rules let unsupported refunds or replacements slip through. They also create abuse opportunities when claim handling is predictable enough for serial misuse or organised friendly-fraud patterns.

Failure mechanism: The process fails when shipping proof, case notes, and review authority are not bound together tightly enough to support a consistent decision, or when operational backlog causes staff to accept incomplete evidence.

Impact: The likely outcomes are chargeback or refund loss, excess reshipment cost, customer-service overload, and reduced confidence that the claims process is fair and repeatable.

Practitioner Guidance

What to watch for: Look for claims that cluster by route, carrier, geography, or customer pattern, because those clusters often reveal whether the issue is logistics, documentation quality, or deliberate misuse. A rising share of “no proof of delivery” outcomes usually signals a workflow problem before it signals a pure fraud problem.

Practitioner takeaway: Treat DNA handling as a controlled adjudication process, not a ticket queue. The strongest programmes make evidence retrieval, review rights, and decision logging part of the claim itself.

Related resources from NHI Mgmt Group

• What do security teams get wrong about the aud claim in JWTs?
• What breaks when audit logs and SSO arrive after users have already adopted a tool?
• Who is accountable when privileged access failures affect a cyber insurance claim?
• Claim Minimisation