SwipeIt was a consulting project I worked on. It's a card recommendation app. It looks at the cards you have and tells you which one to use for a given purchase to get the most cashback or points.
To do that well, three things had to work together.
Real-time transaction processing to see what you'd just bought or were about to buy. A search engine over a rewards catalog to work out which of your cards paid the best rate for that merchant or category. Geofence-based location awareness so it could prompt you before you walked into a store rather than after you'd already tapped the wrong card.
Each piece sat behind its own microservice. That matters for the security story too. The service that talked to Plaid never needed to know your GPS coordinates. The geofence service never needed to see a transaction.
What makes an app like this a different security and privacy problem is that it needs two of the most sensitive categories of personal data at the same time. It needs to know your financial accounts. It needs to know where you physically are, in real time.
Either one alone is sensitive. Both together is a different risk profile. The combination is more revealing than the sum of its parts.
A bank statement alone tells you what someone bought. A location log alone tells you where someone goes. The two joined together tell you which store someone walked into and which card they reached for. That's a level of behavioral detail neither input gives you by itself.
Not Storing Bank Credentials in the First Place
The financial side ran through Plaid rather than anything built in-house to talk to banks directly. That decision matters more than it might sound. It's worth being specific about why.
Before aggregators like Plaid were standard, a lot of personal finance apps worked by screen scraping. The app stored a user's actual online banking username and password. It logged into the bank's website programmatically on the user's behalf. It parsed the resulting HTML for balances and transactions.
That meant every app in that category was, functionally, a second copy of your bank password sitting on someone else's servers. If that app got breached, an attacker didn't get a token. They got a working bank login.
Plaid replaces that entire model. A user authenticates through Plaid's own hosted flow, Plaid Link. It talks to the bank directly using the bank's own supported login method rather than scraping it.
What the app receives back afterward is an access token. It's tied to a specific "item" and scoped to specific data products. It is not the underlying credential. For a rewards app that only needs to see transactions, the integration only has to request the transactions product. It doesn't need account and routing numbers, or full identity data.
That keeps the token's blast radius limited to exactly what the feature needs even if it were somehow compromised.
That has a concrete security consequence. The app itself never touches, sees, or stores a user's actual bank login. A compromised or leaked token can be revoked at the Plaid or bank level without the user changing their real bank password.
A breach of SwipeIt's own systems wouldn't hand an attacker working bank credentials. Those credentials were never in SwipeIt's systems to begin with.
It also simplifies the compliance picture. An app that never touches raw account credentials or full card numbers has a meaningfully smaller PCI and data-handling scope than one that does. There's simply less regulated data sitting in its own database to protect, audit, or explain in a breach disclosure.
Location Data Is Functionally Necessary and Still Sensitive
Geofencing is what makes the product actually work. You can't tell someone which card to use "here" if the app doesn't know where "here" is.
But location data is also one of the more sensitive things a phone produces. A history of someone's location is close to a log of where they live, work, and shop. That's a different kind of sensitive than a single transaction record.
It's also the kind of data that's genuinely hard to anonymize after the fact. A handful of frequent locations is often enough to re-identify a specific person.
There's a real architectural choice buried in "how do we do geofencing." A system can stream a user's continuous location to a server and evaluate geofences there. Or it can push the geofence boundaries to the device and let the device decide locally when it has entered or left one.
In the second approach, the device only notifies the backend when a relevant boundary crossing happens. Raw, continuous location never needs to leave the device. Only the narrower event of "user entered geofence X."
That's a meaningfully different privacy posture than a system that logs a location trail so it can be queried against geofences later.
I want to be precise about what I'm claiming here. The exact retention and storage decisions on this project were the client's to make. I won't speak for implementation details I didn't personally own or can't verify from memory years later.
What I can say honestly is the design principle that should drive that decision either way. Needing real-time location to power a feature in the moment isn't the same as needing a long-term location history. Treating those as interchangeable is how a product ends up holding far more sensitive data than the feature actually requires.
Why This Matters Beyond the User
It's easy to frame data minimization purely as a user-protection story. It's also a practical engineering decision for whoever runs the system.
Data you never collect is data you never have to secure. Never have to include in an access review. Never have to worry about a departing employee having queried. Never have to explain in an incident report if something goes wrong elsewhere.
Every field a service stores is a small ongoing liability, not a one-time decision. That cost compounds quietly for as long as the data sits there.
Choosing Plaid over building bank credential storage was one version of this move. Choosing device-side geofence evaluation over server-side location logging was another. Both trade a bit of engineering convenience today for a permanently smaller pile of sensitive data to be responsible for later.
The General Lesson
When a product's core value proposition genuinely requires two sensitive categories of personal data at once, the more useful security question isn't "how do we protect everything we store." It's "how do we avoid storing more than the feature actually needs in the first place."
Using Plaid instead of building bank credential storage is exactly that kind of decision. It removes an entire category of risk rather than defending it more carefully.
The same discipline applies to location data: using it in the moment for the feature it powers, rather than accumulating it as a side effect. That's the harder version of the same idea, and it's the one worth applying by default any time a product touches data this sensitive.
The question worth asking at design time, before a single line of storage code gets written: does this feature need the data, or does it only need the answer the data would give us right now? Those are two very different things to build for.