A borrower’s loan doesn’t live inside the digital lending app. Before a single rupee is disbursed, it travels through Know Your Customer (KYC) checks, credit bureau pulls, partner application programming interfaces (APIs), repayment mandates and cloud storage. Each of those systems mentioned holds borrower data and guess what each one can be attacked by nefarious cybercriminals.
So, is your digital lending journey secure in truest sense? May be not. That’s indeed a challenge with digital lending app security for non-banking financial companies (NBFCs). And something you need to resolve in the AI era.
In this blog, we walk through what NBFCs should test across the mobile app, the APIs behind it and the cloud it runs on. We also try to explain you how to scope Vulnerability Assessment and Penetration Testing (VAPT) around the borrower journey, so nothing falls between vendors.
Why testing the app alone misses most of the lending journey
The app is the part of the journey your borrowers see. It is rarely the part that holds the most risk.
What a single loan application touch
If you see a typical digital loan, it moves through five stages, and each one runs on different systems:
- Onboarding: the app collects identity documents, selfies and contact details.
- KYC: APIs call the Central KYC Records Registry (CKYCRR) and identity verification partners.
- Underwriting: the platform pulls credit bureau data and, often, bank statements through account aggregators.
- Disbursal: payment APIs move the money and set up electronic mandates for repayment.
- Collections: reminders, repayment links and recovery tools run on yet more systems.
Every stage adds data stores, integrations and partners and every one of them widens the attack surface.
Where assumption and reality split
This is a gap we see often in our dealings with clients: the app gets tested every year and the APIs behind it get partial coverage. But the Lending service provider (LSP) integrations and cloud storage often get left.
In such a scenario, if an attacker skipped your app entirely and went straight for your APIs, would your last test report tell you what they’d find?
What RBI expects from you
The Reserve Bank of India (RBI) Digital Lending Directions, 2025 apply to banks, NBFCs, housing finance companies and other regulated entities. They require all personal data to be available on servers in India and call for compliance with RBI’s cybersecurity standards.
The Master Direction on IT governance, risk, controls and assurance adds another layer, expecting NBFCs to run governance and control frameworks at par with banks.
As our experts who handle RBI Master Directions for many NBFC clients put it:
“Regulation has also moved. Under RBI’s 2025 Directions, the NBFC remains accountable for borrower data security even when an LSP or vendor runs part of the journey.”
In other words, outsourcing a stage of the journey doesn’t outsource the risk. The Directions also expect you to check an LSP’s technical capabilities and storage systems before you sign with them. That turns security testing a governance question.
What to test in the mobile app
Every loan journey starts on the borrower’s phone, and so do many attacks. That phone often holds far more borrower data than your team assumes.
Where sensitive data sits on the device
Lending apps handle KYC images, selfies, session tokens and loan documents. Testers should check whether any of these are cached, logged or stored in plain text on the phone. The OWASP Mobile Application Security Verification Standard (MASVS) gives a useful baseline, with controls on secure storage and on preventing data leakage.
Permissions and access to phone resources
The Directions restrict lending apps from accessing mobile resources such as files and call logs. So, testing should answer two questions. Which permissions does the app ask for? And what data does it read?
Tampering, rooted devices and traffic interception
Can someone run your app on a rooted phone, modify it and replay its requests? Test certificate pinning, anti-tampering and runtime integrity checks. Weak controls here make every API attack that follows much easier.
Third-party SDKs and WebViews
Analytics, KYC and payment software development kits (SDKs) ship inside your app. They run with your app’s permissions. Test what they collect and where they send it, and check WebViews for unsafe content loading. A current inventory of the components inside your app helps you know what you’re testing before the test begins.
What to test in the APIs behind the journey
This is where the most serious issues tend to hide. The app is only a client but the APIs make the decisions.
Can one borrower see another borrower’s loan?
Broken object level authorisation (BOLA) sits at the top of the OWASP API Security Top 10. It lets a user reach or change data that belongs to someone else. In lending terms, that means changing a loan ID in a request and pulling up another borrower’s agreement, PAN details or bank statement. It’s simple to test. At the same time, it’s also easy to miss.
Business logic in loan workflows
Automated scanners rarely catch logic flaws, so a tester needs to think like a fraudster. Here are the moves worth trying:
- Change the loan amount, tenure or interest rate in a request after approval.
- Skip the KYC or eligibility step and jump straight to disbursal.
- Replay a disbursal or refund call.
- Reuse a sanctioned offer for a different borrower.
OTP, session and authentication flows
Most lending journeys rely on one-time passwords (OTPs). Test rate limits, brute force resistance, token expiry and device binding. A weak OTP flow can turn into account takeover at scale.
Partner and third-party APIs
Your platform talks to credit bureaus, CKYCRR, account aggregators, payment gateways and LSPs. Test how your systems handle what those APIs send back. Unsafe consumption of APIs is on the OWASP list for a reason. If you trust partner data blindly, a partner’s weakness quietly becomes yours.
What to test in the cloud
Some of India’s biggest lending data leaks weren’t hacks at all. Millions of KYC files simply sat in cloud storage that anyone could open.
Storage buckets holding KYC documents
In Sep 2024, researchers found that instant loan company FatakPay had left more than 27 million files in a misconfigured cloud storage bucket. The files included ID copies, loan agreements and verification selfies. Weeks later, RBI-registered NBFC Vivifi exposed over 36 million KYC files the same way. That bucket stayed open from Nov 28, 2024, to Jan 16, 2025.
Testing should cover bucket policies, public access settings and how long shared document links stay valid.
Identity, keys and access configuration
Look for cloud roles with far more access than they need. Look for long-lived access keys, and for keys hardcoded into app builds or scripts. Check that admin consoles and management APIs aren’t reachable from the internet.
Test and staging environments with real data
In Aug 2025, researchers found a bucket holding over 200,000 banking transaction documents linked to fintech firm Nupay. The company cited a configuration gap and said many files were test data. Researchers said most were real. The lesson is simple: if a non-production environment holds real borrower data, it belongs in scope.
Data residency checks
The Directions require personal data to sit on servers in India. Confirm where your primary data, backups, logs and partner copies actually live. A cloud configuration review gives you practical evidence of this.
How to scope VAPT around your lending journey
So how do you pull all this together without trying to test everything at once? One possible way is to start with the journey and not touch the asset list first.
Map each journey stage to its systems
A simple map shows where each test belongs and who owns each system:
Bring LSPs and partners into scope or into contracts
Where you can, test partner integrations directly. Where you can’t, write testing rights and evidence requests into your contracts. Remember, the accountability stays with you either way.
If you are drafting or renewing partner agreements, see our 10-point checklist of what every penetration testing contract should cover.
Test on every major release
Lending stacks change fast. A new partner, product or app version can open a path that didn’t exist last quarter. Pair an annual full test with targeted tests on major releases, and your scope stays current.
Close the loop with retests
Open findings don’t reduce risk. Auditors typically ask for VAPT reports, closure trackers and retest evidence for high and critical findings. Fix in order of real exploitability, not severity scores alone, then retest to prove the fix holds.
If you want to know what audit-ready evidence looks like, see our guide to the structure of a strong VAPT report.
Conclusion
Digital lending app security doesn’t stop at the app. Three things stand out. The borrower journey is your real scope. The biggest exposures usually sit in the APIs and cloud behind the app. And under RBI’s Directions, accountability for borrower data stays with you, whoever runs each stage.
At CyberNX, our CERT-In empanelled VAPT services test digital lending stacks the way an attacker sees them: the app, the APIs, partner integrations and the cloud, mapped to your borrower journey. We also help you build the retest and closure evidence your auditors will ask for.
Your lending app may look secure. But first test the journey behind it. Talk to our VAPT team and find out where your real exposure sits.
FAQs
How often should an NBFC run VAPT on its digital lending app?
Run a full test at least once a year. Add targeted tests whenever you release a major app version, onboard a new lending partner or change core APIs. Retest high and critical findings after fixes so you have closure evidence ready.
Is an NBFC responsible for security gaps in its LSP’s systems?
Yes. Our experts who handle RBI Master Directions for many NBFC clients are clear on this: “Under RBI’s 2025 Directions, the NBFC remains accountable for borrower data security even when an LSP or vendor runs part of the journey.” That’s why partner testing rights and evidence clauses matter in your contracts.
What is the difference between mobile app VAPT and API VAPT?
Mobile app VAPT tests the app on the device: data storage, permissions, tampering and traffic. API VAPT tests the backend services: authorisation, business logic and data exposure. A digital lending stack needs both, because most serious flaws sit in the APIs.
Should cloud configuration reviews be part of lending app VAPT?
Yes. Several large Indian lending data leaks came from misconfigured cloud storage, not from app flaws. Reviewing buckets, access roles and keys also helps you show where borrower data is stored.
