Google Play Guidelines Update

Google previously prohibited personal loan apps in the United States where the Annual Percentage Rate was 36% or higher. This rule has been removed from the policy. Developers offering high-APR lending products in the US are no longer blocked by this Play Store rule, though state and federal lending regulations continue to apply independently.

Google has introduced an outright prohibition on apps that promote personal loans requiring full repayment within 60 days of issuance, labeling these 'short-term personal loans.' This is a new rejection category, not just a disclosure requirement. Any app — whether a direct lender, lead generator, or aggregator — that facilitates such loans will be ineligible for distribution on Google Play. Developers with apps in this space must audit their loan products immediately.

All apps offering EWA loans — including direct lenders, lead generators, and consumer-lender connectors — must now set their Play Console app category to 'Finance' and include full disclosure of repayment terms and all fees (subscription, transaction, and other) in their app metadata. This is a new, enforceable requirement that applies broadly across the EWA ecosystem. Failure to comply with either the category setting or the metadata disclosures could result in app rejection or removal.

Previously, sensitive data access restrictions for financial apps focused on personal loan apps; Google has now extended these prohibitions to explicitly include EWA apps alongside personal loan apps, lead generators, and accessory loan/credit apps. These apps are prohibited from accessing sensitive data categories such as photos and contacts. Developers who have integrated any such data access into EWA apps must remove it to avoid rejection.

Google has enumerated a set of Android permissions that are now explicitly forbidden for personal loan, EWA, lead generator, and accessory loan/credit apps — including READ_CONTACTS, ACCESS_FINE_LOCATION, READ_MEDIA_IMAGES, READ_PHONE_NUMBERS, and others. Previously, the restriction was described in general terms; now a concrete permission blocklist exists. Developers must audit their app manifests and remove any of these permissions to avoid rejection.

Google has added a requirement that there must be a traceable, verifiable connection between a developer's Play Console account and any licenses or documentation that demonstrate the developer's authorization to offer financial products. This is a new account-level compliance requirement, not just an app-level one. Developers offering EWA or loan products should ensure their legal entity, licensing documentation, and developer account details are clearly aligned before submitting apps.

Previously there was no explicit APR cap for personal loan apps in the United States on Google Play. Google now prohibits apps that offer personal loans with an Annual Percentage Rate of 36% or higher in the US market. Developers offering high-interest loan products in the US must either restructure their loan terms or remove their apps from Play to avoid rejection or removal.

Previously, Indian personal loan apps did not have an explicit regulatory pre-approval requirement on Google Play. Now, only apps that hold a valid license and appear on the Reserve Bank of India's approved Digital Lending Apps list for Regulated Entities may submit personal loan apps for review. This is a hard gate — apps not on the RBI list will not be accepted, so developers must obtain RBI approval before attempting to publish.

The policy previously provided explicit examples of in-scope loan types (personal, payday, peer-to-peer, title loans) and out-of-scope types (mortgages, car loans, revolving credit), as well as a formal definition of Earned Wage Access. This definitional content has been removed entirely. Developers building lending or EWA apps may lose the clear boundary that previously distinguished regulated loan apps from EWA apps. Watch for replacement guidance that redefines these categories.

The policy previously specified that EWA repayment must occur via payroll deduction or autopay linked to a bank account as a distinguishing feature from traditional loans. This clause has been deleted. Apps that relied on this language to qualify as EWA rather than a regulated loan product no longer have this explicit safe-harbor definition. Developers should monitor for updated EWA criteria to ensure their app is still correctly classified.

Previously, EWA apps were required to ensure that if an autopay repayment failed, no additional interest, penalties, or fees could be charged to the user. This consumer protection requirement has been removed from the policy text. It is unclear whether this protection is now expected to be implicit or has been dropped entirely. EWA app developers should reassess their repayment failure handling and look for any replacement guidance.

The policy previously required that EWA apps restrict access to wages already earned in the current pay period, explicitly prohibiting advances against future income. This defining constraint has been removed. Developers building EWA products used this rule to distinguish their service from a loan; without it, the boundary between EWA and lending is less defined. Await updated policy language before making product changes.

EWA apps were previously required to charge no interest and only a low flat or percentage-based transaction fee as a condition of being treated as EWA rather than a loan. This fee structure requirement has been deleted from the policy. Apps that structured their monetization around this rule to avoid loan-app classification requirements now operate without that explicit framework. Developers should review whether their fee model still qualifies under any updated guidance.

