The ledger is an afterthought
The visible product takes an application or shows a balance. Underneath, a ledger has to match the bank to the paisa, every day.
Finance & Fintech
Fintech software development, built to survive an audit
Lending origination and servicing, wallets and UPI rails, wealth platforms and insurance distribution. With the ledger, the consent trail and the reconciliation a regulated business gets asked to produce.
5 solution blueprints
19 systems we integrate
12–24 weeks, typical build
The starting point
What is usually broken before we arrive
The money cannot flow through you
RBI digital lending rules require disbursement and repayment to move between borrower and lender directly. Discover that late and the money flow gets rebuilt.
Due diligence stalls the launch
Access control, encryption, logging, change management, continuity. A bank partner reviews all of it before go-live, and remediation is slow.
In plain terms
Fintech software development is building regulated financial products. Digital lending, payments and wallets, wealth management, insurance distribution. It also covers the parts no demo shows. KYC and identity checks, double-entry ledgers, daily reconciliation against the bank and the payment rail, Account Aggregator consent, and the audit evidence a regulator asks for.
A fintech product is two systems wearing one interface. One takes an application, shows a balance, places an order. The other keeps a ledger that must reconcile against a bank statement, an aggregator report and an NPCI settlement file.
Teams that build the first and defer the second find the gap at exactly the volume where finding it by hand stops being possible.
Regulation is the second difference. RBI digital lending rules dictate where money may flow. Card storage is constrained by tokenisation rules. Account Aggregator data arrives with a consent artefact carrying a purpose and an expiry. These are architectural constraints, not a checklist for the end.
What we build
Finance & Fintech systems, and who builds each one
Every card links to the practice that does the work. Follow one if you want the detail.
Lending origination and servicing
Application capture, bureau and bank-statement underwriting, sanction and e-agreement, disbursement, EMI schedules, collections. One borrower record from lead to closure.
ExploreConsumer finance apps
Wallets, UPI payments, savings and investment journeys on iOS and Android. Device binding, secure local storage, and re-auth that does not train users to tap past warnings.
ExplorePayment, KYC and bureau integrations
UPI and eNACH rails, aggregator APIs, CKYC and DigiLocker identity, Account Aggregator pulls, bureau enquiries. Each with retry, idempotency and reconciliation built in.
ExploreRisk scoring and fraud detection
Models over bank-statement and bureau features for underwriting. Velocity and device-signal rules that flag activity for review instead of blocking silently.
ExplorePortfolio and collections analytics
Disbursement and collection trends, bucket movement, roll rates, DPD ageing, vintage curves, channel-wise approvals. Refreshed daily, not at month end.
ExploreAgent, DSA and partner portals
Onboarding, lead attribution, commission slabs, payout statements and performance dashboards. Role separation keeps customer data need-to-know.
ExploreFinance, GST and reconciliation
Double-entry books, automated matching against bank and aggregator files, GST on fees and commissions, and exports your auditor accepts first time.
Explore Solution blueprints
Open one and see exactly what gets built
The situation it answers, the architecture, every module, the systems it plugs into and how long it takes. These describe our work, not one client's project. Named clients with measured results are in the case studies.
01 Digital lending: origination and loan management 18–24 weeks
The situation
An NBFC, or a lending service provider partnered with one, offering personal or business loans. Applications arrive through a web journey and a field team. Underwriting reads statements manually. Collections run on spreadsheets that disagree with the books by month end.
How it is built
A rules-driven origination service and a separate servicing ledger, both on Node.js with PostgreSQL, joined by an event log so any application journey is reconstructable. Disbursement and repayment move directly between borrower and lender accounts. The platform records, it does not hold.
Rules it has to follow
Built to the RBI Digital Lending Guidelines. Funds move directly between borrower and regulated lender. A Key Fact Statement is issued before acceptance, and every charge is disclosed as an annual percentage rate. Account Aggregator consent artefacts are stored with their purpose and expiry.
Modules 12
- Digital application journey with save and resume
- CKYC and DigiLocker identity verification
- Bank statement analysis and income assessment
- Credit bureau enquiry and score capture
- Configurable underwriting rules with manual override and reasons
- Sanction letter, key fact statement and e-agreement
- Disbursement instruction and status reconciliation
- EMI schedule, part-payment and foreclosure handling
- eNACH mandate registration and presentation
- Collections queues, DPD buckets and field allocation
- Charges, penal interest and GST treatment
- Regulatory and partner reporting extracts
Plugs into
- CKYC registry
- DigiLocker
- Account Aggregator framework
- CIBIL / Experian bureau
- NPCI eNACH
- Digio eSign
02 Wallet and UPI payments app 16–22 weeks
The situation
A consumer or closed-loop business wallet with UPI collection and payout. Balances, limits and settlement have to stay correct under load. The failure that matters is not a crash. It is a double credit, or a ledger that stops matching the bank.
How it is built
An append-only double-entry ledger is the source of truth. Transactions are idempotent, keyed on the rail reference, so a retried callback cannot post twice. Node.js services, PostgreSQL with serialisable isolation on balance paths, and a reconciliation worker consuming settlement files on schedule.
Rules it has to follow
Prepaid instrument limits and KYC tiers follow the RBI PPI master direction. Card data, where present, is tokenised under RBI card-on-file rules and never stored. Manual ledger adjustments need maker-checker approval and stay permanently attributable.
Modules 12
- Double-entry ledger with immutable postings
- Wallet load, spend, transfer and refund flows
- UPI collect, intent and payout handling
- Idempotency and callback replay protection
- KYC tiering with limits per tier
- Daily reconciliation against bank and aggregator files
- Break investigation queue with ageing
- Chargeback and dispute lifecycle
- Velocity rules and device fingerprinting
- Statement generation and export
- Escheatment and dormancy handling
- Operations console with maker-checker on adjustments
Plugs into
- NPCI UPI
- Razorpay
- Cashfree Payouts
- CKYC registry
- Hyperverge liveness check
03 Wealth and investment platform 16–22 weeks
The situation
A distributor or advisory firm offering mutual funds, and increasingly equities and deposits, to retail investors. Onboarding is a paper form. Portfolio statements get compiled per client at month end. SIP failures surface when the client calls.
How it is built
A portfolio service holds units and transactions separately from valuations, so historical returns stay reproducible when NAV corrections arrive. React web and React Native apps on Node.js, with scheduled jobs for NAV refresh, SIP presentation and corporate actions.
Rules it has to follow
Distributor and advisory activity are separated in the data model, so suitability records and commission disclosure follow the applicable SEBI regime. Risk profiling and recommendation events are retained as evidence that advice matched the recorded profile at the time.
Modules 12
- Investor onboarding with KYC status check
- Risk profiling questionnaire and suitability record
- Goal-based planning and recommendation flows
- Lump-sum, SIP, STP and SWP transaction handling
- Mandate registration and SIP presentation tracking
- Portfolio valuation with XIRR and absolute returns
- Corporate action and NAV correction handling
- Capital gains statement and tax reporting
- Advisor and branch hierarchy with brokerage computation
- Consolidated statements and scheduled reports
- SIP failure alerting and retry workflow
- Audit trail on every advice and transaction event
Plugs into
- BSE StAR MF / NSE NMF platform
- CAMS / KFintech RTA feeds
- NPCI eNACH
- CKYC registry
- Digio eSign
04 Insurance distribution and POSP platform 14–20 weeks
The situation
A corporate agent or broker distributing motor, health and term policies through point-of-sale persons. Quotes come from opening several insurer portals side by side. Issuance is manual. Renewals get chased from a spreadsheet. Commission reconciliation takes a week.
How it is built
A quote layer normalises insurer APIs into one comparable structure. A policy service holds the issued contract independently of whichever insurer produced it, so renewals and claim assistance work uniformly across the whole book.
Rules it has to follow
POSP certification and validity are tracked, and quoting is blocked once they lapse, under the IRDAI point-of-sale framework. Commission disclosure and the product categories a POSP may sell are enforced by the platform, not left to the agent memory.
Modules 12
- POSP onboarding, training record and certification tracking
- Multi-insurer quote comparison for motor, health and term
- Vehicle and member detail capture with validation
- Proposal submission and payment link issuance
- Policy document storage and delivery
- Renewal pipeline with staged reminders
- Endorsement and cancellation requests
- Claim intimation and document assistance tracking
- Commission slabs, clawback and payout statements
- Insurer-wise reconciliation of issued policies
- Lead attribution across POSP and digital channels
- Persistency and lapse reporting
Plugs into
- Insurer quote and issuance APIs
- VAHAN vehicle data
- Razorpay
- Digio eSign
- WhatsApp Business API
05 Merchant payments and reconciliation 12–16 weeks
The situation
A platform or large merchant collecting across UPI, cards and netbanking, with a payout leg to vendors. Settlement reports arrive in different formats on different cycles. Finance reconciles in Excel. Unexplained differences get written off at year end.
How it is built
An ingestion pipeline normalises every rail settlement file into one transaction shape. A rules engine matches it against the platform ledger with tolerance windows. Anything unmatched lands in a break queue where it is aged and assigned, never absorbed.
Rules it has to follow
Every posting keeps a link to its source settlement file, so an auditor question resolves to a document instead of an explanation. GST on payment charges and commissions is computed per transaction, which makes the monthly return reproducible.
Modules 12
- Settlement file ingestion across rails and formats
- Normalisation into a common transaction model
- Automated matching with tolerance and date windows
- Break queue with ageing, assignment and resolution notes
- Fee, tax and net-settlement computation per transaction
- Refund and chargeback tracking through to recovery
- Vendor payout batching and status reconciliation
- GST treatment on payment charges and commissions
- Daily cash position and unsettled exposure view
- Exception alerting on threshold breaches
- Auditor extract with full drill-down
- Retention of source files against every posting
Plugs into
- Razorpay settlement reports
- Cashfree Payouts
- NPCI UPI settlement files
- Bank statement feeds (MT940 / CAMT)
- Tally ERP
Regulation
What fintech software has to comply with in India
Get these wrong and the build is not late, it is unusable. They are design inputs on day one.
RBI Digital Lending Guidelines
Money must move directly between borrower and regulated lender. A lending service provider may not route disbursement or repayment through its own pooled account. A Key Fact Statement with the all-in annual rate goes out before acceptance, and recovery agent details are disclosed to the borrower.
Account Aggregator framework
Data pulled through the AA network arrives with a consent artefact carrying a purpose, a data range and an expiry. Keeping the data past that consent, or using it for something else, is the breach. So consent has to be a first-class object in the schema, not a checkbox on a form.
PCI-DSS and RBI card tokenisation
Card numbers are not stored. The rail issues a token and the platform holds only that, plus the last four digits and the network for display. This removes most of the PCI-DSS surface, and what remains is what the annual assessment covers.
CKYC, DigiLocker and video KYC
Identity verification runs through the CKYC registry and DigiLocker-issued documents instead of uploaded photographs, with liveness checks where the risk tier requires them. Verification evidence stays against the customer record for the period the regulator specifies.
Partner technology due diligence
An NBFC or bank partner reviews access control, encryption, secrets management, logging, retention, change approval, penetration test results and continuity plans before go-live. Build these as standing practice and the review becomes a document exercise instead of a remediation project.
Why Naryon Tech
How we approach fintech projects
- The ledger is designed before the screensBalances come from immutable double-entry postings, never an updated column. It costs a little in month one and saves the quarter where finance and engineering disagree about a number.
- Built for the partner due diligenceAccess control, encryption, logging, secrets and change approval are in place from sprint one, because a bank partner asks for all of it and remediation is slower than doing it once.
- Reconciliation is a feature, not a spreadsheetRail settlement files get ingested and matched automatically. Unmatched items age in a queue with an owner. Differences are resolved while they are still traceable.
- Idempotency on every money pathPayment callbacks retry, networks drop mid-request, users press the button twice. Every balance-affecting operation is keyed and replay-safe, so one event cannot post twice under load.
Tooling
What we build fintech systems with
Application
- React
- React Native
- Node.js
- TypeScript
Data & ledger
- PostgreSQL
- Double-entry ledger
- Redis
- Event sourcing
Rails & identity
- NPCI UPI
- NPCI eNACH
- CKYC
- DigiLocker
- Account Aggregator
Security
- HSM / KMS key management
- AES-256 at rest
- Maker-checker workflows
- Immutable audit logs
Working from Chennai and Trichy, with clients in
- Chennai
- Tiruchirappalli (Trichy)
- Coimbatore
- Madurai
- Salem
- Erode
- Tirunelveli
- Vellore
- Tiruppur
- Puducherry
Straight answers
Finance & Fintech: what people ask us first
Do we need our own NBFC licence to launch lending?
Not necessarily. Many platforms operate as a lending service provider partnered with a licensed NBFC or bank. That is faster to launch, and it is how most Indian digital lenders started. It does not change the RBI Digital Lending Guidelines. Money still moves between borrower and lender directly, so the architecture stays the same.
How do you keep the ledger correct when callbacks repeat?
Every balance-affecting operation is idempotent and keyed on the rail own reference, so a retried or duplicated callback posts once. Postings are immutable, and balances are derived from them instead of stored. A reconciliation worker then matches the day settlement file against those postings and raises anything unmatched into a break queue with an owner.
What does Account Aggregator give us over PDF bank statements?
Data arrives structured and straight from the bank, not as a PDF that may have been edited. That improves underwriting quality and removes a manual review step. It also arrives with a consent artefact stating purpose and expiry, so the compliance position is documented by design instead of argued afterwards.
Can you work with our partner existing core system?
Yes, and often that is the right call. We build the origination journey and the customer-facing product, then integrate with the partner loan management or core system for servicing. Where their system cannot support a feature, we keep a shadow ledger for that feature and reconcile the two instead of duplicating the whole book.
How long does a lending platform take?
Eighteen to twenty-four weeks for origination and servicing together, assuming partner integrations are ready when we need them. The variable is rarely our development speed. It is how fast the lending partner technology team can provision sandbox access, which is worth chasing on day one instead of in month three.
What security review should we expect before go-live?
A partner bank or NBFC typically reviews access control, encryption, secrets management, logging and retention, change management and continuity, plus an independent penetration test. We build to that list from the start and hand over the evidence pack alongside the code, so the review reads as documentation instead of a list of fixes.
Close to this
Related industries
Building something for fintech?
Tell us the workflow that keeps breaking. We will say honestly whether software fixes it, and what it would take.