Nine guides here explain how Indian fintech systems actually work, one system at a time: UPI payment rails, ledger architecture, reconciliation and breaks, lending decision infrastructure, real-time fraud and risk decisioning, KYC and AML engineering, regulated engineering under PCI DSS and the RBI rulebook, core banking migration, and retail broking systems. Each then answers the hiring question that follows: who builds this, what separates a strong candidate from a plausible one, and how hard the search will be.
Most writing about fintech hiring describes roles. This section describes systems, and then asks who can build them.
The reason is practical. A job specification assembled from titles produces a shortlist nobody wants to interview, because titles travel badly: a "backend engineer" at a payments company and a "backend engineer" at a lending platform are solving different problems with different failure modes and different things that get you fired. A specification assembled from the system produces candidates who have actually done the work.
So each guide here takes one piece of financial infrastructure, explains how it works and where it breaks, and then answers the hiring question that follows: which roles own this, what separates a strong candidate from a plausible one, and how hard the search will be.
How to use this section
- If you are writing a brief, start with the system your team is building, not the title you think you need.
- If you are assessing candidates, the "what separates a real one" section of each guide is the interview content.
- If you are deciding whether to build or buy a capability, the failure modes tell you how much senior experience you actually require.
The systems
How UPI payments work, and the engineers behind every layer The rails end to end: PSP, NPCI, remitter and beneficiary banks, settlement cycles, and the specific places transactions fail. The foundation for every payments hire in India.
Ledger architecture in fintech Double-entry at scale, idempotency, immutability and why ledgers get rebuilt at Series B. The system that determines whether your numbers can be trusted.
Reconciliation and breaks The unglamorous function that decides whether a fintech survives audit. Recon engines, settlement files, break handling, and the most under-hired team in Indian fintech.
Lending decision infrastructure Underwriting engines, bureau and account aggregator data, policy versioning and decision replay, and what the RBI's 2025 Digital Lending Directions demand of the architecture.
Real-time fraud and risk decisioning Rules against models, feature stores, latency budgets measured in tens of milliseconds, and the false-positive economics nobody writes down.
KYC, AML and compliance engineering Onboarding and V-CIP, the central KYC registry, sanctions screening against Indian name data, and the transaction monitoring thresholds that inspections always find.
Regulated engineering: PCI-DSS, data residency and the RBI rulebook Where payment data may live, what may touch a card number, PCI DSS v4.0.1, and how the DPDP Rules layer onto the RBI's framework.
Core banking migration, and the team that does not fail it Strangler and coexistence patterns, parallel run, data migration risk, and the resilience posture the RBI's 2026 directions now require of the target state.
Retail broking systems: order routing, margin and settlement Order management, real-time margin under upfront and peak margin rules, T+1 alongside optional T+0, and the UPI block mechanism.
How these connect
The stack has a natural order, and reading it in that order is more useful than reading any single guide.
Money enters through a payment rail, which in India usually means UPI. Every movement writes to a ledger, which is the system of record. Reconciliation proves the ledger against external parties, because the rail, the bank and the scheme each hold their own version of events. Risk decisioning sits inline on the way in, deciding what to allow. Lending infrastructure turns the same rails into a credit product. Compliance engineering wraps all of it with the obligations the regulator imposes.
A team that understands this sequence writes better briefs, because it becomes obvious that a reconciliation engineer and a payments integration engineer are solving different problems, and that hiring one when you need the other is a common and expensive error.
Why systems rather than skills
Three things make financial technology hiring different from general software hiring, and all three are visible at the system level rather than on a CV.
Correctness is not negotiable. In most software, a bug is a defect. In a ledger or a settlement pipeline, a bug is money that has moved and cannot be unmoved, followed by a regulator asking how it happened. Engineers who have worked under that constraint build differently: they design for idempotency, they assume replay, they write reconciliation before they write features. You cannot assess this from a list of technologies.
The regulator is a stakeholder. Architecture decisions in Indian fintech are shaped by the RBI, SEBI, NPCI and the scheme rules, not only by engineering preference. Where data lives, how long it is retained, which checks run before a transaction and who is accountable are all externally determined. An engineer who has only built unregulated products will make reasonable decisions that turn out to be non-compliant.
Scale is uneven. UPI volumes in India are among the highest transaction volumes anywhere, and they arrive with sharp peaks. Systems that work at average load fail at festival peaks, and the engineering that survives it is specific.
None of this appears in a role title. All of it appears in the system.
Talent implications
The pattern across every guide in this section is the same, and it is worth stating once rather than repeating:
Define the stage, not the title. Before writing a brief, establish which part of the stack the role owns. Payment initiation, ledger, reconciliation, settlement, risk decisioning and compliance engineering are different jobs. The candidate pools overlap less than most hiring managers expect.
Assess for failure modes. The best interview question in fintech engineering is not about algorithms. It is "tell me about a time money moved when it should not have, and what you changed afterwards." Candidates who have owned production financial systems have an answer. Candidates who have not, do not.
Regulated experience is the hardest thing to evaluate and the easiest to overstate. Many candidates have worked near regulated systems without owning compliance obligations. The distinction matters enormously at senior level, and it is the single most common cause of a failed fintech leadership hire.
Expect the scarcity to sit in the middle. Graduate engineers are plentiful. Genuine leaders are findable, at a price. The scarce layer in Indian fintech is the senior individual contributor who has personally run a ledger, a recon engine or a settlement pipeline at volume, and that is where searches stall.
Common questions
Who is this section for?
Founders, CTOs, engineering leaders and talent teams writing briefs for fintech engineering roles, and senior engineers who want to understand how the systems they work on fit together. The explanations assume technical literacy but not prior financial services experience.
Why does a search firm publish engineering content?
Because the quality of a search depends on understanding the work. A brief written from job titles produces the wrong shortlist, and the fastest way to demonstrate that we understand a client's problem is to explain the system they are building.
Is this specific to India?
The architecture is general; the regulation, the rails and the talent market are specific to India. UPI, the account aggregator framework, RBI data residency rules and the NPCI scheme structure have no direct equivalent elsewhere, and they shape both the systems and the hiring.
How often is this updated?
Each guide carries its own review date. Regulation changes frequently in Indian fintech, so pages covering compliance and lending are reviewed more often than those covering architecture fundamentals.