Decide in dependency order
Stack decisions are not independent. Each one narrows the next, and taking them out of order means revisiting earlier ones.
DECIDE IN THIS ORDER. Each one constrains the next.
1. LICENCE POSITION -> decides whether you can own a ledger
2. LEDGER -> buy / rent / build (Module 08)
3. DATA RESIDENCY -> decides which AI APIs and clouds are usable
4. EVENT BACKBONE -> the integration contract everything speaks
5. IDENTITY PROVIDER -> indirect anyway; pick on liveness quality
6. RISK STACK -> credit / fraud / AML per your product
7. CUSTOMER OPS PLATFORM -> last, because escalation design matters
more than the platform
REVERSIBILITY, honestly assessed
Easy to change support platform, fraud vendor, analytics tooling
Painful KYC provider (re-verification), decisioning platform
Very hard ledger / core, event schema, data model
Effectively never licence structure, entity structure
Spend your thinking time in inverse proportion to reversibility.
THE DEFERRAL LIST - things teams build too early
- a data warehouse, before there is data worth warehousing
- a feature store, before two models share features
- microservices, before there is a team per service
- a custom rules engine, before the rules stabilise
- multi-region, before one region is reliableOptimise for reversibility first and efficiency later. At low volume, the per-unit differences between platforms are dwarfed by your salary bill. The decisions that matter early are the ones you cannot unwind.
The three questions that settle most of it
1. Do you hold a licence? If not, the partner’s core is the system of record and you are building a control layer. That removes most of the ledger debate.
2. What is your go-live date? Under six months means BaaS. Six to eighteen means a SaaS core or BaaS. Enterprise cores do not land inside eighteen months regardless of budget.
3. How many engineers can work on infrastructure rather than product? Under five means BaaS. Five to fifteen means a SaaS core will consume most of them. Fifteen or more makes an enterprise core operable.
Answer those three honestly and the shortlist is usually one or two options.
Data residency comes earlier than you think
Most teams treat residency as a deployment detail. It is a constraint on the whole stack.
It determines which AI APIs you may call, where backups and disaster recovery copies live, whether a vendor’s support team can access production from outside India, and what your observability pipeline ships offshore by default.
Observability is the one that gets missed. Shipping application logs to a foreign-hosted monitoring service moves transaction data offshore continuously, and nobody notices because it was chosen as a platform tool rather than as a data decision.
What to buy, build and defer
| Component | Decision | Why |
|---|---|---|
| Ledger / core | Buy or rent | Build is ~3–5x cost and 24–36 months to basic function |
| Shadow ledger | Build, from day one | Cannot be retrofitted. History you did not capture does not exist. |
| KYC / identity | Buy | Aadhaar is indirect regardless; buy on liveness quality for your device mix |
| Document extraction | Buy initially | Engine choice matters less than the quality gate and validation around it |
| Sanctions data | Buy enriched | The Bank of Scotland case turned on list enrichment, not algorithm |
| Screening logic | Build or configure yourself | Thresholds are your risk appetite, documented |
| Fraud rules | Build first, buy later | Velocity counters in week one beat any vendor integration |
| Credit model | Build on bought data | Your repayment history is the moat |
| Reconciliation | Build the matching, buy at volume | Start with exact-reference matching; most volume clears there |
| Support platform | Buy | Escalation design is yours; the helpdesk is not differentiating |
| Model registry | Adopt an open tool | An inventory that stays current beats a bespoke one that does not |
The integration contract
The one thing worth designing carefully before writing much code: what your internal events look like.
Vendor-neutral events are what make every other decision reversible. If your services publish and consume your own event schema rather than a provider’s payloads, swapping the provider is an adapter rather than a rewrite.
PUBLISH FACTS, NOT COMMANDS
customer.onboarded not create_customer
payment.settled not update_balance
loan.disbursed not mark_disbursed
EVERY EVENT CARRIES
event_id unique, stable
sequence monotonic per aggregate
occurred_at business time <- when it happened
recorded_at system time <- when we learned
idempotency_key replay-safe
schema_version with backward compatibility enforced in CI
actor who or what caused it
NEVER
- vendor payloads passed through unchanged
- events that assume a specific provider's field names
- mutable events (corrections are NEW events)
WHY THIS IS THE HIGHEST-LEVERAGE EARLY DECISION
Your ledger vendor, KYC provider, fraud vendor and support platform
will all change within five years. Your event schema should not.The deferral discipline
Building too early is as expensive as building too late, and less visible because it feels like progress.
| Defer until | Thing |
|---|---|
| Two models share a feature | Feature store |
| Analytics queries are hurting production | Warehouse |
| You have a team per service | Microservices |
| Rules change weekly and a deploy is the bottleneck | Rules engine |
| One region is reliably reliable | Multi-region |
| Manual review cost exceeds the build cost | Automated matching at volume |
| Vendor API limits actually bind | Caching layer |
The counter-list — things to build early even though they feel premature — is short and worth taking seriously: shadow ledger, decision logging with model and policy versions, outcome capture, and the model inventory.
Testing reversibility before you commit
Before signing anything material, answer these. Most teams cannot, which is itself the finding.
- Can you export full transaction history, not just balances? In what format, how often, at what cost?
- Does the contract guarantee export on termination, within how many days?
- Have you actually run a full export and restored it? Not read the docs — run it.
- What is vendor-specific in your code? Product logic in a vendor DSL is the usual trap.
- If this vendor had a four-day outage, what stops?
- How many critical functions sit with this one provider?
Run a full 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.
A prompt for your stack decision
You are a fintech CTO who has built and later migrated core
infrastructure in India.
My situation:
- Product: [describe]
- Licence position: [describe]
- Go-live target: [months]
- Total engineers, and how many can work on infrastructure rather
than product: [numbers]
- Year 1 and year 3 volumes: [accounts, transactions]
- Data residency constraints: [describe]
- Funding runway: [months]
Give me:
1. A specific stack recommendation, component by component, tied to
MY constraints rather than general best practice.
2. For each component: buy, build, or defer - and if defer, the
trigger that says build it now.
3. My internal event schema - the core events and required fields.
4. Which three decisions here are hardest to reverse, and what to do
now to keep them reversible.
5. What I am likely to build too early, given my team.
6. A realistic year 1 cost picture including implementation and my
own engineering time, not just licence fees.
Be sceptical of anything that sounds like the industry default.
Where vendor pricing is undisclosed, say so rather than estimating.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 outsourcing and IT governance directions — the constraints on vendor choice for regulated entities. www.rbi.org.in
- industryVendor documentation — the capability comparisons. See the build sheets for priced, dated figures.
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.