The policy previously required that EWA services not report transactions to credit bureaus, thereby avoiding impact on users' credit scores or long-term debt. This no-debt-creation characteristic has been removed as a stated EWA requirement. Developers who cited this rule as evidence their product was not a loan product should reassess their classification. The removal could broaden or narrow how EWA is distinguished from regulated lending going forward.

Previously, apps offering personal loans — including direct lenders, lead generators, and third-party connector apps — were explicitly required to set their Play Console app category to 'Finance' and disclose minimum and maximum repayment periods in app metadata. This specific requirement has been removed from the policy. Developers of lending apps should determine whether equivalent requirements exist elsewhere in current policy before removing compliance disclosures.

The policy previously mandated that personal loan apps disclose the maximum APR — including interest, fees, and other annual costs calculated consistently with local law — in their app metadata. This disclosure requirement has been deleted. Developers who added APR disclosures specifically to meet this rule should verify whether the requirement has moved elsewhere or been superseded before removing the disclosure from their store listing.

Google previously banned apps that promoted personal loans requiring full repayment within 60 days of issuance. This blanket prohibition has been removed from the policy. Developers building or publishing short-term loan apps should still verify compliance with any remaining regional restrictions or financial regulations, but this specific Play Store rule is no longer in effect.

The policy previously mandated that Earned Wage Access loan apps — including direct lenders, lead generators, and third-party connectors — set their app category to 'Finance' and disclose repayment terms, subscription fees, transaction fees, and all other fees in their metadata. These specific requirements have been removed. Developers of EWA apps should check whether any successor requirements exist in the current policy before assuming all such obligations are lifted.

Google previously explicitly prohibited personal loan apps, loan facilitators, accessory loan apps, and Earned Wage Access apps from accessing sensitive data such as photos and contacts. This restriction has been removed from the policy. Developers of these app types should still follow Google's general sensitive permissions policies, but the loan-app-specific prohibition on these data types is no longer in force.

The policy previously included a named list of permissions — including READ_CONTACTS, ACCESS_FINE_LOCATION, READ_PHONE_NUMBERS, READ_EXTERNAL_STORAGE, and others — that were expressly forbidden for personal loan and EWA apps. This enumerated prohibition has been removed. Developers should still adhere to Google's general permissions policies, but the loan-specific blocklist of these APIs no longer applies.

US personal loan apps were previously required to display their maximum Annual Percentage Rate, calculated in accordance with the Truth in Lending Act (TILA). This disclosure requirement has been removed from Google's policy. Developers should note that TILA disclosure obligations still exist under US federal law regardless of this policy change, so legal compliance remains necessary.

Google previously required Indian personal loan apps to submit an RBI license and appear on the Reserve Bank of India's 'Digital Lending Apps deployed by Regulated Entities' list before being eligible for Play Store review. This requirement has been removed from the policy text. Indian lending app developers should check whether this guidance has been moved to a Help Center article or replaced with updated regional requirements, as it may signal a policy restructuring rather than a full removal of the obligation.

Apps targeting India were previously required to prominently disclose the names of all registered Non-Banking Financial Companies (NBFCs) and banks in the app's Play Store description. This disclosure requirement has been removed from the policy. Indian lending app developers should determine whether this obligation has been relocated within the policy or dropped entirely before removing such disclosures from their listings.

Apps targeting the Philippines were previously required to disclose their Corporate Name, Business Name, PSEC Registration Number, and Certificate of Authority to Operate a Financing/Lending Company in the app's Play Store description. This specific disclosure requirement has been removed from the policy text. Philippine lending app developers should verify whether this reflects a policy consolidation or a true removal of the obligation before updating their store listings.

Personal loan apps targeting Thailand with interest rates below 15% were previously required to include the statement 'This is a non-regulated loan provider under the BoT/FPO' in their app description. This country-specific disclosure rule has been removed. Developers operating in the Thai lending market should investigate whether this requirement has been updated or consolidated elsewhere, as regulatory disclosure obligations from local authorities may still apply independently of Google's policy.

