SERVICE-SPECIFIC TERMS OF USE

Preamble

This document (“Service-Specific Terms”) sets out the operational rules, eligibility conditions, partner obligations, liability boundaries, and compliance requirements specific to each of Fingpay’s three core service lines: Cash Management Services (Part A), Payment Aggregator Services (Part B), and Business Correspondent Services (Part C). It is published by Tapits Technologies Pvt. Ltd. (“Fingpay”, “we”, “us”, or “our”), an RBI-authorised Payment Aggregator, having its registered office at 20 Dhenu Market, Indore – 452003, Madhya Pradesh, India.

(a) Scope. This document governs service-specific terms only. It does not purport to be a complete statement of the legal relationship between Fingpay and its partners, merchants, or users.

(b) Suite of Documents. These Service-Specific Terms must be read alongside Fingpay’s Privacy Policy, Terms and Conditions, and Website Terms of Use, each of which forms part of Fingpay’s overall legal framework. Together, these documents constitute the binding agreement between Fingpay and the relevant partner or user. In the event of any conflict between these Service-Specific Terms and the general Terms and Conditions on a matter that is specific to a particular service line, these Service-Specific Terms shall prevail for that service-specific matter.

(c) Defined Terms. Capitalised terms used but not defined in these Service-Specific Terms carry the meanings ascribed to them in Fingpay’s Terms and Conditions. References to specific sections (e.g., “Section 6 of the Terms and Conditions”) are cross-references to the corresponding section of that document and are not reproduced here.

(d) Regulatory Framework. Fingpay’s services are governed by the Payment and Settlement Systems Act, 2007, the RBI Master Directions on Payment Aggregators and Payment Gateways, RBI Master Direction on Business Correspondents, NPCI operational circulars, the Aadhaar Act, 2016, the DPDP Act, 2023, and other applicable Indian law. Nothing in these Service-Specific Terms shall be construed to derogate from Fingpay’s or any partner’s obligations under applicable law and regulation.

PART A — CASH MANAGEMENT SERVICES (CMS) TERMS

Fingpay’s Cash Management Services (“CMS”) enable BFSI institutions, MFIs, NBFCs, and corporate enterprises to collect field cash efficiently through a nationwide network of over 8 lakh Fingpay-authorised merchant points spanning 18,000+ pincodes. The service provides same-day settlements, GPS and geo-fenced cash drop tracking, tokenized and bulk deposit options, and real-time reconciliation — bringing transparency and operational control to last-mile cash collection. Part A governs the specific operational terms applicable to CMS partners and their field agents.

A.1 Scope of CMS Services

Fingpay’s CMS encompasses the following service elements:

• Physical cash pickup and deposit by field agents of the CMS partner at Fingpay-authorised CMS merchant points.
• End-to-end tracking of each cash deposit event from field collection through to bank account credit.
• Issuance of digital acknowledgements for each accepted cash deposit, serving as the primary record of deposit.
• Tokenized deposit facilities enabling field agents to initiate deposits against pre-generated deposit tokens, and bulk deposit facilities for high-volume collection scenarios.
• GPS and geo-fencing-based audit trails capturing the location of each cash drop event for verification and reconciliation purposes.
• Real-time reconciliation dashboards accessible by the CMS partner for monitoring collection activity.
• Same-day settlement of accepted deposits to the CMS partner’s designated bank account, subject to the conditions set out in Section A.7.

A.2 CMS Partner Eligibility and Onboarding

A.2.1 Eligible Entities. The CMS service is available exclusively to the following categories of entities (“CMS Partners”):

• Scheduled commercial banks, small finance banks, payment banks, and other regulated banking entities.
• Non-Banking Financial Companies (NBFCs) registered with the RBI.
• Microfinance Institutions (MFIs), whether incorporated as NBFCs, Section 8 companies, societies, or trusts, operating under applicable RBI or state regulatory frameworks.
• Corporate enterprises engaged in high-volume field cash collection as part of their business operations, subject to Fingpay’s assessment.

A.2.2 Onboarding Requirements. Prospective CMS partners must submit the following documentation and satisfy the following conditions as part of the onboarding process:

• Certificate of Incorporation or equivalent constitutional document.
• Valid registration or licence issued by the applicable regulator (RBI, MCA, or state authority, as applicable).
• KYC documentation for authorised signatories and beneficial owners as required under applicable AML/CFT regulations.
• Execution of a separate CMS Partner Agreement (in addition to Fingpay’s general Terms and Conditions), which sets out the commercial terms, volume commitments, SLAs, and operational protocols specific to the CMS engagement.
• Such additional documentation or declarations as Fingpay may specify from time to time in its onboarding guidelines.

A.2.3 Approval Discretion. Fingpay reserves the right to approve or reject any CMS partner application at its sole discretion, without being required to assign reasons. Acceptance of documentation does not constitute approval. Onboarding is complete only upon Fingpay’s express written confirmation and the execution of the CMS Partner Agreement.

A.3 Authorised CMS Points and Network

A.3.1 Authorised Points Only. Cash deposits under the CMS service may be made only at merchant locations that are specifically designated and authorised by Fingpay as CMS merchant points. A list of authorised CMS points or a means to verify the authorisation status of a CMS point will be made available to CMS partners through the Fingpay platform or partner portal.

A.3.2 CMS Partner Responsibility. The CMS partner is solely responsible for directing its field agents to authorised CMS points. Deposits made at locations that are not authorised CMS points will not be processed by Fingpay and will not be eligible for digital acknowledgement or settlement.

A.3.3 Network Changes. Fingpay does not guarantee the availability of a CMS point at any specific location or at any specific time. The CMS network may be updated, expanded, modified, or contracted by Fingpay at any time without prior notice to the CMS partner. Fingpay shall use reasonable commercial efforts to maintain network adequacy but bears no liability for disruptions arising from network changes.

A.4 Cash Deposit Procedures and Limits

A.4.1 Deposit Methods. Fingpay supports the following deposit methods under CMS:

• Tokenized Deposit: The field agent presents a pre-generated deposit token (issued through the Fingpay platform or partner system) at an authorised CMS point. The CMS merchant scans or enters the token to initiate the deposit. No deposit shall be accepted without a valid token.
• Bulk Deposit: Available to CMS partners with high-volume collection requirements. Bulk deposit procedures, documentation requirements, and verification protocols are set out in the CMS Partner Agreement.

A.4.2 Transaction Limits. Per-deposit, per-agent, and per-day transaction limits applicable to CMS operations will be communicated by Fingpay to the CMS partner at the time of onboarding or as updated from time to time. These limits may be set by Fingpay in accordance with applicable RBI guidelines, risk parameters, and network integrity considerations.

A.4.3 CMS Partner’s Responsibility for Compliance. The CMS partner is responsible for ensuring that its field agents are aware of and comply with all applicable deposit procedures and limits. Deposits that do not comply with prescribed procedures or that exceed applicable limits may be rejected at the point of deposit or held by Fingpay for verification before processing. Fingpay bears no liability for delays or losses arising from non-compliant deposits.

A.5 Digital Acknowledgement and Proof of Deposit

