Short answer: Payment apps can use on-device AI for fraud detection, customer service, and transaction categorization without expanding PCI DSS scope — as long as cardholder data never flows to an external AI processor.
Your QSA flagged your AI feature as expanding PCI DSS scope because it processes transaction data through a cloud API outside your cardholder data environment. Your next QSA review is in 90 days.
A scope expansion at QSA review is not just a compliance cost - it's a timeline problem. Adding systems to your CDE requires re-assessment of those systems, which adds 4-8 weeks to your review cycle. On-device processing keeps the AI feature outside the CDE and your QSA timeline intact.
What decisions determine whether this project ships in 6 weeks or 18 months?
Four decisions determine whether your AI feature clears QSA review in the next 90 days or triggers a scope expansion that delays your certification.
CDE scope management. PCI DSS scope extends to any system that stores, processes, or transmits cardholder data. A cloud AI API that receives transaction data - even de-identified at the application level - is in scope if it can reconstruct cardholder identity from the inputs. An on-device model that processes the same data locally, without transmitting it, stays outside the CDE boundary. The architecture document your QSA needs has to make this data flow explicit. Assertions without flow diagrams won't satisfy the review.
Tokenization before inference. Some fraud detection and spending insight tasks can be performed on tokenized transaction data without losing the predictive signal that makes the AI useful. If your specific AI task can run on tokenized data, you may not need full on-device deployment. You need a tokenization step before any API call. Your QSA needs to confirm that the tokenized data is outside PCI scope before your engineering team builds the tokenization-first architecture. Getting the QSA's opinion before building prevents a mid-sprint rework.
Model storage and update security. An on-device model is software on the user's device. PCI DSS requires that software components be protected against tampering and unauthorized modification. The model file needs to be stored in a protected location within the app sandbox, and the model update mechanism needs integrity verification - the app should reject a model update that doesn't pass a cryptographic signature check. These controls have to be built in from the start, not added as a patch before the QSA review.
Logging and audit evidence. Your QSA will ask for evidence that the on-device model doesn't exfiltrate cardholder data. The logging architecture has to produce that evidence in a format your QSA accepts: timestamped records showing that model inputs stayed on-device, that no external network calls were made during inference, and that model outputs were constrained to the app's local processing boundary. Building the logging to your QSA's standard before the review saves 3-4 weeks of remediation.
Most teams spend 4-6 months discovering these decisions by building the wrong version first. A team that has shipped this before compresses that to 1 week.
On-Device AI vs. Cloud AI: What's the Real Difference?
| Factor | On-Device AI | Cloud AI |
|---|---|---|
| Data transmission | None — data never leaves the device | All inputs sent to external server |
| Compliance | No BAA/DPA required for inference step | Requires BAA (HIPAA) or DPA (GDPR) |
| Latency | Under 100ms on Neural Engine | 300ms–2s (network + server queue) |
| Cost at scale | Fixed — one-time integration | Variable — $0.001–$0.01 per query |
| Offline capability | Full functionality, no connectivity needed | Requires active internet connection |
| Model size | 1B–7B parameters (quantized) | Unlimited (GPT-4, Claude 3, etc.) |
| Data sovereignty | Device-local, no cross-border transfer | Depends on server region and DPA chain |
The right choice depends on your compliance constraints, query volume, and task complexity. Wednesday scopes this in the first week — before any code is written.
Why is Wednesday the right team for on-device AI?
We built Off Grid because we hit every one of these problems in production. Off Grid is the fastest-growing on-device AI application in the world, with 50,000+ users running it today.
It's open source, with 1,650+ stars on GitHub and contributors from across the world. It has been cited in peer-reviewed clinical research on offline mobile edge AI.
Every decision named above - model choice, platform, server boundary, compliance posture - we have made before, at scale, for real deployments.
How long does the integration take, and what does it cost?
The engagement is four sprints. Each sprint is fixed-price. Each sprint has a named deliverable your team can put on a roadmap.
Discovery (Week 1, $5K): We resolve the four decisions - model, platform, server boundary, compliance posture. Deliverable: a 1-page architecture doc your CTO can take to the board and your Privacy Officer can take to Legal.
Integration (Weeks 2-3, $5K-$10K): We ship the on-device model into your app behind a feature flag. Deliverable: a working build your QA team can test against real workflows.
Optimization (Weeks 4-5, $5K-$10K): We hit the performance and compliance targets from the discovery doc. Deliverable: benchmarks signed off by your team.
Production hardening (Week 6, $5K): Edge cases, OS version coverage, app store and compliance review readiness. Deliverable: shippable build.
4-6 weeks total. $20K-$30K total.
Money back if we don't hit the benchmarks. We have not had to refund.
"Wednesday Solutions' team is very methodical in their approach. They have a unique style of working. They score very well in terms of the scalability, stability, and security of what they build." - Sachin Gaikwad, Founder & CEO, Buildd
Is on-device AI right for your organization?
Worth 30 minutes? We'll walk you through what your version of the four decisions looks like, what a realistic scope and timeline would be for your app, and what your compliance posture and on-device target mean in practice.
You'll leave with enough to run a planning meeting next week. No pitch deck.
If we're not the right team, we'll tell you who is.
Book a call with the Wednesday team
Frequently Asked Questions
Q: Does adding AI to a payment app expand PCI DSS scope?
Only if cardholder data — PANs, CVVs, expiry dates — are sent to a cloud AI API as part of a prompt. On-device AI processing tokenized or anonymized data locally doesn't expand the cardholder data environment.
Q: Can on-device AI models see raw card numbers under PCI DSS?
No. The standard approach passes tokenized or anonymized transaction data to the model. The model produces a fraud score, category, or recommendation — without seeing the raw PAN. Tokenization sits between cardholder data and model input.
Q: How long does PCI-safe on-device AI take?
4–6 weeks. The data flow architecture — the boundary between cardholder data and model input — is resolved in week one. The remaining sprints build, optimize, and harden.
Q: What does PCI DSS-compatible on-device AI cost?
$20K–$30K across four fixed-price sprints, money back if benchmarks aren't met.
Q: What AI use cases in payment apps can run on-device without PCI scope concerns?
Transaction categorization, spend pattern analysis, customer service routing, and notification personalization — all using anonymized or aggregated data, no cardholder data required. Fraud detection requires more care: model input must exclude raw card data.
Top comments (0)