Google has added new requirements specifically targeting apps that offer personal loans — including direct lenders, lead generators, and third-party lender connectors. These apps must now set their Play Console App Category to 'Finance' and disclose key loan details (including minimum and maximum rates and terms) in app metadata. Payday and peer-to-peer loans are in scope; mortgages, car loans, and revolving credit lines are explicitly excluded. Developers running non-compliant loan apps risk rejection or removal.

As part of the new personal loan disclosure requirements, apps must prominently disclose the Maximum Annual Percentage Rate (APR) — encompassing interest, fees, and other annual costs — or an equivalent rate calculated in accordance with local law. This is a mandatory metadata field, not just a recommended best practice. Failure to include this disclosure could result in app rejection under the new Finance category rules.

Google now requires personal loan apps to provide a concrete example in their app metadata showing the total cost of a loan, including the principal amount and all applicable fees. This requirement is aimed at giving users transparency before downloading a loan app. Developers must ensure this example is present and accurate in their store listing to avoid rejection.

The new personal loan policy requires that apps in this category include a privacy policy that fully discloses how personal and sensitive user data is accessed, collected, used, and shared. This goes beyond the general privacy policy requirement and must align with additional restrictions outlined elsewhere in the Developer Program Policy. Loan apps without a sufficiently comprehensive privacy policy face rejection.

Google has added a formal definition of Earned Wage Access (EWA) services, distinguishing them from traditional loans. A key characteristic is that repayment must occur automatically via payroll deduction or a bank-linked autopay transaction. Developers building EWA apps need to ensure their repayment flow matches this definition or risk being classified differently under financial services policy.

As part of the new EWA definition, Google explicitly requires that if an autopay repayment transaction fails, the app must not charge the user any additional interest, penalties, or fees. This is a new behavioral requirement for EWA apps. Developers whose apps currently impose late fees or penalties on failed repayments will need to revise their fee structures to remain compliant.

Google's new EWA guidelines specify that users may only access wages they have already earned within the current pay period — advances against future income are not permitted under the EWA classification. This income-based access requirement is a definitional boundary that affects how EWA apps calculate and present available funds. Apps that allow advances beyond earned wages may be reclassified as personal loan apps and face stricter requirements.

Google's new policy states that EWA services must not charge interest; instead, they may only charge a flat fee or a percentage-based transaction fee. Any interest-bearing EWA product would fall outside this classification and be subject to personal loan policies. Developers must audit their monetization models to confirm they meet this fee-structure requirement.

There was no prior explicit mention of Google requesting compliance documentation beyond standard account information. Google can now ask developers for additional information or documents to confirm their account meets all applicable local laws and regulations. This matters because failure to provide requested documents could put your account at risk, and developers operating in regulated markets should be prepared to supply legal compliance evidence on demand.

There was no previous requirement on Google Play for US loan apps to disclose APR in a specific way. Personal loan apps targeting US users must now display their maximum APR, calculated in accordance with the Truth in Lending Act (TILA). Developers in this space need to audit their app's UI and store listing to ensure compliant APR disclosure is clearly visible, or risk rejection.

The scope of Google's personal loan policy in the US has been expanded beyond apps that directly offer loans. It now explicitly covers lead generation apps and apps that connect consumers with third-party lenders. Developers who do not lend directly but facilitate loan referrals or matchmaking must ensure they also comply with the APR cap and disclosure requirements.

As a new disclosure requirement for personal loan apps in India, developers must prominently name all registered Non-Banking Financial Companies (NBFCs) and banks associated with their lending product in the Play Store app description. This is in addition to the RBI licensing requirement. Failure to include this information will likely result in rejection, so developers should update their store listings accordingly.

Google has introduced country-specific disclosure requirements for personal loan apps targeting the Philippines. Developers must include their Corporate Name, Business Name, SEC Registration Number, and Certificate of Authority to Operate a Financing/Lending Company (CA) in the app's Play Store description. Apps lacking these disclosures will face rejection, so developers should update listings before submitting or publishing updates.

A new Thailand-specific requirement applies to personal loan apps that offer interest rates below 15%. These apps must include the statement indicating they are a non-regulated loan provider under the Bank of Thailand (BoT) or Fiscal Policy Office (FPO). This disclosure must appear in addition to other required information, and omitting it will put Thai-market loan apps at risk of rejection.