A.5.1 Issuance. Upon successful acceptance of a cash deposit at an authorised CMS point, Fingpay will issue a digital acknowledgement to the depositing field agent and/or to the CMS partner’s portal. The digital acknowledgement will contain a unique transaction reference number, the amount deposited, the date, time, and location of the deposit, and the identity of the depositing agent (where recorded).

A.5.2 Primary Record. The digital acknowledgement issued by Fingpay constitutes the primary and authoritative record of a cash deposit under the CMS service. No physical receipt, handwritten voucher, or other document shall take precedence over the digital acknowledgement for the purposes of settlement, reconciliation, or dispute resolution.

A.5.3 Reconciliation Obligation. The CMS partner must ensure that its field agents retain access to or copies of all digital acknowledgements. The CMS partner must reconcile digital acknowledgements against its own collection records on a daily basis.

A.5.4 Disputes. Any dispute regarding a cash deposit — including disputes regarding the amount, acceptance, or non-issuance of an acknowledgement — must be supported by the relevant digital acknowledgement reference number (or evidence of the absence of an acknowledgement where the dispute relates to a rejected deposit). Disputes raised without the requisite reference information may not be processed.

A.6 GPS, Geo-Fencing, and Location Data

A.6.1 Technology. CMS transactions are tracked using GPS and geo-fencing technology embedded in Fingpay’s platform and/or the devices used at CMS merchant points. Each cash drop event triggers the capture of location data to create an audit trail.

A.6.2 Consent. By accessing and using the CMS service, the CMS partner — on its own behalf and on behalf of its field agents — consents to the capture and retention of GPS and geo-fencing data for each cash drop event. This consent is a condition of using the CMS service. Location data is used exclusively for audit, reconciliation, fraud prevention, and regulatory compliance purposes.

A.6.3 Privacy. Location data collected through CMS operations is handled in accordance with Fingpay’s Privacy Policy, which is incorporated into these Service-Specific Terms by reference.

A.6.4 Technology Limitations. Fingpay is not responsible for GPS inaccuracies, geo-fence discrepancies, or location data gaps caused by device limitations, network outages, or environmental factors beyond Fingpay’s control. Such inaccuracies shall not, by themselves, invalidate a deposit that has otherwise been processed and acknowledged.

A.7 Settlement Under CMS

A.7.1 Same-Day Settlement. Subject to the conditions below, Fingpay will settle deposits accepted on a given business day to the CMS partner’s designated bank account on the same business day or as otherwise specified in the CMS Partner Agreement.

A.7.2 Settlement Conditions. Same-day settlement is contingent upon: (a) successful completion of the deposit at an authorised CMS point with a valid digital acknowledgement; (b) reconciliation by Fingpay of the deposited amount against the relevant deposit token or bulk deposit manifest; and (c) the absence of any verification hold, regulatory directive, or fraud flag applicable to the relevant transaction or CMS partner account.

A.7.3 Settlement Delays. Fingpay may delay settlement in the following circumstances:

• Reconciliation discrepancies requiring investigation.
• Verification holds triggered by risk management systems or compliance reviews.
• Directions from the RBI, NPCI, law enforcement, or any other competent authority.
• Force majeure events (as defined in the Terms and Conditions).
• Suspected fraud or non-compliance by the CMS partner or its field agents, pending investigation.

A.7.4 Withholding. Fingpay reserves the right to withhold settlement, in whole or in part, where it has reasonable grounds to suspect fraud, AML violations, or material breach of the CMS terms by the CMS partner or its agents. Any withheld amounts will be dealt with in accordance with applicable regulatory requirements.

Cross-Reference: General settlement terms, including standard settlement mechanics, banking cut-offs, and the treatment of failed credits, are governed by Section 6 of Fingpay’s Terms and Conditions.

A.8 Cash In Transit Liability

A.8.1 Fingpay’s Responsibility. Fingpay’s liability in respect of cash handled through the CMS service commences only at the point at which cash has been physically deposited at an authorised CMS merchant point and a valid digital acknowledgement has been issued by Fingpay for that deposit.

A.8.2 Pre-Deposit Risk. Fingpay bears no liability whatsoever for cash that is: (a) in transit between the point of collection and the authorised CMS merchant point; (b) lost, stolen, or misappropriated prior to deposit; (c) deposited at a location that is not an authorised CMS point; or (d) deposited without a valid deposit token (in the case of tokenized deposits).

A.8.3 CMS Partner’s Responsibility. The CMS partner is solely responsible for the safety, security, and integrity of all cash held by or in transit with its field agents prior to deposit at an authorised CMS point. The CMS partner bears all risk of loss, theft, damage, or misappropriation of cash prior to the issuance of a digital acknowledgement by Fingpay.

A.8.4 Insurance. The CMS partner must at all times maintain adequate cash-in-transit insurance and fidelity/employee dishonesty insurance covering its field cash collection operations. Evidence of such insurance must be provided to Fingpay upon request.

A.9 Reconciliation And Dispute Resolution For CMS

A.9.1 Daily Reconciliation. Fingpay will make available to the CMS partner, through the Fingpay partner portal or dashboard, a daily reconciliation report setting out all CMS transactions processed on the preceding business day. The CMS partner must review and reconcile this report against its own collection records within the business day of receipt.

A.9.2 Reporting Discrepancies. Any discrepancy identified by the CMS partner must be reported to Fingpay through the designated dispute reporting channel (as specified on the Fingpay portal or in the CMS Partner Agreement) within the period specified by Fingpay, which shall not be less than the period mandated by applicable RBI or NPCI guidelines. Discrepancies reported after the applicable deadline may not be eligible for investigation or redressal.

A.9.3 Investigation Process. Upon receipt of a valid dispute report supported by the relevant digital acknowledgement reference, Fingpay will investigate the discrepancy within the timelines specified in the CMS Partner Agreement. Fingpay may request additional documentation from the CMS partner or its agents during the investigation.

A.9.4 Resolution Outcomes. Following investigation, Fingpay will notify the CMS partner of the outcome. If the discrepancy is found in favour of the CMS partner, Fingpay will credit the differential amount in the next available settlement cycle. If the discrepancy is found against the CMS partner, or if the investigation is inconclusive due to insufficient documentation, Fingpay’s determination shall be final subject to any escalation rights available to the CMS partner under the CMS Partner Agreement.

A.9.5 Unresolved Discrepancies. Where a discrepancy remains unresolved beyond the period specified in the CMS Partner Agreement, either party may escalate the matter in accordance with the dispute resolution mechanism set out in the Terms and Conditions.

A.10 CMS Partner Obligations

In addition to the general obligations set out in the Terms and Conditions, each CMS partner undertakes to:

• Train all field agents on CMS procedures, deposit protocols, deposit limits, and the proper use of deposit tokens before deploying those agents for CMS collection activity.
• Ensure that each field agent carries a valid Fingpay-issued or Fingpay-approved authorisation credential during cash deposit activities, and that agents can produce this credential upon request at a CMS merchant point.
• Not instruct, permit, or facilitate cash deposits at locations that are not authorised CMS points.
• Promptly report any security incident, suspected fraud, misappropriation of cash, or discrepancy to Fingpay within 24 hours of discovery.
• Maintain accurate, complete, and auditable records of all cash collection activities, including collection amounts, agent identities, collection locations, deposit timestamps, and digital acknowledgement references, for the retention period specified in the CMS Partner Agreement or applicable law, whichever is longer.
• Implement and maintain internal controls and supervision processes adequate to detect and deter fraud, misappropriation, and non-compliance by field agents.
• Comply at all times with applicable AML, CFT, and KYC requirements in connection with cash collected and deposited through the CMS service, including maintaining required records of cash transactions and reporting suspicious transactions to the appropriate Financial Intelligence Unit in accordance with the Prevention of Money Laundering Act, 2002.
• Cooperate fully with any audit or investigation conducted by Fingpay or any regulatory authority in connection with CMS operations.

