The Problem: 30+ Tender Types, Zero Clarity
Walk into any modern grocery store or mass-merchandise retailer and you'll see the complexity at checkout. Customers pay with credit cards, debit cards, digital wallets, gift cards, store credit, government benefit programs like WIC (Women, Infants, and Children) and SNAP/EBT, cash, checks — and frequently combine multiple methods in a single transaction.
POS systems faithfully record the total paid by each tender type, but here's the catch: they almost never tell you which item was paid for by which method. That might sound like a minor bookkeeping detail, but it creates massive downstream problems. Government benefit programs have strict eligibility rules (only specific items qualify for WIC, for example), tax calculations depend on knowing the payment source, and fraud patterns hide in the ambiguity.
Roughly 71% of retail transactions complete with a single tender — simple enough. But the remaining 29% involve multi-tender combinations with complex priority rules, eligibility constraints, and refund sequencing logic. That 29% is where things get interesting — and where most analytics pipelines break down.
The Challenge I Wanted to Solve
The core question that drove this work: how do you reconstruct item-level tender assignments when the POS system doesn't give them to you? And once you crack that, it opens up a powerful follow-up — using that granular data to detect fraud that's currently invisible in aggregated totals.
You can't detect fraud in payment data you don't understand. Solving the data disaggregation problem is the prerequisite — fraud detection is the natural next step I'm planning to build on top.
The Solution: Syntactic Data Synthesis (SDS)
The framework I developed is called Syntactic Data Synthesis. The idea is to reconstruct plausible, policy-compliant item-to-tender mappings from the basket-level totals that POS systems actually record — without needing any labeled training data.
SDS works in four phases. It starts with constraint grounding — encoding the actual business rules (WIC eligibility, tax exemption logic, SNAP item restrictions) as hard constraints. Then it builds prior probabilities from historical co-occurrence patterns: how often does baby formula get paid for with WIC vs. cash in this store's history?
The third phase is where the inference happens. I explored several approaches — Gibbs sampling for a Bayesian take, MAP optimization for speed, and a neural hybrid that uses a small neural network to approximate the posterior. Finally, post-processing ensures the outputs are policy-compliant and ready for downstream analytics.
The key result: the SDS hybrid approach achieves 0.85 accuracy with a 0.10 calibration score, approaching the performance of a fully supervised system (0.89) — but without needing any hand-labeled item-to-tender mappings. That's a big deal in retail, where getting ground-truth labels for this kind of data is expensive and often impossible.
What's Next: Building a Fraud Detection Engine on Top
With the disaggregation problem solved, the natural next step is one I'm actively planning: a production-grade fraud detection system that leverages the clean, item-level tender data SDS produces. The ambiguity in multi-tender transactions has long been a hiding spot for fraud, and now that we can see through it, there's a real opportunity to build something meaningful.
The plan is to target six distinct fraud types that plague retail: gift-card laundering, EBT/WIC benefit misuse, return-fraud tender upgrades, transaction structuring, cash-back abuse, and employee collusion. These are well-documented problems that cost large retailers tens of millions of dollars annually, yet current rule-based detection systems suffer from high false-positive rates that create unacceptable customer friction.
No single model will catch all six fraud types well. Gift-card laundering looks nothing like employee collusion. The plan is to build a hybrid ensemble that lets each model specialize while the system as a whole maintains broad coverage.
The approach I'm designing involves roughly 150 engineered features spanning transaction-level signals (how many tenders were used, what percentage was credit), customer velocity metrics (spending patterns over 1-hour, 7-day, and 30-day windows), behavioral deviation scores, time-of-day context, and graph-based dimensions that capture relationships between cards, devices, and store locations.
The detection model will be a hybrid ensemble combining XGBoost (for structured pattern recognition), Isolation Forest (for unsupervised anomaly detection), and an Autoencoder (for detecting previously-unseen fraud patterns by measuring reconstruction error). Each model would contribute a score that gets combined into a final risk assessment.
The key design constraints I'm working within are real-world retail realities: sub-5-second inference latency so it doesn't slow down checkout, a target of over 95% precision and 80% recall (because false positives erode customer trust fast), and explainable outputs using SHAP so investigators can understand why a transaction was flagged. I'll share the results once I have them — stay tuned.
A Quick Look at the SDS Results So Far
To validate the SDS framework, I ran experiments on synthetic and semi-synthetic retail datasets. A concrete example: a basket containing baby formula ($24.99) and other items totaling $32.00, paid with a mix of WIC and cash. The SDS framework correctly identified the WIC-eligible item allocation and reconstructed the full tender split.
The Bigger Picture
The retail payment landscape is only getting more complex. Digital wallets, buy-now-pay-later services, cryptocurrency, and evolving government benefit programs all add new tender types that POS systems need to handle. Every new payment method is another dimension of ambiguity for analytics teams — and another hiding spot for fraud.
What makes this project interesting to me is that it sits at the intersection of data engineering, domain knowledge, and machine learning. You can't solve it with a better model alone — you need to understand how WIC eligibility works, how LIFO refund logic operates, how tax-exempt transactions interact with multi-tender splits. The domain knowledge is the feature engineering.
There are also broader implications. The same SDS framework could apply to healthcare payment disaggregation (insurance + copay + HSA splits), or even to government voucher programs in other countries — the UK's Healthy Start scheme, for instance, faces similar item-level attribution challenges.
In retail analytics, the hardest problems aren't modeling problems — they're data problems. Getting the right representation of messy, policy-laden transaction data is 80% of the battle. Once you solve that, the ML becomes almost straightforward.