Fraud Prevention for Mobile Apps — Inside the App: Product Management Case Study
Executive Summary/TL;DR
Employing various methods of doing urgent and strategic fraud prevention, we secured two different apps from different potential exploitations, ranging from payment-related fraud to fake user engagement and crediting.
Introduction
Disclaimer: For the sake of confidentiality and anonymity, all details contained in this case study (especially PII such as names, addresses etc.) are fictitious and don’t contain any details about the respective client. If you’d like to learn more, reach out to me directly.
In this case, I’ll delve into a fraud risk assessment I did for two mobile apps — one that included a payment feature, and one involving a user credit-/ point-based system.
The intention was to uncover possible vulnerabilities and attack vectors relating to fraud, in an effort to patch them before they’d be exploited.
Problem Statement
Initial Assessment
A client had an existing & published app, as well as another app that wasn’t launched yet.
For the existing app, there had been unusual activity detected, so there was an immediate need to investigate.
This ongoing incident prompted the client to take a closer look at another app that was still in development and make sure to uncover and use all possible potential to pre-empt fraudulent use before launch.
War Room Prioritization: Critical Issues First
I first made sure that this ongoing incident was properly mitigated — unless an organization’s security posture is very strong, such exploits may require temporarily disabling services or taking them offline, resulting in limited business operations and according loss of revenue. I set up an urgent ‘war room’ communication with leadership to facilitate fast and coordinated decision making.
In this case, we unfortunately had to temporarily compromise the user experience by disabling adding payment methods in the app until we would be able to ship a fix in about 2 days.
While this wasn’t an easy or fun decision to make, we weighed the pros and cons of it, and it was clear that intermittently not being able to add payment methods would be outweighed by an exploitable (and already exploited) vulnerability.
Product Forensics
When the immediate dust settled, I had to make sure that we’d be able to ship the necessary hotfix shortly, as well as prepare for a proper fix in due time, by better understanding the problem.
In hectic, critical situations, it often is hard to get a clear picture of a situation beyond what’s absolutely urgent and imminent — to this point, we didn’t have a full picture of the problem at hand.
First, we went back to the abnormal activity that had been detected:
- The payment gateway had noted an unusually high amount of queries for credit card digits that weren’t processed further.
- These all came from a handful of new accounts which also were filled with fraudulent-looking data.
Upon further research, we understood that the intention behind this behavior must have been related to the practice of card testing:
- fraud actors often buy stolen credit card data in bulk,
- but as their vendors are usually not able to ‘guarantee exploitability’ of each of these data sets,
- and banks often already block credit cards after 1–2 fraudulent-seeming activities,
- fraud actors need to go through the list and check which one of those credit card numbers are still active (and which ones are already blocked).
To do these tests, they need access to a payment gateway, API or service. These are usually banks, fintech companies or companies using any type of payment infrastructure — which obviously have a diametrical interest, i.e. protecting payment data from fraud and exploitation.
Accordingly, fraudsters:
- try to find services that lack sophisticated prevention features such as data enrichment (e.g. matching the credit card holder’s name with the number before doing anything else), PCI-DSS compliance, or device fingerprint analysis,
- until these service notice, fix their vulnerabilities and harden their systems,
- and then move to the next vulnerable service they can find.
From Tactical to Strategic
After establishing a firm grip on the existing app’s issue, I took a look at the to-be-released app next:
This app didn’t have an immediate payment-related component, so there was no need to audit it in that regard.
However, the app was built on having users engage, and in turn generate an in-app ‘currency’ (i.e. collecting points) that they could later convert into rewards. It was obvious that if we didn’t audit the entire user journeys and interactions, the app might be susceptible to point generation and redemption fraud.
Upon conducting a first investigation, I uncovered the following possible vulnerabilities:
- There was no volume/frequency cap on point accrual (i.e. if users would be able to maximize collecting points at a rate beyond the client’s intent, excessive reward emission could follow).
- No GPS-related data was used to detect possible fraudulent behavior.
- User profiles were not being verified before reward withdrawal.
Fortunately, the core engine of the app was robustly built and didn’t allow for fraudulent exposure — e.g. it wasn’t possible to submit doctored raw data as the entire processing happened within a proprietary and customized model and API.
Solution
Stopping Card Testing
As a first measure to bring the ability to add payment methods back, we devised a total of 3 updates:
- Requiring more data for a basic KYC check for the actual card holder (or at the very least, someone who has all that information) — for this, we basically had to make more existing fields mandatory to fill out.
- Next, and this was crucial: change the error message to “Fill out all fields” (for trying only a credit card number) and generic “Card cannot be used with this account, please contact support” for data mismatch or high risk score.
- Backward compatibility: Make sure that all of these changes can be applied to previous data (block incomplete payment methods) and versions (ask users to update app to add new payment methods).
Fraud-Proofing the Credit-/Point-Based App User Experience
Next, based on the uncovered vulnerabilities, we planned on implementing the following updates before launch:
- Daily Accrual Cap: To curb the possibility of fraudsters trying to exploit any possible way of accruing an excessive amount of points, the easiest way to guarantee that was to put a per-user limit on how many points could be collected per day. This had two further benefits: it would also prevent skewed user data volumes (i.e. too high percentages of data only being generated by a small amount of users), and establish a possible premise for upselling to a subscription (e.g. “Collect more points per day with Premium”) in the future — other well-known apps such as Sweatcoin are doing something like that.
- GPS Pattern Analysis: Especially financial services-related products use the “Somewhere You Are” authentication factor as a way to detect fraud — you might even have first-hand experience with that yourself if you ever had your your bank inform you about blocking your credit card because it has been charged in a far-away country, while you’ve been using it at home (and the only way it could’ve been you would’ve been if you’d teleported yourself). Based on the app’s (confidential) usage patterns, location would be a factor — and we’d invalidate point accrual tied to suspicious activity, based on GPS continuity.
- Initial & Periodic Verification: Before any user would be able to withdraw from their account (by way of redeeming a reward), we’d trigger a review process in which a user would be checked by a customer service agent before being greenlighted to redeem. We identified the risk of this process scaling poorly, and upon again weighing our options, made an informed decision to proceed with it while already considering possible upgrades to aid scalability in the near future.
Results
First of all, we were not only able to entirely thwart further attempts to conduct card testing, but also didn’t notice any negative impact on overall usage.
This was especially good because the initial apprehension had been the usual ‘simple vs. secure dichotomy’, i.e. the easier you make it for users to engage with your product, the more vulnerable you make it to threats, and vice versa — the more secure you make your product, the harder you make it to use.
Our hypothesis had been that the UX obstacle created would not have a considerable effect on usage and performance (if any), and luckily, we were proven right.
As for the app with points-based usage, we were able to launch it without any major issues regarding improper or fraudulent use. We did encounter some issues outside of the app — but that’s a different case study:
Conclusion
The main conclusions we drew here were:
- Do the math on Simple vs. Secure! Product managers often try to reduce or remove friction to sign up and engage users, and in itself, that’s completely fair. However, regarding possible security vulnerabilities and opening the product, the organization and even its customers up to fraud, you’d rather try to come up with as-good-as-possible estimates for ‘benefit of removing friction’ (e.g. revenue or usage uptick) versus ‘cost of potential exploitation’ (e.g. downtime, destruction of property, damage to reputation) and making an informed decision over just following the “mantra of reducing friction”.
- To stop fraudsters, you need to think like a fraudster. Fraud prevention starts with thinking like a criminal, not like a detective — this is something that experts in the space, from fraud, governance, risk and compliance specialists to penetration testers and ethical hackers, are versed in. It’s worth consulting those people — especially if you’re busier with other things.
- Prioritizing security should be more popular in Product Management. I usually see security rather be treated as a footnote or afterthought by product managers, and I understand that product management requires interfacing many more factors than just security, however in Germany alone, close to €150 billion were lost to cybercrime — just in 2023 (not a typo), so I guess it’s safe to say that security might be underprioritized overall.
Thank you very much for reading!
If you’d like me to help you with a similar challenge you’re facing, I’m a Freelance Product Manager & Consultant for hire — feel free to reach out to me at hi[@]bertrandrothen.com