A.11 Suspension and Termination of CMS Services

A.11.1 Grounds for Suspension or Termination. Fingpay may suspend or terminate CMS services to a CMS partner, in whole or in part, in the following circumstances:

• Material breach of any provision of these CMS Terms or the CMS Partner Agreement, including repeated non-compliance with deposit procedures or limits.
• Credible evidence of fraud, misappropriation, or money laundering involving the CMS partner, its agents, or its operations.
• Direction, instruction, or order from the RBI, NPCI, law enforcement, or any other competent regulatory or judicial authority.
• Actions or omissions by the CMS partner or its agents that, in Fingpay’s reasonable assessment, pose a risk to the integrity, security, or reputation of the CMS network.
• Insolvency, winding up, or other material adverse change in the financial condition of the CMS partner.

A.11.2 Notice. Where practicable and not restricted by regulatory direction or risk considerations, Fingpay will provide the CMS partner with reasonable advance notice of suspension or termination and an opportunity to remedy the breach (if remediable). In cases involving fraud, regulatory direction, or imminent risk to network integrity, suspension may be effected immediately without prior notice.

A.11.3 Pending Settlements. Upon termination, Fingpay will process pending settlements in respect of deposits for which valid digital acknowledgements have already been issued, subject to any verification holds, regulatory requirements, or fraud investigations that may be ongoing at the time of termination. No new deposits will be accepted after the effective date of termination.

PART B — PAYMENT AGGREGATOR (PA) TERMS

Fingpay is an RBI-authorised Payment Aggregator facilitating the acceptance, routing, and settlement of digital payment transactions for merchants across India. Fingpay’s PA services span UPI intent and collect flows, Payment Gateway services (cards, net banking, wallets, mandates), Bharat Bill Payment System (BBPS) bill collection, virtual account issuance, UPI QR and dynamic QR collections, payment link generation, and BHIM Aadhaar Pay. Part B governs the specific terms applicable to merchants and partners using Fingpay’s PA platform.

B.1 Scope of PA Services

Fingpay’s Payment Aggregator services include:

• Acceptance and routing of digital payment transactions across multiple payment instruments including UPI, cards (debit, credit, prepaid), net banking, wallets, and mandates.
• Settlement of transaction proceeds to merchants in accordance with agreed timelines and subject to applicable deductions.
• UPI intent, collect, and QR-based payment collection, including static and dynamic QR codes, UPI AutoPay, and mandate-based recurring collections.
• Payment Gateway services enabling card, net banking, wallet, and EMI transactions on merchant websites and applications.
• BBPS-based bill payment facilitation for registered billers in eligible categories.
• Virtual account creation and management for NEFT, RTGS, and IMPS-based collections.
• Payment link generation enabling merchants to send payment requests to customers via digital channels.
• Access to the Fingpay merchant dashboard for transaction monitoring, reporting, and settlement tracking.

B.2 Merchant Onboarding under PA

B.2.1 PA-Specific Onboarding. In addition to the general registration and account creation requirements in the Terms and Conditions, merchants seeking to use Fingpay’s PA platform must complete the following PA-specific onboarding steps:

• Submission of business verification documents including Certificate of Incorporation (or equivalent), GST registration, and proof of business address.
• KYC documentation for the entity’s authorised signatories and, for high-risk categories or categories specified by Fingpay, for beneficial owners meeting applicable ownership thresholds.
• Merchant Category Code (MCC) assignment: Fingpay will assign an appropriate MCC to the merchant based on the nature of the merchant’s business. The MCC determines applicable transaction routing, limits, and card network rules. Merchants must accurately describe their business activity and must not misrepresent their business category to obtain a more favourable MCC.
• Completion of RBI-mandated due diligence, including verification of the merchant’s website, app, or point-of-sale against the declared business activity.

B.2.2 Enhanced Due Diligence. For merchants in high-risk categories (as designated by Fingpay, card networks, or applicable RBI guidelines), Fingpay may conduct enhanced due diligence including additional document verification, site visits, reference checks, or enhanced monitoring post-onboarding. Fingpay’s determination of whether a merchant falls into a high-risk category is final.

B.2.3 Right to Decline. Fingpay reserves the right to decline any merchant onboarding application at its sole discretion, without providing reasons, and this right is not subject to any appeal or review by the applicant.

B.2.4 Ongoing Monitoring. Post-onboarding, Fingpay will conduct ongoing monitoring of merchant transaction patterns, chargeback rates, and business activity in accordance with RBI requirements applicable to Payment Aggregators. Fingpay may, at any time, require a merchant to resubmit or update its onboarding documentation or to undergo additional due diligence.

B.3 Escrow and Nodal Account Mechanism

B.3.1 Nodal/Escrow Account. As an RBI-authorised Payment Aggregator, Fingpay holds all merchant funds collected through its PA platform in an RBI-designated nodal/escrow account prior to settlement to the merchant. This mechanism is mandated by the RBI’s Master Directions on Payment Aggregators and ensures separation of merchant funds from Fingpay’s own operational funds.

B.3.2 Merchant Funds are Not Fingpay’s Funds. Amounts held in the nodal/escrow account pending settlement are merchant funds and do not constitute Fingpay’s own assets. Fingpay shall not commingle merchant funds with its own operational funds, and the nodal/escrow account shall not be used to fund Fingpay’s own business operations.

B.3.3 Regulatory Compliance. The operation, maintenance, and utilisation of the nodal/escrow account are governed by applicable RBI guidelines on Payment Aggregators, as amended from time to time. The nodal/escrow mechanism does not constitute a deposit-taking arrangement, and merchants do not earn any interest on funds held in the nodal/escrow account pending settlement.

Note: The nodal/escrow account mechanism does not guarantee settlement in the event of fraud, Chargeback, regulatory action, or any other circumstance that gives Fingpay a right to withhold or reverse settlement under these terms or the Terms and Conditions.

B.4 UPI and QR Services

B.4.1 UPI Transaction Types. Fingpay supports the following UPI transaction flows on its PA platform:

• UPI Intent: The customer initiates payment through a UPI-enabled app which is deep-linked by the merchant’s checkout.
• UPI Collect: Fingpay (on behalf of the merchant) initiates a collect request to the customer’s VPA; acceptance by the customer completes the transaction.
• UPI QR: Static QR codes assigned to the merchant’s VPA for over-the-counter payments; and dynamic QR codes generated per transaction for specific payment amounts.
• UPI AutoPay / Mandate: Recurring debit mandates registered on the customer’s UPI-linked bank account for subscription, EMI, or periodic payment use cases.

