The manifest two authorities regulate: RBI paragraph 12(i) and Google Play's Financial Services permission list

Two authorities write requirements that land on the same file.

One of them is a central bank, and it writes in prose about a borrower's phone. The other is a store, and it writes in permission constants. The build has one AndroidManifest.xml, and it is the artefact both of them reach.

Every quotation below was read from the page it is attributed to on 2 September 2026, and the date beside each one is the date it was checked. The Directions number themselves as paragraphs — the instrument's own cross-reference, quoted in full further down, reads "para 12 and 13 of these Directions" — and that is the citation form used here.

Who the Directions address, and who ships the app

Start with the addressee, because the split between who is bound and who holds the build is the reason this is difficult.

Reserve Bank of India (Digital Lending) Directions, 2025 — RBI/2025-26/36, DOR.STR.REC.19/21.07.001/2025-26, dated May 8, 2025, read from rbi.org.in on 2 September 2026. Paragraph 3, in full:

"3. Applicability
These Directions shall be applicable to all digital lending activities of the following entities, hereinafter referred to as a Regulated Entity (RE) and collectively as Regulated Entities (REs), as the context may require:
i. All Commercial Banks, ii. All Primary (Urban) Co-operative Banks, State Co-operative Banks, Central Co-operative Banks, iii. All Non-Banking Financial Companies (including Housing Finance Companies), and iv. All All-India Financial Institutions."

Read the co-operative limb closely: it is enumerated as Primary (Urban), State and Central co-operative banks. And limb iv reads "All All-India Financial Institutions" as published.

Paragraph 4 supplies the two definitions that carry the obligation from the entity to the app:

"Digital Lending Apps/ Platforms (DLAs): Mobile and/or web-based applications, on a standalone basis or as a part of suite of functions of an application with user interface that facilitate digital lending services. DLAs shall include applications of the RE as well as those operated by Lending Service Provider (LSP) engaged by RE for extending any credit facilitation services in conformity with extant outsourcing guidelines issued by the Reserve Bank."

"Lending Service Provider (LSP): An agent of a RE (including another RE) who carries out one or more of RE’s digital lending functions, or part thereof, in customer acquisition, services incidental to underwriting and pricing, servicing, monitoring, recovery of specific loan or loan portfolio on behalf of RE in conformity with extant outsourcing guidelines issued by the Reserve Bank."

Paragraphs 12(i), 13(iii), 13(iv), 15(i), 17(v), 17(vi) and 17(vii) — every one of them quoted below — open with the same three words: "RE shall ensure". The Directions address the Regulated Entity. They reach the app through what the RE must ensure about it, and the definition of a DLA expressly includes the applications "operated by Lending Service Provider (LSP) engaged by RE".

So where the app is built and shipped by an LSP, the party that holds the repository, the Gradle files and the signing key and the party the instrument addresses are two different parties: the one that can change a line in the manifest, and the bank or NBFC that answers for what the line does. That is the whole reason this subject is hard to run, and it is why the rest of this page is about a file rather than about a filing.

Paragraph 2(ii) sets commencement:

"These Directions shall come into force immediately except for para 6, which shall come into effect from November 1, 2025, and para 17, which shall come into effect from June 15, 2025."

Checked 2 September 2026: 8 May 2025, 15 June 2025 and 1 November 2025 are all behind us.

What para 12(i) says about the phone

Chapter IV, Technology and Data Requirement, paragraph 12, Collection, usage and sharing of data with third parties, sub-item i, verbatim and whole, checked 2 September 2026:

"i. RE shall ensure that any collection of data by their DLA and DLA of their LSP is need-based and with prior and explicit consent of the borrower having audit trail. In any case, RE shall also ensure that DLA of RE/LSP desist from accessing mobile phone resources like file and media, contact list, call logs, telephony functions, etc. A one-time access can be taken for camera, microphone, location or any other facility necessary for the purpose of on-boarding/ KYC requirements only, with the explicit consent of the borrower."

Three things in that sub-item bear on a build.

