FINTECH  •  API ARCHITECTURE  •  INDIA NEO-BANKING

By C B Mishra  •  Strategic Technical Project Manager  •  Led Neo-Banking Platform Delivery  •  Decentro, Razorpay, Stripe Integrations  •  cbmishra.com

In 2022–2023 I led the end-to-end delivery of a secure neo-banking mobile platform for an Indian fintech client — a Flutter-based digital banking app integrating Decentro’s Banking-as-a-Service APIs for KYC onboarding, account creation, fund transfers, and dual-recourse capital release workflows.

It was the most technically complex, regulatory-minefield, sleep-depriving, and ultimately rewarding project of my consulting years. It also taught me things about building fintech applications in India that I have never seen documented honestly anywhere.

The blogs you find about ‘how to build a fintech app in India’ are either marketing copy from API vendors or surface-level architecture overviews. They don’t tell you what happens when Decentro’s sandbox doesn’t replicate production edge cases. They don’t tell you what RBI’s co-origination norms mean for your API contract design. They don’t tell you how to build a transaction state machine that handles every failure mode in a payment flow — including the ones that happen at 2 AM when no one is watching.

This blog tells you those things. From first principles, from the scar tissue.

📌   Scope of this blog: This is a technical leadership and architecture blog — not a code tutorial. The target audience is CTOs, TPMs, product managers, and senior engineers building or evaluating fintech platform delivery in India. Code snippets are illustrative. Architecture decisions are real.

1. The India Fintech Landscape: What Makes It Uniquely Complex

Building a banking or payments product in India is not like building one in the US or EU. The regulatory environment, the infrastructure layer, the KYC requirements, and the payment rail architecture are all deeply India-specific — and none of them behave the way Western fintech architecture patterns assume they will.

The RBI Regulatory Layer

The Reserve Bank of India sits above every financial product decision you make. You are not building a product — you are building a regulated entity’s technology stack. Every feature that touches money movement, customer identity, or credit requires either direct RBI licensing or a regulated partner holding the license on your behalf.

For most neo-banking startups that can’t or don’t want to hold their own banking license, the answer is a Banking-as-a-Service (BaaS) provider — a licensed NBFC or bank that exposes their regulated infrastructure via APIs. In India, the primary players are Decentro, RazorpayX, Open, and Yodlee. Each has different license coverage, different API maturity, and different operational reliability in production.

If You Hold Your Own License	If You Use a BaaS Provider
Full control over product features	Faster time to market (weeks vs years)
Higher compliance burden (RBI audits, CKYC)	Compliance partially delegated to BaaS partner
Direct access to NPCI rails (UPI, IMPS)	API-mediated access — rate limits and SLAs apply
Capital requirement: ₹200 Cr+ for NBFC	No direct capital requirement
Viable at Series B+ scale	Viable at MVP to Series A scale
Full data ownership	Shared data governance with BaaS partner

For our project, the client was at MVP-to-Series-A stage. BaaS via Decentro was the right architectural choice. But that choice came with constraints that shaped every subsequent API design decision.

The KYC Complexity in India

Know Your Customer in India is not a single process. It is a layered, document-dependent, government-API-connected workflow that involves multiple verification steps, each with its own failure modes, latency characteristics, and regulatory requirements.

KYC Layer	Data Source / API	Common Failure Mode
PAN Verification	NSDL / ITD via Decentro	Name mismatch between PAN and bank records
Aadhaar OTP eKYC	UIDAI via Decentro	OTP delivery failure on non-Aadhaar linked mobiles
Bank Account Verification	Penny drop / NACH via Decentro	Account inactive or recently opened — penny drop fails
Face Match / Liveness	Decentro AI / third-party	Low-light selfie rejection rate 8–15% in field testing
CKYC Registry Lookup	CERSAI via Decentro	Slow response times (3–8s) causing UX timeout issues
Video KYC (V-KYC)	Regulated: requires live agent	Agent availability SLA breaks during peak hours