B.4.2 QR Integrity. The merchant is responsible for the secure display, maintenance, and integrity of all Fingpay-generated QR codes (static and dynamic) at its point of sale or on its digital platforms. Merchants must not alter, obscure, tamper with, or replace Fingpay-generated QR codes with QR codes generated by any other party. Any QR tamper event must be reported to Fingpay immediately.

B.4.3 UPI AutoPay Terms. Merchants using UPI AutoPay for recurring collections must: (a) obtain explicit, informed customer consent for each mandate registration, including the amount, frequency, and duration of the recurring debit; (b) provide customers with a clear and accessible mechanism to cancel or modify their mandates; and (c) comply with NPCI’s UPI AutoPay operational guidelines, including pre-debit notification requirements.

B.4.4 QR Misuse. Any misuse of Fingpay QR codes, including substitution, duplication, or use for unauthorised collections, constitutes a material breach of these terms and may result in immediate suspension of the merchant’s account and reporting to the relevant regulatory authorities.

B.5 Payment Gateway Services

B.5.1 Supported Instruments. Fingpay’s Payment Gateway supports card transactions (debit cards, credit cards, prepaid cards) across permitted card networks, net banking transactions with supported banks, wallet-based payments, and EMI options where applicable.

B.5.2 PCI-DSS Compliance. Merchants integrating with Fingpay’s Payment Gateway must at all times maintain compliance with the Payment Card Industry Data Security Standard (PCI-DSS) at the level appropriate to their integration type and transaction volume. Proof of current PCI-DSS compliance certification must be provided to Fingpay upon request and upon each annual renewal. Fingpay may suspend card processing for any merchant that cannot demonstrate current PCI-DSS compliance.

B.5.3 Prohibition on Card Data Storage. Merchants are strictly prohibited from storing, transmitting, or processing raw card data (including full Primary Account Numbers (PANs), CVV/CVC codes, card expiry dates in conjunction with PANs, or Track data) on their own systems in connection with Fingpay-facilitated transactions. All card data must be processed exclusively through Fingpay’s PCI-DSS certified infrastructure. Any breach of this prohibition constitutes a critical security incident and must be reported to Fingpay within 24 hours of discovery.

B.5.4 3D Secure Authentication. Card transactions processed through Fingpay’s Payment Gateway are subject to 3D Secure authentication (or equivalent cardholder authentication mechanism) as mandated by RBI and the applicable card networks. Merchants must not attempt to bypass or circumvent authentication requirements. Liability for transactions where authentication is bypassed at the merchant’s request or due to merchant-side integration failures shall rest with the merchant.

B.5.5 International Card Transactions. Where Fingpay enables acceptance of international cards, merchants must comply with applicable Foreign Exchange Management Act (FEMA) requirements, including restrictions on the categories of goods or services for which international card payments may be accepted. Merchants are responsible for ensuring that their international card acceptance complies with all applicable exchange control regulations.

B.5.6 Integration Security. Merchants are responsible for the security of their website, application, and payment integration environment, including protection against cross-site scripting, SQL injection, man-in-the-middle attacks, and other web-application vulnerabilities. Fingpay bears no liability for security breaches arising from vulnerabilities in the merchant’s own systems or integration.

B.6 BBPS (Bharat Bill Payment System) Terms

B.6.1 Fingpay’s Role. Fingpay participates in the BBPS ecosystem as a BBPS Operating Unit (BOU) or as a BBPS sub-agent, as applicable, under its authorisation from NPCI. Fingpay’s role in any specific BBPS transaction will be disclosed to the relevant biller at the time of onboarding.

B.6.2 Biller Eligibility. Entities wishing to use Fingpay’s PA platform to collect bill payments through BBPS must: (a) fall within an eligible biller category as defined and updated by NPCI; and (b) complete biller registration on the BBPS platform through Fingpay, including submission of biller details and category classification as required by NPCI’s BBPS operational framework.

B.6.3 Transaction Processing Timelines. BBPS transactions processed through Fingpay are subject to the processing timelines specified in NPCI’s operational circulars governing BBPS. Fingpay will make best efforts to communicate applicable timelines to billers at the time of onboarding, but timelines are ultimately governed by NPCI’s framework and may be updated by NPCI without prior notice.

B.6.4 Dispute Resolution. Disputes arising from BBPS transactions (including disputes regarding payment confirmation, amount mismatch, or failed bill payment) are subject to the dispute resolution framework prescribed by NPCI for BBPS. Fingpay will facilitate the biller’s participation in this process but the ultimate resolution mechanism is as prescribed by NPCI.

B.6.5 Customer Complaint Handling. Billers using Fingpay’s BBPS integration are responsible for establishing an accessible customer complaint mechanism for BBPS payment-related queries. Fingpay may be required, under NPCI guidelines, to assist in the resolution of customer complaints escalated through the BBPS grievance framework. Billers must cooperate with any such escalation process and provide Fingpay with the information required to facilitate resolution within the timelines specified by NPCI.

B.7 Virtual Accounts

B.7.1 Issuance. Fingpay may issue unique virtual account numbers (VANs) to merchants to enable collection of funds through NEFT, RTGS, and IMPS transfers from payers. Each VAN is uniquely assigned to the merchant and is used by Fingpay’s platform for automatic reconciliation of inbound transfers.

B.7.2 Auto-Reconciliation. Inbound transfers received against a merchant’s VAN are automatically reconciled to the merchant’s Fingpay account and reflected in the merchant dashboard. Reconciliation timelines are subject to interbank transfer processing timelines and NPCI settlement cycles.

B.7.3 Merchant Responsibility for Communication. The merchant is solely responsible for communicating the correct VAN to its payers. Fingpay bears no liability for transfers misdirected as a result of the merchant communicating an incorrect VAN, an outdated VAN, or a VAN not belonging to the merchant.

B.7.4 Misdirected Transfers. In the event that a transfer is received against a VAN in error, the merchant must notify Fingpay immediately. Fingpay will use reasonable commercial efforts to facilitate a return of the misdirected funds but cannot guarantee recovery and bears no liability for losses arising from misdirected transfers caused by merchant error or payer error.

B.7.5 VAN Validity and Renewal. VANs issued by Fingpay remain valid for the period specified at the time of issuance or as extended by Fingpay. Fingpay may deactivate or reassign a VAN upon termination of the merchant’s account or where the VAN has not been used for the period specified in Fingpay’s dormancy policy. The merchant will be notified in advance of VAN deactivation where practicable.

B.8 Settlement under PA

B.8.1 Settlement Cycle. Fingpay will settle transaction proceeds to the merchant’s registered bank account on a T+1 or T+2 business day settlement cycle, as agreed between Fingpay and the merchant at the time of onboarding or as specified in the Fingpay Merchant Agreement. The applicable settlement cycle will be communicated to the merchant in its Fingpay dashboard.

B.8.2 Settlement Deductions. Fingpay will deduct from settlement proceeds the following amounts before crediting the merchant:

• Fingpay’s payment processing fees and applicable taxes (GST and any other statutory levies).
• Chargeback amounts auto-debited in accordance with Section B.10 of these terms.
• Any rolling reserve amounts withheld in accordance with Section B.9.
• Any amounts recoverable by Fingpay from the merchant under the Terms and Conditions or these Service-Specific Terms.

