Building Fintech Software: Compliance, Banking APIs, and What Breaks in Production

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 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.

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 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 →

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 — 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.