The resource list is introduced by "mobile phone resources like" and closed by ", etc.". It is illustrative in its own grammar, and it is written in the vocabulary of a phone rather than the vocabulary of a platform: file and media, contact list, call logs, telephony functions.

The consent condition carries three parts. Collection must be "need-based and with prior and explicit consent of the borrower having audit trail" — a property of the flow, a property of the consent, and a record.

There is a carve-out, and it carries four conditions in one sentence. "A one-time access", for "camera, microphone, location or any other facility", "necessary for the purpose of on-boarding/ KYC requirements only", "with the explicit consent of the borrower".

Sub-items ii to iv of the same paragraph are what make 12(i) operable, and they are quoted here whole for that reason:

"ii. The borrower shall be provided with an option to give or deny consent for use of specific data, restrict disclosure to third parties, data retention, revoke consent already granted to collect personal data and if required, make the RE/LSP delete/ forget the data."

"iii. The purpose of obtaining borrowers’ consent needs to be disclosed at each stage of interface with the borrowers."

"iv. Explicit consent of the borrower shall be taken before sharing personal information with any third party, except for cases where such sharing is required as per statutory or regulatory requirement."

Paragraph 13, Storage of data, carries two more that a build has to answer for:

"iii. RE shall ensure that no biometric data is stored/ collected by the RE and LSP, unless allowed under extant statutory guidelines."

"iv. RE shall ensure that all data is stored only in servers located within India, while ensuring compliance with statutory obligations/ regulatory instructions. Further, in case the data is processed outside India, the same shall be deleted from servers outside India and brought back to India within 24 hours of processing."

Paragraph 13(iv) has two limbs and a clock: India-only storage, and — where processing happens outside India — deletion from the servers abroad plus return to India within 24 hours of processing. That is a claim about where an SDK sends bytes, which is a question about the app's observed network behaviour.

What Google Play's Financial Services policy names

A separate instrument, on a separate surface, in a different vocabulary.

Play Console Help, Financial Services (answer 9876821), checked 2 September 2026. Under the heading General Requirements, the lead-in and the list, verbatim:

"Personal loan apps, apps with the primary purpose of facilitating access to personal loans (for example, lead generators or facilitators) or lines of credit, accessory loan or credit apps (loan calculators, loan guides, etc.), and Earned Wage Access (EWA) apps are prohibited from accessing sensitive data, such as photos and contacts. The following permissions are prohibited:"

READ_EXTERNAL_STORAGE
READ_MEDIA_IMAGES
READ_CONTACTS
ACCESS_FINE_LOCATION
READ_PHONE_NUMBERS
READ_MEDIA_VIDEO
QUERY_ALL_PACKAGES
WRITE_EXTERNAL_STORAGE

That is the list as the policy prints it: eight items, in that order, each one an Android permission constant, each one a string that appears in an AndroidManifest.xml. Read the addressee with it — the list is scoped to personal loan apps, facilitators and lead generators, lines of credit, accessory loan and credit apps including loan calculators and loan guides, and Earned Wage Access apps.

The policy closes that block by pointing onward:

"Apps that utilize sensitive information or APIs are subject to additional restrictions and requirements. Please see the Permissions policy for additional information."

And under Country specific requirements, the India item reads in full:

"Only apps that submit a license and are on the "Digital lending apps (DLAs) deployed by Regulated Entities" list of the Reserve Bank of India (RBI) may submit personal loan apps to Google Play for review (see this Help Center article for guidance)."

"If you are not directly engaged in money lending activities and are only providing a platform to facilitate money lending by registered Non-Banking Financial Companies (NBFCs) or banks to users, you will need to accurately reflect this in the declaration."

"In addition, the names of all registered NBFCs and banks must be prominently disclosed in your app's description."

That first sentence is written in the present tense as a condition on review eligibility. The date you can pin the policy article to is the date you open it, and on 2 September 2026 it stated the requirement as a standing condition of submission.