🚨   The most dangerous assumption in KYC design: that it is a linear, sequential process. In production, KYC is a branching tree with dozens of exception paths. A user whose PAN is linked to a different mobile number than their Aadhaar. A user whose bank account was opened last week and hasn’t propagated to NACH. A user whose face match fails three times because they’re wearing glasses. Every branch needs a handled state — or it becomes a support ticket, then a churn event, then a regulatory exposure.

2. Decentro Deep Dive: What the Documentation Doesn’t Tell You

Decentro is one of India’s most capable Banking-as-a-Service infrastructure providers. Their API coverage is broad — KYC, account issuance, fund transfers, payment collection, co-lending, and more. Their documentation is reasonably good by Indian fintech standards. But ‘reasonably good’ still leaves significant gaps that you will discover in production if you don’t go looking for them first.

Gap 1: Sandbox vs Production Behaviour Divergence

This was our most costly discovery. Decentro’s sandbox environment is designed to let you test the happy path — a successful KYC flow, a successful fund transfer, a successful account creation. The sandbox does not replicate production error states accurately. Several error codes that appear in production either don’t appear in sandbox, or appear with different HTTP status codes, or appear with different response payload structures.

📖   Real example: In sandbox, a failed penny-drop verification returned HTTP 200 with a ‘status: failed’ field in the JSON body. In production, the same failure returned HTTP 422 with a completely different error schema. Our error handler was parsing the sandbox response format. In production, it threw an unhandled exception, which left the user’s KYC in a ‘pending’ state with no recovery path — and no alert to the operations team. We discovered this on Day 3 of production. It had affected 31 users. None of them knew they were stuck.

How we fixed it: We rebuilt our error handler to be schema-agnostic — parsing Decentro responses defensively, with a fallback state machine that treated any unexpected response as a ‘needs review’ state rather than a clean success or failure. Every unexpected response triggered an internal alert. This is the architecture we should have built from day one.

Gap 2: Rate Limits Are Not Documented Per Endpoint

Decentro’s general documentation mentions rate limits. What it doesn’t document clearly is that different endpoints have different rate limits — and some of those limits are surprisingly low for production-scale onboarding flows. The CKYC lookup endpoint, in particular, had a rate limit that our load testing revealed would be breached during peak onboarding hours if we didn’t implement request queuing.

We implemented an internal request queue with Redis, with per-endpoint rate tracking and automatic backoff. This added two sprints to the integration timeline. If we’d known about the endpoint-specific limits in Sprint 1, we would have designed the queue from the start.

Gap 3: Webhook Reliability Is Not Guaranteed

Decentro (like most BaaS providers) uses webhooks to deliver asynchronous event notifications — KYC status updates, transfer completions, account activations. The assumption baked into their documentation is that webhooks are reliable. They are not. Webhooks are HTTP requests from their infrastructure to yours. They fail when your server is temporarily unreachable. They fail under load. They arrive out of order. They occasionally don’t arrive at all.

Every financial event in our system was designed on the principle that a webhook is a notification, not a source of truth. For every critical state transition, we implemented a polling fallback — if no webhook arrived within 30 seconds of an expected event, the system polled the Decentro status endpoint directly. The webhook, when it arrived, confirmed the state. It never defined it.

💡   Architecture principle for any BaaS integration: Treat webhooks as unreliable notifications. Design your state machine so that the system is always recoverable by polling — webhooks are a performance optimisation, not a correctness guarantee. Any system that can only function if webhooks arrive correctly is a system with a production incident waiting to happen.

Gap 4: The Co-Origination and Dual-Recourse Complexity

Our client’s product included a dual-recourse capital release mechanism — a flow where funds were held in escrow and released to counterparties only upon confirmed dual authorisation. This is common in NBFC lending and supply chain finance products.

