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 way we build is different, and it starts before the first line of code with a question most teams answer too late: what licence are you working under, and whose?

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

The most common design 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 data fix for a mismatch, and within a year nobody can explain why the total of the balances does not match the money in the bank.

A balance is not a number you store. It is the sum of a ledger that can never be changed. Every movement of value is a double-sided entry, entries can only be added, and a correction is a reversing entry that leaves the original safe and visible. For any account at any moment in the past, the system must work out a balance from its entries. That balance must match the bank statement, every single day, automatically, with an alarm on any mismatch. This is not optional and it is not something you add in year two.

UPI is not a payment gateway

UPI is a bank-to-bank rail, and it fails in its own ways. 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 state where you cannot be sure it worked or failed — and the only right action is to keep asking for the status, waiting a little longer each time, until the rail tells you.

So: idempotency keys on every request, so a retry cannot debit twice. A status check job that sweeps pending transactions instead of waiting for callbacks to arrive. Never mark a payment successful on a callback alone; check with the rail. And match the money against the NPCI settlement file, because a payment succeeding and the money arriving are two different events, a day apart and sometimes split by a dispute.

KYC has tiers, and the tier decides the product

eKYC through Aadhaar has limits on who may use it and how. Video KYC has a process set by RBI with recording, geotagging and a real person. Minimum KYC limits what a wallet may hold and what it may do. CKYC lets you fetch an existing record instead of collecting it again.

These are product decisions dressed up as rules, and they must be made before design, not during it. A wallet whose limits change when a user completes full KYC needs that built as clear steps from the first sprint. Adding it later means changing every transaction path in the code, and you will miss one.

The unglamorous rest

Data localisation: payment data stays in India, full stop. PCI-DSS scope, kept small by never touching a card number — use tokens and the gateway's hosted fields, and keep your servers out of scope entirely. Audit logs that can only be added to and that an engineer with live-system access cannot edit. Separate environments with test rails. And a guide 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 on the way.