The link between the two instruments is stated by Google, and nothing here has to be inferred. The Help Center article the policy points at — Personal Loans in India, answer 16604194, checked 2 September 2026 — names the instrument, its title and its publication date:

"The requirement for DLAs to register on the list was outlined in the "Reserve Bank of India (Digital Lending) Directions, 2025" (published on May 8, 2025). All regulated entities offering DLAs were to submit the required information to the RBI list as of June 15, 2025, and can still provide it."

The same article sets out the two Play requirements for an India personal loan app — to "hold and present a valid financial services license from the Reserve Bank of India (RBI) to offer personal loans", and to "have provided the required information about the app to the publicly available list of digital lending apps (DLAs) that is published by the RBI" — and names the list and where it sits:

"This list is known as the "DLAs deployed by Regulated Entities." See the RBI site for additional details (listed under "Citizen's Corner")."

Two transition dates are still published on that article, in the future tense, as read on 2 September 2026:

"As of October 30, 2025, all new personal loan apps which publish for the first time to Google Play will be required to be on the RBI list."

"All personal loan apps that are currently on Google Play in India will have until January 28, 2026 to have their app(s) included on the RBI list entitled "DLAs Deployed by Regulated Entities.""

Both dates are behind 2 September 2026, and the policy article's own present-tense condition is the current statement of the position.

The stricter instrument decides, and it decides at design time

Hold the two lists side by side in your head rather than in a table. They are written in different units — one in the vocabulary of a phone, the other in permission constants — and each is quoted above in the units its own author chose.

RBI's paragraph 12(i) permits "A one-time access ... for camera, microphone, location or any other facility necessary for the purpose of on-boarding/ KYC requirements only, with the explicit consent of the borrower." Google Play's Financial Services list names ACCESS_FINE_LOCATION among the permissions prohibited for personal loan apps. Both sentences are quoted above, from their own sources, in their own words.

A build has one manifest, and the design question that follows is a design question: does the on-boarding flow need that constant at all? Whichever of the two instruments is stricter on the point is the one the manifest ends up satisfying, and the moment to settle it is when the KYC flow is designed.

The same shape shows up on the other side of 12(i)'s resource list. Paragraph 12(i) names "call logs" among the phone resources in that list. On Google's side, call logs are governed for every app on Play by a separate policy from the Financial Services one, and that policy is where this subject becomes an engineering question.

Play's rule is written on the declaration

Play Console Help, Permissions and APIs that Access Sensitive Information — checked 2 September 2026 at answer 16558241, reached through two redirects from answer 9888170 via answer 16324062. Older citations point at the first of those three.

Its SMS and Call Log Permissions section carries a table headed Restricted Permission and Requirement. Two rows, verbatim:

Restricted Permission	Requirement
Call Log permission group (for example, `READ_CALL_LOG`, `WRITE_CALL_LOG`, `PROCESS_OUTGOING_CALLS`)	It must be actively registered as the default Phone or Assistant handler on the device.
SMS permission group (for example, `READ_SMS`, `SEND_SMS`, `WRITE_SMS`, `RECEIVE_SMS`, `RECEIVE_WAP_PUSH`, `RECEIVE_MMS`)	It must be actively registered as the default SMS or Assistant handler on the device.

And then the paragraph under it, quoted whole because each of its sentences adds an obligation:

"Apps lacking default SMS, Phone, or Assistant handler capability may not declare use of the above permissions in the manifest. This includes placeholder text in the manifest. Additionally, apps must be actively registered as the default SMS, Phone, or Assistant handler before prompting users to accept any of the above permissions and must immediately stop using the permission when they're no longer the default handler. The permitted uses and exceptions are available on this Help Center page."

Read the verb in the first sentence. It is declare. The rule Google states there is written on what the manifest declares, and the second sentence extends it explicitly to "placeholder text in the manifest" — text that by definition no code path reaches.

