Fintech Software Development

Fintech is the one domain where a bug is not a bug. It is a reconciliation break, a regulatory breach, or somebody's salary that did not arrive. The engineering discipline is different, and it starts before the first line of code with a question most teams answer too late: what licence are you operating under, and whose?

Every rupee is double-entry. There is no shortcut.

The most common architectural failure we are called in to fix is a fintech product where the balance is a column on the users table. It gets updated in a transaction, somebody writes a migration to fix a discrepancy, and within a year nobody can explain why the sum of the balances does not match the money in the bank.

A balance is not a number you store. It is the sum of an immutable ledger. Every movement of value is a double-sided entry, entries are append-only, and a correction is a reversing entry that leaves the original intact and visible. The system must be able to produce, for any account at any moment in history, a balance derived from its entries — and that derived balance must tie out against the bank statement, every single day, automatically, with an alarm on any break. Building this is not optional and it is not something you add in year two.

UPI is not a payment gateway

UPI is an interbank rail, and its failure modes are its own. A collect request can be approved by the user thirty seconds after your system timed it out. A callback can arrive twice, or never. A transaction can sit in a genuinely indeterminate state where neither success nor failure is a safe assumption — and the only correct action is to query status, with backoff, until the rail tells you.

So: idempotency keys on every request, so a retry cannot debit twice. A status reconciliation job that sweeps pending transactions rather than trusting callbacks to arrive. Never mark a payment successful on a callback alone; verify against the rail. And a settlement reconciliation against the NPCI file, because the payment succeeding and the money arriving are two different events separated by a day and, occasionally, by a dispute.

KYC has tiers, and the tier decides the product

eKYC through Aadhaar has constraints on who may use it and how. Video KYC has an RBI-prescribed process with recording, geotagging and a real human. Minimum KYC caps what a wallet may hold and what it may do. CKYC lets you fetch an existing record rather than collecting it again.

These are product decisions wearing compliance clothing, and they must be made before design, not during it. A wallet whose limits change when a user completes full KYC needs that modelled as a state machine from the first sprint. Bolting it on afterwards means touching every transaction path in the codebase, and you will miss one.

The unglamorous rest

Data localisation: payment data stays in India, full stop. PCI-DSS scope, minimised by never touching a card number — tokenise, use the gateway's hosted fields, and keep your servers out of scope entirely. Audit logs that are append-only and that an engineer with production access cannot edit. Segregated environments with sandbox rails. And a runbook for the day the rail is down, because it will be, and "we will figure it out then" is not a plan when money is in flight.