Implementing this with Decentro’s API required understanding their virtual account and escrow flows at a depth that went significantly beyond their public documentation. The key constraint: Decentro’s escrow release is not atomic. The release request is accepted asynchronously, and the actual fund movement happens in a separate event. Between acceptance and execution, there is a window. If your application logic assumes atomicity — ‘I called the release API, therefore the money moved’ — you will have unreconciled transactions.

We built an explicit ‘release pending’ state in our transaction model, with a maximum pending window, an automatic escalation if the window was exceeded, and a daily reconciliation job that compared our internal transaction ledger against Decentro’s statement API. Three times in the first month, the reconciliation job caught discrepancies that the webhook had not surfaced. All three were resolved without user impact because we were watching.

🚨   The single most important principle in fintech API integration: Every money-movement action must have a corresponding reconciliation job. Not a daily report. Not a manual audit. An automated, scheduled comparison between your internal ledger and the upstream provider’s ledger — running at least daily, alerting on any discrepancy above zero. If your transaction model assumes the API is always right, you will have unexplained money disappear from your system in production.

3. The Transaction State Machine: The Architecture That Makes or Breaks a Fintech App

The single most important architectural decision in any fintech application is the design of the transaction state machine. Everything else — the UI, the API layer, the database schema — is secondary. A well-designed state machine makes a fintech product recoverable from any failure. A poorly designed one makes every production incident a potential financial loss.

What a Transaction State Machine Is

A transaction state machine defines every possible state a financial transaction can be in, every valid transition between states, and every action that must occur on each transition. It is the formal specification of how money moves through your system — and how it behaves when something goes wrong.

For our neo-banking app, every fund transfer had the following state model:

1	INITIATED User has submitted transfer. Request validated locally. Not yet sent to Decentro.

2	SUBMITTED API call made to Decentro transfer endpoint. Awaiting async response.

3	PROCESSING Decentro acknowledged receipt. Transfer in NPCI/IMPS queue.

4	COMPLETED Decentro confirmed credit to beneficiary. Reconciliation verified.

5	FAILED Decentro returned failure OR polling timeout exceeded. Funds not moved.

6	REVERSED Debit reversed to source account. Confirmation reconciled.

7	NEEDS_REVIEW Unexpected API response. Automatic escalation to ops team.

Every transition between states was explicit. You could not move from SUBMITTED to COMPLETED without a Decentro confirmation event. You could not move from PROCESSING to COMPLETED without reconciliation. The NEEDS_REVIEW state was the catch-all — any response that didn’t map to a known transition landed there, triggered an alert, and waited for human review before any further action.

The NEEDS_REVIEW State: Your Most Valuable Architecture Decision

Most junior engineers design state machines with three states: pending, success, failed. This is wrong for fintech. The real world has a fourth state: unknown. The API call went out but the response was ambiguous. The webhook arrived but the data was malformed. The transfer completed on Decentro’s side but your server was down when the confirmation came.

The NEEDS_REVIEW state is not a bug — it is a designed safety mechanism. Any transaction in NEEDS_REVIEW cannot be retried, cannot be shown as complete, and cannot be reversed automatically. It is frozen, visible to the operations team, and requires human decision before proceeding. The cost of a NEEDS_REVIEW event is one support ticket. The cost of a NEEDS_REVIEW event handled by automatic retry logic is potentially a double-debit.

📖   Production incident, Month 2: A network timeout on our server caused a fund transfer API call to Decentro to receive no response. The transfer had actually been processed on Decentro’s side. Our state machine, correctly, placed the transaction in NEEDS_REVIEW. Our operations team received the alert, checked Decentro’s transaction API, confirmed the transfer was complete, and manually moved the state to COMPLETED. Total user impact: a 4-minute delay in transfer confirmation notification. Without the NEEDS_REVIEW state, our retry logic would have submitted the transfer again. The user would have been debited twice.

Idempotency: The Principle That Prevents Double-Debits

Every API call to a payment provider must be idempotent. This means: sending the same request twice must produce the same result as sending it once — not double the result. For fund transfers, this is existential. If your retry logic sends the same transfer request twice, and the first request succeeded silently, the second will debit the user again.