That is what makes this an Android engineering question rather than a paperwork one. An app's shipped manifest is not the manifest anyone wrote. The Android build system combines the app's own manifest with the manifest of every library it depends on, in a build step the toolchain names the manifest merger, and a <uses-permission> line contributed by a dependency arrives in the merged output the same way one typed by hand does. An analytics SDK, an attribution SDK, a chat widget, a device-fingerprinting library, a KYC vendor's drop-in module: each ships a manifest, and each of those manifests is an input.

So there are two different artefacts a team can read, and the second of them is the one Google's sentence is written about:

The manifest in the repository is what the team wrote.
The merged manifest in the release build is what the app declares.

Establishing which permissions are in the second one, and which dependency each of them arrived from, is a build-time question with a definite answer. It is also the list to have in front of you when reading paragraph 12(i), which names its own resources in its own vocabulary.

One more thing on that page, because it is dated and it bears on this subject. The article carries a banner reading "Changes are coming to this article" and "This article will be updated with recently announced changes.", and names two of them, verbatim, checked 2 September 2026:

"To better protect user privacy, we're updating our Location Permissions policy. We're introducing the location button as the recommended minimum scope for precise location in line with our user data and sensitive permissions requirements. (effective January 27, 2027)"

"We're introducing the Contacts Permissions policy to govern broad access of users' contacts. Apps that don't need broad access must use the Android Contact Picker, a more secure, easy-to-integrate alternative that minimizes data collection and improves user safety. (This is a new policy, and will be effective January 27, 2027.)"

The article also offers its own preview: "To preview the updated "Permissions and APIs that Access Sensitive Information" article, visit this page." Google has announced changes to its Location Permissions policy and to contacts access, both with a date on them.

The officer who signs for it

This is the step that turns everything above into a demand for evidence rather than an opinion about good practice.

Paragraph 17, Reporting of DLAs to RBI, sub-item iii, verbatim, checked 2 September 2026:

"iii. The Chief Compliance Officer of the RE or any other official designated by the Board of the RE for the purpose shall certify that the data on DLAs submitted by them on the CIMS portal is correct and the DLAs are compliant with all the extant regulatory instructions, including the provisions of these Directions, as updated from time to time."

Sub-item iv, and the four items it introduces, verbatim and whole:

"iv. Without prejudice to the generality of the above, the Chief Compliance Officer/ other official designated by the Board of the RE shall certify the following aspects:"

(a) "DLAs have link to RE’s website where further information about the loan products, the lender, the LSP, particulars of customer care, link to Sachet Portal, privacy policies, etc. can be accessed by the borrower."

"(b) DLAs (in case owned by LSP), have appointed a suitable nodal grievance redressal officer to deal with digital lending related complaints/ issues raised by the borrower, details of which are prominently available on the respective DLA."

"(c) Data collection and storage by DLAs is in compliance with para 12 and 13 of these Directions and other statutory and regulatory requirements, as applicable from time to time."

"(d) The DLA’s particulars submitted by the RE are also suitably disclosed on the RE’s website as required under para 8(iv) of these Directions."

Item (c) is the one that reaches the manifest. A named officer of a bank or an NBFC certifies that data collection and storage by DLAs comply with paragraphs 12 and 13 — the paragraphs quoted above, about what the app may access on a borrower's phone and where the data may then live.

Paragraph 17 also carries the reporting deadline itself:

"vii. RE shall ensure that the reporting in respect of all DLAs on the CIMS portal is completed by June 15, 2025."

Checked 2 September 2026: that date is behind us, and paragraph 17 has been in effect since it.

What RBI states about the listing

Two further sub-items of paragraph 17 are reproduced here whole and in the instrument's own words, checked 2 September 2026.

"v. RE shall ensure the correctness and timeliness of information regarding DLAs, as the data, as submitted by the RE on CIMS, shall be published on the website of RBI in an automated manner and RBI shall not verify/ validate the data submitted on CIMS. All issues and grievances of customers concerning DLAs shall be addressed and dealt with by the RE directly."

"vi. RE shall ensure that the inclusion of any third party DLAs deployed by them as part of above reporting, shall not be construed by the DLAs or any associated entity as conferring any form of registration, authorization, or endorsement by the Reserve Bank. RE shall also ensure that such inclusion is not misrepresented in any marketing, promotional, or other materials issued by or on behalf of the DLAs."