While data policy compliance was already expected, Google now explicitly states that developers are responsible not just for their own code but for any third-party SDKs included in their app and those third parties' data practices. This means if an SDK you use handles user data in a non-compliant way, your app can be held accountable. Developers should audit all SDKs for compliance with Google Play's use and disclosure requirements.

Google has extended the third-party compliance responsibility to explicitly include AI integrations such as AI-powered products, services, and code embedded in apps. Developers remain fully accountable for ensuring any AI components meet Play's policies on limited data use, disclosure, and user consent. This is a significant expansion given the growing use of third-party AI SDKs and APIs, and developers should review any AI integrations immediately for compliance gaps.

Google has added an explicit requirement stating that developers must complete the content rating questionnaire for every new app submitted to the Play Console, as well as for all existing apps currently active on Google Play. Previously this obligation may not have been stated so directly in policy text. Failure to complete the questionnaire for any active app could now be treated as a policy violation, so developers should audit their entire portfolio to ensure all apps have completed ratings.

Google has added explicit examples of what constitutes a minimum functionality violation: apps that are static with no app-specific features (e.g., text-only or PDF-only apps), apps with very little content that don't provide an engaging user experience (e.g., single wallpaper apps), and apps designed to do nothing or have no function. Previously, the minimum functionality policy may have lacked this level of concrete illustration. Developers of simple utility or content apps should review these examples carefully, as apps matching these descriptions are now clearly flagged as violation candidates.

Google has added an explicit 'Broken Functionality' policy stating that apps which crash, force close, freeze, or otherwise function abnormally are not permitted on Google Play. While app stability has always been a practical expectation, codifying this as a named policy category means unstable apps now have a clear rejection basis. Developers should ensure thorough QA testing before submission, as a crashing or freezing app can now be rejected or removed under this explicitly named policy.

Google Play now explicitly requires developers offering specific categories of services to register as an Organization rather than an individual account when creating their Play Console account. This is a new requirement with no direct prior equivalent in this section. Developers in affected categories who have or plan to create individual accounts may need to reconsider their account setup to remain compliant.

Developers offering financial products and services — such as banking, loans, stock trading, investment funds, cryptocurrency software wallets, and cryptocurrency exchanges — are now required to register as an Organization on Google Play. This is a new explicit policy requirement. Any developer in the fintech or crypto space currently registered as an individual account should evaluate whether they need to migrate to an Organization account to avoid potential policy violations.

Under the new onboarding requirements, developers must accurately provide their account information, with specific sub-items enumerating what must be disclosed. This formalizes what was previously implied into an explicit policy requirement. Developers should audit their Play Console account details to ensure all required information is accurate and complete, as inaccuracies could become a compliance issue.

Legal name and address are now formally listed as required fields under the developer account information policy (item 2.1.1 and the start of 2.1.2). While this information has likely always been collected, making it an explicit policy requirement means failure to provide accurate details could be grounds for policy enforcement. Developers should verify their Play Console profile reflects their accurate legal name and address.

Google has added a new account registration requirement: organizations must provide a D-U-N-S number when creating or maintaining a developer account. This is a unique nine-digit identifier issued by Dun & Bradstreet used to verify business identity. Developers registering as individuals are not affected, but organizations that lack a D-U-N-S number will need to obtain one before completing registration.

Google has added a pre-submission requirement specifically for organizations: developer account information must be current and consistent with the details on their Dun & Bradstreet profile. This is part of a broader set of steps developers must complete before submitting an app. Organizations with outdated or mismatched D&B profiles risk submission failures or rejections.

Google has formally listed uploading a privacy policy and completing the Data Safety section as mandatory steps before submitting an app. These have been enforced in practice, but are now explicitly codified as pre-submission requirements. Apps missing either element are at risk of rejection, so developers should treat both as non-negotiable before submission.

Google has added an explicit requirement to provide an active demo account, login credentials, and any other resources (such as QR codes) needed for Google Play reviewers to access and test the app. This formalizes what was previously implicit review preparation. Developers with apps behind authentication must ensure reviewers can fully access their app or risk delays and rejections.

Google Play previously required that Indian personal loan apps hold a valid license and appear on the Reserve Bank of India's list of Digital Lending Apps deployed by Regulated Entities before being eligible for review. This India-specific rule has been removed from the policy. Developers targeting India with personal loan apps should verify whether this requirement now lives in a separate Help Center article or has been fully retired.