Decentro supports idempotency keys — a unique identifier you include in the request header that allows their system to deduplicate requests. We generated an idempotency key for every transaction at the INITIATED state — before the first API call was ever made. That key travelled with the transaction through every retry. Decentro’s system guaranteed that the same idempotency key would never result in two debits, regardless of how many times we sent the request.

📌   Implementation rule: Idempotency keys must be generated from your internal transaction ID — not random UUIDs per attempt. If you generate a new key on every retry, you lose idempotency protection. One transaction = one idempotency key = generated at creation, never changed.

4. KYC Onboarding Architecture: Building for Real Indian Users

The KYC onboarding flow is the first experience a user has with your neo-banking product. In India, it is also the most technically complex, most failure-prone, and most regulated part of the product. Get it wrong and you lose users before they ever see the product. Get it wrong in a specific way and you also get a regulatory notice.

The Onboarding Flow We Built

1	Mobile Number Capture + OTP Verification Firebase OTP or Decentro mobile verification. Handle: SIM swap detection, VoIP number rejection, OTP retry limits.

2	PAN Entry + Instant Verification Decentro PAN verification API. Handle: Name mismatch (allow fuzzy match up to 85% similarity), PAN linked to deceased, invalid PAN format.

3	Aadhaar OTP eKYC UIDAI via Decentro. Handle: Non-linked mobile, OTP non-delivery, UIDAI downtime (falls back to offline XML flow), consent capture and audit log.

4	Face Liveness + Match Decentro liveness SDK or third-party. Handle: Low light, glasses/mask, liveness score threshold calibration — 3 attempts before V-KYC escalation.

5	Bank Account Verification (Penny Drop) Decentro penny drop API. Handle: Inactive account, joint account mismatches, recently opened accounts (24–48hr propagation delay).

6	CKYC Registry Lookup CERSAI via Decentro. Handle: No CKYC record (proceed to fresh KYC), stale data (flag for manual review), timeout fallback.

7	Account Activation Decentro virtual account issuance. Handle: Deduplication check (existing account), activation delay, welcome communication trigger.

The Resumable KYC Session: Non-Negotiable Architecture

Users drop out of KYC flows. Their OTP doesn’t arrive. Their phone dies at step 4. They complete PAN verification and then get distracted for three days. If your KYC flow doesn’t support resumption from the last completed step, you are forcing users to restart the entire process — and in India, where KYC involves government API calls with rate limits, restarting means burning API credits and risking UIDAI rate limit exposure.

Every KYC step in our system wrote its result to a persistent session object with a step identifier, a timestamp, and a hash of the verified data. When a user returned to the app, the system read the session, identified the last completed step, and resumed from there. No step was ever repeated if it had already succeeded.

The Consent and Audit Trail Architecture

Every KYC action in India requires documented user consent. The RBI is explicit: you must be able to prove, at any point in time, that the user consented to each data access and verification step — with a timestamp and the specific scope of consent granted.

We built a consent ledger — an append-only database table recording every consent event: what was consented to, when, on which device, with which IP address, and with which version of the consent text. This table could never be updated or deleted — only appended to. In the event of a regulatory query, we could produce a complete, tamper-evident consent history for any user in under 30 seconds.

⚠️   Regulatory reality check: The RBI’s data localisation requirements mean all KYC and financial data for Indian users must be stored on servers physically located in India. If your cloud architecture defaults to multi-region with foreign data centres, you have a compliance problem. AWS Mumbai, GCP Mumbai, or Azure Central India are your compliant options. Confirm your BaaS provider’s data residency before signing any contract.

5. Payment Gateway Integration: Razorpay and Stripe in the Same Ecosystem

Our platform required two payment rails: Razorpay for domestic INR transactions (UPI, IMPS, NEFT, debit card) and Stripe for international card payments from NRI customers. Operating both in the same transaction ecosystem created architectural challenges that neither provider’s documentation prepares you for.

