Regulation decides more of a fintech product’s design than most founders expect: where the money flows, what the app may ask for, where data lives, what the customer sees before signing, and what evidence you must keep.
This guide explains, in engineering terms, the rules that most often shape fintech software in India and in our other markets, and draws a clear line between what a development team builds and what you, your partners and your advisers must hold.
Not legal advice. This is a summary written by engineers to help you ask the right questions. Regulators update directions, circulars and limits often. Always check the current RBI direction, NPCI circular or regulator guidance, and confirm your model with a qualified adviser or your regulated partner.
Last reviewed .
RBI sets most of the rules, NPCI runs UPI and the mandate rails, and the DPDP Act covers personal data across every sector.
Almost every Indian fintech rule is addressed to a regulated entity (RE): a bank, an NBFC, an authorised payment aggregator or payment system operator, or an entity regulated by SEBI, IRDAI or PFRDA. A startup that is not itself licensed usually works through one of them, as a lending service provider, a merchant, a technology service provider or a distribution partner.
That matters for the software. Even when a rule is not addressed to you, your partner is responsible for how its customers are treated, so it writes the rule into your contract and checks your product against it. RBI’s directions on outsourcing IT services also expect REs to keep audit and access rights over their technology vendors. In practice, your partner’s compliance checklist becomes your product requirements.
RBI first issued digital lending guidelines in 2022 and consolidated them into the Digital Lending Directions in 2025. They apply to lending by REs through digital channels, including loans sourced through a lending service provider (LSP) and its digital lending app. The details are specific and change, so check the current RBI direction and your lending partner’s interpretation before you design the flows.
The themes with the biggest effect on software have stayed consistent: money moves directly between the borrower’s and the lender’s bank accounts, borrowers see full costs before they sign, and personal data is collected only with explicit consent and kept in India.
Related: Loan Management Software · Fintech Software
RBI’s Master Direction on KYC (first issued in 2016 and amended many times since) sets how REs identify customers. Which methods are available to you depends on your partner’s licence and authorisations, not only on what an API vendor sells.
Aadhaar-based e-KYC using OTP or biometrics is only for entities permitted under the Aadhaar Act and UIDAI’s rules; others typically use offline Aadhaar verification (such as the Aadhaar XML or DigiLocker), PAN verification, the Central KYC Registry (CKYCR) or Video-based Customer Identification Process (V-CIP).
V-CIP, usually called Video KYC, has detailed requirements in the Master Direction. Among them: a live video interaction with a trained official of the RE (not an automated bot), liveness checks, geo-tagging to confirm the customer is in India, capture and verification of documents such as PAN, secure end-to-end encrypted sessions, and recordings stored securely with date and time stamps. Check the current text: requirements have been updated several times.
Related: KYC and eKYC Integration · Fintech Software
Non-bank payment aggregators (PAs), which collect money from customers on behalf of merchants and settle it to them, need RBI authorisation. The framework began with the 2020 guidelines, was extended to cross-border aggregators (PA-CB), and has since been extended to physical, point-of-sale aggregators. Rules cover net worth, merchant due diligence, escrow accounts, settlement timelines and security baselines.
Most businesses are merchants, not aggregators, and simply integrate a licensed PA such as Razorpay, Cashfree, PayU or Stripe. The question gets harder for marketplaces and platforms that collect money from buyers and pay it out to sellers: holding and forwarding other people’s money can look like payment aggregation. The usual answer is to use your PA’s split-settlement or marketplace product so funds settle directly to sellers, but take legal advice on your specific flow.
Related: Payment Gateway Integration
Since October 2022, RBI rules have stopped merchants and payment aggregators in India from storing customers’ full card numbers and other card data (limited data such as the last four digits and the issuer name may be kept for tracking and reconciliation). Saved cards and card subscriptions work through tokens issued by the card networks or issuers, created with the customer’s explicit consent and additional authentication.
Related: Payment Gateway Integration
RBI’s 2018 direction on storage of payment system data requires payment system providers to store the entire data relating to payment systems only in India. RBI’s follow-up FAQs allow processing abroad in some cases, provided the data is deleted abroad and brought back to India within a short, defined window; check the current FAQs for the exact conditions. Your PA or bank partner will usually pass the requirement down to you by contract.
Separately, the digital lending directions require borrower data to be stored in India, and CERT-In’s 2022 directions require many organisations to keep ICT system logs for 180 days within Indian jurisdiction and to report certain cyber incidents to CERT-In within 6 hours.
UPI is operated by NPCI under RBI oversight. Merchants accept UPI through a bank or payment aggregator; building your own UPI app for consumers (a third-party application provider, or TPAP) needs NPCI approval and a sponsoring payment service provider bank, which is a partnership and approval process, not just an integration.
NPCI changes UPI rules through circulars, often with short timelines. Recent examples include restricting “collect” requests in favour of intent and QR flows, and limiting how often apps may call some APIs, such as balance and status checks, and when AutoPay debits may be presented. Check your PSP bank’s or PA’s latest guidance before designing flows.
For recurring payments, UPI AutoPay and e-mandates (e-NACH via your sponsor bank or PA, and card e-mandates) replace post-dated cheques and manual reminders. RBI’s e-mandate framework requires a pre-debit notification to the customer before each debit and allows recurring debits without extra authentication only up to set limits, which differ by category. Check the current limits; they have been raised several times.
Related: Payment Gateway Integration · Loan Management Software
Account Aggregators (AAs) are RBI-licensed NBFCs that move financial data, such as bank statements, deposits, investments and, increasingly, GST data, from Financial Information Providers (FIPs) to Financial Information Users (FIUs), only with the customer’s consent. The AA cannot read the data; it is encrypted end to end between FIP and FIU.
FIUs are generally entities regulated by a financial sector regulator (RBI, SEBI, IRDAI or PFRDA). If you are not regulated, you typically access AA data through a regulated partner, for example a lending partner acting as the FIU. Technical standards are published by ReBIT, and the industry body Sahamati coordinates ecosystem participation and certification.
Related: Account Aggregator Integration · Loan Management Software
The DPDP Act is India’s general data protection law. The Government notified the DPDP Rules in November 2025 with a phased timeline, so some obligations may not yet be in force when you read this; check the current dates. Penalties for failing to protect personal data can be very large.
The Act applies alongside sector rules. Where RBI or another law requires you to keep records (for example KYC or loan records), that retention requirement generally continues to apply, so your data deletion design needs a retention schedule, not a single “delete” button.
Card security and data protection rules follow your customers, wherever your developers are. Licensing depends on the country you operate in.
The Payment Card Industry Data Security Standard applies to any business that stores, processes or transmits cardholder data, anywhere in the world. It is set by the PCI Security Standards Council and enforced through card brands and acquiring banks, not by governments. Version 4 is current; check the Council’s site for the latest revision.
The most effective compliance step is to keep card data away from your systems. Merchants that fully outsource card entry to a compliant gateway’s hosted page or embedded fields usually qualify for the shortest self-assessment questionnaire; building your own card form, or storing card data, moves you into much heavier requirements. Your acquirer or gateway confirms which assessment applies.
Related: Payment Gateway Integration
If you serve people in the EU or UK, the GDPR or UK GDPR applies to you as the data controller. A development partner who handles personal data on your behalf is a processor, and the law requires a written data processing agreement between you.
India does not have an EU or UK adequacy decision, so personal data transferred to a team in India needs a transfer mechanism, typically the EU standard contractual clauses or, for the UK, the International Data Transfer Agreement or the UK Addendum, with a transfer risk assessment. The UK is also phasing in changes to its data protection law, so check current ICO guidance.
In the UK, providing payment services, issuing e-money, consumer lending and many investment activities need Financial Conduct Authority authorisation or registration. Many startups begin as an agent of an authorised firm or embed a licensed partner’s product, then apply for their own permissions later.
For authorised firms, several FCA rules shape software directly: the Consumer Duty (fair value, clear communications and monitoring of customer outcomes), strong customer authentication for payments, operational resilience requirements for important business services, safeguarding of customer funds (tightened by rule changes taking effect in 2026), and outsourcing rules under which the firm stays fully responsible for work done by suppliers, including overseas developers.
In the United States, moving money on behalf of others usually requires a money transmitter licence in each state where you operate, managed largely through the NMLS system, plus federal registration with FinCEN as a money services business and an anti-money-laundering programme. Many states have adopted a model law to harmonise licensing, but requirements still differ. Lending brings its own state licences and federal disclosure rules.
Because licensing in many states is slow and expensive, most early-stage US fintechs partner with a sponsor bank or a licensed provider (a banking-as-a-service platform or a payment facilitator) and operate within that partner’s licences and compliance programme. Non-bank financial companies also have obligations under the FTC’s Safeguards Rule, such as a written security programme, multi-factor authentication, encryption and breach notification.
SOC 2 is not a law. It is an independent auditor’s report, under AICPA standards, on how a service company controls security and, optionally, availability, confidentiality, processing integrity and privacy. Banks and larger customers frequently ask B2B fintech vendors for one. A Type I report looks at control design at a point in time; a Type II report tests whether controls worked over a period, typically several months.
Only a licensed CPA firm can issue a SOC 2 report, and it covers your company, not your code. What a development team can do is build the product and delivery pipeline so the evidence already exists when the auditor asks.
In Australia, financial services and credit generally need an Australian Financial Services Licence or Australian Credit Licence from ASIC, and remittance and digital currency exchange providers register with AUSTRAC. The Privacy Act 1988, with its notifiable data breaches scheme, and the Consumer Data Right for open banking shape how data is handled.
In Canada, money services businesses register with FINTRAC, and payment service providers are now supervised by the Bank of Canada under the Retail Payment Activities Act. Privacy is governed by PIPEDA federally, with stricter provincial laws such as Quebec’s Law 25. Check the current guidance from each regulator.
A development partner can make compliance much easier, but cannot hold your licence, sign your audit or own your policies. Here is where the line usually falls.
Swipe sideways to see every column.
| Area | What RED SAG builds | What stays with you |
|---|---|---|
| Licences and authorisations | Software that fits the model your licence or partner allows, and flows that keep you inside it | RBI, NPCI, FCA, state, FINTRAC or other licences and registrations, or the partner agreements you operate under |
| Policies | Features that enforce your policies: limits, approvals, risk rules, retention schedules | KYC/AML, credit, fraud, privacy and information security policies approved by your board or compliance officer |
| Customer-facing legal text | Screens, versioning and consent capture for every document a user accepts | Wording of terms, privacy notices, KFS templates and disclosures, reviewed by your lawyers |
| Audits and certifications | Controls, logs and evidence that make audits faster, and fixes for audit findings | PCI DSS assessments, SOC 2 reports, RBI or partner audits, ISO certification, penetration test sign-off |
| Regulatory reporting | Report generation and data exports in the formats you need | Filing returns and reports with regulators, credit bureaus and FIUs, and answering regulator queries |
| Data protection | Consent records, access controls, encryption, deletion jobs and data residency by design | Role of data fiduciary or controller, grievance or DPO appointments, breach notifications to regulators |
| Operations | Monitoring, alerting, backups, runbooks and admin tools for your team | Customer support, complaint handling, collections conduct and day-to-day decisions |
On every fintech project we start by asking who the regulated entity is, which rules and partner requirements apply, where data must live and how long records must be kept. The answers go into the specification, not a later “compliance phase”. Our security page explains how we protect your code and data while we build.
We can build the software so it supports compliance: consent records, KFS and disclosure screens, audit logs, data residency, secure payment handling and the reports you need. Compliance itself also depends on licences, policies, legal text and audits that stay with you and your advisers. We work alongside your compliance lead or partner bank so the software matches their interpretation.
Not always. Many startups launch as a lending service provider working with a licensed bank or NBFC, or as a merchant using a licensed payment aggregator. Whether you need your own licence depends on whether you lend from your own balance sheet, hold customer funds or settle money to third parties. Get legal advice on your specific model before you build.
No. It is an engineering-focused summary written to help founders ask better questions. Regulations change often, and interpretations differ between partners. Always check the current RBI, NPCI or regulator text and confirm with a qualified adviser.
No. RED SAG does not hold those certifications. We build products that reduce your PCI DSS scope, for example through hosted payment pages and tokenisation, and that make SOC 2 evidence easier to collect. The certifications belong to the company operating the product.
In your own cloud account, in the region your rules require. For Indian payment and lending data that normally means an India region; for UK and EU clients we can host in the UK or EU and keep developer access to personal data to a minimum.
Yes. We expect partner due diligence on fintech projects and are happy to answer security questionnaires, join architecture reviews and adjust the build to the partner’s requirements. It is much cheaper to hear those requirements before development than after.
Payment gateway and UPI integration, lending systems, wallets, eKYC and fintech MVPs built with audit-ready foundations.
Razorpay, Cashfree, PayU, PhonePe, Stripe and PayPal integrations with UPI, subscriptions, split payouts, webhooks, refunds and reconciliation.
Origination, EMI schedules, field collections and overdue tracking for NBFCs, MFIs, societies and gold-loan lenders.
Aadhaar eKYC via licensed partners, DigiLocker, PAN, CKYC, Video KYC, penny drop, face match and OCR in one onboarding flow.
FIU-side AA integration: consent flows, bank statement and investment data fetch, parsing and underwriting insights.
Share a few lines about your idea. We reply within one working day with questions, a rough budget and the next step, with no obligation.
“Great service”
Need a detailed estimate? Request a full quote