Google Play previously required Indonesian apps engaged in OJK-regulated IT-based money lending services (per OJK Regulation No. 77/POJK.01/2016) to submit a valid license copy for review. This country-specific requirement has been removed. Indonesian fintech lending developers should confirm whether this has been consolidated elsewhere or whether the Play Store is no longer independently gating these apps on OJK licensing.

Google Play previously required all Philippine financing and lending companies offering loans via Online Lending Platforms to obtain and hold a valid SEC Registration Number and Certificate of Authority from the Philippines Securities and Exchange Commission. This requirement has been removed from the policy. Philippine lending app developers should verify whether these obligations have moved to another policy section or are no longer enforced at the Play Store level.

Google Play previously required Philippine apps engaged in lending-based crowdfunding or peer-to-peer lending (as defined under the Philippines CF Rules) to process all transactions through PSEC-registered crowdfunding intermediaries. This rule has been removed entirely. Developers building P2P or crowdfunding lending products for the Philippine market should still comply with local regulations but no longer face this specific Play Store gating requirement.

Google Play previously required Nigerian Digital Money Lenders to complete the FCCPC's Limited Interim Regulatory/Registration Framework and Guidelines for Digital Lending (2022) and obtain a verifiable FCCPC approval letter before being listed on Play. This country-specific requirement has been removed. Nigerian fintech lending developers should confirm whether this has been relocated in Play policy or if Play Store enforcement of FCCPC registration is no longer in scope.

Google previously required developers offering or facilitating digital lending services in Pakistan to submit proof of approval from the Securities and Exchange Commission of Pakistan (SECP). This documentation requirement has been removed from the Play Store policy. Developers targeting Pakistan with lending apps no longer need to provide SECP approval evidence to Google, though SECP compliance remains a separate legal obligation.

Google's policy previously prohibited short-term loan apps targeting Pakistan, with a narrow exception for cases explicitly permitted by Pakistani law and regulations. This prohibition and its exception have been removed from the policy. Developers considering short-term lending apps for Pakistan should still assess local regulatory requirements, but the Play Store-level ban is no longer in effect.

Google previously required personal loan apps targeting Thailand with interest rates at or above 15% to hold a valid license from the Bank of Thailand (BoT) or the Ministry of Finance (MoF). This licensing requirement has been removed from the Play Store policy. Developers operating Thailand-targeted lending apps should still verify their obligations under Thai financial regulations, but the explicit Play-side enforcement of this threshold is no longer present.

Previously, Google explicitly prohibited apps in the United States that offered personal loans with an APR of 36% or higher, and required all such apps to display their maximum APR calculated in line with the Truth in Lending Act (TILA). This policy covered direct lenders, lead generators, and apps connecting users to third-party lenders. With this rule removed, high-APR personal loan apps are no longer categorically banned under this specific policy, though developers should monitor whether related financial services policies still apply to their use case.

The opening statement referencing an effective date of May 27, 2026 and the 'world's most trusted source for apps and games' motivational preamble has been removed. This text served as a forward-looking notice for an upcoming policy revision cycle. Its removal may indicate the policy has been restructured or the effective date language is no longer applicable. Developers should check for accompanying policy updates that may have replaced or superseded this transition notice.

The policy previously included a specific benchmark stating that a reasonable EWA fee would be in the range of $1–$5 per transaction or 1–5% of the advance, described as minimal and transparent. This concrete reference range has been removed. Developers previously used this benchmark to validate their pricing as policy-compliant. Without it, there is no longer an explicit fee ceiling or reasonableness standard in the policy text.

Previously, personal loan apps were required to disclose a representative example of the total loan cost, including principal and all applicable fees, in their app metadata. This requirement has been removed from the policy. Developers of loan apps should verify whether equivalent disclosure obligations still exist elsewhere in the updated policy or under applicable local regulations.

The policy previously explicitly required personal loan apps to include a privacy policy that comprehensively disclosed how personal and sensitive user data is accessed, collected, used, and shared. This specific requirement has been removed. Note that broader privacy policy requirements may still apply under Google's general data safety and privacy policies, so developers should not assume privacy policy obligations have been eliminated entirely.