The Currency Reconciliation Problem

Stripe processes in USD (or the card’s billing currency). Razorpay processes in INR. Our internal ledger needed to maintain a single source of truth for account balances. This requires a currency conversion event at the point of transaction posting — not at the point of display. We used RBI’s reference rate, fetched daily via API, and recorded the exchange rate used in every cross-currency transaction as an immutable field. Any reconciliation discrepancy could then be explained by the rate differential.

Webhook Signature Verification: Both Providers, Different Implementations

Both Razorpay and Stripe use webhook signatures to let your server verify that a webhook came from them — not from a malicious actor. The implementations are different, and both are mandatory in a production fintech application. A system that processes webhooks without signature verification is vulnerable to payment injection attacks — an attacker sending a fake ‘payment successful’ webhook to your server.

Razorpay Webhook Verification	Stripe Webhook Verification
HMAC-SHA256 signature	HMAC-SHA256 signature
Key: your Razorpay webhook secret	Key: Stripe webhook signing secret (per endpoint)
Header: X-Razorpay-Signature	Header: Stripe-Signature (includes timestamp)
Compute: HMAC of raw request body	Compute: HMAC of timestamp + ‘.’ + raw body
Compare: computed vs header value	Compare: computed vs parsed signature value
Failure response: 400 Bad Request	Failure response: 400 Bad Request

Both verifications must happen before any business logic executes. If the signature is invalid, the request is rejected silently — no error message, no acknowledgment. This prevents attackers from learning whether their forged request had the right structure.

The Idempotency Challenge Across Two Providers

Razorpay and Stripe both support idempotency keys, but their scoping is different. Stripe’s idempotency keys are scoped per API key — meaning the same key can be reused across different Stripe accounts. Razorpay’s keys are scoped per merchant. If you’re managing multiple client accounts on the same platform, your idempotency key generation logic must incorporate the account identifier to prevent cross-account collisions.

6. Flutter Architecture for a Financial Application

The client platform was built in Flutter — Dart-based, cross-platform, single codebase for iOS and Android. Flutter is an excellent choice for fintech UI: smooth animations, consistent rendering across platforms, and strong state management options. But fintech applications have specific Flutter architecture requirements that generic Flutter tutorials do not cover.

State Management: Why BLoC Is the Right Choice for Fintech

Flutter has multiple state management options: Provider, Riverpod, GetX, MobX, BLoC. For a fintech application, BLoC (Business Logic Component) is the correct choice — not because it’s the most popular, but because it enforces unidirectional data flow and explicit state representation, which maps directly to financial state machine requirements.

In BLoC, every state is an explicit, named class. TransactionInitiated, TransactionProcessing, TransactionCompleted, TransactionFailed, TransactionNeedsReview — each is a distinct state object. This makes it impossible to accidentally display ‘Transfer Successful’ when the underlying state is NEEDS_REVIEW, because the UI layer renders based on the state type, not a boolean flag.

Certificate Pinning: Non-Optional in a Banking App

Certificate pinning means hardcoding the SSL certificate fingerprint of your API servers into the app, so that the app refuses to communicate with any server that doesn’t present the exact certificate — even if that server has a valid CA-signed certificate. This prevents man-in-the-middle attacks on rooted or compromised devices.

In Flutter, certificate pinning is implemented via the `SecurityContext` or via a plugin like `ssl_pinning_plugin`. It is not optional for any application that transmits financial data. The implementation cost is one sprint. The cost of a man-in-the-middle attack on a banking application is existential.

Jailbreak and Root Detection

A rooted Android device or jailbroken iOS device can bypass certificate pinning, intercept API calls, and access local storage. Your fintech application must detect compromised devices and refuse to operate on them. We used a combination of Flutter’s `flutter_jailbreak_detection` plugin and custom checks (presence of known root binaries, modified system properties) to detect compromise at app startup. On detection: the app displayed a regulatory-compliant message and refused to proceed. No exceptions for ‘power users.’