B.8.3 Active Bank Account. Merchants must maintain an active, verified bank account registered with Fingpay for settlement. Settlement cannot be processed to an unverified or inactive bank account.

B.8.4 Bank Account Changes. Where a merchant wishes to change its registered settlement bank account, the merchant must submit the required documentation for re-verification. Settlement to the new bank account will commence only after Fingpay has completed re-verification. Fingpay may place a temporary hold on settlements during the re-verification period.

Cross-Reference: General settlement framework including settlement mechanics, banking cut-off times, and failed settlement handling are governed by Section 6 of Fingpay’s Terms and Conditions.

B.9 Merchant Reserve and Risk Holds

B.9.1 Rolling Reserve. Fingpay reserves the right to withhold a rolling reserve from the settlement proceeds of merchants that are classified as high-risk (whether due to their MCC, transaction patterns, Chargeback history, or other risk indicators). The rolling reserve operates as a financial buffer against potential Chargebacks, fraud-related losses, and other merchant-side liabilities.

B.9.2 Reserve Parameters. The percentage of settlement proceeds to be withheld as a rolling reserve, the minimum reserve floor, and the reserve holding period will be specified by Fingpay at the time of merchant onboarding or as communicated to the merchant subsequently. Fingpay may increase the reserve percentage or holding period if the merchant’s risk profile changes materially.

B.9.3 Reserve Release. Rolling reserves withheld from a merchant’s settlement proceeds will be released after the applicable holding period, subject to the following: (a) no outstanding Chargeback claims against the reserve; (b) no active fraud investigation; and (c) the merchant account being in good standing at the time of release. Reserve release timelines may be extended if any of these conditions are not met.

B.9.4 Reserve Forfeiture. Fingpay reserves the right to apply accumulated reserves against outstanding Chargeback amounts, fraud-related losses, fines imposed by card networks, and any other amounts owed by the merchant to Fingpay. Any residual reserve amount remaining after such application will be released to the merchant, subject to the conditions in B.9.3.

B.10 Chargeback Management under PA

B.10.1 Card Network Timelines. Chargeback timelines for card transactions processed through Fingpay’s PA platform are governed by the rules of the applicable card network (Visa, Mastercard, RuPay, or other applicable network). Fingpay will communicate applicable Chargeback timelines to merchants at the time of onboarding and will provide updates if card network rules change.

B.10.2 Representment Documentation. Where a merchant wishes to contest a Chargeback, the merchant must submit the following documentation to Fingpay within the representment window specified by the applicable card network:

• Proof of transaction (order confirmation, invoice, or equivalent).
• Proof of delivery or service fulfilment (tracking information, signed delivery confirmation, digital access logs, or equivalent).
• Customer communication records (where relevant to the dispute).
• Any other documentation specified by Fingpay or the card network for the specific Chargeback reason code.

B.10.3 Auto-Debit of Chargeback Amounts. Upon receipt of a Chargeback notification from the card network, Fingpay will auto-debit the Chargeback amount (including any card network-imposed fees) from the merchant’s next available settlement or from the merchant’s rolling reserve. The merchant will be notified of the auto-debit through its Fingpay dashboard.

B.10.4 Chargeback Ratio Thresholds. Where a merchant’s Chargeback ratio exceeds the threshold specified by Fingpay or the applicable card network, Fingpay may: (a) suspend the merchant’s card acceptance capability; (b) increase the merchant’s rolling reserve; or (c) terminate the merchant’s access to card payment services under the PA platform. Fingpay will use reasonable efforts to notify the merchant before implementing these measures, except where immediate action is required by the card network.

Cross-Reference: General Chargeback framework, including UPI Chargeback handling and BBPS dispute resolution, are governed by Section 6.5 of Fingpay’s Terms and Conditions.

B.11 Prohibited Merchant Categories under PA

The following merchant categories, business activities, and transaction types are strictly prohibited on Fingpay’s PA platform:

• Cryptocurrency exchanges, cryptocurrency brokers, and platforms facilitating the purchase, sale, or exchange of virtual digital assets without appropriate regulatory authorisation.
• Unlicensed digital lending platforms, peer-to-peer lending platforms without a valid NBFC-P2P licence, and entities offering credit products without the required RBI licence or registration.
• Unregulated investment schemes, collective investment schemes not registered with SEBI, and platforms offering guaranteed returns without appropriate regulatory authorisation.
• Gambling, betting, and gaming platforms where real-money gaming or sports betting is not permitted under applicable state or central legislation.
• Adult content platforms distributing pornographic or sexually explicit material.
• Entities operating pyramid schemes, multi-level marketing schemes involving illegal recruitment, or other schemes that violate the Prize Chits and Money Circulation Schemes (Banning) Act, 1978.
• Firearms, ammunition, and related accessories, where such sale is not expressly permitted under applicable law and the merchant does not hold all required licences.
• Sale of controlled substances, narcotics, or prescription drugs without the required licences or in violation of the Drugs and Cosmetics Act, 1940.
• Any business, product, or service that is illegal under applicable Indian law, is the subject of a regulatory prohibition or advisory issued by the RBI, NPCI, or any other competent authority, or that violates Fingpay’s acceptable use policy as communicated from time to time.

Note: This list is illustrative and not exhaustive. Fingpay reserves the right to designate additional categories as prohibited at any time. Misrepresentation of business category to circumvent this prohibition constitutes a critical breach and will result in immediate termination.

B.12 ODR (Online Dispute Resolution) Framework

B.12.1 Regulatory Mandate. As an RBI-authorised Payment Aggregator, Fingpay is required to provide access to an Online Dispute Resolution (ODR) mechanism for customers who have grievances arising from transactions processed through Fingpay’s PA platform.

B.12.2 Customer Access. Customers transacting with merchants powered by Fingpay’s PA platform may access Fingpay’s ODR mechanism through: (a) the Fingpay grievance portal accessible at the URL specified on the Fingpay website; or (b) such other ODR platform as Fingpay may designate in compliance with the RBI’s ODR guidelines for digital payments. The ODR mechanism is available for unresolved disputes that have not been satisfactorily addressed through the merchant’s own customer support channels.

B.12.3 Merchant Obligation. Merchants using Fingpay’s PA platform must: (a) establish and maintain their own first-level customer dispute resolution mechanism with clear response timelines; (b) cooperate fully with any ODR process initiated by a customer through Fingpay’s ODR facility; (c) provide Fingpay with all documentation and information requested in connection with an ODR complaint within the timelines specified by Fingpay; and (d) not take any adverse action against a customer for initiating an ODR complaint.

B.13 API and SDK Integration Terms

B.13.1 Integration Security. Merchants and developers integrating with Fingpay’s PA platform via API or SDK must comply with the following security obligations:

• API credentials (API keys, secrets, tokens) must be stored securely and must not be exposed in client-side code, publicly accessible repositories, or any environment accessible to unauthorised parties.
• All API communication must occur over TLS 1.2 or higher. Merchants must not configure their integration to accept unencrypted connections.
• Merchants must implement Fingpay’s webhook signature verification to authenticate all incoming notifications from Fingpay.
• Raw card data, CVV codes, and full PANs must not be transmitted to or through the merchant’s own servers. Merchants must use Fingpay’s tokenization or hosted payment page solutions for card data capture.