Previously, Google required that a verifiable connection exist between a developer's account and any licenses or documentation proving the developer's authority to service personal loans. This verification requirement has been removed from the policy. Developers in the lending space should still maintain valid licenses as required by law, but this particular Play Store enforcement mechanism is no longer stated.

The policy previously reserved the right to request additional information or documents to confirm a developer's compliance with local laws and regulations. This clause has been removed. While Google retains broad enforcement rights under other policy sections, this explicit documentation-request provision for loan apps is no longer present.

The policy previously contained an explicit statement clarifying that personal loan rules apply to apps offering loans directly, lead generators, and apps connecting consumers with third-party lenders. This scoping sentence has been removed. Developers in the lending space should verify whether this reflects a broader restructuring of the personal loan policy section rather than a relaxation of requirements, as the underlying rules may still apply elsewhere.

Google's policy previously included an explicit statement requiring developers to ensure that any third-party code (such as SDKs) used in their app, and that third party's user data practices, comply with Google Play Developer Program policies including use and disclosure requirements. This statement has been removed. While the underlying expectation likely remains enforced through other policy sections, developers relying on this text for SDK compliance guidance should review the current SDK-specific policies to confirm their obligations.

The policy previously contained a direct instruction telling developers they must complete the content rating questionnaire for every new app submission and all existing active apps to avoid an 'Unrated' label. This instructional text has been removed. The underlying requirement to rate apps almost certainly still exists and is enforced through Play Console, but developers should refer to updated Help Center documentation for current guidance on the content rating process.

The policy previously included concrete examples of minimum functionality violations—such as text-only apps, single wallpaper apps, and non-functional apps—as well as a statement prohibiting apps that crash, force close, or freeze. These examples and the broken functionality statement have been removed. The core rules likely remain enforced, but developers building simple or utility-style apps should verify current minimum functionality standards in the updated policy to ensure compliance.

Previously, the policy explicitly required developers offering financial products and services — such as banking, loans, stock trading, crypto wallets, and exchanges — to register as an Organization account in Play Console. This specific mandate has been removed from the policy text. Developers in these categories should verify whether equivalent guidance has been relocated elsewhere in the updated policy, as the underlying intent may still be enforced.

The policy previously listed explicit requirements for what information developers must accurately provide when creating a Play Console account, including legal name, address, D-U-N-S number (for organizations), contact details, payment methods, and linked Google payment profiles. This detailed checklist has been removed. Developers should check whether these requirements have been moved to another section or whether the registration flow itself now enforces them implicitly.

Google has added a new introductory statement to the Developer Program Policy establishing an effective date of July 15, 2026 (unless otherwise stated) and framing the policy around building a trusted app ecosystem. This is contextual framing rather than a specific technical requirement. However, the explicit effective date is significant: it signals that upcoming policy changes — including others in this batch — take effect on that date, giving developers a clear compliance deadline.

Google has introduced a new defined category — Earned Wage Access (EWA) — covering financial services that let workers access already-earned but unpaid wages before payday. By formally defining EWA, Google is signaling that these apps will be subject to specific policy treatment distinct from traditional personal loan apps. Developers building EWA products should review the full associated policy section closely to understand any disclosure, category, or eligibility requirements that apply.

Google has provided explicit guidance on what constitutes a 'reasonable' EWA fee: approximately $1–$5 per transaction or 1–5% of the advance amount. The fee must be minimal, transparent, and reflect the actual cost of providing the service. Developers charging fees outside this range may face scrutiny and should be prepared to justify their pricing against this benchmark.

Google's new EWA definition includes a 'No Debt Creation' characteristic, specifying that EWA transactions should not be reported to credit bureaus and should not affect the user's credit score or contribute to long-term debt. While described as typical rather than strictly mandatory, this sets a strong compliance expectation. Developers integrating credit reporting or bureau data sharing into EWA products should reconsider those features.

New text has been added stressing that choosing the correct developer account type and completing verification are essential for a smooth onboarding experience. Previously, this explicit framing was absent. Developers should pay attention as incorrect account type selection could delay or complicate their ability to publish apps on Google Play.

A numbered list item (1.2) has been added as part of the new Organization account registration requirements, indicating an additional category of services that must register as an Organization. The specific content of this category is not yet visible in the provided change data. Developers should monitor for the full policy text to determine if their app category is affected.