💡   Security is not a feature sprint — it is a baseline. Certificate pinning, root detection, biometric authentication, and encrypted local storage are not premium features for a fintech app. They are the minimum viable security posture. Any fintech product launched without all four of these is not ready for production.

7. The Compliance Architecture: Building for RBI Scrutiny

Every Indian fintech product will, at some point, face regulatory scrutiny — either a routine audit from your BaaS partner’s compliance team, an RBI inspection, or a data localisation query. Building the compliance architecture retroactively is five times harder than building it from the start. Here is what we built in from Day 1.

The Four Compliance Pillars We Built

Pillar 1: Immutable Transaction Ledger

The core transaction table in our database was append-only. No transaction record could be updated or deleted — only new records appended. Corrections and reversals were new records, referencing the original transaction ID. This gave us a complete, tamper-evident financial history that could satisfy any audit requirement.

Pillar 2: PII Encryption at Rest

All personally identifiable information — PAN numbers, Aadhaar references, bank account details, mobile numbers — was encrypted at the database field level using AES-256, with keys managed separately from the database. Even a full database dump would be unreadable without the encryption keys. Field-level encryption, not just database-level encryption. The distinction matters to the RBI.

Pillar 3: Audit Log for Every State Change

Every state change in the system — KYC step completion, transaction state transition, admin action, configuration change — wrote a record to an audit log: who triggered it, when, from which IP, in which user session, and what the before/after state was. This log was separate from the application database, write-only for the application, and accessible only to compliance roles.

Pillar 4: Automated Regulatory Reporting Hooks

The RBI requires various reports: suspicious transaction reports (STR), cash transaction reports (CTR), and others depending on the product category. We built reporting hooks into the transaction processing pipeline — not as a post-processing job, but as a triggered evaluation at transaction completion. A transaction that met STR criteria was flagged at the moment of completion, not discovered in a monthly audit.

🎯   What compliance infrastructure costs you: 3–4 additional sprints at the start of the project. What it saves you: months of retroactive rework when your BaaS partner’s compliance team audits your implementation, plus the regulatory risk of operating without it. In fintech, compliance is not overhead — it is the foundation on which the entire product sits.

8. The Things Nobody Tells You (And That Cost You the Most)

Nobody Tells You: Your BaaS Provider Will Have Downtime

Decentro, Razorpay, UIDAI — every infrastructure provider in India’s fintech stack will have downtime. The question is not whether your BaaS provider will go down. The question is what your application does when it happens. We built a ‘degraded mode’ for every critical user flow: if Decentro’s KYC APIs were unreachable, the app displayed an honest status message and offered to notify the user when service resumed. No silent failures. No error code 500 with no explanation. User trust survives a service outage. It does not survive a confusing unexplained failure.

Nobody Tells You: NPCI Has Maintenance Windows

India’s National Payments Corporation of India (NPCI) — the organisation that runs UPI, IMPS, NACH, and RuPay — has scheduled maintenance windows every month, typically on the last Sunday between 1 AM and 3 AM. During these windows, real-time payment processing is suspended. Your application must be aware of these windows and communicate them to users proactively — not let them discover a failed transfer at 1:30 AM with no explanation.

Nobody Tells You: The Penny Drop Has a 2–3% Failure Rate on Valid Accounts

The penny drop process — depositing ₹1 to a bank account to verify its validity — has a persistent background failure rate on accounts that are legitimately valid but have specific bank-side conditions: recently opened (less than 48 hours), dormant, or linked to banks with slow IMPS processing. A 2–3% failure rate on a penny drop means 2–3 out of every 100 legitimate users will fail your bank verification step and need an alternative verification path. We built a manual verification fallback — upload a cancelled cheque or bank statement — for penny drop failures, with a 24-hour review SLA. Without this, those users are permanently blocked.

