A borrower’s phone holds some of the best evidence a lender can find about someone with no credit file, and some of the most private. Bank alerts show deposits, payment messages show regular costs and loan messages show other debts.
The same phone also holds private conversations, one-time passwords, contacts and location. A lender that scores borrowers with phone data has to take what helps the credit decision and leave the rest alone.
This guide explains what SMS and app scoring are, why privacy matters, four principles to follow, nine steps for building a privacy-first process and the platform rules that apply.
What SMS and mobile app scoring are
SMS scoring judges how likely a borrower is to repay from the financial text messages on their phone, such as bank alerts, mobile money notifications, salary credits and loan repayment messages.
Software finds those messages, pulls out details like the amount, date and type of transaction, and feeds them into a credit model. Lendsqr’s documentation explains why lenders use it.
Banks send SMS alerts that show a borrower’s financial activity, so a lender with no bank statement can check whether the person regularly receives money and pays bills.
Mobile app scoring uses data from how the borrower uses the lender’s own app, or from a data connection the borrower has approved.
That can include application details, repayment history, transaction records and how the borrower uses the lender’s products. SMS shows what happens outside the lender’s app, and app data shows how the borrower has dealt with the lender.
Both sources have limits. A text message shows that money arrived, and it does not show that the person earned it.
A borrower who opens the app often may only be checking a balance, which says little about their ability to repay. Before a lender uses any data point in a decision, it should know what that point really measures.
Why privacy matters
A phone holds far more than bank alerts. An inbox can include medical appointments, private conversations, religious messages and one-time passwords, and an app can also ask for contacts, location and a list of installed apps.
Collecting all of this without a clear purpose exposes customers and the lender.
Regulators have started to set limits. In 2022, India’s central bank told digital lending apps to desist from accessing phone resources such as files and media, contact lists, call logs and telephony functions.
The only exception is one-time access to the camera, microphone or location for onboarding and KYC, and only with explicit consent.
The World Bank’s page on data privacy in digital credit lists the risks, including data collection that goes far beyond the purpose a customer agreed to.
In Nigeria, the Data Protection Act 2023 sets the basic principles. The Nigeria Data Protection Commission’s implementation framework lists them in Section 24 of the Act, including fairness, lawfulness and transparency, purpose limitation, data minimization, storage limitation and accuracy.
It also says that consent must be freely given, informed and specific. Digital lenders must follow the FCCPC’s rules too. Its guidelines require applicants to confirm that their apps will not have access to customers’ call logs, contacts or photos and gallery.
A Federal High Court interim order paused enforcement of the regulations in April 2026, and on 20 July 2026 the court upheld them, with the FCCPC announcing that they are enforceable again.
Four principles of ethical scoring
Collect for a clear purpose
Before you collect anything from a phone, decide what you need and why. Say the aim is to estimate regular income.
Verified salary deposits or recurring business receipts will do, and a customer’s private conversations or full contact list add nothing.
Write down the purpose of each data category and how it feeds the underwriting decision, for example “salary credit alerts, to check that income arrives each month.” That keeps the collection in check.
Ask for consent that means something
A pop-up that says “Allow access to improve your loan experience” does not tell the borrower what the lender will do.
A better notice might read: “We will scan your text messages for bank and mobile money alerts and use only the amounts, dates and transaction types to help assess your loan.
We do not keep your other messages. You can withdraw your consent at any time.” It should also say whether a third party processes the data.
Where consent is the legal basis, it must be informed, specific and freely given, and the lender’s data protection team should confirm the basis for each use.
Read more: Frequently asked questions on data privacy laws for loan apps
Collect only what you need
For SMS scoring, a lender can extract the sender, date, amount, transaction type and reference from financial messages, and leave out personal messages and one-time passwords.
A friend’s message about a hospital visit has no place in the data, and neither does a verification code.
For apps, separate the data needed to run the service from the data that might help assess credit.
A borrower’s login frequency should not become an underwriting variable just because the app can record it.
Keep records accurate and let customers correct them
A duplicated alert can inflate a borrower’s income, and a misclassified debit can suggest a debt that does not exist. Say a bank and a payment app both send a message about the same 50,000 transfer.
If the system counts both, it records 100,000 of income. Validate extracted records, remove duplicates and give customers a way to challenge wrong information.
How to build a privacy-first scoring process
Step 1: Map the data you need
Start with the credit questions your team must answer, such as whether the borrower has regular income, existing loans or steady business activity.
List each type of data you plan to collect, where it comes from, why you need it and who can see it, and keep financial data separate from unrelated personal data. Doing this first shows you which permissions you do not need.
Step 2: Choose suitable sources
Pick sources that can answer your credit questions, such as financial SMS, authorized bank records, mobile money records, credit bureau reports, income or business documents from the customer and your own repayment records.
If a bank or payment provider offers an authorized API, structured transaction data can reduce your reliance on incomplete messages and screenshots. An API does not make data accurate, so still check the source and permitted use.
Step 3: Design clear permission screens
Explain what you collect before you ask for access. Say what you will extract, why you need it and what happens to unrelated messages, and let customers read the privacy notice without clicking through several screens. If you do not need contacts or precise location for a lending purpose, do not ask for them.
Step 4: Build secure extraction and processing
Design the parser to recognize financial message formats and extract only the fields you need, and keep private messages and one-time passwords out of the scoring data.
Where you can, process data on the device and send your servers only those fields. If raw data has to go to a service provider, check its security and contract first, and use encryption, access controls, authentication and audit logs.
Step 5: Build variables around repayment capacity
Use variables with a clear link to repayment, such as how regular income is, how often verified transactions occur, what debts the borrower already has and how they repaid before.
Avoid sensitive personal traits and unrelated behavior as shortcuts. A borrower who opens the app often may only be checking a balance or a due date.
Step 6: Test for accuracy and unfair outcomes
Test the model against past repayments and compare predicted risk with real results. Where incomes are irregular and bureau coverage is thin, a model may score salaried workers well and traders, artisans and the self-employed badly, so check performance by customer group.
Drop variables that predict little or carry high privacy risk, and write down the model’s assumptions and limits.
The World Bank’s guidelines on credit scoring approaches recommend that scoring providers build data privacy into their design and use privacy impact assessments.
Step 7: Keep human review and a way to appeal
Send cases with incomplete alerts, or activity spread across several accounts, to a reviewer who can look at other evidence. Give customers an easy way to dispute wrong information and to ask how their data affected a decision.
Step 8: Set retention and deletion rules
Decide how long you need each type of data, because raw SMS content, extracted variables, application records and repayment records may have different needs. Base the periods on legal duties, business need and your privacy policy, delete or anonymize data you no longer need, and ask providers how they handle copies and backups.
Step 9: Monitor vendors and review the system
Identity, SMS parsing, bureau, analytics and cloud providers all touch your data. Review their security, access arrangements, retention, subcontractors and incident reporting before you sign, and set out each party’s responsibilities in the contract.
Keep reviewing after launch, because changes in bank message formats, phone permissions and customer behavior can affect accuracy.
What Google and Apple require of lending apps
The app stores add rules of their own, on top of consent and local law.
Google Play limits SMS access on Android. Its policy says an app must be the user’s default SMS, Phone or Assistant handler before it prompts for SMS permissions.
Google can grant exceptions for some use cases, but personal loan and budgeting apps may not exfiltrate or share a user’s non-financial or personal SMS history, so reading bank alerts does not open the rest of the inbox.
Apple requires developers to describe their app’s privacy practices in App Store Connect, including those of third-party partners whose code they integrate.
A lender that adds a scoring SDK must know what it collects and disclose it, and engineering, compliance, product and legal teams should review the plan together.
How Lendsqr supports lenders
Lendsqr’s documentation describes its SMS feature as a way to ethically pull user data from Android devices and extract relevant information about a borrower’s financial behavior and repayment capacity.
A lender that uses the feature still has to meet consent, data minimization and app store requirements, and should check the results against other records.
Lendsqr’s decision model page lists the other inputs a lender can use in its approval rules, including credit bureau queries, ecosystem data on how borrowers have behaved with other lenders on the platform, and bank statement data that customers share by consent.
To try the platform, sign up for a Lendsqr account.
Read more: A borrower’s right to data privacy is not negotiable
Building trust with the data you collect
Privacy-first scoring means using phone data to understand customers with thin files while collecting only what serves a clear credit purpose.
In practice, that means explaining the collection in plain words, protecting the data, testing the models, letting people correct mistakes and checking permissions against the law and the app stores.
A lender should be able to say what it collects, why it needs it, how it affects a decision and how it protects the customer. Lenders that do this get better evidence for underwriting and earn more trust from the people who share their data.