A numbered list item (1.3) has been added as part of the expanded Organization account registration requirements, indicating a third category of services subject to this rule. The specific content of this item is not yet visible in the provided change data. Developers should review the full updated policy to check whether their service type falls under this requirement.

A fourth numbered category (1.4) has been added to the list of service types required to register as an Organization developer account. The specific content of this item is not yet captured in the provided change data. Developers should consult the full updated policy to identify all affected service categories.

New policy text introduces a set of requirements (starting with item 2.1) that all developers must fulfill after selecting their account type. This marks the beginning of a structured compliance checklist within the onboarding policy. Developers of all types — not just Organizations — should review these new obligations to ensure their account setup meets the updated requirements.

Google has explicitly added contact email address and phone number as required fields for developer accounts. Previously this requirement may not have been formally listed in policy. Developers should ensure their account has accurate, reachable contact details to avoid compliance issues or account flags.

Google has formally listed the developer-facing email address and phone number displayed on Google Play as required account information. This distinguishes the public-facing contact details from internal account contact info. Developers should verify that the contact information visible to users on their Play Store listing is accurate and up to date where applicable.

Google has added payment methods as a named requirement in developer account information. This applies where relevant, such as when developers sell paid apps or in-app purchases. Developers should ensure valid, up-to-date payment information is on file to remain compliant and avoid disruptions.

Google has added an explicit requirement that developers link a Google payment profile to their developer account. This was likely already a practical necessity for monetizing apps, but it is now formally codified in policy. Developers who have not linked a payment profile should do so to ensure their account is fully compliant.

Google has explicitly added the requirement that all app information and metadata must be accurately provided before submission. While this expectation existed in practice, it is now formally enumerated as a pre-submission checklist item. Developers should double-check titles, descriptions, screenshots, and other metadata for accuracy before submitting.

Google has removed the policy that required personal loan apps targeting certain listed countries to comply with additional requirements and provide supplementary documentation via the Financial features declaration in Play Console. Developers with personal loan apps in those regions should check whether any related country-specific guidance still exists elsewhere, as the removal of this explicit requirement may reflect a policy restructuring rather than a relaxation of standards.

Google Play previously stated that apps providing Earned Wage Access (EWA) loans are subject to country-specific requirements where applicable. This clause has been removed entirely. Developers of EWA loan apps should monitor whether this content has migrated elsewhere in the policy or whether Google is relaxing country-level enforcement criteria for EWA products.

Google Play previously reserved the right to request additional information or documents from lending app developers to verify regulatory and licensing compliance. This requirement has been removed from the policy. While this may reduce compliance documentation burden in practice, developers should not assume Google has abandoned enforcement — the underlying expectation of legal compliance likely remains.

Previously, Indian apps that acted solely as platforms facilitating lending by registered NBFCs or banks (rather than lending directly) were required to accurately reflect that intermediary role in their Google Play declaration. This requirement has been removed. Developers operating such platforms in India should still ensure their app descriptions and declarations are accurate, but this specific policy hook is no longer present.

Google Play previously required Indian lending platform apps to prominently list the names of all registered NBFCs and banks they partner with directly in the app's Play Store description. This disclosure requirement has been removed from the policy. Developers should note that transparency obligations under Indian financial regulations may still apply independently of this Play Store rule.

Previously, Philippine lending apps were required to display their Corporate Name, Business Name, PSEC Registration Number, and Certificate of Authority number directly in the app's Play Store description. This disclosure requirement has been removed. While local regulatory obligations in the Philippines may still mandate such disclosures within the app itself, this Play Store-level enforcement mechanism is gone.

Previously, Loan Aggregators targeting certain regions were required to provide documentation, certification for digital lending services, and contact details for every partnered Digital Money Lender (DML). This requirement has been removed from the policy. Developers who previously complied with this rule should note that this specific obligation no longer appears in the guidelines, though regional lending regulations may still apply outside of Google's policy.

Google previously required Kenya-targeted Digital Credit Providers (DCPs) to complete the DCP registration process and obtain a license from the Central Bank of Kenya (CBK). This requirement has been removed from the Play policy. Developers operating in Kenya should be aware that while this Google-specific policy rule is gone, compliance with CBK regulations remains a legal obligation independent of Play Store requirements.