Nobody Tells You: The App Store Review Is a Separate Compliance Layer

Apple App Store and Google Play Store both have specific policies for financial applications that are separate from and in addition to regulatory requirements. Apple requires explicit approval for apps that facilitate money transmission. Google requires financial services applications to register and verify their regulatory status. Both can reject app updates if your payment-related UI doesn’t meet their guidelines — including guidelines around how you display interest rates, fees, and terms.

We had one app update rejected by Apple because a screen in the loan origination flow didn’t display the annual percentage rate prominently enough — even though the disclosure was technically present. The rejection came 3 days before a client-committed launch date. Build App Store compliance review time into every release cycle. Never assume an update will be approved on the first submission.

🚨   The most expensive line item in fintech product delivery that no client budget ever includes: third-party API integration debugging time. Every BaaS API will behave differently in production than in sandbox. Every payment gateway has undocumented edge cases. Every government API has intermittent availability. Budget 30–40% of integration sprint time for debugging, not just implementation.

9. The Architecture Checklist: What a Production-Ready India Fintech App Needs

API Integration Layer

• Idempotency keys generated at transaction creation, never regenerated on retry
• Webhook signature verification for every provider, before any business logic
• Polling fallback for all async operations — webhooks are notifications, not guarantees
• Per-endpoint rate limit tracking with automatic request queuing
• Sandbox-to-production parity testing — explicitly test every documented error code in production pre-launch

Transaction Architecture

• State machine with explicit NEEDS_REVIEW state for all ambiguous outcomes
• Immutable transaction ledger — append only, no updates or deletes
• Daily automated reconciliation against upstream provider statements
• Dual-entry bookkeeping — every financial event creates both a debit and a credit record
• Transaction timeout handling — maximum pending window, automatic escalation on breach

KYC and Compliance

• Resumable KYC sessions — no step repeated if already successfully completed
• Consent ledger — append-only, tamper-evident, per-step consent with timestamp
• PII encryption at field level — AES-256, keys managed separately
• Data localisation — all Indian user data on India-region cloud infrastructure
• Regulatory reporting hooks — STR/CTR triggers at transaction completion, not in batch

Application Security

• Certificate pinning — implemented and tested on both iOS and Android
• Jailbreak/root detection — refuse operation on compromised devices
• Biometric authentication — for all money-movement confirmation flows
• Session token rotation — token refreshed on every sensitive operation
• Audit log for every admin action, state change, and configuration update

Operational Readiness

• Degraded mode UX — honest messaging when upstream services are unavailable
• NPCI maintenance window awareness — proactive user communication
• Penny drop fallback — manual verification path for failed automated verification
• 24/7 alerting — financial anomalies and NEEDS_REVIEW states trigger immediate alerts
• App Store compliance pre-review — every release cycle, before submission

Final Thoughts: Fintech Is Not a Feature — It’s a Responsibility

Building a neo-banking application in India is one of the most technically demanding, regulatorily constrained, and consequentially high-stakes product categories in existence. When your code has a bug, real people lose real money. When your state machine has an unhandled case, real transactions disappear. When your compliance infrastructure is incomplete, real regulatory exposure accumulates.

The industry has a tendency to celebrate the launch — the app store listing, the press release, the first transaction. What deserves celebration is the architecture that makes that first transaction trustworthy. The reconciliation job that ran at 3 AM and found nothing wrong. The NEEDS_REVIEW state that caught a network timeout and prevented a double-debit. The consent ledger that made a regulatory query answerable in 30 seconds.

The unglamorous infrastructure is the product. Everything the user sees is just the surface.

Build the surface beautifully. But build the infrastructure first, and build it correctly — because in fintech, there is no ‘we’ll fix it later.’ There is only ‘it works correctly’ or ‘someone’s money is at risk.’ There is no third option.

C B Mishra  |  Strategic Technical Project Manager  |  cbmishra.com

Available for fintech product consulting, API architecture, and enterprise delivery  •  Book a call