# Building Fintech Software: Compliance, Banking APIs, and What Breaks in Production — Hunchbite > A technical guide for building financial software — PCI-DSS, RBI regulations, UPI and account aggregator integrations, KYC/AML requirements, fraud systems, and the architecture decisions that separate functional fintech from production-ready fintech. Source: https://hunchbite.com/guides/fintech-software-development [Home](https://hunchbite.com/)/[Guides](https://hunchbite.com/guides)/[Industry Software](https://hunchbite.com/guides/topic/industry-software)/Building Fintech Software: Compliance, Banking APIs, and What Breaks in Production [Industry Software](https://hunchbite.com/guides/topic/industry-software) # Building Fintech Software: Compliance, Banking APIs, and What Breaks in Production A technical guide for building financial software — PCI-DSS, RBI regulations, UPI and account aggregator integrations, KYC/AML requirements, fraud systems, and the architecture decisions that separate functional fintech from production-ready fintech. By HunchbiteMarch 12, 202613 min read fintechPCI-DSScompliance > **Fintech is not just software with money in it.** It's software where bugs have financial consequences, where regulatory failures create legal liability, and where security vulnerabilities are directly weaponized for financial fraud. Building it correctly requires understanding both the technical and regulatory landscape. This guide is for engineering teams building financial software in India — lending platforms, wealth management tools, payment infrastructure, insurance technology, or any software that touches the movement or management of money. While the focus here is finance, the same rigour around data handling and compliance carries over to other regulated, data-sensitive industries — our guide on [building education and edtech software](https://hunchbite.com/guides/software-development-edtech) is a useful companion if your product also touches that space. ## The regulatory landscape for Indian fintech Before writing a line of code, understand which regulators apply to your product: | Product type | Regulator | Key compliance | | ------------------------------ | --------- | ------------------------------------ | | Payment aggregator / gateway | RBI | PA/PG guidelines, PCI-DSS | | Lending platform | RBI | NBFC licence or lending partnerships | | Wealth management / investment | SEBI | Investment adviser registration | | Insurance distribution | IRDAI | Broker/agent licence | | Account aggregator | RBI | AA framework licence | | Crypto / digital assets | Evolving | Watch PMLA requirements | **Critical:** Many fintech products operate by partnering with licensed entities (banks, NBFCs, insurance companies) rather than holding their own licence. The technical implications of this are significant — you're building on top of a partner's infrastructure, their APIs, and their compliance requirements. ## Payment infrastructure ### PCI-DSS: what engineers actually need to know PCI-DSS (Payment Card Industry Data Security Standard) has 12 requirements covering network security, data protection, vulnerability management, access control, monitoring, and security policy. **The most important decision:** Do you touch raw card data at all? * **If no** (you use a gateway's hosted fields, iframe, or SDK): You may qualify for SAQ A — the simplest compliance tier. Your frontend never sees the card number; the gateway does. * **If yes** (your server receives card numbers): You're in scope for full PCI-DSS. SAQ D, potentially Level 1 (quarterly external scans, annual on-site audit above 6M transactions). **The right default:** Never touch raw card data. Use Razorpay, Stripe, or PayU's hosted payment page or tokenization. Let them handle PCI compliance. Your scope drops dramatically. ### UPI integration UPI (Unified Payments Interface) is the dominant payment rail in India. Integration options: * **As a PSP (Payment Service Provider):** Requires RBI authorisation and direct integration with NPCI. High bar, only for established players. * **Via a UPI-enabled payment gateway:** Razorpay, PayU, Cashfree, etc. You get UPI collect and UPI intent flows without direct NPCI integration. * **UPI AutoPay for recurring payments:** For subscription businesses, UPI AutoPay is NACH's digital equivalent. Requires a specific mandate flow — don't underestimate the UX complexity. **Common UPI integration failures:** * Not handling all 30+ UPI error codes correctly (payment apps return specific codes; your system needs to map them to user-facing messages) * Race conditions in payment status polling (UPI is async; poll with exponential backoff, don't rely on webhooks alone) * Insufficient timeout handling (UPI transactions can hang; build a reconciliation job) ### Reconciliation: the feature that's always underbuilt Every fintech product needs a reconciliation system. Payments fail silently. Webhooks are missed. Timeouts occur. Without reconciliation: * Money moves that your system doesn't record * Your system records money movement that didn't happen * Disputes you can't resolve Build reconciliation from day one: a scheduled job that compares your internal records with the payment gateway's records and flags discrepancies. This is not optional. Hunchbite Service #### Custom Software Development Production-grade software built around how your business actually works — not forced into a generic template. [Scope your build](https://hunchbite.com/custom-software-development-company) ## Account Aggregator integration The AA framework is a consent-based financial data sharing infrastructure. The key participants: * **FIP (Financial Information Provider):** Banks, NBFCs, depositories — hold the data * **FIU (Financial Information User):** Your product — requests data with user consent * **AA (Account Aggregator):** Intermediary managing consent As an FIU, your integration involves: 1. Onboarding with an AA (Sahamati network members) 2. Creating a consent artefact (specifying what data, for what purpose, for how long) 3. Presenting the consent flow to the user 4. Receiving and processing the consented data **Data you can access via AA:** * Bank account statements * Mutual fund holdings * Insurance policies * NPS holdings * GST data (emerging) * Tax data (emerging) **Technical considerations:** * Data is delivered as encrypted, digitally signed JSON * You must verify the digital signature before using the data * Consent has a lifecycle — track consent status, handle revocations * Data retention: don't store more data than your consent artefact permits ## KYC and AML implementation ### KYC (Know Your Customer) KYC is mandatory for most financial products. Implementation options: **Aadhaar-based eKYC (OTP or biometric):** * Fastest, highest trust * Requires UIDAI sub-AUA/KUA licence or partnership with an AUA * Biometric eKYC requires specific hardware; OTP eKYC is software-only **Video KYC (V-CIP):** * RBI-approved for account opening * Requires video recording, liveness detection, document capture * Use a provider (IDfy, Hyperverge, IDMERIT) unless you have significant scale **Document verification:** * OCR + validation of PAN, Aadhaar, driving licence, passport * Third-party providers handle the ML and database lookups * Validate at collection, re-validate periodically **What to store (and how):** * Store KYC status (verified/rejected/pending), method, timestamp, and outcome — not necessarily the underlying document * KYC documents stored for regulatory purposes must be encrypted and access-logged * Retention period: typically 5 years after customer relationship ends (verify with your legal team) ### AML (Anti-Money Laundering) If you're in regulated financial services: * **Transaction monitoring:** Flag unusual patterns (large amounts, rapid transactions, structuring patterns) * **PEP and sanctions screening:** Screen customers against politically exposed persons lists and sanctioned entities * **STR filing:** Suspicious Transaction Reports to FIU-IND when required * **Record keeping:** Maintain customer transaction records for 5+ years For most products, use a third-party AML/compliance provider (ComplyAdvantage, IDCOM, Perfios) rather than building monitoring systems from scratch. ## Fraud and risk systems Financial products are targets. Plan for fraud from day one: ### Device and session signals * Device fingerprinting (IP, user agent, timezone, screen resolution) * Velocity checks (too many transactions from one device/IP in a time window) * Location anomalies (transaction from a new city immediately after another city) ### Payment fraud patterns * Card testing (small amounts to verify stolen cards) * Account takeover (credential stuffing, SIM swap) * Friendly fraud (chargebacks on legitimate transactions) * Synthetic identity fraud (fabricated identities passing KYC) **Architecture for fraud:** Fraud rules should be evaluated in a separate service, not in-line with transaction processing. You want to be able to update rules without deploying the payment service. Use a rules engine or a feature flag system for fraud thresholds. ## Data architecture for financial products ### Immutability Financial records must not be updatable or deletable. Implement an append-only ledger for all financial transactions. If a correction is needed, record a reversing entry — never update or delete the original. This append-only discipline isn't unique to finance: regulated domains like healthcare hold patient records to the same standard, and our guide on [building HIPAA-compliant healthcare software](https://hunchbite.com/guides/healthtech-software-development) covers the parallel audit-logging and PHI requirements. ### Decimal precision Floating point arithmetic does not work for financial calculations. Use: * PostgreSQL: `NUMERIC(19, 4)` for amounts * JavaScript: a decimal library (decimal.js, big.js) — never native `float` * Python: `Decimal` type — never `float` `0.1 + 0.2 = 0.30000000000000004` in floating point. This is not acceptable in financial software. ### Idempotency Payment and transfer operations must be idempotent. Every operation should accept an idempotency key. If the same operation is attempted twice (network retry, user double-click), the second attempt should return the result of the first — not execute again. Implement idempotency at the API layer, not in the client. Getting the ledger, decimal precision, and idempotency right from the first commit is far cheaper than retrofitting them after money has already moved. If you would rather not learn these the hard way, [book a call with our team →](https://cal.com/hunchbite/discovery) ## What to get right from day one * HTTPS everywhere, no exceptions * All financial data encrypted at rest * Audit logging on all financial operations (who did what, when) * Idempotent payment operations * Decimal types for all monetary values * Reconciliation job running from first transaction * Separate environments for development, testing, and production — no production data in dev --- _Building a fintech product and need to get the architecture and compliance foundation right? [Contact us](https://hunchbite.com/contact) — we've built payment infrastructure, lending platforms, and financial data products. We know which shortcuts cost you later and which are genuinely fine to defer._ Ask an AI assistant about this guide: [ChatGPT](https://chatgpt.com/?q=Read%20https%3A%2F%2Fhunchbite.com%2Fguides%2Ffintech-software-development%20and%20help%20me%20apply%20it%20to%20my%20situation.%20Answer%20my%20questions%20about%20it.&hints=search) · [Claude](https://claude.ai/new?q=Read%20https%3A%2F%2Fhunchbite.com%2Fguides%2Ffintech-software-development%20and%20help%20me%20apply%20it%20to%20my%20situation.%20Answer%20my%20questions%20about%20it.) · [Perplexity](https://www.perplexity.ai/search?q=Read%20https%3A%2F%2Fhunchbite.com%2Fguides%2Ffintech-software-development%20and%20help%20me%20apply%20it%20to%20my%20situation.%20Answer%20my%20questions%20about%20it.) On this page * [The regulatory landscape for Indian fintech](#the-regulatory-landscape-for-indian-fintech) * [Payment infrastructure](#payment-infrastructure) * [PCI-DSS: what engineers actually need to know](#pci-dss-what-engineers-actually-need-to-know) * [UPI integration](#upi-integration) * [Reconciliation: the feature that's always underbuilt](#reconciliation-the-feature-thats-always-underbuilt) * [Account Aggregator integration](#account-aggregator-integration) * [KYC and AML implementation](#kyc-and-aml-implementation) * [KYC (Know Your Customer)](#kyc-know-your-customer) * [AML (Anti-Money Laundering)](#aml-anti-money-laundering) * [Fraud and risk systems](#fraud-and-risk-systems) * [Device and session signals](#device-and-session-signals) * [Payment fraud patterns](#payment-fraud-patterns) * [Data architecture for financial products](#data-architecture-for-financial-products) * [Immutability](#immutability) * [Decimal precision](#decimal-precision) * [Idempotency](#idempotency) * [What to get right from day one](#what-to-get-right-from-day-one) Ask AI about this guide * [Open in ChatGPT](https://chatgpt.com/?q=Read%20https%3A%2F%2Fhunchbite.com%2Fguides%2Ffintech-software-development%20and%20help%20me%20apply%20it%20to%20my%20situation.%20Answer%20my%20questions%20about%20it.&hints=search) * [Open in Claude](https://claude.ai/new?q=Read%20https%3A%2F%2Fhunchbite.com%2Fguides%2Ffintech-software-development%20and%20help%20me%20apply%20it%20to%20my%20situation.%20Answer%20my%20questions%20about%20it.) * [Open in Perplexity](https://www.perplexity.ai/search?q=Read%20https%3A%2F%2Fhunchbite.com%2Fguides%2Ffintech-software-development%20and%20help%20me%20apply%20it%20to%20my%20situation.%20Answer%20my%20questions%20about%20it.) FAQ Does every fintech product need PCI-DSS compliance? Only if you store, process, or transmit cardholder data (credit/debit card numbers, CVVs, expiry dates). If you use a payment gateway like Razorpay or Stripe and never touch raw card data — the gateway handles it, your backend only receives a token — you may qualify for SAQ A (the simplest compliance tier). But if you're building a payment processor, acquiring bank, or any system that touches raw card data, full PCI-DSS compliance is required. What is the Account Aggregator framework and why does it matter for Indian fintech? The Account Aggregator (AA) framework is RBI's consent-based financial data sharing system. It allows users to share financial data (bank statements, investment holdings, tax returns) with financial service providers through a standardized, consent-managed API — without sharing credentials. For Indian fintech building lending, wealth management, or credit products, integrating with the AA framework is increasingly essential and will likely become mandatory for certain use cases. How do you handle KYC in a scalable fintech product? Most teams use a third-party KYC provider (Aadhaar-based eKYC through UIDAI, video KYC, or document verification APIs from providers like IDfy, Hyperverge, or Digilocker). The critical architectural decision is how you store and audit KYC status — you need an immutable record of what was verified, when, by what method, and what the outcome was. KYC status must be re-verified periodically and when risk signals change. Next step ## Build fintech that survives production and audits. Hunchbite builds payment infrastructure, lending platforms, and financial data products with compliance and reconciliation designed in from day one. We will map your regulatory scope, choose the integrations that fit, and architect the ledger, idempotency, and fraud layers correctly the first time. [Book a Free Call](https://cal.com/hunchbite/discovery)[Industry-Specific Software](https://hunchbite.com/industry-specific-software) Trusted by VMAC Industries, TKD Logistics, Astitva Jewellery & more. [See our on-demand manufacturing platform build →](https://hunchbite.com/case-studies/manufacturing-platform) Fixed-price, no hourly billing · No obligation · We tell you upfront if we're not a fit Continue Reading [Industry SoftwareSoftware Development for Finance and FintechA guide to building fintech software — payment platforms, banking applications, investment tools, and the regulatory, security, and compliance challenges unique to financial technology.12 min read](https://hunchbite.com/guides/software-development-fintech) [Industry SoftwareBuilding GDPR-Compliant SaaS: The Technical Guide for Founders and EngineersA practical technical guide to GDPR compliance for SaaS products — what the regulation actually requires engineers to build, lawful basis for processing, data subject rights implementation, consent management, and the architecture decisions that make compliance sustainable.13 min read](https://hunchbite.com/guides/gdpr-compliant-saas-technical-guide) [All Guides](https://hunchbite.com/guides)