B.13.2 Audit Rights. Fingpay reserves the right to audit the security practices and integration configurations of merchants using Fingpay’s API and SDK. Merchants must cooperate with any such audit and implement recommended security remediation within the timelines specified by Fingpay. Failure to implement required security remediations may result in suspension of API access.

B.13.3 SLA Framework. Fingpay will publish an API uptime SLA on its developer documentation portal. This SLA represents Fingpay’s target availability for its PA API infrastructure, measured on a monthly basis and excluding scheduled maintenance windows notified in advance.

B.13.4 API Versioning and Deprecation. Fingpay will support major API versions for the period specified in its API versioning policy, published on the Fingpay developer portal. Fingpay will provide not less than 90 days’ advance notice of the deprecation of a major API version, except where immediate deprecation is required due to a critical security vulnerability or regulatory direction. Merchants are responsible for updating their integrations to supported API versions within the applicable notice period.

B.13.5 Sandbox Testing. Prior to production go-live, merchants must conduct integration testing in Fingpay’s sandbox environment. Production API credentials will not be issued until Fingpay is satisfied that the merchant’s integration has been tested in the sandbox. Fingpay bears no liability for errors or losses arising from merchants bypassing sandbox testing.

PART C — BUSINESS CORRESPONDENT (BC) TERMS

Fingpay operates a Business Correspondent (BC) network designed to bring last-mile banking and financial services to rural and semi-urban communities across India. Through a network of empanelled Corporate BC partners and their agents, Fingpay enables AEPS cash withdrawal, deposit, and balance enquiry; Micro ATM (mATM) debit card-based cash access; BHIM Aadhaar Pay biometric merchant payments; and UPI QR-based cardless cash withdrawal. Fingpay also offers plug-and-play AEPS SDKs and APIs to Corporate BC networks. Part C governs the specific terms applicable to Corporate BC partners, their agents, and the BC service ecosystem.

C.1 Scope of BC Services

Fingpay’s BC services include the following service elements:

• AEPS Cash Withdrawal: Enabling customers to withdraw cash from their Aadhaar-linked bank accounts at BC agent locations using biometric authentication.
• AEPS Cash Deposit: Enabling customers to deposit cash into their Aadhaar-linked bank accounts at BC agent locations using biometric authentication, where supported by the customer’s bank.
• AEPS Balance Enquiry: Enabling customers to check the balance of their Aadhaar-linked bank accounts at BC agent locations.
• Micro ATM (mATM): Enabling customers to withdraw cash at BC agent locations using their debit card and PIN, without requiring ATM infrastructure.
• BHIM Aadhaar Pay: Enabling merchants at BC agent locations to accept biometric-authenticated payments directly from customers’ Aadhaar-linked bank accounts.
• UPI QR-based Cardless Cash Withdrawal: Enabling UPI-based cardless cash withdrawal at supported BC agent locations through interoperable QR mechanisms.
• SDK and API Services: Providing plug-and-play AEPS SDKs and APIs to Corporate BC partners for integration into their own agent networks and applications.

C.2 Corporate BC Partner Eligibility and Empanelment

C.2.1 Eligible Entities. The following categories of entities may apply to become Corporate BC partners of Fingpay (“BC Partners”):

• Scheduled commercial banks, small finance banks, and payment banks that are themselves authorised to appoint Business Correspondents.
• NBFCs registered with the RBI that satisfy the eligibility criteria for appointment as Business Correspondents under RBI’s Master Direction on Business Correspondents.
• Microfinance Institutions (MFIs) and other regulated entities that are eligible to act as Business Correspondents under applicable RBI guidelines.
• Other corporate entities that satisfy the eligibility criteria prescribed by RBI’s Master Direction on Business Correspondents and are approved by Fingpay.

C.2.2 Empanelment Requirements. Prospective BC partners must submit the following to Fingpay:

• Certificate of Incorporation, constitutional documents, and applicable regulatory registrations or licences.
• Details of the BC partner’s existing agent network, geographic coverage, and proposed BC activities.
• KYC documentation for authorised signatories and, where required by Fingpay, beneficial owners.
• Execution of a BC Partner Agreement with Fingpay, setting out the operational terms, commission structures, SLAs, and compliance obligations specific to the BC engagement.
• Such other documentation as Fingpay may require in accordance with applicable RBI guidelines.

C.2.3 Approval Discretion. Fingpay reserves the right to approve, reject, or revoke the empanelment of any BC partner at its sole discretion, including where the BC partner no longer satisfies applicable RBI eligibility criteria, where the BC partner’s agent network has been found to engage in misconduct, or where Fingpay determines that continued empanelment poses a risk to the BC network’s integrity or Fingpay’s regulatory compliance.

C.3 BC Agent Empanelment and Responsibility

C.3.1 BC Partner’s Responsibility. The Corporate BC partner is responsible for recruiting, training, and supervising the BC agents operating within its network. The BC partner must ensure that each BC agent:

• Meets RBI’s eligibility criteria for BC agents as set out in RBI’s Master Direction on Business Correspondents, as updated from time to time.
• Has undergone appropriate training on the BC services they are authorised to provide, including transaction procedures, customer identification, biometric device operation, and applicable regulatory requirements.
• Holds a valid Fingpay-issued or BC partner-issued agent credential at all times during agent operations.
• Complies with all applicable regulatory requirements in the conduct of BC activities, including customer service standards, transaction limits, and fee disclosure obligations.

C.3.2 BC Partner Liability for Agent Conduct. The Corporate BC partner is fully liable for the conduct of its BC agents in connection with Fingpay-facilitated BC services. The BC partner must indemnify Fingpay and hold Fingpay harmless against any losses, claims, penalties, regulatory actions, or costs arising from any act or omission of a BC agent that constitutes fraud, non-compliance, misconduct, or negligence.

C.3.3 Re-Verification. Fingpay may, at any time, require periodic re-verification of BC agents within the BC partner’s network, including re-submission of agent KYC documentation and re-confirmation of agent eligibility. The BC partner must comply with re-verification requests within the timelines specified by Fingpay.

C.4 AEPS Transaction Terms

C.4.1 Transaction Types. AEPS transactions processed through Fingpay’s BC network include cash withdrawal, cash deposit (where supported by the customer’s bank), and balance enquiry, using Aadhaar-based biometric authentication through UIDAI’s authentication infrastructure.

C.4.2 Transaction Limits. Per-transaction and per-day AEPS transaction limits are set by NPCI’s AEPS operational framework and may be further restricted by Fingpay’s risk parameters or by the customer’s bank. Applicable limits will be communicated by Fingpay to BC partners. BC agents must not facilitate transactions that exceed applicable limits.

C.4.3 Biometric Device Requirements. BC agents must conduct AEPS transactions using biometric devices that are: (a) certified by STQC (Standardisation Testing and Quality Certification) or another UIDAI-recognised certification body; (b) registered with UIDAI for biometric authentication; and (c) approved by Fingpay as compatible with the Fingpay AEPS platform. The BC partner is responsible for ensuring that all biometric devices within its agent network are certified, registered, functional, and maintained in accordance with UIDAI requirements.

