Building on the UPI rails themselves? PSP banks, NPCI certification, the deemed state, and what the September 2026 MDR notification changes: UPI Switch Infrastructure: How to Build It →
Building cash and treasury software for small businesses? The eight steps, the four lines that turn it into a regulated business, and the IRN that makes a receivable real: SME Treasury: How to Build It →
Need the number to stop existing in your systems? The eight steps, what the Aadhaar Data Vault actually requires, and where it has already leaked: Government ID Masking: How to Build It →
Every tool for this module, how to use each one, what it costs, the best combinations and three recommended builds: Infrastructure Build Sheet →
What "infrastructure" means in a fintech
Underneath every fintech product sits a ledger that answers one question: what is the balance right now, and is this transaction allowed?
Everything else — the app, the cards, the lending journey, the analytics — sits on top of that ledger and trusts it to be correct. Get the ledger wrong and no amount of product quality above it matters.
The stack, from the bottom up:
| Layer | What it does | Can you skip it? |
|---|---|---|
| Licence / sponsor | The legal right to hold money or lend | No. You hold it or you rent it. |
| Core ledger | Accounts, balances, postings, interest, fees | No. Buy, rent or build. |
| Product logic | What this specific product does | No — this is your actual business. |
| Rails | Payments, cards, transfers | No. Always via a licensed provider. |
| Risk stack | KYC, fraud, AML, credit | No. Modules 01–05. |
| Data | Analytics, reporting, model features | Deferrable, and deferring it is expensive. |
| Channels | App, web, agent tooling | No, but this is the easy part. |
The three ways to get a ledger
Buy a core banking platform. A vendor supplies the ledger and product engine; you configure it. Cloud-native options exist that were built after 2010 and behave like software rather than like a mainframe.
Rent through BaaS. A provider bundles the sponsor bank relationship, the compliance stack and the core ledger. Fastest route to market, least control, and you inherit the provider’s regulatory standing.
Build your own. Full control, full cost, full responsibility for correctness.
Published estimates put building in-house at roughly 3–5x the cost of buying — on the order of $15–25M — and 24–36 months minimum to reach basic functionality. That is the number before the first customer. Teams routinely underestimate it because the happy path is genuinely simple; the cost is in reconciliation, edge cases, interest accrual, statement generation, and being correct on the worst day of the year.
What AI can and cannot do here
| Task | How well AI does it |
|---|---|
| Write the integration and glue code | Very well. Most of a core integration is boilerplate. |
| Generate test cases and edge-case scenarios | Very well, and underused. This is where ledger bugs hide. |
| Explain a legacy system nobody understands | Well. Reading undocumented code is a genuine strength. |
| Assist a data migration | Partially. Mapping yes; reconciling balances no. |
| Operate the ledger | It must not. Money movement is deterministic code, not inference. |
| Decide the architecture | No. It will confidently recommend the median answer from its training data, which is a bank you are not. |
Notice that none of the high-value uses are in the transaction path. AI belongs in building and understanding the infrastructure, not in running it. A ledger that produces a different answer on a retry is not a ledger.
The structural fact: your licence decides your architecture
Most technology choices are reversible. This one largely is not, because it is downstream of a regulatory position rather than a technical preference.
| Your position | What that forces |
|---|---|
| No licence, partnering with an NBFC or bank | Their core is the system of record. Yours is a control layer. You cannot own the ledger even if you want to. |
| Own NBFC licence | You own the book. You need a real core, real reporting, real audit. |
| Payment aggregator authorisation | Escrow mechanics and settlement obligations shape the ledger design. |
| Bank | Core banking in the full sense, with regulatory reporting to match. |
Decide the licence path before the architecture. Teams that build first and license later discover that the regulator expects a system of record they do not control, or controls they did not build.
The build, buy or rent decision
This is the decision teams spend the most time on and frame worst, because they start with a vendor comparison instead of with their own constraints.
ANSWER THESE FIRST. They decide more than any feature comparison.
1. Do you hold a licence, or rent one?
Renting -> you get a control layer, not a core. Stop here.
2. What is your go-live target?
< 6 months -> BaaS. Nothing else lands.
6-18 months -> SaaS core or BaaS. Enterprise cores will not.
18+ months -> the full range opens up.
3. How many engineers can you dedicate to infrastructure, not product?
< 5 -> BaaS
5-15 -> SaaS core, and expect it to consume most of them
15+ -> enterprise core becomes operable
50+ -> building becomes arguable, not obviously right
4. Is your product logic genuinely unusual?
If your lending or deposit product fits standard patterns, buying
is correct. "We are different" is usually pricing and journey
differences, which live ABOVE the ledger.
5. What volume, and what is the per-account economics?
Cloud-native cores report roughly $4-15 per account per year
versus $40-80 on legacy. At low volume this is noise. At millions
of accounts it is the whole argument.
6. Can you afford to be wrong?
A core migration mid-life is one of the most expensive projects in
financial services. Optimise for reversibility early, efficiency later.
THE PATTERN THAT WORKS FOR MOST
Start on BaaS or a SaaS core. Keep a shadow ledger from day one.
Move deeper only when volume economics or product constraints
actually force it - not when the engineering team gets bored.Where each option actually fits
| Option | Fits | Does not fit |
|---|---|---|
| BaaS — bundled sponsor, compliance and ledger | Vertical SaaS adding accounts or cards; seed to Series A; sub-18-month go-live with a small team | Anyone needing deep product control or owning their own licence |
| SaaS core — cloud-native, API-first | Neobanks and lenders with real engineering capacity; faster than enterprise, still substantial | Teams expecting it to be turnkey. It is a core, not a product. |
| Enterprise core — programmable, tier-one scale | Banks and large institutions where core modernisation is the strategic programme | A Series A fintech. Multi-year timelines and contract minimums sized for tier-one and tier-two banks. |
| Build | Large, well-funded, proven product-market fit, genuinely unusual product logic | Almost everyone else, almost always |
Pricing in this market is almost entirely undisclosed and sales-negotiated. A vendor that gives you a number before understanding your volume should prompt scepticism rather than relief — it usually means the number excludes implementation, professional services, or the integration work that dominates the real cost.
The thin ledger pattern
The most useful architectural idea in this module, and the one that keeps your options open.
YOUR SYSTEM PROVIDER / PARTNER
----------- -----------------
customer identity <------> KYC records
product logic & pricing
eligibility rules
YOUR SHADOW LEDGER <====> SYSTEM OF RECORD LEDGER
every posting mirrored authoritative balances
reconciled continuously regulatory reporting
customer experience
analytics & features <------> transaction feed
WHY MIRROR A LEDGER YOU DO NOT OWN
1. You can answer questions the provider's API cannot
("what did this customer's balance look like at 14:02 on Tuesday")
2. You detect provider errors, because you have an independent view
3. You can migrate. Without your own history you are captive.
4. Your analytics and model features do not depend on a rate-limited
vendor API
THE RULE THAT MAKES IT SAFE
Your shadow ledger is NEVER authoritative. On any disagreement the
provider's ledger wins and yours raises an exception.
A shadow ledger that silently "corrects" itself to match is not a
control - it is a way to hide breaks.The shadow ledger costs real engineering effort and buys three things that are hard to acquire later: an independent view for detecting provider errors, a complete history that makes migration possible, and analytics that do not depend on a vendor API.
Many fintechs adopt this early to move fast and shift toward deeper control over time. That progression only works if the shadow ledger existed from the start. Retrofitting history you never captured is not possible.
Data architecture
Three planes with different guarantees, kept genuinely separate.
TRANSACTIONAL PLANE strict consistency, low latency
core ledger money movement, balances
-> Postgres-class, ACID, boring, no clever caching of balances
OPERATIONAL PLANE near-real-time, eventually consistent
event stream every state change published once
-> Kafka / Pulsar. The integration backbone.
-> Consumers: fraud scoring, notifications, shadow ledger,
feature computation
ANALYTICAL PLANE batch + interactive, no SLA to production
warehouse / lakehouse history, reporting, model training
-> The regulatory reporting substrate as well as the BI one
THE RULE
Analytics NEVER reads the transactional database directly.
Not "should not" - never. One badly-written query against the
ledger during a settlement window is an outage.
EVENT DESIGN THAT SAVES YOU LATER
- every event immutable, append-only, with a sequence number
- business time AND system time on every event
- idempotency key so replay is safe
- schema registry, with backward compatibility enforced in CI
- publish FACTS ("payment_settled"), not commands ("update_balance")
WHY THIS MATTERS MORE IN FINTECH
You will be asked to reconstruct a point in time. Not "what is the
balance" but "what did we believe the balance was on 14 March, and
what did we know when we made that decision". Only an immutable
event log answers that.The feature store point, restated
Modules 02 and 03 both depend on features computed consistently between training and serving. That consistency is a data architecture property, not a model property. If the operational plane is the single source of events for both paths, training-serving skew largely disappears. If analytics recomputes features from a warehouse using different logic, it does not.
The India stack
Indian fintech infrastructure has consolidated into a recognisable set of layers, and the right choice depends more on what you are building than on vendor quality.
| Need | Typical route |
|---|---|
| Simple payment acceptance | Payment aggregator — Razorpay, Cashfree, PayU. Do not over-engineer this. |
| Banking APIs without card ambitions | Setu, Decentro — plug-and-play KYC, credit and payment APIs |
| Card issuance, lending OS, core replacement | M2P and comparable platforms — deeper RBI compliance coverage, NBFC references, heavier engagement |
| Lending lifecycle | LOS for origination, LMS for servicing, BRE for rules, plus collections and co-lending engines |
| Money movement and holding | Sponsor bank or your own licence. Not optional. |
LOS, LMS and BRE
Worth separating because they are frequently bought as one thing and have different lifespans.
- LOS — origination: journey, eligibility, document collection, decisioning integration
- LMS — servicing: disbursal, EMI scheduling, part-payments, restructuring, moratoria, write-offs, re-amortisation
- BRE — the rule engine, ideally no-code with maker-checker and version control so policy changes take hours rather than a release cycle
- Co-lending engine — if you co-lend, the RBI framework requires specific schedule generation, blended rates and escrow handling. Retrofitting this is painful.
Data localisation
RBI, IRDAI and SEBI each impose data residency expectations, and they are not identical. The practical consequences run deeper than choosing an Indian cloud region:
- Which AI APIs you may call, since inference is processing
- Where backups and disaster recovery copies live
- Whether a vendor’s support team can access production data from outside India
- What your logging and observability pipeline ships offshore by default
Observability is the one that catches teams out. Shipping application logs to a foreign-hosted monitoring service moves transaction data offshore continuously, and nobody notices because it was a platform decision rather than a data decision.
The registry
Core banking and ledger platforms
Verified May 2026India — BaaS and lending infrastructure
Verified May 2026Data and platform
Verified May 2026Registry reflects what was publicly visible in May 2026. Vendor ownership in this space changes frequently through acquisition, which affects roadmaps and contracts — verify the current corporate position before signing.
A prompt for the architecture decision
You are a fintech CTO who has built and migrated core infrastructure
in India, and has been through an RBI inspection.
My situation:
- Product: [describe]
- Licence position: [own NBFC / partnering with an NBFC or bank /
payment aggregator / none yet]
- Go-live target: [months]
- Engineering team size, and how many can work on infrastructure
rather than product: [numbers]
- Expected accounts and transactions in year 1 and year 3: [numbers]
- Data residency constraints: [describe]
Give me:
1. A build / buy / rent recommendation with the reasoning tied to MY
constraints, not to general best practice.
2. The specific layers I should own versus rent, and why each.
3. Whether I should run a shadow ledger, and what it must capture
from day one.
4. My event schema for the operational plane - the core events and
the fields each must carry.
5. What data localisation means concretely for my stack, including
observability, backups and vendor support access.
6. A realistic cost picture for year 1 and year 3 - build cost,
run cost, and the cost of the migration I will eventually face.
7. The three decisions here that are hardest to reverse, and what
I should do now to keep them reversible.
Be concrete and sceptical. Where vendor pricing is undisclosed, say
so rather than estimating.Vendor concentration is an architecture problem
Procurement treats vendor choice as a commercial question. In regulated infrastructure it is a resilience question with a regulatory dimension.
QUESTIONS TO ANSWER BEFORE SIGNING, NOT AFTER
DATA
Can you export the full transaction history, not just balances?
In what format, how often, at what cost?
Does the contract guarantee export on termination, and within
how many days?
Have you actually RUN a full export? (most teams have not)
BLAST RADIUS
If this vendor has a four-hour outage, what stops?
If they have a four-DAY outage, what stops?
If they exit the market or lose their own licence, what happens
to your customers' money?
PORTABILITY
What is genuinely vendor-specific in your code?
Product logic expressed in their DSL is the usual trap.
Could you stand up a second provider in parallel for one product?
CONCENTRATION
How many critical functions sit with this one vendor?
KYC + ledger + cards + payments with one provider is efficient
procurement and a single point of failure with regulatory
consequences.
THE TEST THAT MATTERS
Run a full data export quarterly and restore it into a scratch
environment. If you cannot reconstruct balances from the export,
you do not have an exit - you have a clause.Blast radius thinking
The useful exercise is not "is this vendor reliable". It is "what specifically stops working, for how long, and what do we tell customers and the regulator".
Write that down per vendor. The answers are usually worse than assumed, and the exercise tends to reveal that one provider sits underneath four functions nobody realised were connected.
Cloud exit strategy is now a standing expectation in Indian BFSI architecture discussions, not a theoretical exercise. If you cannot describe how you would leave a critical provider, you have accepted a dependency you have not assessed.
Cost, honestly
The published figures are useful as shape. The line items teams forget are more useful still.
YEAR ONE - the numbers teams forget
Platform licence / BaaS fees usually negotiated, often minimums
Implementation & professional services frequently comparable to year-one licence
Systems integrator (if enterprise core) often the largest single line
Your own engineering time on integration 6-18 engineer-months is typical
Sponsor bank / partner setup and minimums
Audit, penetration testing, compliance review
Cloud, observability, security tooling
RUN COST
Cloud-native cores report roughly $4-15 per account per year
versus $40-80 on legacy platforms. At 10,000 accounts that spread
is noise against your salary bill. At 5 million accounts it is
the entire argument for modernisation.
THE COST NOBODY MODELS
The migration you will eventually do.
Core migration mid-life is among the most expensive projects in
financial services - dual running, balance reconciliation to the
paisa, customer communication, regulatory notification, and a
period where two systems must agree exactly.
Budget for it conceptually at the START, because the decisions
that make it cheap or ruinous are made on day one:
- did you keep your own history? (shadow ledger)
- is product logic in your code or theirs? (portability)
- are your events vendor-neutral? (integration)
BUILD, FOR COMPLETENESS
Published estimates: 3-5x the cost of buying, on the order of
$15-25M, 24-36 months to basic functionality. Before the first
customer. The happy path is easy; correctness on the worst day
is where the money goes.Optimise for reversibility first
Early-stage infrastructure decisions should be judged on how cheaply they can be undone, not on how efficient they are. Efficiency matters at scale; at low volume the per-account spread is dwarfed by salaries.
Three decisions determine whether your eventual migration is a project or a crisis: whether you kept your own transaction history, whether product logic lives in your code or the vendor’s, and whether your internal events are vendor-neutral. All three are cheap on day one and impossible to retrofit.
Correctness properties a ledger must have
Whatever you buy or build, these are the properties to verify rather than assume. Vendors will assert all of them; test the ones you can.
| Property | What it means | How to test it |
|---|---|---|
| Idempotency | A retried instruction produces one posting, not two | Send the same request twice with the same key. Check the balance. |
| Atomicity across legs | A transfer either moves both sides or neither | Kill the process mid-transfer in a test environment. |
| Ordering | Postings apply in a defined order under concurrency | Fire concurrent debits against a balance that can only fund one. |
| Point-in-time reconstruction | You can state the balance as at any past moment | Ask for a balance as at a timestamp three months ago. |
| Immutability | Corrections are new entries, never edits | Attempt to amend a posting. It should be impossible. |
| Precision | Integer minor units end to end | Push a value that rounds badly in float and check for drift. |
| Determinism under replay | Replaying the event log reproduces the same state | Replay into a scratch environment and diff. |
The concurrency test is the one that finds real bugs. Two simultaneous debits against a balance that can fund only one is the simplest possible race, and systems that pass every other test fail this one more often than you would expect — usually by allowing a negative balance that the product does not permit.
Resilience and the incident you will have
Financial infrastructure fails differently from consumer software: the failure is often silent, and the damage accumulates before anyone notices.
The failure modes worth designing for
- Partial provider degradation — the API responds but slowly, or returns stale balances. Worse than an outage because nothing alerts.
- Duplicate processing — a retry storm or a reprocessed file. Idempotency is the defence; test it under load, not in isolation.
- Split brain — your view and the provider’s diverge and both keep operating. This is what continuous reconciliation exists to catch.
- Silent data loss — a consumer falls behind, a topic is retained too briefly, events vanish. Monitor consumer lag as a first-class alert.
- Certificate and credential expiry — unglamorous and a recurring cause of outages at exactly the wrong moment.
Containing without spreading
The hard part of a core incident is stopping it without taking everything else down. Practical measures: circuit breakers per downstream dependency, a documented read-only degraded mode, queued rather than dropped writes where the ledger is unavailable, and a kill switch per product rather than per system.
Decide in advance what you do when the ledger is unreachable: reject transactions, or accept and queue them. Both are defensible and they have very different consequences. Deciding during the incident guarantees an inconsistent answer across your services.
The architecture record, and where this module ends
# One of these per significant infrastructure decision.
# Written at the time, never reconstructed afterwards.
id: ADR-014
title: Core ledger - buy SaaS core rather than build
date: 2026-05-23
status: accepted
supersedes: null
context:
licence_position: partnering_with_nbfc
go_live_target_months: 9
infra_engineers_available: 4
year1_accounts: 40000
year3_accounts: 900000
data_residency: india_only
decision: >
Adopt a cloud-native SaaS core with a shadow ledger in our own
Postgres. Product logic stays in our services, not in the vendor DSL.
alternatives_considered:
- build_in_house:
rejected_because: "3-5x cost, 24-36 months to basic function.
Team is 4 engineers. Not survivable."
- baas_bundled:
rejected_because: "Partner NBFC already holds the licence; the
bundled sponsor layer is redundant and adds a
dependency we cannot exit."
- enterprise_core:
rejected_because: "Multi-year implementation and contract minimums
sized for tier-1/2 banks."
consequences:
accepted:
- vendor dependency on ledger correctness
- per-account run cost above self-hosted at very high volume
mitigated_by:
- shadow ledger from day one (independent history + migration path)
- product logic kept in our code (portability)
- vendor-neutral internal event schema
revisit_when:
- accounts exceed 2,000,000
- or per-account cost exceeds X
- or we obtain our own licence
exit_readiness:
full_export_tested: false # <- DO THIS BEFORE GO-LIVE
export_frequency_target: quarterly
restore_test_owner: platform_leadThe revisit_when block is the part that earns its keep. Decisions made sensibly at 40,000 accounts become wrong at two million, and without a written trigger nobody revisits them until something breaks.
Where this module ends
- Ledger schema and reconciliation detail is Module 05 — this module chooses the ledger, that one operates it.
- The risk stack that sits on this infrastructure is Modules 01 to 04.
- Model infrastructure — feature stores, training pipelines, serving — is touched here and governed in Governance.
- Licence and partnership questions are in the India and global regulatory spine pages.
- The sequencing of all of this for a new company is the Build Playbook.
Illustrative throughout. Core infrastructure decisions in a regulated entity need architecture review, security assessment, and sign-off from whoever is accountable for operational resilience — and in India, an understanding of what your regulator expects of outsourced arrangements.
Sources
Every figure, rule and date on this page, and where to check it. Entries are typed so you can see which are primary-sourced and which are industry reporting.
- officialRBI payment data storage direction — the India-only storage requirement and the offshore return-and-delete window. www.rbi.org.in
- officialRBI guidance on outsourcing of IT services — cloud adoption, concentration risk and exit obligations for regulated entities. www.rbi.org.in
- officialDPDP Act, 2023 — personal data obligations that sit on top of payment localisation. www.meity.gov.in
- officialIndiaAI Mission — the sovereign compute programme referenced in the cost discussion. indiaai.gov.in
Tooling, pricing and cost sources for this module are on its build sheet: sources →
Checked September 2026. Regulation in this area is actively developing; the date is part of the claim.
Ask an AI about this page
Opens your assistant with this page as the source, and a question rather than a summary. It will ask what you are building before it answers.
Nothing is sent from here. The link carries only this page’s title and address.