Loan and Wallet App Privacy Label Checker That Compares Claims With Real Traffic

The problem: finance apps that take more than they say

Personal loan apps spread quickly in Pakistan because they lend small amounts in minutes. Some of them became notorious for downloading the borrower's contact list and photos, then threatening to message family and employers when a payment was late. The Securities and Exchange Commission of Pakistan has repeatedly acted against illegal loan apps, and Google introduced a Pakistan personal loan app policy that allows only SECP-approved lenders on the Play Store.

Policy helps, but it relies on what apps declare. Google Play's Data Safety section is filled in by the developer. A user deciding whether to trust a wallet or loan app has no way to check the label against reality, and regulators and journalists lack evidence when they need it.

What already exists and the gap

• Google Play Data Safety labels are self-declared by developers.
• Exodus Privacy lists trackers and permissions found in Android apps by static analysis.
• Academic measurement studies compare labels with code or traffic at scale, as research rather than a maintained tool.
• SECP's list of approved lenders tells you who is licensed, not what their app does with your data.

The gap is a focused, repeatable test bench for finance apps used in Pakistan and similar markets, that produces evidence per app: "the label says no contacts are collected; here is the request at 14:02 that sent 214 contacts to this host."

Inspiration

"Unpacking Privacy Labels: A Measurement and Developer Perspective on Google's Data Safety Section" by Rishabh Khandelwal, Asmit Nayak, Paul Chung and Kassem Fawaz (USENIX Security 2024) measured the Data Safety sections of about 1.1 million apps and found internal inconsistencies, with both over- and under-reporting. This project narrows the method to one high-harm category and adds dynamic evidence from real traffic.

What you build

• Researchers and journalists get a per-app report with the declared label, the observed behaviour and the evidence behind every mismatch.
• Users see a short plain-language summary, in English and Urdu, of what an app collected in testing.
• Regulators and consumer groups get a repeatable method they can rerun on new versions.

The technically interesting part

• Seeded data you can recognise. Fill the emulator with fake contacts, messages and photos containing unique marker strings. If a marker appears in outgoing traffic, you know exactly what leaked.
• Seeing encrypted traffic. Most apps use TLS, and many pin certificates. Use mitmproxy with Frida scripts to bypass pinning in the emulator, and record which apps resist and how.
• Encoded payloads. Data may be compressed, base64 encoded or encrypted again inside the app. Hook the networking and crypto functions with Frida to catch data before it is encoded.
• Driving the app. Many apps only collect data after sign-up or during a loan application. Script these flows with fake but valid-looking details, and stop before any real loan or payment.
• Third-party SDKs. Much collection happens inside analytics, credit scoring and device fingerprinting libraries bundled into the app. Attribute each request to the app or a known SDK by host and stack trace, because the fix and the responsibility differ.
• Mapping to labels. Translate observed fields into Data Safety categories (contacts, SMS, location, device IDs) consistently, and record your mapping rules so others can check them.

How to evaluate it

• Detector accuracy: on test apps you write yourselves that leak known data, measure detection rate.
• Manual check: every reported mismatch is verified by a second team member before publication.
• Coverage: share of apps where traffic could be decrypted and the main flows reached.
• Consistency: rerun a sample of apps a week later and compare results.

Suggested plan

• Weeks 1 to 3: emulator setup, mitmproxy, Frida pinning bypass on a test app.
• Weeks 4 to 7: label and permission collector; seeded data and detectors.
• Weeks 8 to 11: scripted flows for the first ten apps; comparison logic.
• Weeks 12 to 15: the 30-app study, report pages, Urdu summaries and write-up.

Path to a product

Consumer protection groups, fintech compliance teams and app stores all need this kind of evidence. A maintained public index of finance app behaviour, or a paid pre-release privacy check for legitimate fintech companies that want to prove they are clean, are both credible directions.

Scope warning

Test only in an emulator with fake data, never with real personal details, and never take an actual loan. Get your supervisor's approval for the study, and contact app developers with findings before you publish named results. Stay with one Android version and one category of app.

Learn what you need on Sefism

• OWASP Mobile Application Security (MASVS and MASTG): the testing guide behind traffic interception and Frida.
• Mobile development roadmap: how Android apps, permissions and networking work.
• Cybersecurity roadmap: mobile security and privacy testing.
• Cybersecurity cheat sheet: TLS, certificates and interception basics.
• Where do I start if I want a career in cybersecurity or IT operations?: the career context for this kind of work.

Get help with this idea

The care needed here is ethical as much as technical: fake data only, verified findings and responsible disclosure. Tauseef can help you plan the study, set up the test bench and decide how to publish. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session