C.4.4 Customer Authentication. Each AEPS transaction requires successful Aadhaar biometric authentication of the customer (fingerprint, iris, or face authentication, as supported) through UIDAI’s authentication infrastructure. BC agents must not proceed with a transaction where biometric authentication has failed.

C.4.5 Failed Transactions and TAT. Failed AEPS transactions (where the customer’s account has been debited but cash has not been dispensed, or where cash has been dispensed but the account has not been debited) are subject to NPCI’s applicable turnaround time (TAT) for resolution and customer compensation as specified in NPCI’s AEPS Circular 46 and any subsequent NPCI circulars governing AEPS failed transaction resolution. The BC partner must ensure that its agents follow the prescribed procedure for reporting failed transactions.

C.4.6 Customer Fee Restrictions. BC agents must not charge customers any fee for AEPS transactions that exceeds the fee permitted by NPCI’s AEPS guidelines. Any fee charged in excess of NPCI’s permitted limits is prohibited and constitutes a violation of these BC Terms, subject to immediate remediation and potential suspension of the agent’s access to the AEPS service.

C.5 Biometric Data Handling under BC/AEPS

C.5.1 UIDAI Authentication Infrastructure. Aadhaar-based biometric authentication data (fingerprint, iris, or face) captured during AEPS and BHIM Aadhaar Pay transactions is transmitted directly to UIDAI’s authentication servers for verification. Fingpay does not store, retain, or process raw biometric data from AEPS or BHIM Aadhaar Pay transactions.

C.5.2 Prohibition on Biometric Data Capture. The BC partner and all BC agents within the BC partner’s network are strictly and unconditionally prohibited from: (a) attempting to capture, record, store, copy, or replicate biometric data (fingerprint, iris scan, face data, or any other biometric) of any customer or person; (b) using any device or software to intercept biometric data during the authentication process; or (c) retaining any biometric data beyond the point of transmission to UIDAI for authentication.

C.5.3 Consequences of Breach. Any breach of the prohibition in C.5.2 constitutes a critical violation of these BC Terms, the Aadhaar Act, 2016, and applicable UIDAI regulations. Upon discovery or reasonable suspicion of such a breach, Fingpay will: (a) immediately suspend all BC services to the relevant agent and/or BC partner; (b) report the breach to UIDAI, RBI, and any other relevant regulatory authority; and (c) exercise all available legal remedies against the breaching party.

C.5.4 Regulatory Framework. Biometric data handling in connection with Fingpay’s BC services is subject to the Aadhaar (Targeted Delivery of Financial and Other Subsidies, Benefits and Services) Act, 2016, the Aadhaar (Data Security) Regulations, the Aadhaar (Authentication and Offline Verification) Regulations, and any other applicable UIDAI regulations and circulars.

C.6 Micro ATM (mATM) Terms

C.6.1 Service Description. Micro ATM services enable customers to withdraw cash at BC agent locations by inserting or swiping their debit card and entering their PIN on a Fingpay-approved mATM device, without requiring a full ATM terminal. The mATM transaction is routed through the applicable card network and the customer’s bank.

C.6.2 Device Standards and Certification. mATM devices deployed by BC agents must: (a) comply with applicable RBI and NPCI technical standards for Micro ATM terminals; (b) be PCI PTS (PIN Transaction Security) certified; and (c) be registered with and approved by Fingpay prior to activation. The BC partner is responsible for procuring, deploying, and maintaining only approved, certified mATM devices within its agent network.

C.6.3 Card Data Security. At the point of interaction, mATM devices must not store, log, or transmit clear-text card data (PANs or PINs) beyond the encrypted transmission required for transaction processing. The BC partner must ensure its agents are trained to identify signs of device tampering or skimming and to report any such incidents immediately to Fingpay.

C.6.4 Permitted Card Networks and Transaction Types. mATM transactions processed through Fingpay’s BC platform are permitted for the card networks and transaction types notified by Fingpay from time to time, subject to applicable NPCI and RBI guidelines.

C.6.5 Transaction Limits. Per-transaction and per-day cash withdrawal limits applicable to mATM transactions are governed by NPCI and RBI guidelines and may be further restricted by the customer’s issuing bank or Fingpay’s risk parameters.

C.6.6 Device Security and Tamper Reporting. The BC partner must ensure that mATM devices are stored securely when not in use, are not left unattended in unsecured environments, and are regularly inspected for signs of physical tampering. Any device tamper event must be reported to Fingpay within 24 hours of discovery. Compromised devices must be immediately withdrawn from service pending investigation.

C.7 BHIM Aadhaar Pay Terms

C.7.1 Service Description. BHIM Aadhaar Pay enables customers to make payments to merchants at BC agent locations by authenticating their identity using Aadhaar biometrics, directly debiting their Aadhaar-linked bank account without requiring a card or mobile device.

C.7.2 Merchant Eligibility. Merchants wishing to accept BHIM Aadhaar Pay at BC agent locations must be registered with Fingpay as BHIM Aadhaar Pay merchants and must satisfy the eligibility criteria communicated by Fingpay and NPCI from time to time.

C.7.3 Customer Consent and Authentication. Each BHIM Aadhaar Pay transaction requires: (a) explicit, informed customer consent to the specific transaction amount and recipient merchant; and (b) successful Aadhaar biometric authentication through UIDAI’s infrastructure. The BC agent must clearly communicate the transaction details to the customer before initiating authentication.

C.7.4 Prohibition on Coercion. BC agents and merchants must not coerce, pressure, or incentivise customers to use BHIM Aadhaar Pay over any other payment method. Customers have the right to choose their preferred payment instrument, and any coercion to use Aadhaar-based payment is prohibited and constitutes a violation of UIDAI’s guidelines.

C.7.5 Failed and Disputed Transactions. Liability for failed or disputed BHIM Aadhaar Pay transactions is governed by NPCI’s operational guidelines for BHIM Aadhaar Pay and applicable RBI directives. The BC partner must ensure that its agents follow the prescribed procedure for reporting and resolving failed BHIM Aadhaar Pay transactions.

C.8 BC Agent Commission and Payouts

C.8.1 Commission Structure. The commission rates payable to BC partners (for onward disbursement to BC agents) in respect of AEPS, mATM, BHIM Aadhaar Pay, and other BC transactions are as communicated by Fingpay to the BC partner at the time of empanelment or as updated by Fingpay from time to time with reasonable prior notice.

C.8.2 Payout Timelines. Commissions earned by the BC partner in respect of completed and verified BC transactions will be credited to the BC partner’s designated bank account on the payout cycle specified in the BC Partner Agreement. Fingpay will provide the BC partner with a commission statement reflecting the transactions on which commission has been calculated.

C.8.3 Adjustment, Withholding, and Recovery. Fingpay reserves the right to:

• Adjust commission payable to the BC partner in the event of transaction reversals, failed transactions determined to be caused by BC partner or agent error, or any adjustment arising from NPCI or bank-side settlement processes.
• Withhold commission pending investigation of fraud, misconduct, or compliance violations involving the BC partner’s agent network.
• Recover previously paid commissions where those commissions were paid in respect of fraudulent, reversed, or disputed transactions subsequently determined to be ineligible.