Google's policy previously mandated that Kenya-based Digital Credit Providers submit a copy of their Central Bank of Kenya (CBK) license as part of their app declaration. This submission requirement has been dropped from the policy. Developers who built compliance workflows around this step should update their processes, though the underlying CBK licensing obligation remains a legal matter separate from Play Store policy.

Developers who provided a platform to facilitate lending by registered DCPs (rather than lending directly) were previously required to accurately reflect that role in their declaration and submit their partner DCPs' licenses. This requirement has been removed from Google's policy. Platform-based lending app developers in Kenya no longer face this specific Google-side documentation obligation, though legal compliance with CBK rules remains unchanged.

Google previously only accepted declarations and licenses from entities listed in the Central Bank of Kenya's official Directory of Digital Credit Providers. This restriction has been removed from the policy. Developers targeting Kenya with lending apps should note that the Play-side enforcement of the CBK directory listing is no longer an explicit policy requirement.

Google's policy previously restricted each Non-Banking Finance Company (NBFC) lender in Pakistan to publishing only a single Digital Lending App (DLA) on the Play Store. This one-app-per-NBFC rule has been removed. Developers and NBFCs in Pakistan should note this constraint is no longer enforced at the policy level, though local regulatory requirements from SECP may still govern how many apps an NBFC can operate.

Previously, Google explicitly warned that developers publishing more than one Digital Lending App per NBFC in Pakistan risked termination of their developer account and associated accounts. This enforcement language has been removed alongside the underlying one-app-per-NBFC rule. Developers who structured their Pakistan lending app strategy around this restriction should be aware the explicit penalty clause no longer exists in the policy.

Removed content in Country specific requirements

Removed content in Country specific requirements

Removed content in Country specific requirements

Removed content in Country specific requirements

Removed content in Country specific requirements

Removed content in Country specific requirements

Removed content in Country specific requirements

Moved content in Earned Wage Access

Moved content in General Requirements

Moved content in 1. Misleading Claims

The policy previously directed developers to the Help Center for information about regional rating authorities and how to complete the content rating questionnaire. This informational reference has been removed. Developers new to the content rating process may find it harder to locate guidance directly from the policy page and should proactively search the Play Console Help Center for current rating instructions.

A sentence pointing developers to information about what data is displayed on Google Play has been removed. This was a navigational reference rather than a substantive policy requirement. Developers seeking information about Play Store listing display behavior should consult the Help Center directly, as this change has minimal impact on compliance obligations.

Google removed a brief introductory sentence that framed account type selection and verification as key to smooth onboarding. This was purely contextual framing with no requirements attached. Developers are not affected by any change in rules, but the removal signals a restructuring of the onboarding guidance section.

A standalone numbered list marker '1.' has been added to the Developer Program Policy. This appears to be a structural/formatting addition likely introducing a new numbered list. On its own it carries no substantive meaning, but it signals new list-based content is being introduced in this section.

A standalone numbered list marker '2.' has been added to the Developer Program Policy. Like index 60, this is a structural element that forms part of a new numbered list being introduced. It has no standalone policy meaning but is part of broader structural changes.

A standalone numbered list marker '3.' has been added to the Developer Program Policy. This continues the numbered list structure being added across several indices. It has no standalone policy meaning in isolation.

A standalone numbered list marker '4.' has been added to the Developer Program Policy. This is another structural list element forming part of the new numbered list. No standalone policy meaning in isolation.

A standalone numbered list marker '5.' has been added to the Developer Program Policy. This completes a set of five numbered list markers added across indices 60–64. No standalone policy meaning in isolation, but context from surrounding additions is needed for full interpretation.

Google has added a reference directing developers to the Help Center for more information about the content rating questionnaire, including details on regional rating authorities. This is informational and supplements the new requirement added at index 65. Developers unfamiliar with how ratings vary by region should consult the Help Center to ensure compliance across all markets where their app is distributed.

Another standalone numbered list marker '1.' has been added, suggesting the start of a new nested or separate numbered list within the Developer Program Policy. On its own it carries no policy meaning, but in context with index 68 it introduces a list of minimum functionality violation examples.

A new informational reference has been added directing developers to learn about what information is displayed on Google Play. There was no prior equivalent link in this section. While this is primarily a navigational aid, it signals that Google Play is surfacing more transparency around store listing data, which developers should review to ensure their displayed information is accurate.