Collapse a coordinated return fraud ring without a policy change
Closing a $1M return fraud scheme required a four-step process, a technical partner, and one 15-minute fix.
It’s the same people all day, every day.
That’s what an investigative systems expert says about a coordinated group that had cracked a gap in a major multi-brand apparel retailer’s returns infrastructure.
But recognition and prevention are two different things. The store associates knew the group on sight. They couldn’t do anything about it.
- Person 1 buys a high-dollar item — a leather jacket at $600 — and immediately presents the physical receipt for a return.
- Simultaneously, Person 2 walks into a second location with the stolen item and the e-receipt from the purchase. They do the return at the exact same time.
A 15-minute lag between when a transaction hit the register and when it appeared in the returns management database is what allowed this to happen. The second store saw a valid e-receipt while the POS didn’t flag the item had already been returned with that receipt physically. So the return was processed.
Over several years, the scheme cost the retailer more than $1M. $350K in one year alone.
One investigative systems expert stopped the group in their tracks, but it wasn’t through a policy change. They routed the fraud method to the technical team that owned the database, then asked that team to close the gap and get the fix approved despite the difficulty of technical escalations.
This kind of ask only works if the case is presented with all the relevant data.
Key Takeaways:
- Coordinated return fraud persists when the team that can see the problem doesn’t own the system where the fix lives.
- Dollar attribution tied to a specific systems gap is what converts an AP complaint into a technical team priority.
- A database fix stops a fraud method everywhere, simultaneously — something policy enforcement can’t do.
- The same window exploited by one group is almost certainly active at a smaller scale across other markets.
When the lock looks engaged but isn’t
Most coordinated return fraud and abuse doesn’t require specialized equipment. It just needs a door with a broken latch — one that looks like it closes properly under normal use, but gives way the moment someone pushes at exactly the right spot.
The returns management database lag was exactly that. The returns system appeared to be working because it was processing transactions and updating the database. But there was a 15-minute window between a transaction completing and the data becoming visible to the authorization system.
All the fraudsters had to do to push the door open was walk into the second store with the stolen item.
Policy changes aren’t effective at beating this kind of fraud. A blanket restriction on e-receipts would have penalized legitimate customers to address a method that only certain groups knew to exploit. A systemic fix creates zero friction to anyone except the people trying to abuse it.
What prevented the scheme was replacing the latch — a single targeted change that stopped the fraudsters in their tracks. No matter how hard they pushed, the door wouldn’t budge.
The 2026 Total Retail Loss Benchmark Report underscores why this matters at scale: BORIS returns — bought online, returned in-store — now account for 29% of all returns, representing $208B. Each channel operates with different detection capabilities. A customer flagged online can return the same item in-store without a warning. The e-receipt scheme exploited exactly that cross-channel gap. Closing the lag patches the latch for every location.
Four steps from field observation to database fix
Most AP escalations to technical teams fail before they start. The request is too broad, the dollar figure is missing, or it lands with a team that doesn’t own the relevant system. The process below is how this expert’s team moved from the first pattern flag to watching the fraud group walk away for good.
1. Establish the validity of the pattern and precisely document the method
A technical team won’t reprioritize database work for a vague fraud trend.
That’s why the investigators didn’t just flag “high shrink” and escalate. They mapped the full method: which stores were being hit, what items were involved, the time between purchase and return, and who the repeat offenders were.
Then they documented it for the technical team like this:
Person A buys Item X at Store 1, gets the physical receipt, returns it immediately; Person B enters Store 2 with the stolen Item X and the e-receipt within 15 minutes; the system processes the return because the first return hasn’t populated in the returns database yet.
Being able to reconstruct the scenario with this much specificity gave the technical team something concrete to solve.
2. Quantify the loss in dollars and attribute it to a specific systems gap
Without a well-documented fraud method, $350K in annual losses would have been a shrink number — and shrink numbers alone don’t move technical teams.
The investigative team framed the problem deliberately: this is what we’re dealing with. They presented the cost as a direct function of the 15-minute lag rather than as a store performance issue. Which made the Product Management team’s involvement feel necessary, not optional. They weren’t being asked to help manage a vague fraud problem. This was a systems gap with an attributable dollar cost.
3. Identify the correct technical partner and make a specific request
Instead of sending a general request to PDM, the team turned to the POS team — the group that owned the returns management database — with one concrete ask: close the lag between transaction completion and data visibility in the authorization system.
“We presented this challenge to our PDM team: we’ve got a 15-minute delay in returns hitting our returns management database,” the expert explains.
The request worked because the expert understood both sides: the fraud method precisely enough to document it, and the systems architecture precisely enough to name the fix. Specificity is what separated this from every AP request that sits in a queue — the request was clear and so was the magnitude of the problem it was addressing.
To get the entire picture and system to work together, both the PDM and POS teams were needed to understand the issue, own the data, and take action on the request.
4. Fix the latch, make sure it holds
When the fix went live, the group tried the scheme again. It failed.
“It was so gratifying seeing them try to do their little scheme,” the expert says. “That one transaction made them go away. We’ve not seen them since.”
Because the fix was in the database rather than in policy or associate behavior, the return couldn’t be processed at any location across the company’s brands. The expert notes the pattern was “probably happening in much smaller ways across the country” — meaning the fix had protection value well beyond the group that triggered it.
Replacing a broken latch doesn’t just stop the one person who found it.
One change, zero policy updates, no legitimate customers punished
The fraud group that hit this retailer for $350K in a single year wasn’t particularly sophisticated. They didn’t really need to be. They found an unlocked door and walked through it because no one with the authority to fix the mechanism knew to look there.
The infuriating part was that the evidence was visible. The associates recognized the offenders and the pattern was documented in the data. What was missing was ownership: someone who understood the fraud method precisely enough to describe it and understood the systems architecture well enough to know which team could fix it.
Most broken latches in retail returns infrastructure don’t get found this way. They get addressed through policy — broader restrictions, tighter windows, more friction at the register — changes that inconvenience legitimate customers without touching the underlying gap.
Instead, this team made a database change that stopped a multi-year, multi-location fraud scheme without hurting a single legitimate customer. All because they understood exactly what they were being asked to fix and why.
That’s how you keep the bad guys out.
Frequently asked questions
How do I know when a fraud or abuse pattern warrants escalating to a technical team versus addressing through policy?
Escalate when the method exploits a gap in data infrastructure rather than associate behavior. If the scheme would work regardless of which associate processes the return or how well the policy is communicated, the fix isn’t human — it’s in the system. The clearest signal: store staff can identify the offenders but have no mechanism to stop the transaction. That gap between recognition and prevention is a database problem.
Policy changes also create collateral damage that database fixes don’t. A fix that blocks concurrent returns on the same item within a defined window leaves normal customer behavior untouched. A policy change can also invite human driven exceptions that may unintentionally create friction as well, especially when applied inconsistently – which may be inevitable along the way.
Our technical team fields requests from multiple departments. How do we get prioritized?
Dollar attribution is the most direct path. “We’ve identified a fraud method costing $350K annually that traces to a 15-minute database lag” lands differently than “we’re seeing high returns at certain locations.” The first is a scoped business problem with a named system. The second is a report.
The other factor is the relationship before the request. Teams with cross-functional credibility built in ordinary workflows get responses. AP teams that only contact the POS group during crises wait in the same queue as everyone else.
What if we can’t quantify the dollar impact precisely?
Approximate attribution is still attribution — as long as it’s tied to the specific gap, not left as a general shrink trend. “We estimate this group has cost us between $200K and $400K over three years based on transaction frequency and item value” is more actionable than “shrink is up 14% at these locations.” The first gives the technical team a reason to act. The second makes it an AP performance conversation.
Document what you know with precision: the stores affected, the items, the timing relationship between purchase and return. Let the dollar range reflect that documented scope.
How does a database fix hold up if the fraud group changes their approach?
The fix addressed the method, not the group. A database change is harder to adapt to than a policy change — the group can’t adjust behavior to avoid it without knowing the exact parameter that changed and finding a different gap in the authorization logic.
The more important question is what happens after: monitor return patterns where the group was most active, watch for similar methods across other brands or markets, and treat the fix as a proof of concept for how AP surfaces and routes these problems — not as a permanent seal. Fraud groups that lose one entry point often test for adjacent ones. The goal is a repeatable process for finding and closing gaps, not a one-time fix.