C.8.4 Commission Disputes. Disputes regarding commission calculations must be raised by the BC partner within the period specified in the BC Partner Agreement. Disputes raised after this period may not be eligible for investigation or redressal.

C.9 Device and Infrastructure Obligations

C.9.1 BC Partner Responsibility. The BC partner is responsible for ensuring that all BC agents within its network are equipped with the necessary devices, connectivity, and infrastructure to provide BC services. This includes:

• NPCI-certified and STQC-certified biometric devices for AEPS and BHIM Aadhaar Pay transactions.
• PCI PTS-certified mATM terminals for debit card-based cash dispensing.
• Adequate connectivity (mobile data or broadband) to support real-time transaction processing.
• Power supply solutions appropriate to the operating environment of each agent location.

C.9.2 Fingpay’s Non-Liability. Fingpay is not responsible for transaction failures, data loss, or service disruptions arising from: (a) device malfunction or technical failure at a BC agent location; (b) network outages, low bandwidth, or connectivity disruptions at or around agent locations; or (c) power failures at agent locations.

C.9.3 Device Maintenance. The BC partner must ensure that all devices deployed within its agent network are regularly maintained, updated with required firmware and software updates, and functioning correctly. Devices that are defective, tampered with, or non-compliant with applicable certification requirements must be withdrawn from service immediately.

C.9.4 Tamper Reporting. Any event involving actual or suspected device tampering (including physical modification, software alteration, skimming attachment, or PIN capture device installation) must be reported to Fingpay within 24 hours of discovery. The BC partner must retain the tampered device for forensic investigation and must not restore it to service without Fingpay’s clearance.

C.10 Connectivity and Low-Connectivity Environment Obligations

C.10.1 Low-Connectivity Design. Fingpay’s BC platform is designed to support transaction processing in low-connectivity environments commonly encountered in rural and semi-urban India. However, Fingpay does not guarantee service availability in all geographies at all times, and transaction processing remains subject to minimum connectivity requirements for successful authentication and settlement through UIDAI’s and NPCI’s infrastructure.

C.10.2 Agent and Customer Communication. The BC partner must communicate service availability limitations clearly to its agents and, through its agents, to customers. Agents must not initiate transactions when connectivity is insufficient to complete the transaction, and must inform customers that the service may be unavailable in low-connectivity situations.

C.10.3 Failed Transaction Protocol. Where a transaction fails due to connectivity or network-related issues, the BC agent must follow NPCI’s prescribed failed transaction protocol, including providing the customer with a transaction failure acknowledgement and advising the customer to retry the transaction once connectivity is restored.

C.10.4 NPCI TAT for Customer Compensation. Failed transactions arising from connectivity issues are subject to NPCI’s applicable turnaround time guidelines for failed transaction resolution and customer compensation. The BC partner must ensure its agents comply with NPCI’s requirements in handling such failures.

C.11 Fraud Prevention and Reporting under BC

C.11.1 BC Partner Fraud Controls. The BC partner must implement and maintain internal controls adequate to detect, prevent, and respond to fraud within its BC agent network. These controls must include, at a minimum: (a) agent transaction monitoring with alerts for anomalous transaction patterns; (b) regular agent performance and compliance reviews; (c) a mechanism for customers to report fraudulent transactions to the BC partner directly; and (d) a zero-tolerance policy for agent misconduct communicated clearly to all agents.

C.11.2 Fraud Reporting Timeline. Any suspected fraud, device compromise, unauthorised transaction, or security incident within the BC partner’s agent network must be reported to Fingpay within 24 hours of detection or first reasonable suspicion. The report must include all available details of the incident, including affected agent identity, transaction references, suspected amounts, and any evidence gathered.

C.11.3 Suspension Pending Investigation. Upon receipt of a fraud report or upon Fingpay’s own detection of suspicious activity, Fingpay may immediately suspend BC services to the affected agent or agents, and to such other agents or locations as Fingpay considers necessary to contain the risk, pending investigation. The BC partner must cooperate fully with Fingpay’s investigation.

C.11.4 BC Partner Liability. The BC partner bears liability for losses arising from fraud within its agent network where the BC partner, its agents, or its personnel are found to be negligent, complicit, or in breach of their obligations under these BC Terms. The BC partner must indemnify Fingpay for all losses, costs, and regulatory penalties arising from such fraud to the extent attributable to the BC partner’s or its agents’ negligence or non-compliance.

C.12 Regulatory Compliance under BC

C.12.1 Applicable Regulatory Framework. The BC partner must at all times comply with the following regulatory requirements in the conduct of BC activities facilitated through Fingpay’s platform:

• RBI’s Master Direction on Business Correspondents (as amended from time to time).
• NPCI’s AEPS operational circulars and guidelines, including Circular 46 and any subsequent circulars governing AEPS operations, failed transactions, and agent conduct.
• UIDAI’s regulations under the Aadhaar (Targeted Delivery of Financial and Other Subsidies, Benefits and Services) Act, 2016, and applicable UIDAI circulars.
• PMLA, 2002, and the Prevention of Money Laundering (Maintenance of Records) Rules, 2005, and applicable AML and CFT requirements.
• The DPDP Act, 2023, and applicable data protection obligations, particularly in respect of customer data collected during BC transactions.
• Any other law, rule, or regulation applicable to the conduct of Business Correspondent activities in India, as notified from time to time.

C.12.2 Implementation of Regulatory Changes. Where changes in applicable regulatory requirements affect BC operations, Fingpay will, to the extent practicable, communicate those changes to BC partners with a reasonable implementation timeline. The BC partner must implement required changes within the timelines specified by Fingpay. Failure to implement required regulatory changes within the specified timeline constitutes a breach of these BC Terms.

C.13 Suspension and Termination of BC Services

C.13.1 Grounds for Suspension or Termination. Fingpay may suspend or terminate BC services to a BC partner or to specific BC agents within the BC partner’s network in the following circumstances:

• Direction, instruction, or order from the RBI, NPCI, UIDAI, or any other competent regulatory or judicial authority.
• Discovery of or credible evidence of fraud, device compromise, biometric data misuse, or any other serious security incident within the BC partner’s agent network.
• Persistent non-compliance with applicable transaction limits, customer fee restrictions, device certification requirements, or reporting obligations.
• Material breach of any provision of these BC Terms or the BC Partner Agreement.
• Actions by the BC partner or its agents that, in Fingpay’s reasonable assessment, pose a risk to the integrity of the BC network, UIDAI’s authentication infrastructure, or NPCI’s AEPS ecosystem.
• Insolvency or material adverse change in the financial condition of the BC partner.

C.13.2 Notice. Where the grounds for suspension or termination are not urgent or safety-critical, Fingpay will provide the BC partner with reasonable prior notice and an opportunity to remedy the breach (where the breach is capable of remedy). In cases involving regulatory direction, fraud, device compromise, or biometric data misuse, suspension may be effected immediately without prior notice.

C.13.3 Pending Commissions and Transactions. Upon termination of a BC partner’s empanelment, Fingpay will process pending commission payables in respect of transactions completed and verified prior to the effective date of termination, subject to any withholding rights arising from fraud investigations or outstanding liabilities of the BC partner to Fingpay. No new BC transactions will be facilitated after the effective date of termination.

Last Updated: April 2026