Both are quoted as the instrument states them.

The assurance obligation, and where it points

Paragraph 15, Technology standards, has a single sub-item, and it is where the Directions discharge assurance. Verbatim and complete, checked 2 September 2026:

"i. RE shall ensure that they and the LSPs engaged by them comply with various technology standards/ requirements on cybersecurity stipulated by RBI and other relevant agencies, or as may be specified from time to time, for undertaking digital lending."

Note where it points. It binds the RE to ensure that they and the LSPs engaged by them comply, and it discharges into technology standards and cybersecurity requirements "stipulated by RBI and other relevant agencies, or as may be specified from time to time". In India, CERT-In empanelment is the qualifying standard for the assessment work that sits under a sentence like that one. Security Brigade has been CERT-In empanelled since 2008.

The build, and who certifies

A person signs their name to a statement about what an app does. What an app does is establishable from the app.

That is the whole of the offer on this page. We establish facts about a binary; the Chief Compliance Officer certifies. The certification is the officer's, under paragraph 17, and it stays theirs.

The published scope of our Android work, as published: Android Hardening — Keystore misuse, root detection, intent abuse, manifest exposure, NSC bypass; component mapping across activities, intents, providers, services, schemes and deep links, to build a complete attack surface inventory of the app; and the APK retrieved, decompiled and analysed for hardening posture. Security Brigade has been CERT-In empanelled since 2008, with 693+ mobile application scopes assessed.

A penetration test and a Play policy requirement are different obligations on the same release. If you want the build looked at, the service page is securitybrigade.com/services/mobile-application-security-testing/ and the number is +91 22 4164 2220.

The obligations around this one

Named here because a reader meets them next, and each is performed by a named party.

The CIMS return is the RE's. Paragraph 17 puts the submission of DLA data on the CIMS portal with the Regulated Entity, and 17(iii) names it as "the data on DLAs submitted by them on the CIMS portal".

The RBI list is populated by a filing. Google's own India requirement is that an app has provided the required information to the list RBI publishes; the party that provides it is the Regulated Entity.

The app-store declaration is the developer account's. Play's India item requires that a facilitator reflect its position accurately in the declaration, and that the names of all registered NBFCs and banks be prominently disclosed in the app's description. Both are actions in the store listing and the Play Console account.

Those are filings and console actions. The manifest is not one of them, and that is the difference this page is about.

If you are shipping a lending app on Android

Six things, in order.

Build a release artefact and read its merged manifest, not the manifest in the repository. The merged one is what the app declares.
For every <uses-permission> line in it, establish which input contributed it — the app's own manifest, or a named dependency's.
For every permission the app requests at runtime, establish which flow requests it, at what point, and against what record of consent. Paragraph 12(i) asks for need-based collection with prior and explicit consent having audit trail; 12(ii) and 12(iii) ask for revocation and for disclosure at each stage.
Read paragraph 12 and paragraph 13 against that list, in the Directions' own words, with the officer who will certify item (c) in the room. The certification is per DLA.
Read Google Play's Financial Services policy and its SMS and Call Log rule against the same list. The Financial Services list is scoped to personal loan, facilitator, accessory-loan and EWA apps; the SMS and Call Log rule is written on what any app declares in its manifest.
Check Play Console for the state of the app itself. The console is the authority on your own packages; a published policy page is a description of the policy.

The policy article says the same thing about its own summaries, and it is the right note to end on:

"Disclaimer: Policy summaries and Key Considerations are overviews only; always refer to the full policy for compliance. The full policy takes precedence in case of conflict."

Both instruments land on one file. Read the merged one.

Every quotation above was read on 2 September 2026 from the page it is attributed to: the Reserve Bank of India (Digital Lending) Directions, 2025 at rbi.org.in/Scripts/NotificationUser.aspx?Id=12848&Mode=0, and Play Console Help answers 9876821, 16604194 and 16558241.