The Complete Guide to Indian Banking and Payment Systems Engineering

A Technical Reference for Software Engineers, Architects, and FinTech Professionals

Preface

This book exists because understanding banking and payment systems requires knowledge scattered across central bank documentation, payment network specifications, internal banking architecture documents, and tribal knowledge held by engineers who have built these systems. No single resource explains how money actually moves through the Indian financial system at the level of detail required by engineers building these systems.
This is not a business book about banking. This is an engineering book. Every concept explained here connects directly to code you will write, databases you will design, and systems you will debug at 3 AM when settlement fails.
The reader who finishes this book will understand:
  • How the Reserve Bank of India controls money supply and why this matters for payment systems
  • The complete technical architecture of every payment rail in India
  • How to design, build, and operate payment systems at scale
  • What happens inside core banking systems during every transaction
  • How settlement and clearing actually work at the ledger level
  • How to debug production incidents in payment systems
  • How to answer any banking domain interview question
Let us begin from first principles.

PART 1: Banking Fundamentals

Chapter 1: The Evolution of Banking

1.1 What is Banking?

Banking is the business of accepting deposits from the public, lending those deposits to borrowers, and facilitating the movement of money between parties. This definition, while simple, contains the fundamental principle that separates banks from all other financial institutions: banks can create money.
When a bank lends money, it does not remove that money from another account. The bank creates a new deposit in the borrower's account while simultaneously creating a loan asset on its books. This is called fractional reserve banking, and understanding it is essential for understanding why banking is the most regulated industry in any economy.
Consider this scenario: You deposit 100,000 rupees in a bank. The bank is required to keep only a fraction of this as reserves (currently around 4% as Cash Reserve Ratio in India). The remaining 96,000 rupees can be lent to another customer. When that customer receives the loan, the bank creates a new deposit of 96,000 rupees. The money supply has now increased from 100,000 to 196,000 rupees. The bank has created 96,000 rupees of new money.
This money creation power is why banks require banking licenses, why central banks exist, and why banking regulations are extensive. Every payment system, every transaction, every ledger entry you build as an engineer exists within this framework of regulated money creation.

1.2 History of Banking

Banking originated in ancient Mesopotamia around 2000 BCE when temples and palaces provided safe storage for grain and precious metals. The concept of lending with interest emerged from agricultural loans where farmers borrowed seeds and repaid with a portion of their harvest.
The word "bank" comes from the Italian "banca," meaning bench. Medieval Italian money changers conducted business on benches in marketplaces. When a money changer could not meet obligations, their bench was broken—"banca rotta"—giving us the word bankruptcy.
Modern banking began in 1609 with the Bank of Amsterdam, which introduced the concept of deposit banking and book-entry transfers. The Bank of England, established in 1694, became the first central bank, introducing banknotes and acting as the government's banker.
In India, banking history begins with the establishment of the Bank of Hindustan in 1770 in Calcutta, which failed in 1829. The first successful bank was the Bank of Bengal, established in 1806, which later merged with Bank of Bombay (1840) and Bank of Madras (1843) to form the Imperial Bank of India in 1921. This Imperial Bank became the State Bank of India in 1955.
Understanding this history matters because banking systems carry legacy architecture decisions made decades ago. The batch processing in NEFT, the message formats in SWIFT, the account numbering schemes in Core Banking Systems—all reflect historical constraints that engineers must work within.

1.3 The Indian Banking System Structure

The Indian banking system operates as a tiered structure with the Reserve Bank of India at the apex. Understanding this structure is essential because it determines which entities can participate in which payment systems, who settles with whom, and what regulatory requirements apply to each type of institution.
┌─────────────────────────────────────────────────────────────────────┐
│                     RESERVE BANK OF INDIA                           │
│                    (Central Bank - Regulator)                       │
└─────────────────────────────────────────────────────────────────────┘
                                │
        ┌───────────────────────┼───────────────────────┐
        │                       │                       │
        ▼                       ▼                       ▼
┌───────────────┐     ┌───────────────┐     ┌───────────────────────┐
│  SCHEDULED    │     │ NON-SCHEDULED │     │    COOPERATIVE        │
│    BANKS      │     │    BANKS      │     │      BANKS            │
└───────────────┘     └───────────────┘     └───────────────────────┘
        │
        ├──────────────────────────────────────────────┐
        │                                              │
        ▼                                              ▼
┌───────────────────────────┐             ┌───────────────────────────┐
│    COMMERCIAL BANKS       │             │    NON-COMMERCIAL         │
│                           │             │         BANKS             │
├───────────────────────────┤             ├───────────────────────────┤
│ • Public Sector Banks     │             │ • Development Banks       │
│ • Private Sector Banks    │             │ • NABARD                  │
│ • Foreign Banks           │             │ • SIDBI                   │
│ • Regional Rural Banks    │             │ • EXIM Bank               │
│ • Small Finance Banks     │             │ • NHB                     │
│ • Payment Banks           │             │                           │
└───────────────────────────┘             └───────────────────────────┘

Scheduled Banks

A scheduled bank is one included in the Second Schedule of the Reserve Bank of India Act, 1934. To be scheduled, a bank must have paid-up capital and reserves of at least 5 lakh rupees and must satisfy the RBI that its affairs are conducted in a manner not detrimental to depositors' interests.
Being scheduled matters for payment systems because:
  • Only scheduled banks can maintain accounts with the RBI
  • Only scheduled banks participate directly in RTGS
  • Only scheduled banks can settle directly for NEFT/IMPS/UPI
  • Only scheduled banks can borrow from the RBI under normal circumstances

Non-Scheduled Banks

Non-scheduled banks are not included in the Second Schedule. They cannot maintain accounts with the RBI and must route settlements through scheduled banks. These are typically small local area banks with limited operations.

1.4 Types of Banks in India

Public Sector Banks (PSBs)

Public Sector Banks are banks where the Government of India holds more than 50% ownership. As of 2024, there are 12 PSBs following the 2019 consolidation:
  1. State Bank of India
  2. Punjab National Bank
  3. Bank of Baroda
  4. Canara Bank
  5. Union Bank of India
  6. Bank of India
  7. Indian Bank
  8. Central Bank of India
  9. Indian Overseas Bank
  10. UCO Bank
  11. Bank of Maharashtra
  12. Punjab and Sind Bank
PSBs handle approximately 60% of banking business in India. For engineers, understanding PSBs matters because:
  • They have the largest legacy systems
  • They process the highest transaction volumes
  • They often have complex multi-vendor technology stacks
  • Their systems must interface with government schemes (DBT, PMJDY, etc.)
  • Their technology decisions affect the entire banking ecosystem

Private Sector Banks

Private sector banks are owned by private shareholders. They are further classified as:
Old Private Sector Banks: Established before 1991 nationalization
  • Federal Bank
  • South Indian Bank
  • Karnataka Bank
  • Karur Vysya Bank
  • City Union Bank
  • Dhanlaxmi Bank
  • Tamilnad Mercantile Bank
New Private Sector Banks: Licensed after 1991 economic liberalization
  • HDFC Bank
  • ICICI Bank
  • Axis Bank
  • Kotak Mahindra Bank
  • IndusInd Bank
  • Yes Bank
  • IDFC First Bank
  • Bandhan Bank
Private banks typically have more modern technology infrastructure because they were established after computerization became standard. HDFC Bank processes over 100 million transactions daily. ICICI Bank was among the first to implement real-time Core Banking. These banks often lead in technology adoption and are preferred employers for banking technology professionals.

Small Finance Banks

Small Finance Banks were introduced by the RBI in 2015 to further financial inclusion. They must:
  • Extend 75% of their credit to priority sector lending
  • Maintain at least 50% of their loan portfolio as loans below 25 lakh rupees
  • Open at least 25% of branches in unbanked rural areas
Licensed Small Finance Banks include:
  • AU Small Finance Bank
  • Equitas Small Finance Bank
  • Ujjivan Small Finance Bank
  • Jana Small Finance Bank
  • Fincare Small Finance Bank
  • ESAF Small Finance Bank
  • Capital Small Finance Bank
  • Suryoday Small Finance Bank
  • Utkarsh Small Finance Bank
  • North East Small Finance Bank
For engineers, Small Finance Banks represent a greenfield opportunity. These banks often build technology from scratch without legacy constraints. They adopt cloud-native architectures, modern API designs, and contemporary development practices.

Payment Banks

Payment Banks were licensed starting 2015 to promote financial inclusion. They can:
  • Accept deposits up to 2 lakh rupees per customer
  • Issue debit cards and provide internet banking
  • Provide remittance services
  • Act as Business Correspondents for other banks
  • Distribute financial products like insurance and mutual funds
Payment Banks cannot:
  • Issue credit cards
  • Provide loans
  • Accept NRI deposits
Operational Payment Banks:
  • Paytm Payments Bank
  • Airtel Payments Bank
  • India Post Payments Bank
  • Fino Payments Bank
  • Jio Payments Bank
  • NSDL Payments Bank
Payment Banks are technology-first institutions. They operate primarily through mobile apps, have no physical branch networks, and process millions of small-value transactions daily. Their technology architecture emphasizes:
  • High transaction throughput
  • Low-latency processing
  • Mobile-first interfaces
  • Cost-efficient infrastructure for small-value transactions
  • Integration with UPI and other payment rails

Cooperative Banks

Cooperative banks are organized under the Co-operative Societies Act. They serve specific communities or regions and operate under a different governance structure than commercial banks.
Urban Cooperative Banks (UCBs): Operate in urban and semi-urban areas. Multi-state UCBs are regulated by RBI, while single-state UCBs are regulated jointly by RBI and state governments.
State Cooperative Banks (SCBs): Apex banks for cooperative credit structure in each state.
District Central Cooperative Banks (DCCBs): Operate at district level, primarily serving agricultural credit needs.
Primary Agricultural Credit Societies (PACS): Village-level cooperatives providing credit to farmers.
Cooperative banks have faced technology challenges historically. Many still use legacy systems, batch processing, and limited digital capabilities. The 2020 PMC Bank crisis highlighted risks in cooperative bank operations and led to increased regulatory scrutiny.

Foreign Banks

Foreign banks operating in India may do so through:
  • Branches (Citibank, Standard Chartered, HSBC)
  • Wholly Owned Subsidiaries (DBS Bank India)
Foreign banks bring global technology practices and often have sophisticated treasury and trade finance systems. They typically focus on corporate banking, trade finance, and high-net-worth individuals rather than retail mass market.

Regional Rural Banks (RRBs)

Regional Rural Banks were established to provide credit to rural areas. They are jointly owned by:
  • Central Government (50%)
  • State Government (15%)
  • Sponsor Bank (35%)
RRBs primarily serve agricultural credit needs and operate through a technology infrastructure often provided by their sponsor banks.

1.5 The Reserve Bank of India

The Reserve Bank of India, established on April 1, 1935, under the Reserve Bank of India Act, 1934, is India's central bank. Every engineer building payment systems in India must understand the RBI's role because the RBI:
  • Issues and regulates currency
  • Acts as banker to banks
  • Acts as banker to the government
  • Manages foreign exchange reserves
  • Operates settlement systems (RTGS, NEFT)
  • Regulates payment systems
  • Regulates banks and NBFCs
  • Formulates monetary policy

RBI as Banker to Banks

Every scheduled bank maintains a current account with the RBI. This account is used for:
  • Maintaining CRR (Cash Reserve Ratio)
  • Settling interbank transactions
  • Receiving and making payments to the government
  • Participating in RBI's monetary operations
When you transfer money from your HDFC Bank account to an SBI account, the final settlement happens through these RBI accounts. HDFC Bank's account with RBI is debited, and SBI's account with RBI is credited. This is why the RBI is called the "bank of banks."

RBI as Settlement System Operator

The RBI operates:
  • RTGS (Real Time Gross Settlement): For high-value real-time transfers
  • NEFT (National Electronic Funds Transfer): For batch-based transfers
  • SFMS (Structured Financial Messaging System): Secure messaging between banks
The RBI also licenses and regulates:
  • NPCI (National Payments Corporation of India) for retail payments
  • CCIL (Clearing Corporation of India Limited) for forex and securities settlement
  • Card networks operating in India

Monetary Policy Functions

The RBI's monetary policy decisions directly affect banking systems:
Repo Rate: The rate at which RBI lends to banks. When repo rate increases, lending becomes expensive, reducing money supply. Current banking systems must incorporate repo rate changes in interest calculations.
Reverse Repo Rate: The rate at which banks deposit excess funds with RBI. This creates a floor for interest rates in the banking system.
Cash Reserve Ratio (CRR): The percentage of deposits banks must maintain with RBI as cash reserves. Currently around 4%. Banks must calculate CRR daily and maintain required balances. CRR affects liquidity and therefore affects payment system capacity.
Statutory Liquidity Ratio (SLR): The percentage of deposits banks must maintain in approved securities (government bonds, gold, etc.). Currently around 18%. SLR affects how much banks can lend and therefore affects credit creation.
Marginal Standing Facility (MSF): Banks can borrow overnight from RBI at MSF rate (repo rate + 0.25%) against government securities. This provides emergency liquidity.
Bank Rate: The rate at which RBI provides long-term funds to banks. Less frequently used in modern monetary policy.
┌─────────────────────────────────────────────────────────────────────┐
│                    RBI MONETARY POLICY TOOLS                        │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  QUANTITATIVE TOOLS              QUALITATIVE TOOLS                  │
│  ─────────────────              ────────────────                    │
│                                                                     │
│  • CRR (Cash Reserve Ratio)     • Credit Rationing                  │
│  • SLR (Statutory Liquidity     • Moral Suasion                     │
│    Ratio)                       • Direct Action                     │
│  • Repo Rate                    • Priority Sector                   │
│  • Reverse Repo Rate              Lending Norms                     │
│  • Open Market Operations                                           │
│  • Bank Rate                                                        │
│  • MSF Rate                                                         │
│                                                                     │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │              LIQUIDITY ADJUSTMENT FACILITY                   │   │
│  │                                                              │   │
│  │    MSF Rate (Ceiling)                                        │   │
│  │         │                                                    │   │
│  │         ▼                                                    │   │
│  │    ┌─────────┐                                               │   │
│  │    │  REPO   │ ─── Banks borrow from RBI                     │   │
│  │    │  RATE   │                                               │   │
│  │    └─────────┘                                               │   │
│  │         │                                                    │   │
│  │         ▼                                                    │   │
│  │    ┌─────────┐                                               │   │
│  │    │ REVERSE │ ─── Banks deposit with RBI                    │   │
│  │    │  REPO   │                                               │   │
│  │    └─────────┘                                               │   │
│  │         │                                                    │   │
│  │         ▼                                                    │   │
│  │    SDF Rate (Floor)                                          │   │
│  │                                                              │   │
│  └─────────────────────────────────────────────────────────────┘   │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

1.6 Non-Banking Financial Companies (NBFCs)

NBFCs are companies registered under the Companies Act that engage in financial activities like lending, investment, and insurance. The critical difference from banks: NBFCs cannot accept demand deposits (savings/current accounts withdrawable on demand).
This matters because:
  • NBFCs cannot create money like banks
  • NBFCs cannot participate directly in payment systems
  • NBFCs must work through banks for settlements
  • NBFCs have different capital requirements
Types of NBFCs:
  • NBFC-ICC: Investment and Credit Companies (largest category)
  • NBFC-MFI: Microfinance Institutions
  • NBFC-Factors: Factoring businesses
  • NBFC-IDF: Infrastructure Debt Funds
  • NBFC-P2P: Peer-to-Peer Lending Platforms
  • NBFC-AA: Account Aggregators
  • HFCs: Housing Finance Companies

Why NBFCs Cannot Create Money

When a bank makes a loan, it creates a deposit simultaneously. The borrower's account shows a credit (deposit), and the bank's books show an asset (loan). Money supply increases.
When an NBFC makes a loan, it must first acquire funds from somewhere—from its own capital, by borrowing from banks, by issuing bonds, or by securitizing existing loans. The NBFC transfers existing money to the borrower. Total money supply does not change.
This fundamental difference explains:
  • Why NBFCs have liquidity risk (they cannot create deposits)
  • Why NBFCs failed during the 2018-2019 liquidity crisis
  • Why NBFCs need different regulatory treatment
  • Why NBFCs cannot be payment system participants

1.7 How Banks Earn Money

Understanding bank revenue models helps engineers understand business priorities and therefore technology priorities.

Net Interest Income (NII)

The primary revenue source for most banks is the spread between interest earned on loans and interest paid on deposits.
Net Interest Income = Interest Earned - Interest Paid

Example:
Bank accepts deposits at 6% average rate
Bank lends at 12% average rate
Spread = 6%

If bank has 1,00,000 Cr in loans:
NII = 1,00,000 Cr × 6% = 6,000 Cr annually

Fee Income

Banks earn fees from:
  • Transaction fees (ATM, fund transfer, etc.)
  • Account maintenance charges
  • Loan processing fees
  • Card interchange fees
  • Foreign exchange conversion
  • Trade finance fees
  • Advisory services
  • Distribution of insurance and mutual funds
For payment engineers, fee income is directly relevant. Every transaction you process generates revenue. Transaction pricing, volume discounts, and fee structures are implemented in payment systems.

Treasury Operations

Banks trade in:
  • Government securities
  • Foreign exchange
  • Derivatives
  • Corporate bonds
Treasury profits come from trading gains and interest income on investment portfolios.

CASA Ratio

CASA (Current Account Savings Account) ratio measures the proportion of deposits in low-cost current and savings accounts versus term deposits.
CASA Ratio = (Current Account Deposits + Savings Account Deposits) / Total Deposits × 100

Higher CASA = Lower cost of funds = Higher profit margin
Banks with high CASA ratios (HDFC Bank historically around 45%) have competitive advantages. This explains why banks invest heavily in:
  • Salary account acquisition
  • Current account features for businesses
  • Mobile banking features to retain customers
  • UPI integration to drive transaction engagement

1.8 Banking Balance Sheet

Every banking system, every transaction, every payment ultimately affects the bank's balance sheet. Understanding this structure is essential.

Assets (What the bank owns or is owed)

ASSETS
├── Cash and Balances with RBI
│   ├── Cash in hand
│   └── Balances with RBI (including CRR)
│
├── Balances with Banks and Money at Call
│   ├── Balances with banks in India
│   ├── Balances with banks outside India
│   └── Money at call and short notice
│
├── Investments
│   ├── Government Securities (SLR)
│   ├── Other approved securities
│   ├── Shares
│   ├── Debentures and bonds
│   └── Subsidiaries and joint ventures
│
├── Advances (Loans)
│   ├── Bills purchased and discounted
│   ├── Cash credits, overdrafts, loans repayable on demand
│   ├── Term loans
│   └── Less: Provisions for NPAs
│
├── Fixed Assets
│   ├── Premises
│   └── Other fixed assets
│
└── Other Assets
    ├── Interest accrued
    ├── Tax paid in advance
    ├── Stationery and stamps
    └── Others

Liabilities (What the bank owes)

LIABILITIES
├── Capital
│   └── Paid-up capital
│
├── Reserves and Surplus
│   ├── Statutory reserves
│   ├── Capital reserves
│   ├── Revenue reserves
│   └── Balance in P&L account
│
├── Deposits
│   ├── Demand deposits (Current accounts)
│   ├── Savings deposits
│   ├── Term deposits
│   └── Deposits from banks
│
├── Borrowings
│   ├── Borrowings from RBI
│   ├── Borrowings from other banks
│   └── Other borrowings (bonds, etc.)
│
└── Other Liabilities
    ├── Bills payable
    ├── Interest accrued
    ├── Provisions
    └── Others

Balance Sheet Identity

Total Assets = Total Liabilities + Capital

For banks:
Loans + Investments + Cash + Fixed Assets = Deposits + Borrowings + Capital + Reserves
When you process a payment:
  • The sender's account (a deposit liability for the bank) decreases
  • The receiver's account (another deposit liability) increases
  • If accounts are in different banks, interbank settlement affects cash/balances with banks
Every transaction is a double-entry accounting event affecting this balance sheet.

1.9 Non-Performing Assets (NPAs)

An NPA is a loan where interest or principal payment remains overdue for more than 90 days. NPA classification matters because:
  • Banks must provision for NPAs (set aside capital)
  • NPAs reduce profitability
  • High NPAs indicate poor credit underwriting
  • NPAs affect capital adequacy ratios

NPA Classification

┌─────────────────────────────────────────────────────────────────────┐
│                        NPA CLASSIFICATION                           │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  STANDARD ASSETS                                                    │
│  ───────────────                                                    │
│  Payments received on time                                          │
│  Provisioning: 0.4% (general provision)                             │
│                                                                     │
│        ▼ (90 days overdue)                                          │
│                                                                     │
│  SUB-STANDARD ASSETS                                                │
│  ───────────────────                                                │
│  Overdue for 90 days to 12 months                                   │
│  Provisioning: 15%                                                  │
│                                                                     │
│        ▼ (12 months in sub-standard)                                │
│                                                                     │
│  DOUBTFUL ASSETS                                                    │
│  ───────────────                                                    │
│  Remained sub-standard for 12 months                                │
│  Provisioning: 25-100% (depending on security and period)           │
│                                                                     │
│        ▼ (Recovery impossible)                                      │
│                                                                     │
│  LOSS ASSETS                                                        │
│  ───────────────                                                    │
│  Identified as loss by bank/auditor/RBI                             │
│  Provisioning: 100%                                                 │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

NPA Impact on Technology Systems

Banking systems must:
  • Track payment due dates accurately
  • Flag accounts crossing 90-day threshold automatically
  • Calculate provisions based on classification
  • Generate regulatory reports (SMA-0, SMA-1, SMA-2)
  • Support recovery and legal processes
  • Handle write-offs and write-backs
Special Mention Accounts (SMA) require daily reporting to CRILC (Central Repository of Information on Large Credits):
  • SMA-0: Payment not overdue but showing signs of stress
  • SMA-1: 31-60 days overdue
  • SMA-2: 61-90 days overdue

1.10 Basel Norms and Capital Adequacy

Basel norms are international banking regulations developed by the Basel Committee on Banking Supervision. India follows Basel III norms.

Capital Adequacy Ratio (CAR)

CAR = (Tier 1 Capital + Tier 2 Capital) / Risk-Weighted Assets × 100

India requires minimum CAR of 9% (higher than Basel III minimum of 8%)
Tier 1 Capital (Going concern capital):
  • Common Equity Tier 1 (CET1): Share capital, retained earnings
  • Additional Tier 1 (AT1): Perpetual bonds
Tier 2 Capital (Gone concern capital):
  • Subordinated debt
  • General provisions
Risk-Weighted Assets (RWA): Assets weighted by their risk level. Government bonds have 0% risk weight (no capital required). Corporate loans might have 100% risk weight.

Why Capital Adequacy Matters for Engineers

Capital constraints affect:
  • How much a bank can lend (limited by capital, not just deposits)
  • Pricing of products (riskier products need more capital, hence higher prices)
  • Technology investments (capital is finite; technology competes with lending)
  • Growth strategies (rapid loan growth requires capital raising)

1.11 Risk Management in Banking

Banks manage multiple types of risks:

Credit Risk

The risk that borrowers will not repay loans. Managed through:
  • Credit scoring and rating
  • Collateral requirements
  • Exposure limits
  • Portfolio diversification
  • Provisioning
Technology systems for credit risk:
  • Credit scoring engines
  • Loan origination systems
  • Limit management systems
  • Early warning systems
  • Collection management systems

Market Risk

The risk of losses from changes in market prices (interest rates, forex, equity prices). Managed through:
  • Value at Risk (VaR) limits
  • Position limits
  • Stop-loss limits
  • Hedging

Operational Risk

The risk of losses from failed processes, people, or systems. This includes:
  • System failures
  • Fraud
  • Human errors
  • External events
For payment system engineers, operational risk is the primary concern. Every bug, every downtime, every incorrect transaction is an operational risk event.

Liquidity Risk

The risk that a bank cannot meet its payment obligations. Managed through:
  • Liquidity Coverage Ratio (LCR)
  • Net Stable Funding Ratio (NSFR)
  • Liquidity stress testing

1.12 AML, KYC, and Regulatory Compliance

Know Your Customer (KYC)

KYC is the process of verifying customer identity. In India, RBI mandates:
Customer Identification:
  • Officially Valid Documents (OVD): Passport, Driving License, Voter ID, Aadhaar, NREGA card
  • Proof of address
  • Recent photograph
Customer Due Diligence (CDD):
  • Basic CDD for low-risk customers
  • Enhanced CDD for high-risk customers
  • Ongoing monitoring of transactions
KYC Types:
  • CKYC (Central KYC): Centralized KYC Registry managed by CERSAI
  • eKYC: Aadhaar-based electronic KYC
  • Video KYC (V-KYC): Video-based customer identification

Anti-Money Laundering (AML)

AML refers to regulations and procedures to prevent criminals from disguising illegally obtained funds as legitimate income.
Key AML Regulations in India:
  • Prevention of Money Laundering Act (PMLA), 2002
  • Financial Intelligence Unit (FIU-IND) reporting requirements
  • RBI Master Direction on KYC
AML Systems Must:
  • Screen customers against sanctions lists
  • Monitor transactions for suspicious patterns
  • Generate Suspicious Transaction Reports (STRs)
  • Generate Currency Transaction Reports (CTRs) for cash transactions > 10 lakh
  • Maintain transaction records for 5 years

Financial Action Task Force (FATF)

FATF is an intergovernmental body setting global AML/CFT standards. India is a FATF member. FATF conducts Mutual Evaluation Reviews (MER) of member countries.
Non-compliance can result in:
  • FATF grey listing (increased monitoring)
  • FATF black listing (counter-measures by other countries)
  • Difficulty in international correspondent banking

Technology Systems for AML/KYC

┌─────────────────────────────────────────────────────────────────────┐
│                    AML/KYC TECHNOLOGY STACK                         │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │                    CUSTOMER ONBOARDING                       │   │
│  │                                                              │   │
│  │  Document OCR → Identity Verification → CKYC Integration    │   │
│  │       │                  │                    │              │   │
│  │       ▼                  ▼                    ▼              │   │
│  │  Face Match ───────► PAN/Aadhaar API ───► Risk Scoring      │   │
│  │                                                              │   │
│  └─────────────────────────────────────────────────────────────┘   │
│                              │                                      │
│                              ▼                                      │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │                TRANSACTION MONITORING                        │   │
│  │                                                              │   │
│  │  Real-time Screening ──► Rule Engine ──► Alert Generation   │   │
│  │         │                    │                │              │   │
│  │         ▼                    ▼                ▼              │   │
│  │  Sanctions Check ───► Pattern Analysis ──► Case Management  │   │
│  │                                                              │   │
│  └─────────────────────────────────────────────────────────────┘   │
│                              │                                      │
│                              ▼                                      │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │                   REGULATORY REPORTING                       │   │
│  │                                                              │   │
│  │  STR Generation ──► CTR Generation ──► FIU-IND Submission   │   │
│  │                                                              │   │
│  └─────────────────────────────────────────────────────────────┘   │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

1.13 Chapter Summary and Key Concepts

This chapter established the foundation for understanding banking systems:
  1. Banks create money through fractional reserve lending. This is why banking is heavily regulated.
  2. The RBI is the apex institution controlling monetary policy, operating settlement systems, and regulating banks.
  3. Different types of banks have different capabilities, regulatory requirements, and technology maturity levels.
  4. NBFCs cannot create money and therefore have different risk profiles and regulatory treatment.
  5. Bank profitability depends on net interest margin, fee income, and treasury operations.
  6. Capital adequacy constrains bank growth and affects technology investment decisions.
  7. Risk management covers credit, market, operational, and liquidity risks.
  8. AML/KYC compliance is mandatory and requires sophisticated technology systems.

Chapter 1 Interview Questions

Basic Level

  1. What is the difference between a scheduled bank and a non-scheduled bank?
  2. Why can banks create money but NBFCs cannot?
  3. What is CASA ratio and why does it matter?
  4. What is CRR and how does it affect banking operations?
  5. What is the difference between repo rate and reverse repo rate?
  6. What are the types of banks in India?
  7. What is a Payment Bank? What can it do and what can it not do?
  8. What is NPA? How is it classified?
  9. What is KYC and why is it important?
  10. What is the role of RBI in the banking system?

Intermediate Level

  1. Explain how fractional reserve banking leads to money creation with a numerical example.
  2. What is Capital Adequacy Ratio? Why do regulators mandate minimum CAR?
  3. What is SLR and how does it differ from CRR?
  4. Explain the NPA classification stages and provisioning requirements.
  5. What is FATF and why is FATF compliance important for Indian banks?
  6. How does a high CASA ratio provide competitive advantage to a bank?
  7. What is the Liquidity Adjustment Facility (LAF)? How does it work?
  8. What is the difference between Tier 1 and Tier 2 capital?
  9. Explain the difference between standard assets and NPAs from a provisioning perspective.
  10. What regulatory reports must banks submit related to stressed assets?

Advanced Level

  1. A bank has deposits of 1,00,000 Cr, CRR of 4%, SLR of 18%. Calculate the maximum amount available for lending.
  2. Design a system to track NPA classification in real-time and trigger provisioning calculations.
  3. How would you implement a real-time AML transaction monitoring system?
  4. Explain how Basel III capital requirements affect bank technology investment decisions.
  5. Design a KYC system that integrates with CKYC, supports eKYC, and enables Video KYC.
  6. What are the challenges in implementing a unified customer view across banking products from an AML perspective?
  7. How does operational risk capital calculation work under Basel III Advanced Measurement Approach?
  8. Design an early warning system for detecting potential NPAs before they become overdue.
  9. How would you implement cross-border transaction screening against multiple sanctions lists in real-time?
  10. Explain the impact of Interest Rate Risk in Banking Book (IRRBB) on banking system design.

Expert Level

  1. A bank operates in India and 15 other countries. Design a compliant AML system that handles different regulatory requirements across jurisdictions.
  2. How would you design a system to calculate Risk-Weighted Assets in real-time for capital adequacy monitoring?
  3. Design the data architecture for a banking system that must support regulatory reporting to multiple regulators (RBI, SEBI, FIU, IFSCA).
  4. How would you implement a stress testing framework for liquidity risk that can simulate various market scenarios?
  5. Design a system to implement IRRBB calculations including repricing risk, basis risk, and optionality risk.

Chapter 2: How Money Moves in India

This chapter explains the complete technical journey of a payment from initiation to final settlement. We will trace a single transaction through every system component, every database update, every ledger entry, and every network hop.

2.1 Understanding Money Movement

When you send money from your HDFC Bank account to your friend's SBI account, what actually happens? The simple answer—HDFC reduces your balance and SBI increases your friend's balance—hides enormous complexity.
The complete journey involves:
  1. Authentication and authorization
  2. Debiting your account in HDFC's Core Banking System
  3. Creating a payment instruction message
  4. Routing through payment networks
  5. Settlement between HDFC and SBI through RBI accounts
  6. Crediting your friend's account in SBI's Core Banking System
  7. Sending notifications to both parties
  8. Recording everything for reconciliation and audit
Let us trace this journey for different payment types.

2.2 Anatomy of a Payment Transaction

Before diving into specific payment rails, understand the common components:
┌─────────────────────────────────────────────────────────────────────┐
│                    PAYMENT TRANSACTION ANATOMY                       │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  ┌─────────────────┐                                                │
│  │     SENDER      │                                                │
│  │  (Payer/Debtor) │                                                │
│  └────────┬────────┘                                                │
│           │                                                         │
│           ▼                                                         │
│  ┌─────────────────┐     ┌─────────────────┐                       │
│  │    CHANNEL      │     │                 │                       │
│  │  (Mobile/Web/   │────▶│  AUTHENTICATION │                       │
│  │   Branch/ATM)   │     │                 │                       │
│  └─────────────────┘     └────────┬────────┘                       │
│                                   │                                 │
│                                   ▼                                 │
│                          ┌─────────────────┐                       │
│                          │  AUTHORIZATION  │                       │
│                          │  (Limits, AML,  │                       │
│                          │   Fraud Check)  │                       │
│                          └────────┬────────┘                       │
│                                   │                                 │
│                                   ▼                                 │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │                      CORE BANKING                            │   │
│  │                                                              │   │
│  │  ┌─────────────┐    ┌─────────────┐    ┌─────────────┐      │   │
│  │  │   LEDGER    │    │   ACCOUNT   │    │   PAYMENT   │      │   │
│  │  │   DEBIT     │◀──▶│   UPDATE    │◀──▶│   SWITCH    │      │   │
│  │  │             │    │             │    │             │      │   │
│  │  └─────────────┘    └─────────────┘    └─────────────┘      │   │
│  │                                                              │   │
│  └───────────────────────────┬─────────────────────────────────┘   │
│                              │                                      │
│                              ▼                                      │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │                    PAYMENT NETWORK                           │   │
│  │         (NPCI for UPI/IMPS, RBI for NEFT/RTGS)              │   │
│  └───────────────────────────┬─────────────────────────────────┘   │
│                              │                                      │
│                              ▼                                      │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │                  DESTINATION BANK CBS                        │   │
│  │                                                              │   │
│  │  ┌─────────────┐    ┌─────────────┐    ┌─────────────┐      │   │
│  │  │   PAYMENT   │    │   ACCOUNT   │    │   LEDGER    │      │   │
│  │  │   RECEIVE   │──▶│   UPDATE    │──▶│   CREDIT    │      │   │
│  │  │             │    │             │    │             │      │   │
│  │  └─────────────┘    └─────────────┘    └─────────────┘      │   │
│  │                                                              │   │
│  └───────────────────────────┬─────────────────────────────────┘   │
│                              │                                      │
│                              ▼                                      │
│                     ┌─────────────────┐                            │
│                     │    RECEIVER     │                            │
│                     │(Payee/Creditor) │                            │
│                     └─────────────────┘                            │
│                                                                     │
│  ════════════════════════════════════════════════════════════════  │
│                                                                     │
│                         SETTLEMENT                                  │
│                    (Deferred or Real-time)                         │
│                                                                     │
│     SENDER BANK ──────────────────────────▶ RECEIVER BANK          │
│     RBI Account Debit                       RBI Account Credit      │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

2.3 Complete UPI Payment Flow

Let us trace a UPI payment of Rs. 500 from Priya (HDFC Bank, using PhonePe) to Rahul (SBI, using Google Pay).

Step 1: Payment Initiation

Priya opens PhonePe and initiates payment to rahul@oksbi for Rs. 500.
Priya's Phone (PhonePe App)
│
├── User Action: Send Rs. 500 to rahul@oksbi
│
├── App Actions:
│   ├── Validate VPA format (rahul@oksbi)
│   ├── Check local transaction limits
│   ├── Generate unique transaction reference (PhonePe Reference ID)
│   └── Prepare payment request
│
└── API Call to PhonePe Backend:
    POST /api/v1/payments/upi/send
    {
      "payerVpa": "priya@ybl",
      "payeeVpa": "rahul@oksbi",
      "amount": 50000,  // in paise
      "currency": "INR",
      "deviceId": "ABC123",
      "appVersion": "11.5.0",
      "transactionId": "PHN202401150001234567"
    }

Step 2: PhonePe Backend Processing (PSP - Payment Service Provider)

PhonePe acts as a Third Party Application Provider (TPAP) through its PSP partner (Yes Bank, using VPA handle @ybl).
PhonePe Backend
│
├── Receive payment request
│
├── Authentication:
│   ├── Verify device binding
│   ├── Check session validity
│   └── Validate app signature
│
├── Rate Limiting:
│   ├── Check transactions per minute for user
│   ├── Check transactions per day for user
│   └── Check aggregate limits
│
├── Fraud Checks:
│   ├── Device fingerprint validation
│   ├── Transaction velocity check
│   ├── Beneficiary risk scoring
│   └── Amount threshold checks
│
├── Generate UPI Transaction ID:
│   └── Format: YBL + date + sequence = "YBL2401150000001234"
│
└── Forward to Yes Bank (PSP):
    API Call: POST https://yesbank.com/upi/psp/api/pay/request
    {
      "txnId": "YBL2401150000001234",
      "payerVpa": "priya@ybl",
      "payeeVpa": "rahul@oksbi",
      "amount": 500.00,
      "payerPspId": "YESB",
      "note": "Payment for dinner"
    }

Step 3: Yes Bank (PSP) to NPCI

Yes Bank routes the payment request to NPCI (National Payments Corporation of India).
Yes Bank UPI System
│
├── Receive request from PhonePe
│
├── Validations:
│   ├── Verify PhonePe is registered TPAP
│   ├── Verify VPA format
│   └── Apply PSP-level limits
│
├── Message Construction:
│   ├── Create UPI message in XML format
│   ├── Add digital signature
│   └── Encrypt payload
│
└── Send to NPCI:
    Connection: Dedicated leased line / VPN
    Protocol: HTTPS with mutual TLS

    API: POST https://upi.npci.org.in/api/ReqPay

    UPI XML Message:
    <?xml version="1.0" encoding="UTF-8"?>
    <upi:ReqPay xmlns:upi="http://npci.org/upi/schema/">
      <Head ver="2.0" ts="2024-01-15T10:30:00+05:30"
            orgId="YESB" msgId="MSG123456789"/>
      <Txn id="YBL2401150000001234"
           type="PAY"
           refId="PHN202401150001234567"
           ts="2024-01-15T10:30:00+05:30"/>
      <Payer addr="priya@ybl"
             name="PRIYA SHARMA"
             type="PERSON">
        <Device>
          <Tag name="MOBILE" value="919876543210"/>
          <Tag name="GEOCODE" value="12.9716,77.5946"/>
          <Tag name="APP" value="com.phonepe.app"/>
        </Device>
        <Ac addrType="ACCOUNT">
          <Detail name="IFSC" value="HDFC0001234"/>
          <Detail name="ACNUM" value="50100123456789"/>
        </Ac>
        <Amount value="500.00" curr="INR"/>
      </Payer>
      <Payee addr="rahul@oksbi"
             name="RAHUL KUMAR"
             type="PERSON">
        <Ac addrType="ACCOUNT">
          <Detail name="IFSC" value="SBIN0001234"/>
          <Detail name="ACNUM" value="32145678901234"/>
        </Ac>
        <Amount value="500.00" curr="INR"/>
      </Payee>
    </upi:ReqPay>

Step 4: NPCI UPI Switch Processing

NPCI receives the payment request and routes it appropriately.
NPCI UPI Switch
│
├── Message Reception:
│   ├── TLS termination
│   ├── Signature verification (Yes Bank's certificate)
│   └── XML validation against schema
│
├── Transaction Validation:
│   ├── Check for duplicate transaction ID
│   ├── Validate timestamp (not older than 5 minutes)
│   ├── Verify payer PSP is active
│   └── Check NPCI system limits
│
├── VPA Resolution:
│   │
│   │   For Payer (priya@ybl):
│   │   └── Already resolved - HDFC account included in message
│   │
│   │   For Payee (rahul@oksbi):
│   │   ├── Parse handle: oksbi → SBI Bank
│   │   ├── Query SBI: GET /upi/vpa/resolve?vpa=rahul@oksbi
│   │   └── Response: Account 32145678901234, IFSC SBIN0001234
│
├── Create Settlement Record:
│   INSERT INTO upi_transactions (
│     txn_id, payer_vpa, payee_vpa, amount,
│     payer_psp, payee_psp, payer_ifsc, payee_ifsc,
│     status, created_at
│   ) VALUES (
│     'YBL2401150000001234', 'priya@ybl', 'rahul@oksbi', 500.00,
│     'YESB', 'SBIB', 'HDFC0001234', 'SBIN0001234',
│     'INITIATED', '2024-01-15 10:30:00'
│   );
│
├── Debit Request to Payer Bank (HDFC via Yes Bank PSP):
│   POST https://yesbank.com/upi/psp/api/debit
│   (Yes Bank forwards to HDFC)
│
└── Credit Request to Payee Bank (SBI):
    POST https://sbi.co.in/upi/api/credit

Step 5: Debit from Payer Account (HDFC Bank)

HDFC Bank receives the debit request and processes it.
HDFC Bank UPI System
│
├── Receive Debit Request from NPCI (via Yes Bank):
│   Verify NPCI signature
│   Parse UPI XML message
│
├── Account Lookup:
│   SELECT account_number, balance, status, account_type,
│          kyc_status, frozen_flag
│   FROM accounts
│   WHERE account_number = '50100123456789';
│
│   Result: Balance = 15,000.00, Status = ACTIVE
│
├── Validation Checks:
│   ├── Account status = ACTIVE ✓
│   ├── Account not frozen ✓
│   ├── KYC valid ✓
│   ├── Sufficient balance (15,000 >= 500) ✓
│   ├── Transaction limits not exceeded ✓
│   └── Account allows UPI debit ✓
│
├── Place Hold on Funds:
│   BEGIN TRANSACTION;
│
│   -- Create hold
│   INSERT INTO account_holds (
│     account_number, amount, hold_type, reference_id,
│     created_at, expires_at
│   ) VALUES (
│     '50100123456789', 500.00, 'UPI_DEBIT',
│     'YBL2401150000001234',
│     NOW(), NOW() + INTERVAL '30 minutes'
│   );
│
│   -- Update available balance
│   UPDATE accounts
│   SET available_balance = available_balance - 500.00,
│       last_updated = NOW()
│   WHERE account_number = '50100123456789';
│
│   COMMIT;
│
├── Generate Debit Response:
│   <?xml version="1.0" encoding="UTF-8"?>
│   <upi:RespPay xmlns:upi="http://npci.org/upi/schema/">
│     <Head ver="2.0" ts="2024-01-15T10:30:02+05:30"
│           orgId="HDFC" msgId="RSP123456789"/>
│     <Txn id="YBL2401150000001234"
│          type="PAY"
│          result="SUCCESS"
│          errCode=""/>
│     <Payer addr="priya@ybl">
│       <ApprovalNum value="HDFC1234567"/>
│     </Payer>
│   </upi:RespPay>
│
└── Send Response to NPCI

Step 6: Credit to Payee Account (SBI)

SBI receives the credit instruction and credits Rahul's account.
SBI UPI System
│
├── Receive Credit Request from NPCI:
│   Verify NPCI signature
│   Parse UPI XML message
│
├── Account Lookup:
│   SELECT account_number, status, account_type,
│          credit_blocked_flag
│   FROM accounts
│   WHERE account_number = '32145678901234';
│
│   Result: Status = ACTIVE, Credit allowed
│
├── Validation Checks:
│   ├── Account exists ✓
│   ├── Account status = ACTIVE ✓
│   ├── Account allows credits ✓
│   └── Account type supports UPI ✓
│
├── Credit Account:
│   BEGIN TRANSACTION;
│
│   -- Credit the account
│   UPDATE accounts
│   SET balance = balance + 500.00,
│       available_balance = available_balance + 500.00,
│       last_updated = NOW()
│   WHERE account_number = '32145678901234';
│
│   -- Create transaction record
│   INSERT INTO transactions (
│     account_number, txn_type, amount,
│     reference_id, description, balance_after,
│     created_at
│   ) VALUES (
│     '32145678901234', 'CREDIT', 500.00,
│     'YBL2401150000001234', 'UPI/priya@ybl/Dinner',
│     (SELECT balance FROM accounts WHERE account_number = '32145678901234'),
│     NOW()
│   );
│
│   -- Create ledger entry
│   INSERT INTO ledger_entries (
│     account_id, entry_type, amount,
│     contra_account, reference_id, created_at
│   ) VALUES (
│     '32145678901234', 'CREDIT', 500.00,
│     'UPI_CLEARING', 'YBL2401150000001234', NOW()
│   );
│
│   COMMIT;
│
├── Generate Credit Response:
│   <?xml version="1.0" encoding="UTF-8"?>
│   <upi:RespPay xmlns:upi="http://npci.org/upi/schema/">
│     <Head ver="2.0" ts="2024-01-15T10:30:03+05:30"
│           orgId="SBIN" msgId="RSP987654321"/>
│     <Txn id="YBL2401150000001234"
│          type="PAY"
│          result="SUCCESS"
│          errCode=""/>
│     <Payee addr="rahul@oksbi">
│       <ApprovalNum value="SBI9876543"/>
│     </Payee>
│   </upi:RespPay>
│
└── Send Response to NPCI

Step 7: NPCI Finalizes Transaction

NPCI receives both debit and credit confirmations.
NPCI UPI Switch
│
├── Receive Credit Confirmation from SBI
│
├── Update Transaction Status:
│   UPDATE upi_transactions
│   SET status = 'SUCCESS',
│       debit_confirmation = 'HDFC1234567',
│       credit_confirmation = 'SBI9876543',
│       completed_at = NOW()
│   WHERE txn_id = 'YBL2401150000001234';
│
├── Create Settlement Entry:
│   INSERT INTO settlement_entries (
│     txn_id, debit_bank, credit_bank, amount,
│     settlement_cycle, status
│   ) VALUES (
│     'YBL2401150000001234', 'HDFC', 'SBIN', 500.00,
│     'CYCLE_2024011510', 'PENDING'
│   );
│
├── Send Final Response to Payer PSP (Yes Bank):
│   POST https://yesbank.com/upi/callback/response
│   {
│     "txnId": "YBL2401150000001234",
│     "status": "SUCCESS",
│     "approvalNum": "NPCI123456789",
│     "responseCode": "00"
│   }
│
└── Yes Bank forwards to PhonePe → Priya sees "Payment Successful"

Step 8: Notifications

Both parties receive notifications.
Notification Flow:

HDFC Bank:
├── Send SMS to Priya: "Rs 500 debited from A/c X6789. UPI Ref YBL2401150000001234"
├── Send Push notification via banking app
└── Update mini-statement

SBI:
├── Send SMS to Rahul: "Rs 500 credited to A/c X1234 from priya@ybl"
├── Send Push notification via banking app
└── Update mini-statement

PhonePe:
├── Show success screen to Priya
├── Send push notification
└── Update transaction history

Google Pay (for Rahul):
├── Send push notification: "Received Rs 500 from Priya"
└── Update transaction history

Step 9: Settlement

Settlement happens between banks, not for individual transactions.
UPI Settlement (Net Settlement)
│
├── Settlement Cycles:
│   NPCI runs settlement cycles throughout the day
│   Approximately every 2 hours (specific times defined by NPCI)
│
├── For settlement cycle containing our transaction:
│
│   NPCI calculates net positions for all banks:
│
│   Example for this cycle:
│   ┌──────────┬─────────────┬──────────────┬──────────────┐
│   │   Bank   │ Total Debit │ Total Credit │ Net Position │
│   ├──────────┼─────────────┼──────────────┼──────────────┤
│   │ HDFC     │  50,00,000  │  45,00,000   │  -5,00,000   │
│   │ SBI      │  40,00,000  │  48,00,000   │  +8,00,000   │
│   │ ICICI    │  35,00,000  │  32,00,000   │  -3,00,000   │
│   │ ...      │     ...     │     ...      │     ...      │
│   └──────────┴─────────────┴──────────────┴──────────────┘
│
│   Net positions sum to zero (multilateral netting)
│
├── NPCI sends settlement file to RBI:
│   Contains net positions for each bank
│
├── RBI Settlement:
│   BEGIN TRANSACTION;
│
│   -- Debit banks with negative net position
│   UPDATE rbi_settlement_accounts
│   SET balance = balance - 5,00,000
│   WHERE bank_code = 'HDFC';
│
│   -- Credit banks with positive net position
│   UPDATE rbi_settlement_accounts
│   SET balance = balance + 8,00,000
│   WHERE bank_code = 'SBIN';
│
│   COMMIT;
│
└── Settlement confirmation sent to all banks

Step 10: Reconciliation

Each bank reconciles its transactions.
Daily Reconciliation Process (at each bank):
│
├── Download settlement file from NPCI
│
├── Compare with internal transaction records:
│
│   SELECT
│     npci.txn_id,
│     npci.amount as npci_amount,
│     internal.amount as internal_amount,
│     CASE
│       WHEN npci.amount = internal.amount THEN 'MATCHED'
│       ELSE 'MISMATCH'
│     END as status
│   FROM npci_settlement_file npci
│   LEFT JOIN internal_transactions internal
│     ON npci.txn_id = internal.reference_id
│   WHERE npci.settlement_date = CURRENT_DATE;
│
├── Identify discrepancies:
│   - Transactions in NPCI file but not in internal records
│   - Transactions in internal records but not in NPCI file
│   - Amount mismatches
│
├── Generate reconciliation report
│
└── Investigate and resolve discrepancies

2.4 Complete NEFT Payment Flow

NEFT (National Electronic Funds Transfer) operates differently from UPI. It uses batch processing with deferred net settlement.

Step 1: Customer Initiates NEFT

Customer Action:
│
├── Login to HDFC NetBanking
├── Navigate to Fund Transfer → NEFT
├── Select beneficiary (previously added with SBI account details)
├── Enter amount: Rs. 50,000
├── Confirm transaction
│
└── HDFC Bank Receives Request:
    POST /api/v1/transfers/neft
    {
      "fromAccount": "50100123456789",
      "toAccount": "32145678901234",
      "toIfsc": "SBIN0001234",
      "toBeneficiaryName": "RAHUL KUMAR",
      "amount": 50000.00,
      "remarks": "Loan repayment"
    }

Step 2: HDFC Bank Processing

HDFC Bank NEFT Processing:
│
├── Authentication & Authorization:
│   ├── Verify user session
│   ├── Verify transaction password/OTP
│   └── Check device binding
│
├── Validation:
│   ├── Verify IFSC code format (SBIN0001234)
│   ├── Check IFSC exists in RBI IFSC database
│   ├── Verify account has sufficient balance
│   ├── Check daily NEFT limits
│   └── AML screening
│
├── Debit Account:
│   BEGIN TRANSACTION;
│
│   UPDATE accounts
│   SET balance = balance - 50000.00,
│       available_balance = available_balance - 50000.00
│   WHERE account_number = '50100123456789';
│
│   INSERT INTO transactions (...);
│   INSERT INTO ledger_entries (...);
│
│   COMMIT;
│
├── Create NEFT Message:
│   Format: ISO 8583 / SFMS Message
│
│   Message Type: NEFT01 (Credit Transfer)
│   ├── Sender Bank: HDFC0001234
│   ├── Sender Account: 50100123456789
│   ├── Sender Name: PRIYA SHARMA
│   ├── Receiver Bank: SBIN0001234
│   ├── Receiver Account: 32145678901234
│   ├── Receiver Name: RAHUL KUMAR
│   ├── Amount: 50000.00
│   └── UTR: HDFC2401150000001
│
├── Queue for Next Batch:
│   INSERT INTO neft_outward_queue (
│     utr, sender_ifsc, receiver_ifsc,
│     amount, message_content, batch_id, status
│   ) VALUES (
│     'HDFC2401150000001', 'HDFC0001234', 'SBIN0001234',
│     50000.00, '<message_xml>', NULL, 'QUEUED'
│   );
│
└── Customer sees: "NEFT initiated. Will be processed in next batch."

Step 3: Batch Processing at HDFC

NEFT batches are processed every 30 minutes (24x7 since December 2019).
HDFC Bank NEFT Batch Processing:
│
├── At batch time (e.g., 10:30 AM):
│
│   SELECT * FROM neft_outward_queue
│   WHERE batch_id IS NULL
│   AND status = 'QUEUED'
│   ORDER BY created_at;
│
├── Create batch:
│   Batch ID: HDFC_2024011510_001
│
│   UPDATE neft_outward_queue
│   SET batch_id = 'HDFC_2024011510_001'
│   WHERE id IN (selected_records);
│
├── Generate SFMS batch file:
│   File contains all transactions for this batch
│   Digitally signed by HDFC
│   Encrypted for transmission
│
└── Transmit to RBI SFMS:
    Protocol: SFMS (Structured Financial Messaging System)
    Connection: Dedicated INFINET (Indian Financial Network)

Step 4: RBI NEFT Processing

RBI NEFT System:
│
├── Receive batch from HDFC Bank
│
├── Validate batch:
│   ├── Verify digital signature
│   ├── Check batch format
│   ├── Validate each transaction
│   └── Check for duplicates
│
├── Aggregate all batches from all banks for this time slot
│
├── For each transaction, route to destination bank:
│
│   Transaction HDFC2401150000001:
│   ├── Destination: SBIN (State Bank of India)
│   └── Add to SBI inward batch
│
├── Create settlement positions:
│
│   Net Settlement Calculation:
│   ┌──────────┬──────────────┬──────────────┬──────────────┐
│   │   Bank   │    Outward   │    Inward    │ Net Position │
│   ├──────────┼──────────────┼──────────────┼──────────────┤
│   │ HDFC     │  10,00,00,000│   8,00,00,000│ -2,00,00,000 │
│   │ SBI      │   7,00,00,000│   9,50,00,000│ +2,50,00,000 │
│   │ ICICI    │   5,00,00,000│   4,50,00,000│   -50,00,000 │
│   │ ...      │     ...      │     ...      │     ...      │
│   └──────────┴──────────────┴──────────────┴──────────────┘
│
├── Settlement in RBI Books:
│   Debit settlement accounts of net payers
│   Credit settlement accounts of net receivers
│
├── Generate inward batches for each bank
│
└── Transmit inward batches to respective banks

Step 5: SBI Processes Inward NEFT

SBI Inward NEFT Processing:
│
├── Receive inward batch from RBI
│
├── For each transaction in batch:
│
│   Transaction HDFC2401150000001:
│   ├── Parse message
│   ├── Extract beneficiary details
│   └── Validate account
│
├── Account Validation:
│   SELECT account_number, account_name, status
│   FROM accounts
│   WHERE account_number = '32145678901234';
│
│   ├── If account exists and active → Credit
│   ├── If account closed → Return (NEFT return)
│   ├── If name mismatch → Manual review or return
│   └── If account frozen → Hold for review
│
├── Credit Account:
│   BEGIN TRANSACTION;
│
│   UPDATE accounts
│   SET balance = balance + 50000.00,
│       available_balance = available_balance + 50000.00
│   WHERE account_number = '32145678901234';
│
│   INSERT INTO transactions (
│     account_number, txn_type, amount,
│     reference_id, description, created_at
│   ) VALUES (
│     '32145678901234', 'CREDIT', 50000.00,
│     'HDFC2401150000001', 'NEFT/HDFC0001234/PRIYA SHARMA',
│     NOW()
│   );
│
│   COMMIT;
│
├── Send acknowledgment to RBI
│
└── Notify customer (SMS/Email)

NEFT Timing and Settlement

NEFT Settlement Timeline:
│
├── NEFT operates 24x7 since December 2019
│
├── Batch timings: Every 30 minutes
│   00:00, 00:30, 01:00, 01:30, ... , 23:30
│
├── Settlement is net and deferred:
│   All transactions in a batch are netted
│   Settlement happens after batch processing
│
├── Example Timeline for 10:15 AM transaction:
│   10:15 - Transaction initiated by customer
│   10:15 - Debit from sender account
│   10:15 - Queued for 10:30 batch
│   10:30 - Batch cutoff
│   10:32 - Batch transmitted to RBI
│   10:35 - RBI processes batch
│   10:40 - Settlement in RBI books
│   10:42 - Inward batch sent to destination banks
│   10:45 - Credit to beneficiary account
│
└── Total time: Approximately 30-45 minutes

2.5 Complete RTGS Payment Flow

RTGS (Real Time Gross Settlement) differs from NEFT in one crucial way: transactions are settled individually in real-time, not batched.
RTGS Characteristics:
│
├── Minimum amount: Rs. 2,00,000 (no maximum)
├── Settlement: Real-time, gross (each transaction settled individually)
├── Timing: 24x7 since December 2020
├── Finality: Immediate and irrevocable
└── Used for: Large value transfers, time-critical payments

RTGS Message Flow

RTGS Transaction Flow:
│
│  SENDER BANK                        RBI                         RECEIVER BANK
│       │                              │                                │
│  [1] Customer initiates              │                                │
│       │                              │                                │
│  [2] Debit account ─────────────────▶│                                │
│       │                              │                                │
│       │                         [3] Validate                          │
│       │                              │                                │
│       │                         [4] Check liquidity                   │
│       │                              │                                │
│       │                         [5] Settlement in RBI books           │
│       │                              │                                │
│       │◀─────────────────────── [6] Confirmation                      │
│       │                              │                                │
│       │                              │────────────────────────────▶   │
│       │                              │                           [7] Credit
│       │                              │                                │
│       │                              │◀────────────────────────────   │
│       │                              │                           [8] Ack
│       │                              │                                │
│  [9] Notify customer                 │                      [10] Notify customer
│       │                              │                                │

RTGS Liquidity Management

RTGS Liquidity Management:
│
├── Each bank maintains settlement account with RBI
│
├── Intraday Liquidity Facility (ILF):
│   Banks can avail collateralized intraday credit from RBI
│   Collateral: Government securities
│
├── Queue Management:
│   If insufficient balance:
│   ├── Transaction goes into queue
│   ├── Queue position based on priority
│   └── Processed when liquidity available
│
├── Gridlock Resolution:
│   If multiple banks have queued transactions
│   RBI runs optimization algorithm to resolve
│
└── End of Day:
    All ILF must be repaid
    Any shortfall → Penalty (MSF rate + 2%)

2.6 Database Updates During Payment

Let us trace the exact database operations for a payment.

Sender Bank Database Operations

sql
-- Step 1: Begin Transaction (Database)
BEGIN TRANSACTION;

-- Step 2: Lock the account row
SELECT balance, available_balance, status
FROM accounts
WHERE account_number = '50100123456789'
FOR UPDATE;

-- Step 3: Verify sufficient balance
-- Application checks: available_balance >= transaction_amount

-- Step 4: Debit the account
UPDATE accounts
SET balance = balance - 500.00,
    available_balance = available_balance - 500.00,
    last_transaction_date = NOW(),
    version = version + 1
WHERE account_number = '50100123456789'
  AND version = @current_version;  -- Optimistic locking

-- Step 5: Create transaction record
INSERT INTO transactions (
    transaction_id,
    account_number,
    transaction_type,
    amount,
    balance_after,
    reference_number,
    description,
    channel,
    created_at
) VALUES (
    'TXN20240115100001',
    '50100123456789',
    'DEBIT',
    500.00,
    (SELECT balance FROM accounts WHERE account_number = '50100123456789'),
    'YBL2401150000001234',
    'UPI/rahul@oksbi/Payment',
    'UPI',
    NOW()
);

-- Step 6: Create ledger entry (Double-entry bookkeeping)
INSERT INTO ledger_entries (
    entry_id,
    transaction_id,
    account_number,
    entry_type,
    amount,
    contra_account,
    created_at
) VALUES (
    'LE20240115100001',
    'TXN20240115100001',
    '50100123456789',
    'DEBIT',
    500.00,
    'UPI_CLEARING_ACCOUNT',
    NOW()
);

-- Corresponding credit to clearing account
INSERT INTO ledger_entries (
    entry_id,
    transaction_id,
    account_number,
    entry_type,
    amount,
    contra_account,
    created_at
) VALUES (
    'LE20240115100002',
    'TXN20240115100001',
    'UPI_CLEARING_ACCOUNT',
    'CREDIT',
    500.00,
    '50100123456789',
    NOW()
);

-- Step 7: Commit
COMMIT;

Receiver Bank Database Operations

sql
-- Step 1: Begin Transaction
BEGIN TRANSACTION;

-- Step 2: Lock the account row
SELECT balance, available_balance, status
FROM accounts
WHERE account_number = '32145678901234'
FOR UPDATE;

-- Step 3: Verify account can receive credit
-- Application checks: status = 'ACTIVE', credit_blocked = FALSE

-- Step 4: Credit the account
UPDATE accounts
SET balance = balance + 500.00,
    available_balance = available_balance + 500.00,
    last_transaction_date = NOW(),
    version = version + 1
WHERE account_number = '32145678901234';

-- Step 5: Create transaction record
INSERT INTO transactions (
    transaction_id,
    account_number,
    transaction_type,
    amount,
    balance_after,
    reference_number,
    description,
    channel,
    created_at
) VALUES (
    'TXN20240115100002',
    '32145678901234',
    'CREDIT',
    500.00,
    (SELECT balance FROM accounts WHERE account_number = '32145678901234'),
    'YBL2401150000001234',
    'UPI/priya@ybl',
    'UPI',
    NOW()
);

-- Step 6: Create ledger entries
INSERT INTO ledger_entries (
    entry_id,
    transaction_id,
    account_number,
    entry_type,
    amount,
    contra_account,
    created_at
) VALUES (
    'LE20240115100003',
    'TXN20240115100002',
    'UPI_CLEARING_ACCOUNT',
    'DEBIT',
    500.00,
    '32145678901234',
    NOW()
);

INSERT INTO ledger_entries (
    entry_id,
    transaction_id,
    account_number,
    entry_type,
    amount,
    contra_account,
    created_at
) VALUES (
    'LE20240115100004',
    'TXN20240115100002',
    '32145678901234',
    'CREDIT',
    500.00,
    'UPI_CLEARING_ACCOUNT',
    NOW()
);

-- Step 7: Commit
COMMIT;

2.7 Failure Scenarios and Handling

Scenario 1: Debit Success, Credit Failure

Failure: SBI account closed, cannot credit

Timeline:
T+0:    HDFC debits Priya's account (SUCCESS)
T+1:    NPCI sends credit instruction to SBI
T+2:    SBI returns: "Account Closed" error

Recovery:
T+3:    NPCI receives failure from SBI
T+4:    NPCI updates transaction status to FAILED
T+5:    NPCI sends refund instruction to HDFC (via Yes Bank)
T+6:    HDFC reverses the debit
T+7:    Priya's balance restored
T+8:    Priya notified: "Payment failed. Amount refunded."

HDFC Refund Processing:
BEGIN TRANSACTION;

-- Reverse the original debit
UPDATE accounts
SET balance = balance + 500.00,
    available_balance = available_balance + 500.00
WHERE account_number = '50100123456789';

-- Create reversal transaction
INSERT INTO transactions (
    transaction_type, amount, reference_number, description
) VALUES (
    'CREDIT', 500.00, 'YBL2401150000001234_REV',
    'REFUND/UPI/Original txn failed'
);

-- Ledger entries for reversal
INSERT INTO ledger_entries (...);

COMMIT;

Scenario 2: NPCI System Timeout

Failure: NPCI does not respond within timeout

Timeline:
T+0:     HDFC receives payment request
T+0:     HDFC checks balance, places hold (not debit yet)
T+1:     HDFC sends to Yes Bank PSP
T+2:     Yes Bank sends to NPCI
T+30s:   No response from NPCI
T+31s:   Timeout triggered

Recovery:
Option A: If hold was placed
├── Release hold on Priya's account
├── Mark transaction as TIMEOUT
└── Customer can retry

Option B: Pending state
├── Transaction marked as PENDING
├── Reconciliation process queries NPCI later
├── NPCI provides final status
└── Appropriate action based on status

Status Check (Later):
HDFC queries NPCI for transaction status:
GET /api/v1/transaction/status?txnId=YBL2401150000001234

Response scenarios:
├── SUCCESS → Debit already done, confirm
├── FAILED → Release hold, notify customer
├── NOT_FOUND → Transaction never processed, release hold
└── PENDING → Wait and retry status check

Scenario 3: Duplicate Transaction Detection

Scenario: Same payment request sent twice

First Request:
T+0: Request received with txn_id = "YBL2401150000001234"
T+1: Transaction processed, SUCCESS

Second Request (duplicate):
T+5: Same request with txn_id = "YBL2401150000001234"

Detection:
SELECT status FROM upi_transactions
WHERE txn_id = 'YBL2401150000001234';

Result: Record exists, status = SUCCESS

Action:
├── Do NOT process again
├── Return original transaction details
└── Log duplicate attempt for monitoring

Response to second request:
{
  "txnId": "YBL2401150000001234",
  "status": "ALREADY_PROCESSED",
  "originalStatus": "SUCCESS",
  "message": "Transaction already completed"
}

Scenario 4: Insufficient Balance

Scenario: Priya's balance is Rs. 300, tries to send Rs. 500

Timeline:
T+0: Request received
T+1: Balance check
     SELECT available_balance FROM accounts
     WHERE account_number = '50100123456789';
     Result: 300.00
T+2: 300 < 500, insufficient funds

Action:
├── Do not debit
├── Return error immediately
└── No need to involve NPCI

Response:
{
  "status": "FAILED",
  "errorCode": "U16",
  "errorMessage": "Insufficient funds"
}

2.8 Idempotency in Payment Systems

Idempotency ensures that processing the same request multiple times produces the same result as processing it once. This is critical in payment systems where network failures can cause request retries.
Idempotency Implementation:
│
├── Client generates unique idempotency key
│   Example: "IDK_PHONEPE_2024011510300012345"
│
├── Server processing:
│
│   Step 1: Check if idempotency key exists
│   SELECT * FROM idempotency_keys
│   WHERE key = 'IDK_PHONEPE_2024011510300012345';
│
│   Step 2a: If exists, return cached response
│   Return stored_response
│
│   Step 2b: If not exists, process request
│   BEGIN TRANSACTION;
│
│   -- Insert idempotency record first
│   INSERT INTO idempotency_keys (
│     key, request_hash, status, created_at, expires_at
│   ) VALUES (
│     'IDK_PHONEPE_2024011510300012345',
│     SHA256(request_body),
│     'PROCESSING',
│     NOW(),
│     NOW() + INTERVAL '24 hours'
│   );
│
│   -- Process payment
│   -- ... payment processing logic ...
│
│   -- Update idempotency record with response
│   UPDATE idempotency_keys
│   SET status = 'COMPLETED',
│       response = @response_json
│   WHERE key = 'IDK_PHONEPE_2024011510300012345';
│
│   COMMIT;
│
└── Cleanup: Delete expired idempotency keys periodically

2.9 Chapter Summary

This chapter traced the complete journey of payments through:
  1. UPI: Real-time payments with immediate confirmation, net settlement
  2. NEFT: Batch processing, half-hourly batches, net settlement
  3. RTGS: Real-time gross settlement for large values
Key concepts covered:
  • Every payment involves debit at sender, credit at receiver
  • Settlement is separate from transaction processing
  • Banks maintain accounts with RBI for interbank settlement
  • Idempotency prevents duplicate processing
  • Multiple failure scenarios exist and require careful handling
  • Reconciliation ensures consistency across systems

Chapter 2 Interview Questions

Basic Level

  1. What happens when you send Rs. 500 via UPI from HDFC to SBI?
  2. What is the difference between NEFT and RTGS?
  3. What is settlement? How does it differ from the actual transaction?
  4. What is a VPA in UPI? How is it resolved to a bank account?
  5. Why does NEFT take 30-60 minutes while UPI is instant?
  6. What is the role of NPCI in UPI transactions?
  7. What is UTR (Unique Transaction Reference)?
  8. What happens if the beneficiary account is closed during a NEFT transfer?
  9. What is the minimum amount for RTGS?
  10. What is the difference between gross settlement and net settlement?

Intermediate Level

  1. Explain the complete message flow in a UPI transaction.
  2. How does NPCI handle a timeout from the payee bank during UPI?
  3. What database operations happen when a payment is processed?
  4. How do banks ensure idempotency in payment processing?
  5. What is the settlement cycle for UPI? How is net position calculated?
  6. Explain how NEFT batch processing works.
  7. What happens to pending RTGS transactions at end of day?
  8. How does a bank handle a debit success but credit failure scenario?
  9. What is the role of the clearing account in payment processing?
  10. Explain the difference between available balance and ledger balance.

Advanced Level

  1. Design the database schema for a payment transaction system.
  2. How would you implement exactly-once semantics in a payment system?
  3. What is the double-entry bookkeeping model for a payment transaction?
  4. How does RTGS liquidity management work? What is gridlock resolution?
  5. Design a reconciliation system that compares internal records with NPCI settlement files.
  6. How would you handle a network partition during payment processing?
  7. Explain how UPI handles collect requests differently from pay requests.
  8. What is the role of SFMS in NEFT/RTGS? How does it differ from the UPI protocol?
  9. Design an idempotency service that handles millions of payments per day.
  10. How do you ensure consistency between the account balance and ledger entries?

Expert Level

  1. Design a payment system that handles 10 million transactions per day with 99.99% availability.
  2. How would you implement saga pattern for a cross-border payment involving multiple banks?
  3. Design the architecture for a payment switch that routes to different payment rails based on transaction attributes.
  4. How do you handle clock skew across distributed payment systems?
  5. Design a system to detect and prevent duplicate payments across multiple channels.

PART 3: Core Banking System (CBS)

Chapter 3: Core Banking System Architecture

3.1 What is Core Banking?

Core Banking refers to the centralized system that processes all banking transactions and maintains customer account information. The word "Core" stands for "Centralized Online Real-time Exchange." Before core banking, each bank branch maintained its own ledgers and accounts. A customer could only transact at their "home branch." Core banking changed this by centralizing all data, enabling "anywhere banking."
For engineers, Core Banking System (CBS) is the most critical system in a bank. Every payment you process, every account you query, every balance you check ultimately touches the CBS. Understanding CBS architecture is fundamental to building any banking application.

3.2 CBS Components

┌─────────────────────────────────────────────────────────────────────────────┐
│                        CORE BANKING SYSTEM ARCHITECTURE                      │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                              │
│  ┌─────────────────────────────────────────────────────────────────────┐    │
│  │                         CHANNEL LAYER                                │    │
│  │                                                                      │    │
│  │  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐  │    │
│  │  │ Internet │ │  Mobile  │ │  Branch  │ │   ATM    │ │   API    │  │    │
│  │  │ Banking  │ │ Banking  │ │ Terminal │ │ Switch   │ │ Gateway  │  │    │
│  │  └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘  │    │
│  │       │            │            │            │            │         │    │
│  └───────┴────────────┴────────────┴────────────┴────────────┴─────────┘    │
│                                    │                                         │
│                                    ▼                                         │
│  ┌─────────────────────────────────────────────────────────────────────┐    │
│  │                      MIDDLEWARE / ESB LAYER                          │    │
│  │                                                                      │    │
│  │   • Service Orchestration                                            │    │
│  │   • Protocol Translation                                             │    │
│  │   • Security & Authentication                                        │    │
│  │   • Message Transformation                                           │    │
│  │   • Routing                                                          │    │
│  │                                                                      │    │
│  └──────────────────────────────────┬──────────────────────────────────┘    │
│                                     │                                        │
│                                     ▼                                        │
│  ┌─────────────────────────────────────────────────────────────────────┐    │
│  │                         CBS APPLICATION LAYER                        │    │
│  │                                                                      │    │
│  │  ┌───────────────┐ ┌───────────────┐ ┌───────────────┐              │    │
│  │  │   CUSTOMER    │ │    ACCOUNT    │ │   DEPOSIT     │              │    │
│  │  │  MANAGEMENT   │ │  MANAGEMENT   │ │   MODULE      │              │    │
│  │  └───────────────┘ └───────────────┘ └───────────────┘              │    │
│  │                                                                      │    │
│  │  ┌───────────────┐ ┌───────────────┐ ┌───────────────┐              │    │
│  │  │    LOANS      │ │   PAYMENTS    │ │    LIMITS     │              │    │
│  │  │   MODULE      │ │    MODULE     │ │   MODULE      │              │    │
│  │  └───────────────┘ └───────────────┘ └───────────────┘              │    │
│  │                                                                      │    │
│  │  ┌───────────────┐ ┌───────────────┐ ┌───────────────┐              │    │
│  │  │   GENERAL     │ │   INTEREST    │ │   CHARGES &   │              │    │
│  │  │   LEDGER      │ │   ENGINE      │ │   FEES        │              │    │
│  │  └───────────────┘ └───────────────┘ └───────────────┘              │    │
│  │                                                                      │    │
│  └──────────────────────────────────┬──────────────────────────────────┘    │
│                                     │                                        │
│                                     ▼                                        │
│  ┌─────────────────────────────────────────────────────────────────────┐    │
│  │                         DATA LAYER                                   │    │
│  │                                                                      │    │
│  │  ┌───────────────────────────────────────────────────────────────┐  │    │
│  │  │                    PRIMARY DATABASE                            │  │    │
│  │  │                  (Oracle / DB2 / SQL Server)                   │  │    │
│  │  │                                                                │  │    │
│  │  │  • Customer Master     • Account Master     • Transaction Log  │  │    │
│  │  │  • General Ledger      • Product Master     • Audit Trail      │  │    │
│  │  │                                                                │  │    │
│  │  └───────────────────────────────────────────────────────────────┘  │    │
│  │                                                                      │    │
│  │  ┌─────────────────────────────┐  ┌─────────────────────────────┐  │    │
│  │  │      REPORTING DATABASE     │  │      ARCHIVE DATABASE       │  │    │
│  │  │      (Data Warehouse)       │  │      (Historical Data)      │  │    │
│  │  └─────────────────────────────┘  └─────────────────────────────┘  │    │
│  │                                                                      │    │
│  └─────────────────────────────────────────────────────────────────────┘    │
│                                                                              │
└─────────────────────────────────────────────────────────────────────────────┘

3.3 Customer Information File (CIF)

The Customer Information File is the master record for each customer. A single customer may have multiple accounts, but there is only one CIF.
sql
-- Customer Master Table Structure
CREATE TABLE customer_master (
    cif_id              VARCHAR(20) PRIMARY KEY,
    customer_type       VARCHAR(10) NOT NULL,  -- INDIVIDUAL, CORPORATE, HUF, TRUST
    title               VARCHAR(10),
    first_name          VARCHAR(100) NOT NULL,
    middle_name         VARCHAR(100),
    last_name           VARCHAR(100) NOT NULL,
    date_of_birth       DATE,
    gender              VARCHAR(10),
    marital_status      VARCHAR(20),
    nationality         VARCHAR(50),
    resident_status     VARCHAR(20),  -- RESIDENT, NRI, NRO, NRE
    pan_number          VARCHAR(10) UNIQUE,
    aadhaar_number      VARCHAR(12),
    passport_number     VARCHAR(20),
    email               VARCHAR(255),
    mobile_number       VARCHAR(15) NOT NULL,
    alternate_mobile    VARCHAR(15),
    kyc_status          VARCHAR(20) DEFAULT 'PENDING',
    kyc_date            DATE,
    risk_category       VARCHAR(20) DEFAULT 'LOW',
    segment             VARCHAR(20),  -- MASS, AFFLUENT, HNI, ULTRA_HNI
    relationship_manager VARCHAR(20),
    created_at          TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at          TIMESTAMP,
    created_by          VARCHAR(50),
    updated_by          VARCHAR(50),
    version             INTEGER DEFAULT 1,
    status              VARCHAR(20) DEFAULT 'ACTIVE'
);

-- Customer Address Table
CREATE TABLE customer_address (
    address_id          SERIAL PRIMARY KEY,
    cif_id              VARCHAR(20) REFERENCES customer_master(cif_id),
    address_type        VARCHAR(20) NOT NULL,  -- PERMANENT, CORRESPONDENCE, OFFICE
    address_line1       VARCHAR(255) NOT NULL,
    address_line2       VARCHAR(255),
    address_line3       VARCHAR(255),
    city                VARCHAR(100) NOT NULL,
    state               VARCHAR(100) NOT NULL,
    country             VARCHAR(100) DEFAULT 'INDIA',
    pincode             VARCHAR(10) NOT NULL,
    is_primary          BOOLEAN DEFAULT FALSE,
    verified            BOOLEAN DEFAULT FALSE,
    verification_date   DATE,
    created_at          TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- KYC Documents Table
CREATE TABLE kyc_documents (
    document_id         SERIAL PRIMARY KEY,
    cif_id              VARCHAR(20) REFERENCES customer_master(cif_id),
    document_type       VARCHAR(50) NOT NULL,  -- PAN, AADHAAR, PASSPORT, VOTER_ID
    document_number     VARCHAR(50) NOT NULL,
    issue_date          DATE,
    expiry_date         DATE,
    issuing_authority   VARCHAR(100),
    document_path       VARCHAR(500),
    verification_status VARCHAR(20) DEFAULT 'PENDING',
    verified_by         VARCHAR(50),
    verified_at         TIMESTAMP,
    created_at          TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

3.4 Account Management

Accounts are linked to customers through CIF. A customer can have multiple accounts of different types.
sql
-- Account Master Table
CREATE TABLE account_master (
    account_number      VARCHAR(20) PRIMARY KEY,
    cif_id              VARCHAR(20) REFERENCES customer_master(cif_id),
    account_type        VARCHAR(30) NOT NULL,  -- SAVINGS, CURRENT, FD, RD, LOAN, CC
    product_code        VARCHAR(20) NOT NULL,
    currency            VARCHAR(3) DEFAULT 'INR',
    branch_code         VARCHAR(10) NOT NULL,
    opening_date        DATE NOT NULL,
    maturity_date       DATE,
    status              VARCHAR(20) DEFAULT 'ACTIVE',
    -- ACTIVE, DORMANT, FROZEN, CLOSED, BLOCKED

    -- Balance Fields
    ledger_balance      DECIMAL(18,2) DEFAULT 0,
    available_balance   DECIMAL(18,2) DEFAULT 0,
    hold_amount         DECIMAL(18,2) DEFAULT 0,
    unclear_balance     DECIMAL(18,2) DEFAULT 0,
    minimum_balance     DECIMAL(18,2) DEFAULT 0,
    overdraft_limit     DECIMAL(18,2) DEFAULT 0,

    -- Interest Fields
    interest_rate       DECIMAL(8,4),
    interest_accrued    DECIMAL(18,2) DEFAULT 0,
    last_interest_date  DATE,

    -- Control Fields
    debit_allowed       BOOLEAN DEFAULT TRUE,
    credit_allowed      BOOLEAN DEFAULT TRUE,
    cheque_book_issued  BOOLEAN DEFAULT FALSE,
    atm_card_issued     BOOLEAN DEFAULT FALSE,
    internet_banking    BOOLEAN DEFAULT FALSE,
    mobile_banking      BOOLEAN DEFAULT FALSE,

    -- Nominee Information
    nominee_name        VARCHAR(200),
    nominee_relation    VARCHAR(50),
    nominee_address     VARCHAR(500),

    -- Audit Fields
    created_at          TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at          TIMESTAMP,
    created_by          VARCHAR(50),
    updated_by          VARCHAR(50),
    version             INTEGER DEFAULT 1,

    CONSTRAINT chk_balance CHECK (ledger_balance >= -overdraft_limit)
);

-- Account Balance Components
-- ledger_balance: Actual balance after all posted transactions
-- available_balance: Balance available for withdrawal = ledger_balance - hold_amount + overdraft_limit
-- hold_amount: Amount on hold for pending transactions, cheque clearing, etc.
-- unclear_balance: Balance from cheques not yet cleared

Balance Calculation Logic

Available Balance = Ledger Balance - Hold Amount + Overdraft Limit - Unclear Balance

Example:
Ledger Balance:     10,000.00
Hold Amount:         1,000.00 (pending UPI transaction)
Overdraft Limit:     5,000.00
Unclear Balance:     2,000.00 (deposited cheque not cleared)

Available Balance = 10,000 - 1,000 + 5,000 - 2,000 = 12,000.00

3.5 Transaction Processing

sql
-- Transaction Table
CREATE TABLE transactions (
    transaction_id          VARCHAR(30) PRIMARY KEY,
    account_number          VARCHAR(20) REFERENCES account_master(account_number),
    transaction_type        VARCHAR(10) NOT NULL,  -- DEBIT, CREDIT
    transaction_code        VARCHAR(10) NOT NULL,  -- Identifies type of transaction
    amount                  DECIMAL(18,2) NOT NULL,
    currency                VARCHAR(3) DEFAULT 'INR',

    -- Balance Snapshot
    balance_before          DECIMAL(18,2) NOT NULL,
    balance_after           DECIMAL(18,2) NOT NULL,

    -- Transaction Details
    value_date              DATE NOT NULL,
    posting_date            DATE NOT NULL,
    transaction_time        TIMESTAMP NOT NULL,
    description             VARCHAR(500),
    reference_number        VARCHAR(50),
    external_reference      VARCHAR(50),

    -- Counterparty Details
    contra_account          VARCHAR(20),
    contra_bank_ifsc        VARCHAR(11),
    contra_bank_name        VARCHAR(100),

    -- Channel Information
    channel                 VARCHAR(20) NOT NULL,
    -- BRANCH, ATM, INTERNET_BANKING, MOBILE_BANKING, UPI, NEFT, RTGS, IMPS

    -- Branch Information
    transaction_branch      VARCHAR(10),
    posting_branch          VARCHAR(10),

    -- Instrument Details (for cheques)
    instrument_number       VARCHAR(20),
    instrument_date         DATE,

    -- Status
    status                  VARCHAR(20) DEFAULT 'POSTED',
    -- PENDING, POSTED, REVERSED, FAILED

    -- Audit
    created_at              TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    created_by              VARCHAR(50),
    reversal_id             VARCHAR(30),  -- Reference to reversal transaction if reversed

    -- Indexes
    INDEX idx_account_date (account_number, posting_date),
    INDEX idx_reference (reference_number),
    INDEX idx_value_date (value_date)
);

-- Transaction Codes Master
CREATE TABLE transaction_codes (
    transaction_code    VARCHAR(10) PRIMARY KEY,
    description         VARCHAR(100) NOT NULL,
    debit_credit        VARCHAR(6) NOT NULL,  -- DEBIT, CREDIT
    gl_account          VARCHAR(20) NOT NULL,
    is_cash             BOOLEAN DEFAULT FALSE,
    requires_approval   BOOLEAN DEFAULT FALSE,
    affects_interest    BOOLEAN DEFAULT TRUE
);

-- Common Transaction Codes:
-- CSH: Cash Deposit/Withdrawal
-- TRF: Transfer
-- CHQ: Cheque Deposit/Payment
-- INT: Interest Credit
-- CHG: Charges
-- SAL: Salary Credit
-- EMI: EMI Debit
-- UPI: UPI Transaction
-- ATM: ATM Transaction

3.6 Double-Entry Bookkeeping in CBS

Every transaction in CBS follows double-entry bookkeeping: every debit has a corresponding credit.
Transaction: Customer deposits Rs. 10,000 cash

Accounting Entries:
┌────────────────────────────────────────────────────────────────────┐
│                                                                    │
│  DEBIT:  Cash in Hand (Asset) ─────────────── Rs. 10,000          │
│  CREDIT: Customer Savings Account (Liability)─ Rs. 10,000          │
│                                                                    │
│  GL Impact:                                                        │
│  ├── Assets increase (Cash received)                               │
│  └── Liabilities increase (Bank owes customer this money)          │
│                                                                    │
└────────────────────────────────────────────────────────────────────┘

Transaction: Customer withdraws Rs. 5,000 from ATM

Accounting Entries:
┌────────────────────────────────────────────────────────────────────┐
│                                                                    │
│  DEBIT:  Customer Savings Account (Liability)─ Rs. 5,000          │
│  CREDIT: Cash at ATM (Asset) ───────────────── Rs. 5,000          │
│                                                                    │
│  GL Impact:                                                        │
│  ├── Liabilities decrease (Bank owes less to customer)             │
│  └── Assets decrease (Cash dispensed)                              │
│                                                                    │
└────────────────────────────────────────────────────────────────────┘

Ledger Entry Table

sql
CREATE TABLE ledger_entries (
    entry_id            SERIAL PRIMARY KEY,
    transaction_id      VARCHAR(30) NOT NULL,
    entry_type          VARCHAR(6) NOT NULL,  -- DEBIT or CREDIT
    account_type        VARCHAR(20) NOT NULL, -- CUSTOMER, GL, INTERNAL
    account_number      VARCHAR(20) NOT NULL,
    amount              DECIMAL(18,2) NOT NULL,
    currency            VARCHAR(3) DEFAULT 'INR',
    value_date          DATE NOT NULL,
    posting_date        DATE NOT NULL,
    gl_code             VARCHAR(20),
    cost_center         VARCHAR(20),
    profit_center       VARCHAR(20),
    narration           VARCHAR(500),
    created_at          TIMESTAMP DEFAULT CURRENT_TIMESTAMP,

    INDEX idx_account (account_number, posting_date),
    INDEX idx_gl (gl_code, posting_date)
);

-- For each transaction, sum of DEBITs must equal sum of CREDITs
-- This is enforced at application level or through triggers

3.7 General Ledger (GL)

The General Ledger is the master accounting record of the bank. Every customer transaction ultimately affects GL accounts.
sql
-- Chart of Accounts (GL Structure)
CREATE TABLE gl_accounts (
    gl_code             VARCHAR(20) PRIMARY KEY,
    gl_name             VARCHAR(200) NOT NULL,
    gl_type             VARCHAR(20) NOT NULL,
    -- ASSET, LIABILITY, INCOME, EXPENSE, CAPITAL
    parent_gl           VARCHAR(20),
    level               INTEGER NOT NULL,
    is_leaf             BOOLEAN DEFAULT TRUE,
    currency            VARCHAR(3) DEFAULT 'INR',
    branch_code         VARCHAR(10),
    status              VARCHAR(20) DEFAULT 'ACTIVE',
    created_at          TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- GL Account Balances
CREATE TABLE gl_balances (
    gl_code             VARCHAR(20),
    branch_code         VARCHAR(10),
    currency            VARCHAR(3),
    balance_date        DATE,
    opening_balance     DECIMAL(18,2),
    total_debit         DECIMAL(18,2),
    total_credit        DECIMAL(18,2),
    closing_balance     DECIMAL(18,2),
    PRIMARY KEY (gl_code, branch_code, currency, balance_date)
);

-- GL Structure Example:
-- 1000000 - Assets
--   1100000 - Cash and Bank Balances
--     1101000 - Cash in Hand
--       1101001 - Cash at Branches
--       1101002 - Cash at ATMs
--     1102000 - Balances with RBI
--     1103000 - Balances with Banks
--   1200000 - Investments
--     1201000 - Government Securities
--     1202000 - Other Investments
--   1300000 - Advances (Loans)
--     1301000 - Retail Loans
--     1302000 - Corporate Loans
-- 2000000 - Liabilities
--   2100000 - Deposits
--     2101000 - Savings Deposits
--     2102000 - Current Deposits
--     2103000 - Term Deposits
--   2200000 - Borrowings
-- 3000000 - Capital
-- 4000000 - Income
--   4100000 - Interest Income
--   4200000 - Fee Income
-- 5000000 - Expenses
--   5100000 - Interest Expense
--   5200000 - Operating Expenses

3.8 Interest Calculation Engine

Banks calculate interest on deposits and loans. This is one of the most critical CBS components.

Savings Account Interest Calculation

sql
-- Interest Calculation Parameters
CREATE TABLE interest_parameters (
    product_code        VARCHAR(20),
    slab_from           DECIMAL(18,2),
    slab_to             DECIMAL(18,2),
    interest_rate       DECIMAL(8,4),
    calculation_basis   VARCHAR(20),  -- DAILY_BALANCE, MONTHLY_MINIMUM
    compounding         VARCHAR(20),  -- MONTHLY, QUARTERLY, HALF_YEARLY
    effective_from      DATE,
    effective_to        DATE,
    PRIMARY KEY (product_code, slab_from, effective_from)
);

-- Daily Product Balance (for interest calculation)
CREATE TABLE daily_product_balance (
    account_number      VARCHAR(20),
    balance_date        DATE,
    opening_balance     DECIMAL(18,2),
    closing_balance     DECIMAL(18,2),
    minimum_balance     DECIMAL(18,2),
    average_balance     DECIMAL(18,2),
    interest_accrued    DECIMAL(18,2),
    PRIMARY KEY (account_number, balance_date)
);

Interest Calculation Logic

python
# Savings Account Interest Calculation (Daily Product Basis)

def calculate_savings_interest(account_number, month, year):
    """
    Calculate interest for savings account
    Interest = Principal × Rate × Time / 365
    Calculated on daily closing balance
    Posted quarterly (March, June, September, December)
    """

    # Get daily balances for the month
    daily_balances = get_daily_balances(account_number, month, year)

    # Get applicable interest rate
    interest_rate = get_interest_rate(account_number)

    total_interest = 0

    for day, balance in daily_balances.items():
        if balance > 0:
            # Daily interest = Balance × (Rate/100) × (1/365)
            daily_interest = balance * (interest_rate / 100) * (1 / 365)
            total_interest += daily_interest

            # Store accrued interest
            update_accrued_interest(account_number, day, daily_interest)

    return round(total_interest, 2)


def post_quarterly_interest(quarter_end_date):
    """
    Post accrued interest to accounts at quarter end
    """
    accounts = get_all_savings_accounts()

    for account in accounts:
        # Get total accrued interest for the quarter
        accrued = get_accrued_interest(account.account_number, quarter_end_date)

        if accrued > 0:
            # Deduct TDS if applicable (interest > 40,000 per year)
            tds = calculate_tds(account.cif_id, accrued)
            net_interest = accrued - tds

            # Credit interest to account
            post_transaction(
                account_number=account.account_number,
                transaction_type='CREDIT',
                amount=net_interest,
                transaction_code='INT',
                description=f'Interest for Q ending {quarter_end_date}'
            )

            # Post TDS if applicable
            if tds > 0:
                post_tds_entry(account, tds)

            # Reset accrued interest
            reset_accrued_interest(account.account_number)

Loan Interest Calculation

python
def calculate_loan_emi(principal, annual_rate, tenure_months):
    """
    Calculate EMI using reducing balance method

    EMI = P × r × (1+r)^n / ((1+r)^n - 1)

    Where:
    P = Principal loan amount
    r = Monthly interest rate (annual rate / 12 / 100)
    n = Loan tenure in months
    """
    monthly_rate = annual_rate / 12 / 100

    emi = principal * monthly_rate * ((1 + monthly_rate) ** tenure_months) / \
          (((1 + monthly_rate) ** tenure_months) - 1)

    return round(emi, 2)


def generate_amortization_schedule(principal, annual_rate, tenure_months, start_date):
    """
    Generate complete loan amortization schedule
    """
    emi = calculate_loan_emi(principal, annual_rate, tenure_months)
    monthly_rate = annual_rate / 12 / 100
    balance = principal
    schedule = []

    for month in range(1, tenure_months + 1):
        interest_component = round(balance * monthly_rate, 2)
        principal_component = round(emi - interest_component, 2)
        balance = round(balance - principal_component, 2)

        # Handle last EMI adjustment for rounding
        if month == tenure_months:
            principal_component += balance
            balance = 0

        schedule.append({
            'installment_number': month,
            'due_date': start_date + timedelta(days=30 * month),
            'emi_amount': emi,
            'principal': principal_component,
            'interest': interest_component,
            'outstanding_balance': balance
        })

    return schedule

3.9 End of Day (EOD) Processing

EOD is a critical batch process that runs after business hours to complete the day's processing.
┌─────────────────────────────────────────────────────────────────────────────┐
│                           EOD PROCESSING SEQUENCE                            │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                              │
│  STEP 1: Cutoff                                                              │
│  ─────────────────                                                           │
│  • Stop online transaction processing                                        │
│  • Queue any pending transactions                                            │
│  • Lock accounts for processing                                              │
│                                                                              │
│  STEP 2: Transaction Verification                                            │
│  ────────────────────────────────────                                        │
│  • Verify all transactions are posted                                        │
│  • Check debit = credit for all entries                                      │
│  • Identify stuck/failed transactions                                        │
│                                                                              │
│  STEP 3: Interest Accrual                                                    │
│  ────────────────────────────                                                │
│  • Calculate daily interest for all accounts                                 │
│  • Update accrued interest fields                                            │
│  • Apply penalty interest where applicable                                   │
│                                                                              │
│  STEP 4: Charges Processing                                                  │
│  ─────────────────────────────                                               │
│  • Apply minimum balance charges                                             │
│  • Apply account maintenance charges                                         │
│  • Process SMS charges                                                       │
│                                                                              │
│  STEP 5: Clearing Processing                                                 │
│  ──────────────────────────────                                              │
│  • Process inward clearing (cheque credits)                                  │
│  • Process outward clearing returns                                          │
│  • Update unclear balances                                                   │
│                                                                              │
│  STEP 6: GL Balancing                                                        │
│  ────────────────────────                                                    │
│  • Calculate GL balances for the day                                         │
│  • Verify GL is balanced (Assets = Liabilities + Capital)                    │
│  • Generate GL reports                                                       │
│                                                                              │
│  STEP 7: NPA Classification                                                  │
│  ────────────────────────────                                                │
│  • Check loan overdue status                                                 │
│  • Update NPA classification                                                 │
│  • Calculate provisions                                                      │
│                                                                              │
│  STEP 8: Dormancy Processing                                                 │
│  ────────────────────────────                                                │
│  • Identify accounts with no transactions for 24 months                      │
│  • Mark as dormant                                                           │
│  • Block debit for dormant accounts                                          │
│                                                                              │
│  STEP 9: Report Generation                                                   │
│  ───────────────────────────                                                 │
│  • Generate daily reports                                                    │
│  • Generate regulatory reports                                               │
│  • Generate exception reports                                                │
│                                                                              │
│  STEP 10: Date Rollover                                                      │
│  ───────────────────────────                                                 │
│  • Move system date to next business day                                     │
│  • Initialize next day's files                                               │
│  • Resume online processing                                                  │
│                                                                              │
│  Typical Duration: 2-6 hours depending on bank size                          │
│                                                                              │
└─────────────────────────────────────────────────────────────────────────────┘

3.10 ACID Properties in CBS

CBS transactions must maintain ACID properties.

Atomicity

sql
-- Example: Fund Transfer (must be atomic)

BEGIN TRANSACTION;

-- Step 1: Debit source account
UPDATE account_master
SET ledger_balance = ledger_balance - 10000,
    available_balance = available_balance - 10000
WHERE account_number = '123456789';

-- Check if debit successful
IF @@ROWCOUNT = 0 OR (SELECT available_balance FROM account_master WHERE account_number = '123456789') < 0
BEGIN
    ROLLBACK TRANSACTION;
    RAISERROR ('Insufficient balance', 16, 1);
    RETURN;
END

-- Step 2: Credit destination account
UPDATE account_master
SET ledger_balance = ledger_balance + 10000,
    available_balance = available_balance + 10000
WHERE account_number = '987654321';

-- Check if credit successful
IF @@ROWCOUNT = 0
BEGIN
    ROLLBACK TRANSACTION;
    RAISERROR ('Destination account not found', 16, 1);
    RETURN;
END

-- Step 3: Create transaction records
INSERT INTO transactions (...);
INSERT INTO ledger_entries (...);

COMMIT TRANSACTION;
-- Either both accounts are updated, or neither is updated

Isolation Levels

sql
-- Read Committed (default in most banks)
-- Prevents dirty reads but allows non-repeatable reads

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

-- For balance enquiry (allow reads during updates)
SELECT ledger_balance, available_balance
FROM account_master WITH (NOLOCK)
WHERE account_number = '123456789';

-- For transactions (prevent concurrent modifications)
SELECT ledger_balance, available_balance
FROM account_master WITH (UPDLOCK, ROWLOCK)
WHERE account_number = '123456789';

Concurrency Control

sql
-- Optimistic Locking using version number
UPDATE account_master
SET ledger_balance = ledger_balance - @amount,
    version = version + 1
WHERE account_number = @account_number
AND version = @expected_version;

-- If @@ROWCOUNT = 0, someone else modified the record
-- Retry the transaction

-- Pessimistic Locking for high-contention scenarios
SELECT * FROM account_master WITH (UPDLOCK, ROWLOCK)
WHERE account_number = @account_number;
-- Row is locked until transaction completes

3.11 CBS Vendors

Major CBS vendors in India:
VendorProductBanks Using
TCSTCS BaNCSSBI, Axis Bank, Deutsche Bank
InfosysFinacleICICI, HDFC, Bank of Baroda
OracleFLEXCUBEKotak, Yes Bank, IndusInd
TemenosT24Some small/mid banks
FISPROFILESome foreign banks
Nucleus SoftwareFinnOneNBFCs, HFCs

Why Banks Still Use Oracle/DB2

  1. Proven reliability: Decades of production use
  2. ACID compliance: Critical for financial transactions
  3. Vendor support: Enterprise SLAs
  4. Regulatory acceptance: Auditors understand these systems
  5. Legacy integration: Existing procedures and skills
  6. Performance at scale: Handles millions of accounts

Chapter 3 Interview Questions

Basic Level

  1. What is Core Banking System (CBS)?
  2. What is CIF and why is it important?
  3. What is the difference between ledger balance and available balance?
  4. What is EOD processing? Why is it necessary?
  5. What is double-entry bookkeeping?
  6. Name three CBS vendors used in Indian banks.
  7. What is General Ledger?
  8. What is the purpose of a hold on an account?
  9. What are the common transaction codes in CBS?
  10. What is dormancy in banking?

Intermediate Level

  1. Design the database schema for account management.
  2. Explain interest calculation for savings accounts.
  3. How does EMI calculation work? Derive the formula.
  4. Explain the sequence of EOD processing.
  5. How do you ensure ACID properties in CBS transactions?
  6. What is optimistic vs pessimistic locking? When to use which?
  7. How is TDS calculated and deducted on interest?
  8. Explain the GL structure in a bank.
  9. How does cheque clearing affect account balances?
  10. What is the difference between posting date and value date?

Advanced Level

  1. Design a high-availability architecture for CBS.
  2. How would you handle concurrent transactions on the same account?
  3. Design the interest calculation engine for a bank.
  4. How do you ensure GL balancing in a distributed CBS?
  5. Design the NPA classification system.
  6. How would you migrate from one CBS to another?
  7. Design disaster recovery for CBS.
  8. How do you handle EOD failures?
  9. Design the audit trail system for CBS.
  10. How do you handle regulatory reporting from CBS?

PART 4: Payment Rails in India

Chapter 4: UPI - Unified Payments Interface

4.1 What is UPI?

UPI (Unified Payments Interface) is an instant real-time payment system developed by NPCI. Launched in April 2016, it enables instant fund transfers between bank accounts using a mobile phone.

UPI Statistics (2024)

  • Monthly transactions: 12+ billion
  • Monthly value: Rs. 18+ lakh crore
  • Registered users: 350+ million
  • Daily transactions: 400+ million

Why UPI Succeeded

  1. Interoperability: Any bank to any bank, any app to any app
  2. Simplicity: VPA eliminates need to share account details
  3. Free: No transaction charges for users
  4. 24x7: Works anytime
  5. Mobile-first: Designed for smartphones
  6. Government push: BHIM app, demonetization timing

4.2 UPI Architecture

┌─────────────────────────────────────────────────────────────────────────────┐
│                           UPI ECOSYSTEM                                      │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                              │
│  ┌─────────────────────────────────────────────────────────────────────┐    │
│  │                        UPI APPLICATIONS                              │    │
│  │                                                                      │    │
│  │   ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐  │    │
│  │   │ PhonePe │  │  GPay   │  │  Paytm  │  │  BHIM   │  │  Bank   │  │    │
│  │   │  @ybl   │  │  @okXXX │  │ @paytm  │  │  @upi   │  │  Apps   │  │    │
│  │   └────┬────┘  └────┬────┘  └────┬────┘  └────┬────┘  └────┬────┘  │    │
│  │        │            │            │            │            │        │    │
│  │   Third Party Application Providers (TPAPs)  │       PSP Apps      │    │
│  │                                              │                      │    │
│  └──────────────────────────┬───────────────────┴──────────────────────┘    │
│                             │                                                │
│                             ▼                                                │
│  ┌─────────────────────────────────────────────────────────────────────┐    │
│  │                   PAYMENT SERVICE PROVIDERS (PSPs)                   │    │
│  │                                                                      │    │
│  │   ┌───────────┐  ┌───────────┐  ┌───────────┐  ┌───────────┐       │    │
│  │   │ Yes Bank  │  │ ICICI Bank│  │ Axis Bank │  │ HDFC Bank │       │    │
│  │   │   @ybl    │  │   @icici  │  │   @axl    │  │   @hdfcbank│      │    │
│  │   └─────┬─────┘  └─────┬─────┘  └─────┬─────┘  └─────┬─────┘       │    │
│  │         │              │              │              │              │    │
│  └─────────┴──────────────┴──────────────┴──────────────┴──────────────┘    │
│                                    │                                         │
│                                    ▼                                         │
│  ┌─────────────────────────────────────────────────────────────────────┐    │
│  │                           NPCI UPI SWITCH                            │    │
│  │                                                                      │    │
│  │   • VPA Resolution              • Transaction Routing                │    │
│  │   • Message Validation          • Settlement Calculation             │    │
│  │   • Fraud Checks                • Dispute Management                 │    │
│  │   • Rate Limiting               • Reporting                          │    │
│  │                                                                      │    │
│  └─────────────────────────────────────────────────────────────────────┘    │
│                                    │                                         │
│                                    ▼                                         │
│  ┌─────────────────────────────────────────────────────────────────────┐    │
│  │                          ISSUER BANKS                                │    │
│  │                 (All banks offering UPI to customers)                │    │
│  │                                                                      │    │
│  │   ┌───────────┐  ┌───────────┐  ┌───────────┐  ┌───────────┐       │    │
│  │   │    SBI    │  │   HDFC    │  │   ICICI   │  │   Axis    │       │    │
│  │   │  @oksbi   │  │ @okhdfcbank│  │  @okicici │  │  @okaxis  │       │    │
│  │   └───────────┘  └───────────┘  └───────────┘  └───────────┘       │    │
│  │                                                                      │    │
│  └─────────────────────────────────────────────────────────────────────┘    │
│                                                                              │
│  ════════════════════════════════════════════════════════════════════════   │
│                                                                              │
│  KEY TERMINOLOGY:                                                            │
│                                                                              │
│  PSP (Payment Service Provider):                                             │
│  Bank that provides UPI rails to TPAPs and operates as UPI member.           │
│  Handles VPA registration, authentication, and message routing.              │
│                                                                              │
│  TPAP (Third Party Application Provider):                                    │
│  Non-bank entity providing UPI app. Must partner with PSP bank.              │
│  Examples: PhonePe (via Yes Bank), Google Pay (via multiple banks)           │
│                                                                              │
│  Issuer Bank:                                                                │
│  Bank where customer's account is held. Executes debit/credit.               │
│                                                                              │
│  Acquirer/Remitter Bank:                                                     │
│  Bank initiating the payment request (payer's side).                         │
│                                                                              │
│  Beneficiary Bank:                                                           │
│  Bank receiving the payment (payee's side).                                  │
│                                                                              │
└─────────────────────────────────────────────────────────────────────────────┘

4.3 UPI Transaction Types

Pay (Push Payment)

Scenario: Priya pays Rs. 500 to Rahul

Flow:
Priya (PhonePe) ──Pay Rs.500──▶ rahul@oksbi

• Priya initiates payment
• Priya's account debited first
• Rahul's account credited
• Rahul receives money without any action

Collect (Pull Payment)

Scenario: Merchant requests payment from Customer

Flow:
Merchant ──Collect Request──▶ customer@ybl
customer@ybl ──Approves──▶ Merchant receives money

• Merchant initiates collect request
• Customer receives notification
• Customer approves with UPI PIN
• Customer's account debited
• Merchant's account credited

Intent Payment

Scenario: Payment through QR code or deep link

QR Code contains:
upi://pay?pa=merchant@ybl&pn=ShopName&am=100&cu=INR&tr=TXN123

• Customer scans QR
• App parses intent URL
• Pre-fills payment details
• Customer confirms and enters PIN

4.4 UPI Message Format

UPI uses XML-based messaging. Key message types:
xml
<!-- ReqPay: Payment Request -->
<upi:ReqPay xmlns:upi="http://npci.org/upi/schema/">
  <Head ver="2.0" ts="2024-01-15T10:30:00+05:30"
        orgId="YESB" msgId="MSG123456789"/>
  <Txn id="YBL2401150000001234"
       type="PAY"
       note="Payment for groceries"
       refId="PHN202401150001234567"
       refUrl="https://phonepe.com/txn/123"
       ts="2024-01-15T10:30:00+05:30">
    <RiskScores>
      <Score provider="PHONEPE" type="TXNRISK" value="000"/>
    </RiskScores>
  </Txn>
  <Payer addr="priya@ybl"
         name="PRIYA SHARMA"
         seqNum="1"
         type="PERSON"
         code="0000">
    <Info>
      <Identity type="ACCOUNT" verifiedName="PRIYA SHARMA"/>
    </Info>
    <Device>
      <Tag name="MOBILE" value="919876543210"/>
      <Tag name="GEOCODE" value="12.9716,77.5946"/>
      <Tag name="APP" value="com.phonepe.app"/>
      <Tag name="CAPABILITY" value="011001"/>
    </Device>
    <Ac addrType="ACCOUNT">
      <Detail name="IFSC" value="HDFC0001234"/>
      <Detail name="ACNUM" value="50100123456789"/>
    </Ac>
    <Creds>
      <Cred type="PIN" subType="MPIN">
        <Data code="NPCI" ki="20240115">encrypted_pin_block</Data>
      </Cred>
    </Creds>
    <Amount value="500.00" curr="INR"/>
  </Payer>
  <Payee addr="rahul@oksbi"
         name="RAHUL KUMAR"
         seqNum="2"
         type="PERSON"
         code="0000">
    <Ac addrType="ACCOUNT">
      <Detail name="IFSC" value="SBIN0001234"/>
      <Detail name="ACNUM" value="32145678901234"/>
    </Ac>
    <Amount value="500.00" curr="INR"/>
  </Payee>
</upi:ReqPay>

<!-- RespPay: Payment Response -->
<upi:RespPay xmlns:upi="http://npci.org/upi/schema/">
  <Head ver="2.0" ts="2024-01-15T10:30:02+05:30"
        orgId="NPCI" msgId="RSP123456789"/>
  <Txn id="YBL2401150000001234"
       type="PAY"
       orgTxnId="YBL2401150000001234"
       result="SUCCESS"
       orgRespCode="00"
       respCode="00">
    <Ref type="PAYER" seqNum="1"
         addr="priya@ybl"
         settAmount="500.00"
         settCurrency="INR"
         approvalNum="HDFC1234567"
         regName="PRIYA SHARMA"/>
    <Ref type="PAYEE" seqNum="2"
         addr="rahul@oksbi"
         settAmount="500.00"
         settCurrency="INR"
         approvalNum="SBI9876543"
         regName="RAHUL KUMAR"/>
  </Txn>
</upi:RespPay>

4.5 UPI Error Codes

CodeDescriptionAction
00SuccessTransaction successful
U16Insufficient fundsRetry not recommended
U30Debit timeoutCheck status and retry
U31Credit timeoutCheck status, may need reversal
U66Device not registeredRe-register device
U67MPIN not setSet MPIN first
U68Credential not presentReset credentials
U69Account blockedContact bank
U70Account does not existVerify account
ZMInvalid MPINRetry with correct PIN
Z9Insufficient fundsSame as U16

4.6 UPI Settlement

UPI Settlement Process:
│
├── Settlement Cycles: Multiple times daily (approximately every 2 hours)
│
├── Net Settlement:
│   All transactions between banks are netted
│   Only net positions are settled
│
├── Example:
│
│   HDFC → SBI transactions today:  Rs. 10,00,00,000
│   SBI → HDFC transactions today:  Rs.  8,00,00,000
│                                    ─────────────────
│   Net: HDFC owes SBI             Rs.  2,00,00,000
│
│   Settlement: HDFC's RBI account debited by 2 Cr
│              SBI's RBI account credited by 2 Cr
│
├── Settlement Bank: Yes Bank (designated by NPCI)
│
└── Final Settlement: Through RBI settlement account

4.7 UPI Lite

UPI Lite is a simplified version for small-value offline payments.
UPI Lite Characteristics:
│
├── Maximum transaction: Rs. 500
├── Maximum balance: Rs. 2,000
├── No PIN required for transactions
├── Works offline (stored value)
├── No bank involvement for individual transactions
│
├── How it works:
│
│   1. Customer loads UPI Lite wallet from bank account
│   2. Wallet balance stored on device
│   3. Payments made from wallet (no bank round-trip)
│   4. Periodic sync with bank for settlement
│
└── Use case: Small daily payments (tea, parking, etc.)

4.8 UPI AutoPay (Mandates)

UPI AutoPay allows recurring payments with pre-authorized mandates.
sql
-- UPI Mandate Structure
CREATE TABLE upi_mandates (
    mandate_id          VARCHAR(50) PRIMARY KEY,
    payer_vpa           VARCHAR(50) NOT NULL,
    payee_vpa           VARCHAR(50) NOT NULL,
    mandate_type        VARCHAR(20) NOT NULL,  -- RECURRING, SINGLE
    frequency           VARCHAR(20),  -- DAILY, WEEKLY, MONTHLY, YEARLY
    amount_rule         VARCHAR(20),  -- EXACT, MAX
    amount              DECIMAL(18,2) NOT NULL,
    start_date          DATE NOT NULL,
    end_date            DATE NOT NULL,
    validity_days       INTEGER,
    status              VARCHAR(20) DEFAULT 'PENDING',
    -- PENDING, APPROVED, ACTIVE, PAUSED, REVOKED, EXPIRED
    created_at          TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    approved_at         TIMESTAMP,
    last_execution      TIMESTAMP
);

-- Mandate can be:
-- amount_rule = EXACT: Debit exactly Rs. 499 on 1st of every month
-- amount_rule = MAX: Debit up to Rs. 1000 per month

4.9 UPI Production Architecture

┌─────────────────────────────────────────────────────────────────────────────┐
│                        UPI PRODUCTION ARCHITECTURE                           │
│                         (Simplified Bank-side View)                          │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                              │
│  ┌─────────────────────────────────────────────────────────────────────┐    │
│  │                        EXTERNAL CONNECTIONS                          │    │
│  │                                                                      │    │
│  │   NPCI ◀═══════════════════════════════════════▶ PSP Bank Switch    │    │
│  │   (Leased Line / VPN)                            (API Gateway)       │    │
│  │                                                                      │    │
│  └──────────────────────────────────┬──────────────────────────────────┘    │
│                                     │                                        │
│  ┌──────────────────────────────────┴──────────────────────────────────┐    │
│  │                          UPI SWITCH                                  │    │
│  │                                                                      │    │
│  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐ │    │
│  │  │   Message   │  │   Message   │  │    VPA      │  │  Transaction│ │    │
│  │  │   Receiver  │──│   Router    │──│  Resolver   │──│   Manager   │ │    │
│  │  └─────────────┘  └─────────────┘  └─────────────┘  └─────────────┘ │    │
│  │                                                                      │    │
│  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐ │    │
│  │  │  Duplicate  │  │   Crypto    │  │   Fraud     │  │   Limit     │ │    │
│  │  │  Detection  │  │   Module    │  │   Engine    │  │   Manager   │ │    │
│  │  └─────────────┘  └─────────────┘  └─────────────┘  └─────────────┘ │    │
│  │                                                                      │    │
│  └──────────────────────────────────┬──────────────────────────────────┘    │
│                                     │                                        │
│  ┌──────────────────────────────────┴──────────────────────────────────┐    │
│  │                       DATA STORES                                    │    │
│  │                                                                      │    │
│  │   ┌─────────────────┐   ┌─────────────────┐   ┌─────────────────┐   │    │
│  │   │   VPA Registry  │   │  Transaction DB │   │   Mandate DB    │   │    │
│  │   │   (Redis/Cache) │   │   (PostgreSQL)  │   │   (PostgreSQL)  │   │    │
│  │   └─────────────────┘   └─────────────────┘   └─────────────────┘   │    │
│  │                                                                      │    │
│  │   ┌─────────────────┐   ┌─────────────────┐                         │    │
│  │   │   Audit Log     │   │   Settlement    │                         │    │
│  │   │   (Append-only) │   │   (PostgreSQL)  │                         │    │
│  │   └─────────────────┘   └─────────────────┘                         │    │
│  │                                                                      │    │
│  └──────────────────────────────────┬──────────────────────────────────┘    │
│                                     │                                        │
│  ┌──────────────────────────────────┴──────────────────────────────────┐    │
│  │                     CORE BANKING INTEGRATION                         │    │
│  │                                                                      │    │
│  │   ┌─────────────┐     ┌─────────────┐     ┌─────────────┐          │    │
│  │   │   Account   │◀───▶│   Balance   │◀───▶│   Debit/    │          │    │
│  │   │   Lookup    │     │   Enquiry   │     │   Credit    │          │    │
│  │   └─────────────┘     └─────────────┘     └─────────────┘          │    │
│  │                                                                      │    │
│  └─────────────────────────────────────────────────────────────────────┘    │
│                                                                              │
└─────────────────────────────────────────────────────────────────────────────┘

Chapter 4 Interview Questions

Basic Level

  1. What is UPI? Who developed it?
  2. What is a VPA? Give examples.
  3. What is the difference between Pay and Collect?
  4. What is NPCI's role in UPI?
  5. What is a PSP? What is a TPAP?
  6. What is UPI PIN? How is it different from ATM PIN?
  7. What are UPI transaction limits?
  8. What happens when UPI transaction fails?
  9. What is UPI Lite?
  10. What is UPI AutoPay?

Intermediate Level

  1. Explain the complete UPI transaction flow.
  2. How does VPA resolution work?
  3. What is the settlement process for UPI?
  4. Explain UPI error codes and handling.
  5. How is UPI PIN encrypted and transmitted?
  6. What is the role of the issuer bank vs PSP bank?
  7. How does UPI handle duplicate transactions?
  8. Explain UPI mandate (AutoPay) flow.
  9. What security measures are in UPI?
  10. How does UPI QR code work?

Advanced Level

  1. Design a UPI-like payment system.
  2. How would you scale UPI to handle 1 billion transactions per day?
  3. Design fraud detection for UPI.
  4. How does UPI achieve sub-second latency?
  5. Design the UPI settlement engine.
  6. How would you implement UPI Lite?
  7. Design disaster recovery for UPI infrastructure.
  8. How do you ensure exactly-once processing in UPI?
  9. Design the VPA registry for 500 million VPAs.
  10. How would you implement cross-border UPI?

Chapter 5: IMPS - Immediate Payment Service

5.1 What is IMPS?

IMPS (Immediate Payment Service) is a real-time interbank electronic fund transfer system launched by NPCI in November 2010. It was India's first 24x7x365 instant payment system, predating UPI by six years.
While UPI has largely overshadowed IMPS for retail payments, IMPS remains critical infrastructure because:
  • UPI uses IMPS rails for the actual fund transfer
  • IMPS supports higher transaction limits (up to ₹5 lakhs vs ₹1 lakh for UPI)
  • IMPS works without smartphone apps via USSD and SMS
  • Many corporate and B2B payments still use IMPS directly

5.2 IMPS Architecture

┌─────────────────────────────────────────────────────────────────────┐
│                        IMPS ARCHITECTURE                             │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│   ┌─────────────┐                              ┌─────────────┐      │
│   │   Sender    │                              │  Receiver   │      │
│   │   Customer  │                              │  Customer   │      │
│   └──────┬──────┘                              └──────▲──────┘      │
│          │                                            │              │
│          ▼                                            │              │
│   ┌─────────────┐                              ┌─────────────┐      │
│   │   Sender    │                              │  Receiver   │      │
│   │   Bank      │                              │   Bank      │      │
│   │   (Remitter)│                              │(Beneficiary)│      │
│   └──────┬──────┘                              └──────▲──────┘      │
│          │                                            │              │
│          │         ┌─────────────────────┐           │              │
│          └────────▶│        NPCI         │───────────┘              │
│                    │   IMPS SWITCH       │                          │
│                    │                     │                          │
│                    │  • Message Routing  │                          │
│                    │  • Validation       │                          │
│                    │  • Settlement       │                          │
│                    └─────────────────────┘                          │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

5.3 IMPS Identifiers

IMPS supports multiple ways to identify the beneficiary:

MMID (Mobile Money Identifier)

MMID: 7-digit number issued by bank
Format: First 4 digits = Bank identifier, Last 3 digits = Unique number

Example: 9876543
- 9876 = HDFC Bank identifier
- 543 = Customer's unique number within HDFC

Registration: Customer links mobile number with bank account
Result: Bank issues MMID for that mobile + account combination

Account Number + IFSC

Account Number: Bank account number
IFSC: Indian Financial System Code (11 characters)

Example:
Account: 50100123456789
IFSC: HDFC0001234

IFSC Format: AAAA0BBBBBB
- AAAA = Bank code (4 letters)
- 0 = Reserved (always 0)
- BBBBBB = Branch code (6 characters)

Aadhaar Number

Aadhaar: 12-digit unique identity number
Requires: Aadhaar linked to bank account via NPCI mapper

Example: 1234-5678-9012

5.4 IMPS Transaction Flow

┌─────────────────────────────────────────────────────────────────────┐
│                    IMPS TRANSACTION FLOW                             │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  SENDER                NPCI                    BENEFICIARY          │
│  BANK                  IMPS                    BANK                 │
│    │                    │                         │                  │
│    │  1. Transfer       │                         │                  │
│    │     Request        │                         │                  │
│    │───────────────────▶│                         │                  │
│    │                    │                         │                  │
│    │                    │  2. Route to            │                  │
│    │                    │     Beneficiary Bank    │                  │
│    │                    │────────────────────────▶│                  │
│    │                    │                         │                  │
│    │                    │                         │  3. Credit       │
│    │                    │                         │     Account      │
│    │                    │                         │     ───────      │
│    │                    │                         │                  │
│    │                    │  4. Credit              │                  │
│    │                    │     Confirmation        │                  │
│    │                    │◀────────────────────────│                  │
│    │                    │                         │                  │
│    │  5. Debit Account  │                         │                  │
│    │     + Response     │                         │                  │
│    │◀───────────────────│                         │                  │
│    │                    │                         │                  │
│    │  ═══════════════════════════════════════════│                  │
│    │           SETTLEMENT (via RBI)              │                  │
│    │  ═══════════════════════════════════════════│                  │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

5.5 IMPS Message Format

xml
<!-- IMPS Transfer Request -->
<IMPS>
  <Header>
    <MsgId>HDFC20240115123456789012</MsgId>
    <OrgId>HDFC</OrgId>
    <CreDtTm>2024-01-15T14:30:00</CreDtTm>
    <MsgType>TRANSFER_REQ</MsgType>
  </Header>
  <Transaction>
    <TxnId>HDFC240115143000123456</TxnId>
    <TxnType>P2P</TxnType>
    <Amount>10000.00</Amount>
    <Currency>INR</Currency>
  </Transaction>
  <Remitter>
    <AccountNo>50100123456789</AccountNo>
    <IFSC>HDFC0001234</IFSC>
    <Name>RAHUL SHARMA</Name>
    <Mobile>9876543210</Mobile>
  </Remitter>
  <Beneficiary>
    <AccountNo>026291800001234</AccountNo>
    <IFSC>YESB0000262</IFSC>
    <Name>PRIYA PATEL</Name>
    <Mobile>9876543211</Mobile>
  </Beneficiary>
  <Purpose>
    <Code>00</Code>
    <Narration>Gift transfer</Narration>
  </Purpose>
</IMPS>

5.6 IMPS Response Codes

sql
-- IMPS Response Code Reference
CREATE TABLE imps_response_codes (
    response_code   VARCHAR(3) PRIMARY KEY,
    description     VARCHAR(200),
    category        VARCHAR(50),
    action          VARCHAR(100)
);

INSERT INTO imps_response_codes VALUES
('00', 'Transaction successful', 'SUCCESS', 'None'),
('01', 'Request in progress', 'PENDING', 'Wait and retry'),
('02', 'Invalid beneficiary', 'FAILURE', 'Verify account details'),
('03', 'Invalid MMID', 'FAILURE', 'Verify MMID'),
('04', 'Invalid mobile number', 'FAILURE', 'Verify mobile'),
('05', 'Account blocked/frozen', 'FAILURE', 'Contact bank'),
('06', 'Insufficient funds', 'FAILURE', 'Check balance'),
('07', 'Transaction limit exceeded', 'FAILURE', 'Reduce amount'),
('08', 'Invalid IFSC', 'FAILURE', 'Verify IFSC code'),
('09', 'Beneficiary bank unavailable', 'FAILURE', 'Retry later'),
('10', 'Transaction timeout', 'PENDING', 'Check status'),
('11', 'Duplicate transaction', 'FAILURE', 'Transaction already processed'),
('12', 'Invalid account number', 'FAILURE', 'Verify account number'),
('91', 'Beneficiary bank not reachable', 'FAILURE', 'Retry later'),
('92', 'Invalid transaction', 'FAILURE', 'Contact support'),
('96', 'System error', 'FAILURE', 'Retry later');

5.7 IMPS Settlement

IMPS uses deferred net settlement through NPCI:
┌─────────────────────────────────────────────────────────────────────┐
│                    IMPS SETTLEMENT CYCLE                             │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  Settlement Windows (Multiple per day):                             │
│                                                                      │
│  Window 1: 00:00 - 08:00  → Settlement at 08:30                    │
│  Window 2: 08:00 - 11:00  → Settlement at 11:30                    │
│  Window 3: 11:00 - 14:00  → Settlement at 14:30                    │
│  Window 4: 14:00 - 17:00  → Settlement at 17:30                    │
│  Window 5: 17:00 - 20:00  → Settlement at 20:30                    │
│  Window 6: 20:00 - 00:00  → Settlement at 08:30 (next day)         │
│                                                                      │
│  Settlement Process:                                                 │
│  1. NPCI calculates net positions for each bank                     │
│  2. Net debit banks fund their settlement account                   │
│  3. NPCI initiates multilateral netting via RBI                     │
│  4. RBI debits/credits bank settlement accounts                     │
│  5. Settlement confirmation sent to all banks                       │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘
sql
-- IMPS Settlement Position Calculation
CREATE TABLE imps_settlement_position (
    settlement_id       VARCHAR(30) PRIMARY KEY,
    settlement_window   INTEGER NOT NULL,
    settlement_date     DATE NOT NULL,
    bank_code           VARCHAR(10) NOT NULL,
    total_outward       DECIMAL(18,2) DEFAULT 0,
    total_inward        DECIMAL(18,2) DEFAULT 0,
    net_position        DECIMAL(18,2) GENERATED ALWAYS AS
                        (total_inward - total_outward) STORED,
    transaction_count   INTEGER DEFAULT 0,
    status              VARCHAR(20) DEFAULT 'PENDING',
    settled_at          TIMESTAMP
);

-- Example: Calculate net positions
SELECT
    bank_code,
    SUM(CASE WHEN direction = 'OUTWARD' THEN amount ELSE 0 END) as total_outward,
    SUM(CASE WHEN direction = 'INWARD' THEN amount ELSE 0 END) as total_inward,
    SUM(CASE WHEN direction = 'INWARD' THEN amount ELSE -amount END) as net_position
FROM imps_transactions
WHERE settlement_window = 3
  AND settlement_date = '2024-01-15'
  AND status = 'SUCCESS'
GROUP BY bank_code;

5.8 IMPS vs UPI Comparison

FeatureIMPSUPI
Launch Year20102016
Transaction Limit₹5,00,000₹1,00,000
IdentifierAccount+IFSC, MMID, AadhaarVPA
ChannelNet Banking, Mobile, USSDApp only
Collect RequestNoYes
QR SupportLimitedFull
Merchant PaymentsLimitedExtensive
API AccessBank APIsPSP APIs
InternationalNoExpanding

5.9 IMPS Database Schema

sql
-- Core IMPS Transaction Table
CREATE TABLE imps_transactions (
    txn_id              VARCHAR(35) PRIMARY KEY,
    rrn                 VARCHAR(12) NOT NULL UNIQUE,
    npci_txn_id         VARCHAR(35),

    -- Amount
    amount              DECIMAL(18,2) NOT NULL,
    currency            CHAR(3) DEFAULT 'INR',

    -- Remitter (Sender)
    remitter_account    VARCHAR(20) NOT NULL,
    remitter_ifsc       VARCHAR(11) NOT NULL,
    remitter_name       VARCHAR(100),
    remitter_mobile     VARCHAR(15),
    remitter_bank_code  VARCHAR(10) NOT NULL,

    -- Beneficiary (Receiver)
    beneficiary_account VARCHAR(20),
    beneficiary_ifsc    VARCHAR(11),
    beneficiary_mmid    VARCHAR(7),
    beneficiary_mobile  VARCHAR(15),
    beneficiary_aadhaar VARCHAR(12),
    beneficiary_name    VARCHAR(100),
    beneficiary_bank    VARCHAR(10) NOT NULL,

    -- Identifier Type
    identifier_type     VARCHAR(20) NOT NULL,
    -- ACCOUNT_IFSC, MMID_MOBILE, AADHAAR

    -- Transaction Details
    purpose_code        VARCHAR(4),
    narration           VARCHAR(100),

    -- Status
    status              VARCHAR(20) NOT NULL DEFAULT 'INITIATED',
    response_code       VARCHAR(3),
    response_message    VARCHAR(200),

    -- Timestamps
    initiated_at        TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    completed_at        TIMESTAMP,

    -- Settlement
    settlement_window   INTEGER,
    settlement_date     DATE,
    settlement_status   VARCHAR(20),

    -- Indexes
    INDEX idx_rrn (rrn),
    INDEX idx_remitter (remitter_account, remitter_bank_code),
    INDEX idx_beneficiary (beneficiary_account, beneficiary_bank),
    INDEX idx_settlement (settlement_date, settlement_window)
);

Chapter 5 Interview Questions

Basic Level

  1. What is IMPS? When was it launched?
  2. What is MMID? How is it generated?
  3. What are the different ways to send money via IMPS?
  4. What is the transaction limit for IMPS?
  5. Is IMPS available 24x7?
  6. What is the difference between IMPS and NEFT?
  7. What is an IFSC code? What does each part mean?
  8. Can IMPS transactions be reversed?
  9. What happens if beneficiary account is wrong?
  10. What are IMPS charges?

Intermediate Level

  1. Explain the complete IMPS transaction flow.
  2. How does IMPS settlement work?
  3. What is the relationship between UPI and IMPS?
  4. How does IMPS handle transaction failures?
  5. Explain IMPS response codes.
  6. How is IMPS different from RTGS?
  7. What security measures does IMPS use?
  8. How does Aadhaar-based IMPS work?
  9. What is NPCI's role in IMPS?
  10. How does IMPS handle duplicate transactions?

Advanced Level

  1. Design an IMPS-like instant payment system.
  2. How would you handle IMPS settlement failures?
  3. Design fraud detection for IMPS.
  4. How does IMPS achieve sub-second latency?
  5. Design the MMID registry for 500 million users.
  6. How would you implement IMPS timeout handling?
  7. Design disaster recovery for IMPS.
  8. How do you ensure exactly-once processing?
  9. Design IMPS reconciliation system.
  10. How would you scale IMPS to 100 million transactions/day?

Chapter 6: NEFT - National Electronic Funds Transfer

6.1 What is NEFT?

NEFT (National Electronic Funds Transfer) is an electronic funds transfer system maintained by the Reserve Bank of India. Launched in November 2005, NEFT was India's first nationwide electronic fund transfer system and remains one of the most widely used payment rails for high-value transactions.
Key characteristics:
  • Operates 24x7x365 (since December 2019)
  • Batch-based processing (half-hourly batches)
  • No minimum or maximum transaction limit
  • Deferred net settlement
  • Push-only (no collect requests)

6.2 NEFT vs RTGS vs IMPS

FeatureNEFTRTGSIMPS
SettlementDeferred NetReal-time GrossDeferred Net
Timing24x7 (half-hourly batches)24x7 (instant)24x7 (instant)
Min Amount₹1₹2,00,000₹1
Max AmountNo limitNo limit₹5,00,000
Speed30 mins - 2 hoursImmediateImmediate
Operated byRBIRBINPCI
Primary UseRegular transfersHigh-value/urgentInstant retail

6.3 NEFT Architecture

┌─────────────────────────────────────────────────────────────────────┐
│                        NEFT ARCHITECTURE                             │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  ┌────────────┐    ┌────────────┐    ┌────────────┐               │
│  │  Sender    │    │  Sender    │    │  RBI NEFT  │               │
│  │  Customer  │───▶│   Bank     │───▶│  Clearing  │               │
│  └────────────┘    │  (Sending  │    │   House    │               │
│                    │   Member)  │    └─────┬──────┘               │
│                    └────────────┘          │                       │
│                                            │                       │
│                                    ┌───────┴───────┐               │
│                                    │   SFMS/INFINET│               │
│                                    │   Network     │               │
│                                    └───────┬───────┘               │
│                                            │                       │
│  ┌────────────┐    ┌────────────┐         │                       │
│  │  Receiver  │◀───│  Receiver  │◀────────┘                       │
│  │  Customer  │    │   Bank     │                                  │
│  └────────────┘    │ (Receiving │                                  │
│                    │   Member)  │                                  │
│                    └────────────┘                                  │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

6.4 NEFT Batch Processing

NEFT processes transactions in half-hourly batches:
┌─────────────────────────────────────────────────────────────────────┐
│                    NEFT BATCH SCHEDULE (24x7)                        │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  Batch 1:  00:00 - 00:30  →  Settlement at 00:30                   │
│  Batch 2:  00:30 - 01:00  →  Settlement at 01:00                   │
│  Batch 3:  01:00 - 01:30  →  Settlement at 01:30                   │
│  ...                                                                 │
│  Batch 48: 23:30 - 00:00  →  Settlement at 00:00 (next day)        │
│                                                                      │
│  Total: 48 batches per day                                          │
│                                                                      │
│  Cut-off times for each batch:                                       │
│  - Sending bank: 10 minutes before batch time                       │
│  - Message validation: 5 minutes before batch time                   │
│  - Settlement: At batch time                                        │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

6.5 NEFT Transaction Flow

┌─────────────────────────────────────────────────────────────────────┐
│                    NEFT TRANSACTION FLOW                             │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  Step 1: Initiation                                                 │
│  ─────────────────                                                   │
│  Customer initiates transfer via net banking/branch                  │
│  Sender bank debits customer account immediately                     │
│  Transaction queued for next NEFT batch                              │
│                                                                      │
│  Step 2: Message Creation                                            │
│  ────────────────────────                                            │
│  Bank creates NEFT message (ISO 8583 format)                         │
│  Message includes: sender, receiver, amount, purpose                 │
│  Message sent to NEFT clearing center (SFMS)                         │
│                                                                      │
│  Step 3: Batch Processing                                            │
│  ────────────────────────                                            │
│  RBI NEFT system collects messages for current batch                 │
│  Messages validated and sorted by destination bank                   │
│  Net positions calculated for all participating banks                │
│                                                                      │
│  Step 4: Settlement                                                  │
│  ────────────────                                                    │
│  Net debit banks' accounts debited at RBI                           │
│  Net credit banks' accounts credited at RBI                         │
│  Settlement confirmation sent to all banks                           │
│                                                                      │
│  Step 5: Credit to Beneficiary                                       │
│  ─────────────────────────────                                       │
│  Receiving bank gets credit advice                                   │
│  Bank credits beneficiary account                                    │
│  Confirmation sent to beneficiary                                    │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

6.6 NEFT Message Format (ISO 8583)

┌─────────────────────────────────────────────────────────────────────┐
│                    NEFT MESSAGE STRUCTURE                            │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  Field   Description                    Example                     │
│  ─────   ───────────                    ───────                     │
│  MTI     Message Type Indicator         1100 (Auth Request)         │
│  DE2     Primary Account Number         50100123456789              │
│  DE3     Processing Code                400000                      │
│  DE4     Transaction Amount             000000010000 (₹100.00)      │
│  DE7     Transmission DateTime          0115143000                  │
│  DE11    System Trace Audit Number      123456                      │
│  DE12    Local Transaction Time         143000                      │
│  DE13    Local Transaction Date         0115                        │
│  DE32    Acquiring Institution ID       HDFC                        │
│  DE37    Retrieval Reference Number     401512345678                │
│  DE41    Card Acceptor Terminal ID      NETBANK01                   │
│  DE42    Card Acceptor ID               HDFC0001234                 │
│  DE43    Card Acceptor Name/Location    HDFC BANK MUMBAI            │
│  DE49    Currency Code                  356 (INR)                   │
│  DE100   Receiving Institution ID       ICIC                        │
│  DE102   Account ID 1 (Sender)          50100123456789              │
│  DE103   Account ID 2 (Receiver)        026291800001234             │
│  DE123   Additional Data (IFSC)         ICIC0001234                 │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

6.7 NEFT Return Codes

sql
-- NEFT Return/Rejection Codes
CREATE TABLE neft_return_codes (
    return_code     VARCHAR(4) PRIMARY KEY,
    description     VARCHAR(200),
    action          VARCHAR(100)
);

INSERT INTO neft_return_codes VALUES
('0000', 'Transaction successful', 'None'),
('R01', 'Account closed', 'Return to sender'),
('R02', 'Account blocked/frozen', 'Return to sender'),
('R03', 'No such account', 'Return to sender'),
('R04', 'Account dormant', 'Contact beneficiary'),
('R05', 'Invalid IFSC', 'Verify IFSC'),
('R06', 'NRI account - NEFT not allowed', 'Use other channel'),
('R07', 'Beneficiary name mismatch', 'Verify details'),
('R08', 'Account under litigation', 'Return to sender'),
('R09', 'Credit not allowed in account', 'Contact bank'),
('R10', 'Duplicate transaction', 'Already processed'),
('R11', 'Format error in message', 'Resubmit correctly'),
('R12', 'Invalid currency', 'Only INR allowed'),
('R99', 'Other reason', 'Check with bank');

6.8 NEFT Settlement Process

sql
-- NEFT Settlement Position Calculation
CREATE TABLE neft_settlement (
    settlement_id       VARCHAR(30) PRIMARY KEY,
    batch_number        INTEGER NOT NULL,
    settlement_date     DATE NOT NULL,
    bank_ifsc           VARCHAR(11) NOT NULL,

    -- Outward (Debits - money going out)
    outward_count       INTEGER DEFAULT 0,
    outward_amount      DECIMAL(18,2) DEFAULT 0,

    -- Inward (Credits - money coming in)
    inward_count        INTEGER DEFAULT 0,
    inward_amount       DECIMAL(18,2) DEFAULT 0,

    -- Net Position
    net_position        DECIMAL(18,2) GENERATED ALWAYS AS
                        (inward_amount - outward_amount) STORED,

    -- Settlement Status
    status              VARCHAR(20) DEFAULT 'PENDING',
    settled_at          TIMESTAMP,

    UNIQUE (batch_number, settlement_date, bank_ifsc)
);

-- Example: Batch settlement calculation
/*
Bank A sends: ₹1,00,000 (to Bank B: ₹60,000, to Bank C: ₹40,000)
Bank B sends: ₹80,000 (to Bank A: ₹50,000, to Bank C: ₹30,000)
Bank C sends: ₹50,000 (to Bank A: ₹30,000, to Bank B: ₹20,000)

Net Positions:
Bank A: Receives (50,000+30,000) - Sends (100,000) = -20,000 (Net Payer)
Bank B: Receives (60,000+20,000) - Sends (80,000) = 0 (Square)
Bank C: Receives (40,000+30,000) - Sends (50,000) = +20,000 (Net Receiver)

Settlement: RBI debits Bank A ₹20,000, credits Bank C ₹20,000
*/

6.9 NEFT Database Schema

sql
-- Core NEFT Transaction Table
CREATE TABLE neft_transactions (
    txn_id              VARCHAR(35) PRIMARY KEY,
    utr_number          VARCHAR(22) NOT NULL UNIQUE,

    -- Amount
    amount              DECIMAL(18,2) NOT NULL,
    currency            CHAR(3) DEFAULT 'INR',

    -- Sender Details
    sender_account      VARCHAR(20) NOT NULL,
    sender_ifsc         VARCHAR(11) NOT NULL,
    sender_name         VARCHAR(100) NOT NULL,
    sender_bank_name    VARCHAR(100),

    -- Receiver Details
    receiver_account    VARCHAR(20) NOT NULL,
    receiver_ifsc       VARCHAR(11) NOT NULL,
    receiver_name       VARCHAR(100) NOT NULL,
    receiver_bank_name  VARCHAR(100),

    -- Transaction Details
    purpose_code        VARCHAR(4),
    narration           VARCHAR(100),

    -- Batch Information
    batch_number        INTEGER,
    batch_date          DATE,

    -- Status
    status              VARCHAR(20) NOT NULL DEFAULT 'INITIATED',
    return_code         VARCHAR(4),
    return_reason       VARCHAR(200),

    -- Timestamps
    initiated_at        TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    submitted_at        TIMESTAMP,
    settled_at          TIMESTAMP,
    credited_at         TIMESTAMP,

    INDEX idx_utr (utr_number),
    INDEX idx_batch (batch_date, batch_number),
    INDEX idx_status (status)
);

Chapter 6 Interview Questions

Basic Level

  1. What is NEFT? When was it launched?
  2. What are NEFT timings?
  3. Is there a minimum/maximum limit for NEFT?
  4. How long does a NEFT transfer take?
  5. What is UTR number?

Intermediate Level

  1. Explain NEFT batch processing.
  2. How does NEFT settlement work?
  3. What is deferred net settlement?
  4. Explain NEFT message format.
  5. How are NEFT returns handled?

Advanced Level

  1. Design a NEFT-like batch payment system.
  2. How would you optimize NEFT batch processing?
  3. Design NEFT reconciliation system.
  4. How does multilateral netting work?
  5. How would you implement NEFT 24x7?

Chapter 7: RTGS - Real Time Gross Settlement

7.1 What is RTGS?

RTGS (Real Time Gross Settlement) is a funds transfer system where money moves between banks in real-time on a gross (transaction-by-transaction) basis. Operated by the Reserve Bank of India since March 2004, RTGS is the backbone for high-value interbank transfers in India.
Key characteristics:
  • Real-time: Settlement happens immediately
  • Gross: Each transaction settled individually (not netted)
  • High-value: Minimum ₹2,00,000 per transaction
  • Irrevocable: Once settled, cannot be reversed
  • Available 24x7x365 (since December 2020)

7.2 Why Gross Settlement Matters

┌─────────────────────────────────────────────────────────────────────┐
│            NET SETTLEMENT vs GROSS SETTLEMENT                        │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  NET SETTLEMENT (NEFT):                                             │
│  ───────────────────────                                             │
│  Bank A → Bank B: ₹50 lakh                                          │
│  Bank B → Bank A: ₹30 lakh                                          │
│  Net: Bank A pays Bank B ₹20 lakh (settled at batch time)           │
│                                                                      │
│  Risk: If Bank A fails before batch, Bank B loses ₹50 lakh          │
│                                                                      │
│  GROSS SETTLEMENT (RTGS):                                            │
│  ────────────────────────                                            │
│  Bank A → Bank B: ₹50 lakh (settled immediately)                    │
│  Bank B → Bank A: ₹30 lakh (settled immediately)                    │
│  Each transaction final when processed                               │
│                                                                      │
│  Risk: None - settlement is immediate and irrevocable               │
│                                                                      │
│  Trade-off: RTGS requires more liquidity (no netting benefit)       │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

7.3 RTGS Architecture

┌─────────────────────────────────────────────────────────────────────┐
│                        RTGS ARCHITECTURE                             │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  ┌────────────────────────────────────────────────────────────────┐ │
│  │                    RBI RTGS SYSTEM                              │ │
│  │                                                                  │ │
│  │  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐         │ │
│  │  │   Message    │  │   Queue      │  │  Settlement  │         │ │
│  │  │   Handler    │──│   Manager    │──│   Engine     │         │ │
│  │  └──────────────┘  └──────────────┘  └──────────────┘         │ │
│  │                                              │                  │ │
│  │  ┌──────────────┐  ┌──────────────┐         │                  │ │
│  │  │   Liquidity  │  │   Account    │◀────────┘                  │ │
│  │  │   Manager    │──│   Manager    │                            │ │
│  │  └──────────────┘  └──────────────┘                            │ │
│  │                                                                  │ │
│  └────────────────────────────────────────────────────────────────┘ │
│                            │                                         │
│             ┌──────────────┼──────────────┐                         │
│             │              │              │                         │
│             ▼              ▼              ▼                         │
│  ┌──────────────┐ ┌──────────────┐ ┌──────────────┐                │
│  │   Bank A     │ │   Bank B     │ │   Bank C     │                │
│  │   RTGS       │ │   RTGS       │ │   RTGS       │                │
│  │   Interface  │ │   Interface  │ │   Interface  │                │
│  └──────────────┘ └──────────────┘ └──────────────┘                │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

7.4 RTGS Settlement Account

Every RTGS member bank maintains a settlement account with RBI:
sql
-- RBI Settlement Account for RTGS
CREATE TABLE rtgs_settlement_accounts (
    account_id          VARCHAR(20) PRIMARY KEY,
    bank_code           VARCHAR(10) NOT NULL UNIQUE,
    bank_name           VARCHAR(100) NOT NULL,

    -- Balance
    available_balance   DECIMAL(18,2) NOT NULL DEFAULT 0,
    blocked_balance     DECIMAL(18,2) NOT NULL DEFAULT 0,
    total_balance       DECIMAL(18,2) GENERATED ALWAYS AS
                        (available_balance + blocked_balance) STORED,

    -- Limits
    intraday_limit      DECIMAL(18,2),  -- Borrowing limit from RBI
    utilized_limit      DECIMAL(18,2) DEFAULT 0,

    -- Status
    status              VARCHAR(20) DEFAULT 'ACTIVE',
    last_transaction_at TIMESTAMP,

    CONSTRAINT chk_balance CHECK (available_balance >= 0)
);

-- Start of day: Banks transfer funds from their current account
-- to settlement account based on expected RTGS volume

7.5 RTGS Transaction Flow

┌─────────────────────────────────────────────────────────────────────┐
│                    RTGS TRANSACTION FLOW                             │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  SENDING           RBI RTGS              RECEIVING                   │
│  BANK              SYSTEM                BANK                        │
│    │                  │                      │                       │
│    │ 1. Submit        │                      │                       │
│    │    Payment       │                      │                       │
│    │─────────────────▶│                      │                       │
│    │                  │                      │                       │
│    │                  │ 2. Validate          │                       │
│    │                  │    Message           │                       │
│    │                  │    ────────          │                       │
│    │                  │                      │                       │
│    │                  │ 3. Check Sender      │                       │
│    │                  │    Balance           │                       │
│    │                  │    ────────          │                       │
│    │                  │                      │                       │
│    │                  │ 4. Debit Sender      │                       │
│    │                  │    Credit Receiver   │                       │
│    │                  │    (ATOMIC)          │                       │
│    │                  │    ────────          │                       │
│    │                  │                      │                       │
│    │ 5. Debit         │ 6. Credit            │                       │
│    │    Confirmation  │    Advice            │                       │
│    │◀─────────────────│─────────────────────▶│                       │
│    │                  │                      │                       │
│    │                  │               7. Credit Customer              │
│    │                  │                      │────────               │
│    │                  │                      │                       │
│                                                                      │
│  Total Time: < 30 seconds (typically < 10 seconds)                  │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

7.6 RTGS Queuing Mechanism

When sender has insufficient balance, transaction enters queue:
sql
-- RTGS Transaction Queue
CREATE TABLE rtgs_queue (
    queue_id            VARCHAR(35) PRIMARY KEY,
    transaction_id      VARCHAR(35) NOT NULL,
    sender_bank         VARCHAR(10) NOT NULL,
    receiver_bank       VARCHAR(10) NOT NULL,
    amount              DECIMAL(18,2) NOT NULL,

    -- Priority (P1 = Highest, P5 = Lowest)
    priority            VARCHAR(2) NOT NULL DEFAULT 'P3',

    -- Queue entry time
    queued_at           TIMESTAMP DEFAULT CURRENT_TIMESTAMP,

    -- Status
    status              VARCHAR(20) DEFAULT 'QUEUED',
    -- QUEUED, PROCESSING, SETTLED, CANCELLED, EXPIRED

    -- Resolution
    resolved_at         TIMESTAMP,
    resolution_type     VARCHAR(20),
    -- SETTLED, CANCELLED_BY_BANK, EXPIRED, REJECTED

    INDEX idx_sender_priority (sender_bank, priority, queued_at),
    INDEX idx_status (status)
);

-- Queue processing order:
-- 1. Higher priority first (P1 before P2)
-- 2. Within same priority, FIFO (earlier queued_at first)
-- 3. Transactions expire at end of day if not settled

7.7 RTGS Liquidity Management

┌─────────────────────────────────────────────────────────────────────┐
│                    RTGS LIQUIDITY MANAGEMENT                         │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  INTRADAY LIQUIDITY (IDL):                                          │
│  ─────────────────────────                                           │
│  - Banks can borrow from RBI during the day                         │
│  - Collateralized by government securities                          │
│  - Must be repaid by end of day                                     │
│  - Interest-free if repaid same day                                 │
│                                                                      │
│  LIQUIDITY OPTIMIZATION:                                             │
│  ───────────────────────                                             │
│                                                                      │
│  Gridlock Resolution:                                                │
│  ┌─────┐ owes ₹100cr ┌─────┐ owes ₹100cr ┌─────┐                   │
│  │Bank │────────────▶│Bank │────────────▶│Bank │                   │
│  │  A  │             │  B  │             │  C  │                   │
│  └─────┘             └─────┘             └─────┘                   │
│     ▲                                        │                       │
│     │         owes ₹100cr                    │                       │
│     └────────────────────────────────────────┘                       │
│                                                                      │
│  Without gridlock resolution: All 3 transactions stuck              │
│  With gridlock resolution: System detects cycle, settles all at     │
│                            once with zero net liquidity needed      │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

7.8 RTGS Message Format (ISO 20022)

RTGS uses ISO 20022 XML message format:
xml
<?xml version="1.0" encoding="UTF-8"?>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.008.001.08">
  <FIToFICstmrCdtTrf>
    <GrpHdr>
      <MsgId>HDFC20240115143000001</MsgId>
      <CreDtTm>2024-01-15T14:30:00</CreDtTm>
      <NbOfTxs>1</NbOfTxs>
      <SttlmInf>
        <SttlmMtd>CLRG</SttlmMtd>
      </SttlmInf>
    </GrpHdr>
    <CdtTrfTxInf>
      <PmtId>
        <InstrId>HDFC240115143000001</InstrId>
        <EndToEndId>CUST-REF-123456</EndToEndId>
        <TxId>HDFC2401151430000001</TxId>
      </PmtId>
      <PmtTpInf>
        <SvcLvl>
          <Cd>RTGS</Cd>
        </SvcLvl>
      </PmtTpInf>
      <IntrBkSttlmAmt Ccy="INR">500000.00</IntrBkSttlmAmt>
      <ChrgBr>SHAR</ChrgBr>
      <Dbtr>
        <Nm>RAHUL SHARMA</Nm>
      </Dbtr>
      <DbtrAcct>
        <Id>
          <Othr>
            <Id>50100123456789</Id>
          </Othr>
        </Id>
      </DbtrAcct>
      <DbtrAgt>
        <FinInstnId>
          <BICFI>HDFCINBB</BICFI>
          <ClrSysMmbId>
            <MmbId>HDFC0001234</MmbId>
          </ClrSysMmbId>
        </FinInstnId>
      </DbtrAgt>
      <CdtrAgt>
        <FinInstnId>
          <BICFI>ABORINBB</BICFI>
          <ClrSysMmbId>
            <MmbId>ABOR0001234</MmbId>
          </ClrSysMmbId>
        </FinInstnId>
      </CdtrAgt>
      <Cdtr>
        <Nm>PRIYA PATEL</Nm>
      </Cdtr>
      <CdtrAcct>
        <Id>
          <Othr>
            <Id>026291800001234</Id>
          </Othr>
        </Id>
      </CdtrAcct>
      <RmtInf>
        <Ustrd>Property Payment</Ustrd>
      </RmtInf>
    </CdtTrfTxInf>
  </FIToFICstmrCdtTrf>
</Document>

7.9 RTGS Database Schema

sql
-- Core RTGS Transaction Table
CREATE TABLE rtgs_transactions (
    txn_id              VARCHAR(35) PRIMARY KEY,
    utr_number          VARCHAR(22) NOT NULL UNIQUE,
    message_id          VARCHAR(35) NOT NULL,

    -- Amount
    amount              DECIMAL(18,2) NOT NULL,
    currency            CHAR(3) DEFAULT 'INR',

    -- Sender
    sender_account      VARCHAR(20) NOT NULL,
    sender_ifsc         VARCHAR(11) NOT NULL,
    sender_name         VARCHAR(140),
    sender_bank_bic     VARCHAR(11) NOT NULL,

    -- Receiver
    receiver_account    VARCHAR(20) NOT NULL,
    receiver_ifsc       VARCHAR(11) NOT NULL,
    receiver_name       VARCHAR(140),
    receiver_bank_bic   VARCHAR(11) NOT NULL,

    -- Priority
    priority            VARCHAR(2) DEFAULT 'P3',

    -- Status
    status              VARCHAR(20) NOT NULL DEFAULT 'INITIATED',
    -- INITIATED, SUBMITTED, QUEUED, SETTLED, CREDITED, REJECTED

    -- Timestamps
    initiated_at        TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    submitted_at        TIMESTAMP,
    settled_at          TIMESTAMP,
    credited_at         TIMESTAMP,

    -- Settlement details
    settlement_ref      VARCHAR(35),

    INDEX idx_utr (utr_number),
    INDEX idx_status (status),
    INDEX idx_settlement (settled_at)
);

Chapter 7 Interview Questions

Basic Level

  1. What is RTGS? What does "gross settlement" mean?
  2. What is the minimum amount for RTGS?
  3. What is RTGS timing?
  4. What is the difference between RTGS and NEFT?
  5. Is RTGS reversible?

Intermediate Level

  1. Explain RTGS transaction flow.
  2. What happens if sender has insufficient balance?
  3. What is Intraday Liquidity (IDL)?
  4. Explain RTGS queue management.
  5. What is gridlock resolution?

Advanced Level

  1. Design an RTGS-like gross settlement system.
  2. How would you handle settlement account failures?
  3. Design liquidity optimization for RTGS.
  4. How does RTGS achieve sub-second settlement?
  5. Design disaster recovery for RTGS.

Chapter 8: Card Payments

8.1 Card Payment Ecosystem

Card payments involve multiple parties working together:
┌─────────────────────────────────────────────────────────────────────┐
│                    CARD PAYMENT ECOSYSTEM                            │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  ┌──────────────┐                          ┌──────────────┐         │
│  │  CARDHOLDER  │                          │   MERCHANT   │         │
│  │  (Customer)  │                          │              │         │
│  └──────┬───────┘                          └──────┬───────┘         │
│         │                                         │                  │
│         │                                         │                  │
│  ┌──────▼───────┐                          ┌──────▼───────┐         │
│  │    ISSUER    │                          │   ACQUIRER   │         │
│  │    BANK      │                          │    BANK      │         │
│  │              │                          │              │         │
│  │ Issues card  │                          │ Provides POS │         │
│  │ to customer  │                          │ to merchant  │         │
│  └──────┬───────┘                          └──────┬───────┘         │
│         │                                         │                  │
│         │         ┌──────────────────┐           │                  │
│         └────────▶│   CARD NETWORK   │◀──────────┘                  │
│                   │                  │                               │
│                   │  • Visa          │                               │
│                   │  • Mastercard    │                               │
│                   │  • RuPay         │                               │
│                   │  • Amex          │                               │
│                   └──────────────────┘                               │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘
Key Players:
  • Cardholder: Customer who owns the card
  • Issuer Bank: Bank that issued the card to customer
  • Merchant: Business accepting card payments
  • Acquirer Bank: Bank that provides POS/payment gateway to merchant
  • Card Network: Visa, Mastercard, RuPay - routes transactions between banks

8.2 Card Types

┌─────────────────────────────────────────────────────────────────────┐
│                         CARD TYPES                                   │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  DEBIT CARD                                                         │
│  ──────────                                                          │
│  • Linked to bank account                                           │
│  • Money debited immediately from account                           │
│  • Limited to account balance                                       │
│  • Lower fraud risk for bank                                        │
│                                                                      │
│  CREDIT CARD                                                        │
│  ───────────                                                         │
│  • Credit line provided by bank                                     │
│  • Payment due at end of billing cycle                              │
│  • Interest charged on outstanding balance                          │
│  • Higher fraud risk for bank                                       │
│                                                                      │
│  PREPAID CARD                                                       │
│  ────────────                                                        │
│  • Pre-loaded with fixed amount                                     │
│  • Not linked to bank account                                       │
│  • Gift cards, forex cards, meal cards                              │
│  • Stored value product                                             │
│                                                                      │
│  CORPORATE CARD                                                      │
│  ──────────────                                                      │
│  • Issued to employees for business expenses                        │
│  • Company liable for payments                                      │
│  • Enhanced reporting and controls                                  │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

8.3 Card Number Structure (PAN)

┌─────────────────────────────────────────────────────────────────────┐
│           PRIMARY ACCOUNT NUMBER (PAN) STRUCTURE                     │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  Card Number: 4 1 2 3  5 6 7 8  9 0 1 2  3 4 5 6                   │
│               ─ ─────  ────────────────  ─────  ─                   │
│               │   │           │            │    │                   │
│               │   │           │            │    └─ Check Digit      │
│               │   │           │            │       (Luhn Algorithm) │
│               │   │           │            │                        │
│               │   │           │            └─ Account Number        │
│               │   │           │               (Bank assigned)       │
│               │   │           │                                     │
│               │   │           └─ Issuer Identification              │
│               │   │              (Bank identifier)                  │
│               │   │                                                 │
│               │   └─ Bank Identification Number (BIN)               │
│               │      (First 6-8 digits)                             │
│               │                                                     │
│               └─ Major Industry Identifier (MII)                    │
│                  1, 2 = Airlines                                    │
│                  3 = Travel/Entertainment (Amex)                    │
│                  4 = Visa                                           │
│                  5 = Mastercard                                     │
│                  6 = RuPay/Discover                                 │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

-- Luhn Algorithm (Check Digit Validation)
-- From rightmost digit (check digit), double every second digit
-- If doubling results in > 9, subtract 9
-- Sum all digits; valid if sum mod 10 = 0

Example: 4123 5678 9012 3456
Step 1: 4 2 2 6 5 12 7 16 9 0 1 4 3 8 5 12
Step 2: 4 2 2 6 5 3  7 7  9 0 1 4 3 8 5 3
Step 3: Sum = 69, 69 mod 10 ≠ 0, Invalid card

8.4 Card Transaction Flow

┌─────────────────────────────────────────────────────────────────────┐
│               CARD TRANSACTION FLOW (POS/Online)                     │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  1. AUTHORIZATION (Real-time)                                       │
│  ────────────────────────────                                        │
│                                                                      │
│  Customer ──▶ Merchant ──▶ Acquirer ──▶ Network ──▶ Issuer          │
│  (Swipe/Tap)    (POS)       Bank                     Bank           │
│                                                                      │
│              ◀── Auth Response (Approve/Decline) ◀──                │
│                                                                      │
│  Time: 1-3 seconds                                                  │
│  Result: Amount blocked on customer's card (not yet debited)        │
│                                                                      │
│  2. CLEARING (Batch - End of Day)                                   │
│  ────────────────────────────────                                    │
│                                                                      │
│  Merchant ──▶ Acquirer ──▶ Network                                  │
│  (Batch file)   Bank      (Clearing file)                           │
│                                                                      │
│  Network sorts transactions by issuer and sends clearing files      │
│                                                                      │
│  3. SETTLEMENT (T+1 or T+2)                                         │
│  ──────────────────────────                                          │
│                                                                      │
│  Issuer Bank ──▶ Network ──▶ Acquirer Bank ──▶ Merchant             │
│  (Debit customer) (Net settlement)  (Credit)    (Credit)            │
│                                                                      │
│  Fees Distribution:                                                  │
│  • Interchange Fee: Issuer Bank (1.5-2%)                            │
│  • Network Fee: Visa/MC/RuPay (0.1%)                                │
│  • MDR: Acquirer Bank (from merchant) (1.5-2.5%)                    │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

8.5 ISO 8583 Message Format

Card transactions use ISO 8583 message format:
┌─────────────────────────────────────────────────────────────────────┐
│                    ISO 8583 MESSAGE STRUCTURE                        │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  ┌─────────────┬─────────────┬──────────────────────────────────┐  │
│  │ MTI (4)     │ Bitmap (8)  │ Data Elements (Variable)         │  │
│  └─────────────┴─────────────┴──────────────────────────────────┘  │
│                                                                      │
│  MTI - Message Type Indicator:                                      │
│  • 0100 - Authorization Request                                     │
│  • 0110 - Authorization Response                                    │
│  • 0200 - Financial Request (Purchase)                              │
│  • 0210 - Financial Response                                        │
│  • 0400 - Reversal Request                                          │
│  • 0410 - Reversal Response                                         │
│  • 0420 - Reversal Advice                                           │
│  • 0430 - Reversal Advice Response                                  │
│                                                                      │
│  Key Data Elements:                                                  │
│  DE2  - Primary Account Number (PAN)                                │
│  DE3  - Processing Code (Purchase/Cash/Refund)                      │
│  DE4  - Transaction Amount                                          │
│  DE7  - Transmission Date/Time                                      │
│  DE11 - System Trace Audit Number (STAN)                            │
│  DE12 - Local Transaction Time                                      │
│  DE13 - Local Transaction Date                                      │
│  DE14 - Card Expiration Date                                        │
│  DE22 - POS Entry Mode (Swipe/Chip/Contactless)                     │
│  DE23 - Card Sequence Number                                        │
│  DE25 - POS Condition Code                                          │
│  DE35 - Track 2 Data                                                │
│  DE37 - Retrieval Reference Number (RRN)                            │
│  DE38 - Authorization Code                                          │
│  DE39 - Response Code                                               │
│  DE41 - Terminal ID                                                 │
│  DE42 - Merchant ID                                                 │
│  DE43 - Merchant Name/Location                                      │
│  DE49 - Currency Code                                               │
│  DE52 - PIN Block (Encrypted)                                       │
│  DE55 - EMV Chip Data                                               │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

8.6 Card Transaction Response Codes

sql
-- ISO 8583 Response Codes (DE39)
CREATE TABLE card_response_codes (
    response_code   VARCHAR(2) PRIMARY KEY,
    description     VARCHAR(100),
    action          VARCHAR(100)
);

INSERT INTO card_response_codes VALUES
('00', 'Approved', 'Transaction successful'),
('01', 'Refer to card issuer', 'Call bank'),
('03', 'Invalid merchant', 'Check merchant setup'),
('04', 'Pick up card', 'Card reported lost/stolen'),
('05', 'Do not honor', 'Generic decline'),
('12', 'Invalid transaction', 'Check transaction type'),
('13', 'Invalid amount', 'Check amount'),
('14', 'Invalid card number', 'Check PAN'),
('30', 'Format error', 'Check message format'),
('41', 'Lost card', 'Card reported lost'),
('43', 'Stolen card', 'Card reported stolen'),
('51', 'Insufficient funds', 'Check balance'),
('54', 'Expired card', 'Card validity expired'),
('55', 'Incorrect PIN', 'Wrong PIN entered'),
('57', 'Transaction not allowed', 'Card restriction'),
('58', 'Transaction not permitted to terminal', 'Terminal restriction'),
('61', 'Exceeds withdrawal limit', 'Daily limit exceeded'),
('62', 'Restricted card', 'Card blocked'),
('65', 'Exceeds withdrawal frequency', 'Too many transactions'),
('75', 'PIN tries exceeded', 'Card blocked'),
('91', 'Issuer unavailable', 'Retry later'),
('96', 'System malfunction', 'Retry later');

8.7 EMV Chip Technology

┌─────────────────────────────────────────────────────────────────────┐
│                    EMV CHIP TECHNOLOGY                               │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  EMV = Europay, Mastercard, Visa                                    │
│                                                                      │
│  WHY EMV?                                                           │
│  • Magnetic stripe can be cloned (skimming)                         │
│  • EMV chip generates unique code for each transaction              │
│  • Even if intercepted, code cannot be reused                       │
│                                                                      │
│  EMV TRANSACTION FLOW:                                              │
│                                                                      │
│  1. Card Inserted → Terminal reads chip                             │
│  2. Terminal sends transaction data to chip                         │
│  3. Chip generates Application Cryptogram (AC)                      │
│     using secret key stored in chip                                 │
│  4. Cryptogram sent to issuer                                       │
│  5. Issuer validates cryptogram with HSM                            │
│  6. Transaction approved/declined                                   │
│                                                                      │
│  CRYPTOGRAM TYPES:                                                  │
│  • ARQC (Authorization Request Cryptogram) - Online auth requested  │
│  • TC (Transaction Certificate) - Approved offline                  │
│  • AAC (Application Authentication Cryptogram) - Declined offline   │
│                                                                      │
│  CVV TYPES:                                                         │
│  • CVV1 - Encoded in magnetic stripe                                │
│  • CVV2 - Printed on card (for CNP transactions)                    │
│  • iCVV - Dynamic, generated by chip for each transaction           │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

8.8 3D Secure (Online Card Payments)

┌─────────────────────────────────────────────────────────────────────┐
│                    3D SECURE AUTHENTICATION                          │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  3D Secure adds authentication layer for online (CNP) transactions  │
│                                                                      │
│  Brand Names:                                                       │
│  • Visa: Verified by Visa (VbV)                                     │
│  • Mastercard: Mastercard SecureCode / Identity Check               │
│  • RuPay: RuPay PaySecure                                           │
│                                                                      │
│  3DS 2.0 FLOW:                                                      │
│                                                                      │
│  Customer ──▶ Merchant ──▶ Payment Gateway ──▶ 3DS Server          │
│  (Checkout)                                                         │
│                                                                      │
│  3DS Server ──▶ Directory Server ──▶ Issuer ACS                    │
│                 (Visa/MC/RuPay)       (Access Control Server)       │
│                                                                      │
│  ACS Decision:                                                      │
│  • Frictionless: Low risk, approve without OTP                      │
│  • Challenge: OTP/biometric required                                │
│                                                                      │
│  Challenge Flow:                                                     │
│  ACS ──▶ Customer ──▶ OTP Entry ──▶ ACS Validation ──▶ Response    │
│                                                                      │
│  LIABILITY SHIFT:                                                   │
│  • Without 3DS: Merchant liable for fraud                           │
│  • With 3DS: Issuer liable for fraud (after authentication)        │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

8.9 Card Database Schema

sql
-- Card Master Table
CREATE TABLE cards (
    card_id             VARCHAR(30) PRIMARY KEY,
    card_number_hash    VARCHAR(64) NOT NULL,  -- SHA-256 hash
    card_token          VARCHAR(30) NOT NULL,  -- Network token
    last_four_digits    CHAR(4) NOT NULL,

    -- Card details
    card_type           VARCHAR(20) NOT NULL,  -- DEBIT, CREDIT, PREPAID
    card_network        VARCHAR(20) NOT NULL,  -- VISA, MC, RUPAY
    card_variant        VARCHAR(20),  -- CLASSIC, GOLD, PLATINUM

    -- Linked account (for debit cards)
    account_id          VARCHAR(20),

    -- Credit details (for credit cards)
    credit_limit        DECIMAL(18,2),
    available_limit     DECIMAL(18,2),
    billing_cycle_day   INTEGER,

    -- Validity
    expiry_month        INTEGER NOT NULL,
    expiry_year         INTEGER NOT NULL,

    -- Status
    status              VARCHAR(20) DEFAULT 'ACTIVE',
    -- ACTIVE, BLOCKED, EXPIRED, CANCELLED

    -- Customer
    customer_id         VARCHAR(20) NOT NULL,

    INDEX idx_token (card_token),
    INDEX idx_customer (customer_id)
);

-- Card Transaction Table
CREATE TABLE card_transactions (
    txn_id              VARCHAR(35) PRIMARY KEY,
    rrn                 VARCHAR(12) NOT NULL,
    auth_code           VARCHAR(6),

    -- Card
    card_id             VARCHAR(30) NOT NULL,
    card_token          VARCHAR(30) NOT NULL,

    -- Amount
    amount              DECIMAL(18,2) NOT NULL,
    currency            CHAR(3) DEFAULT 'INR',
    billing_amount      DECIMAL(18,2),
    billing_currency    CHAR(3),

    -- Merchant
    merchant_id         VARCHAR(15) NOT NULL,
    merchant_name       VARCHAR(100),
    merchant_category   VARCHAR(4),  -- MCC code
    terminal_id         VARCHAR(8),

    -- Transaction details
    txn_type            VARCHAR(20) NOT NULL,
    -- PURCHASE, CASH_WITHDRAWAL, REFUND, REVERSAL
    entry_mode          VARCHAR(20),
    -- CHIP, CONTACTLESS, SWIPE, ECOMMERCE

    -- 3D Secure
    is_3ds              BOOLEAN DEFAULT FALSE,
    eci_indicator       VARCHAR(2),

    -- Status
    status              VARCHAR(20) NOT NULL,
    -- AUTHORIZED, CAPTURED, SETTLED, DECLINED, REVERSED
    response_code       VARCHAR(2),

    -- Timestamps
    auth_at             TIMESTAMP,
    captured_at         TIMESTAMP,
    settled_at          TIMESTAMP,

    INDEX idx_card (card_id),
    INDEX idx_rrn (rrn),
    INDEX idx_merchant (merchant_id)
);

8.10 RuPay - India's Card Network

┌─────────────────────────────────────────────────────────────────────┐
│                         RUPAY NETWORK                                │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  RuPay is India's indigenous card network operated by NPCI          │
│  Launched: March 2012                                               │
│                                                                      │
│  ADVANTAGES:                                                        │
│  • Lower transaction costs (no foreign exchange fees to Visa/MC)    │
│  • Data stays within India                                          │
│  • Linked with Jan Dhan accounts                                    │
│  • Integrated with UPI (RuPay on UPI)                               │
│                                                                      │
│  RUPAY CARD VARIANTS:                                               │
│  • RuPay Classic - Basic debit card                                 │
│  • RuPay Platinum - Premium features                                │
│  • RuPay Select - Super premium (airport lounges)                   │
│  • RuPay Credit - Credit cards                                      │
│  • NCMC (National Common Mobility Card) - Transit payments         │
│                                                                      │
│  MARKET SHARE (2024):                                               │
│  • ~60% of all debit cards issued in India                          │
│  • Growing credit card presence                                     │
│  • International acceptance growing                                 │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

Chapter 8 Interview Questions

Basic Level

  1. What are the different card types?
  2. What is the difference between issuer and acquirer?
  3. What is PAN? How is check digit calculated?
  4. What is CVV? What are different types?
  5. What is EMV?

Intermediate Level

  1. Explain the card transaction flow.
  2. What is authorization vs settlement?
  3. Explain ISO 8583 message format.
  4. What is 3D Secure? How does it work?
  5. What is interchange fee?

Advanced Level

  1. Design a card payment gateway.
  2. How would you implement fraud detection for cards?
  3. Design card tokenization system.
  4. How does EMV prevent card cloning?
  5. Design a card settlement system.

Chapter 9: NACH - National Automated Clearing House

9.1 What is NACH?

NACH (National Automated Clearing House) is a centralized clearing service for bulk/repetitive electronic transactions. Operated by NPCI, NACH consolidates multiple regional ECS (Electronic Clearing Service) systems into one national system.
┌─────────────────────────────────────────────────────────────────────┐
│                         NACH OVERVIEW                                │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  USE CASES:                                                         │
│                                                                      │
│  NACH DEBIT (Pull Payments):                                        │
│  • EMI collections (loans, mortgages)                               │
│  • Insurance premium collection                                      │
│  • Mutual fund SIP debits                                           │
│  • Utility bill payments                                            │
│  • Subscription payments                                            │
│                                                                      │
│  NACH CREDIT (Push Payments):                                       │
│  • Salary disbursement                                              │
│  • Dividend payments                                                │
│  • Interest payments                                                │
│  • Government subsidies (DBT - Direct Benefit Transfer)             │
│  • Pension payments                                                 │
│                                                                      │
│  VOLUME: ~10 crore transactions per day                             │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

9.2 NACH Architecture

┌─────────────────────────────────────────────────────────────────────┐
│                      NACH ARCHITECTURE                               │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  ┌──────────────┐    ┌──────────────┐    ┌──────────────┐          │
│  │   SPONSOR    │    │    NPCI      │    │ DESTINATION  │          │
│  │    BANK      │───▶│    NACH      │───▶│    BANK      │          │
│  │              │    │   SYSTEM     │    │              │          │
│  └──────────────┘    └──────────────┘    └──────────────┘          │
│        ▲                                        │                   │
│        │                                        │                   │
│        │                                        ▼                   │
│  ┌──────────────┐                        ┌──────────────┐          │
│  │   CORPORATE  │                        │   CUSTOMER   │          │
│  │  (Originator)│                        │ (Destination)│          │
│  └──────────────┘                        └──────────────┘          │
│                                                                      │
│  SPONSOR BANK: Bank through which corporate submits NACH files     │
│  DESTINATION BANK: Bank where customer's account is held           │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

9.3 NACH Mandate

Before any NACH debit, customer must provide a mandate:
sql
-- NACH Mandate Table
CREATE TABLE nach_mandates (
    mandate_id          VARCHAR(30) PRIMARY KEY,
    umrn                VARCHAR(20) NOT NULL UNIQUE,
    -- UMRN = Unique Mandate Reference Number

    -- Customer Details
    customer_name       VARCHAR(100) NOT NULL,
    customer_account    VARCHAR(20) NOT NULL,
    customer_ifsc       VARCHAR(11) NOT NULL,
    customer_bank       VARCHAR(100),

    -- Corporate Details
    corporate_name      VARCHAR(100) NOT NULL,
    corporate_code      VARCHAR(20) NOT NULL,
    sponsor_bank_code   VARCHAR(11) NOT NULL,

    -- Mandate Details
    mandate_type        VARCHAR(10) NOT NULL,  -- DEBIT, CREDIT
    frequency           VARCHAR(20) NOT NULL,
    -- ADHOC, DAILY, WEEKLY, FORTNIGHTLY, MONTHLY, QUARTERLY, YEARLY

    amount_type         VARCHAR(10) NOT NULL,  -- FIXED, MAXIMUM
    amount              DECIMAL(18,2) NOT NULL,

    -- Validity
    start_date          DATE NOT NULL,
    end_date            DATE,
    until_cancelled     BOOLEAN DEFAULT FALSE,

    -- Status
    status              VARCHAR(20) DEFAULT 'PENDING',
    -- PENDING, APPROVED, ACTIVE, SUSPENDED, CANCELLED, EXPIRED

    -- Timestamps
    created_at          TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    approved_at         TIMESTAMP,
    last_debit_date     DATE,

    INDEX idx_umrn (umrn),
    INDEX idx_customer (customer_account, customer_ifsc),
    INDEX idx_corporate (corporate_code)
);

9.4 NACH Transaction Flow

┌─────────────────────────────────────────────────────────────────────┐
│                    NACH DEBIT FLOW                                   │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  Day T-2: File Submission                                           │
│  ────────────────────────                                            │
│  1. Corporate prepares debit file with customer list                │
│  2. File submitted to Sponsor Bank                                  │
│  3. Sponsor Bank validates and uploads to NPCI                      │
│                                                                      │
│  Day T-1: Processing                                                │
│  ───────────────────                                                 │
│  4. NPCI validates all transactions                                 │
│  5. Transactions sorted by destination bank                         │
│  6. Files sent to destination banks                                 │
│                                                                      │
│  Day T: Settlement                                                  │
│  ────────────────                                                    │
│  7. Destination banks process debits                                │
│  8. Success/failure response sent to NPCI                           │
│  9. NPCI calculates net positions                                   │
│  10. Settlement via RBI                                             │
│                                                                      │
│  Day T+1: Credit                                                    │
│  ───────────────                                                     │
│  11. Successful amount credited to corporate account                │
│  12. Return file sent for failed transactions                       │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

9.5 NACH File Format

┌─────────────────────────────────────────────────────────────────────┐
│                    NACH FILE FORMAT                                  │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  Header Record (Record Type: 01)                                    │
│  ─────────────────────────────────                                   │
│  Field              Position   Length   Description                 │
│  Record Type        1-2        2        "01"                        │
│  File Reference     3-15       13       Unique file ID              │
│  Sponsor Bank Code  16-26      11       IFSC of sponsor bank        │
│  User Name          27-66      40       Corporate name              │
│  User Number        67-84      18       Corporate ID                │
│  Transaction Count  85-93      9        Number of records           │
│  Total Amount       94-110     17       Sum of all transactions     │
│  Settlement Date    111-118    8        DDMMYYYY                    │
│  Settlement Cycle   119-120    2        01-04                       │
│                                                                      │
│  Detail Record (Record Type: 56)                                    │
│  ─────────────────────────────────                                   │
│  Record Type        1-2        2        "56"                        │
│  UMRN               3-22       20       Mandate reference           │
│  Dest Account       23-42      20       Customer account            │
│  Dest Bank IFSC     43-53      11       Customer bank IFSC          │
│  Amount             54-70      17       Transaction amount          │
│  Reference 1        71-88      18       Corporate reference         │
│  Reference 2        89-106     18       Additional reference        │
│  Account Name       107-146    40       Customer name               │
│                                                                      │
│  Trailer Record (Record Type: 99)                                   │
│  ──────────────────────────────────                                  │
│  Record Type        1-2        2        "99"                        │
│  Hash Total         3-19       17       Sum of account numbers      │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

9.6 NACH Return Codes

sql
-- NACH Return Reason Codes
CREATE TABLE nach_return_codes (
    return_code     VARCHAR(2) PRIMARY KEY,
    description     VARCHAR(100),
    category        VARCHAR(20)
);

INSERT INTO nach_return_codes VALUES
('00', 'Successful', 'SUCCESS'),
('01', 'Insufficient funds', 'FAILURE'),
('02', 'Account closed', 'FAILURE'),
('03', 'No such account', 'FAILURE'),
('04', 'Account blocked', 'FAILURE'),
('05', 'NRI account', 'FAILURE'),
('06', 'Mandate not found', 'FAILURE'),
('07', 'Mandate cancelled', 'FAILURE'),
('08', 'Mandate expired', 'FAILURE'),
('09', 'Amount exceeds mandate limit', 'FAILURE'),
('10', 'Frequency mismatch', 'FAILURE'),
('11', 'Invalid account number', 'FAILURE'),
('12', 'Invalid IFSC', 'FAILURE'),
('68', 'Customer deceased', 'FAILURE'),
('69', 'Account under dispute', 'FAILURE'),
('96', 'System error', 'FAILURE');

9.7 e-NACH (Electronic Mandate)

┌─────────────────────────────────────────────────────────────────────┐
│                    e-NACH (Electronic Mandate)                       │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  Traditional NACH: Paper mandate → Physical signature → Slow        │
│  e-NACH: Digital mandate → Aadhaar OTP/Net banking → Instant        │
│                                                                      │
│  e-NACH REGISTRATION FLOW:                                          │
│                                                                      │
│  1. Customer initiates mandate on corporate website                 │
│  2. Redirected to NPCI e-mandate page                               │
│  3. Customer selects authentication method:                          │
│     • Aadhaar OTP                                                   │
│     • Net Banking                                                   │
│     • Debit Card                                                    │
│  4. Authentication completed                                        │
│  5. Mandate registered instantly                                    │
│  6. UMRN generated and shared with corporate                        │
│                                                                      │
│  BENEFITS:                                                          │
│  • Instant registration (vs 15-30 days for physical)                │
│  • No paper handling                                                │
│  • Lower operational cost                                           │
│  • Better customer experience                                       │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

9.8 NACH Database Schema

sql
-- NACH Transaction Table
CREATE TABLE nach_transactions (
    txn_id              VARCHAR(35) PRIMARY KEY,
    file_reference      VARCHAR(13) NOT NULL,
    record_number       INTEGER NOT NULL,

    -- Mandate
    umrn                VARCHAR(20) NOT NULL,
    mandate_id          VARCHAR(30),

    -- Transaction Type
    txn_type            VARCHAR(10) NOT NULL,  -- DEBIT, CREDIT

    -- Amount
    amount              DECIMAL(18,2) NOT NULL,

    -- Corporate (Sponsor)
    corporate_code      VARCHAR(20) NOT NULL,
    corporate_name      VARCHAR(100),
    sponsor_bank_ifsc   VARCHAR(11) NOT NULL,

    -- Customer (Destination)
    customer_account    VARCHAR(20) NOT NULL,
    customer_ifsc       VARCHAR(11) NOT NULL,
    customer_name       VARCHAR(100),

    -- References
    corporate_ref_1     VARCHAR(18),
    corporate_ref_2     VARCHAR(18),

    -- Processing
    settlement_date     DATE NOT NULL,
    settlement_cycle    VARCHAR(2),

    -- Status
    status              VARCHAR(20) NOT NULL DEFAULT 'SUBMITTED',
    -- SUBMITTED, PROCESSING, SUCCESS, RETURNED, REJECTED
    return_code         VARCHAR(2),
    return_reason       VARCHAR(100),

    -- Timestamps
    submitted_at        TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    processed_at        TIMESTAMP,
    settled_at          TIMESTAMP,

    INDEX idx_umrn (umrn),
    INDEX idx_file (file_reference),
    INDEX idx_settlement (settlement_date),
    INDEX idx_corporate (corporate_code)
);

9.9 APBS - Aadhaar Payment Bridge System

APBS is a variant of NACH for government benefit transfers:
┌─────────────────────────────────────────────────────────────────────┐
│                    APBS (Aadhaar Payment Bridge)                     │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  PURPOSE: Direct Benefit Transfer (DBT) using Aadhaar               │
│                                                                      │
│  Government ──▶ Sponsor Bank ──▶ NPCI ──▶ NPCI Mapper ──▶ Bank     │
│  Department                              (Aadhaar→Account)          │
│                                                                      │
│  NPCI MAPPER:                                                       │
│  • Database linking Aadhaar to bank account                         │
│  • Customer can link Aadhaar to any one bank account                │
│  • IIN (Issuer Identification Number) identifies the bank          │
│                                                                      │
│  USE CASES:                                                         │
│  • MGNREGA wage payments                                            │
│  • PM-KISAN farmer benefits                                         │
│  • LPG subsidy                                                      │
│  • Pension payments                                                 │
│  • Scholarship disbursement                                         │
│                                                                      │
│  VOLUME: ~30 crore transactions per month                           │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

Chapter 9 Interview Questions

Basic Level

  1. What is NACH? What is it used for?
  2. What is the difference between NACH Debit and NACH Credit?
  3. What is a mandate? What is UMRN?
  4. What is e-NACH?
  5. What is APBS?

Intermediate Level

  1. Explain NACH transaction flow.
  2. How does mandate registration work?
  3. Explain NACH file format.
  4. How are NACH returns handled?
  5. What is settlement cycle in NACH?

Advanced Level

  1. Design a recurring payment system like NACH.
  2. How would you handle NACH reconciliation?
  3. Design e-NACH mandate system.
  4. How does APBS achieve Aadhaar-to-account mapping?
  5. Design a system to handle 10 million NACH transactions daily.

Chapter 10: International Remittances

10.1 Cross-Border Payment Landscape

┌─────────────────────────────────────────────────────────────────────┐
│               INTERNATIONAL REMITTANCE CHANNELS                      │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  INWARD REMITTANCES (Money coming INTO India):                      │
│  • NRI sending money to family in India                             │
│  • Export payments received by Indian companies                     │
│  • Foreign investment (FDI, FPI)                                    │
│  Volume: ~$100 billion/year (India is #1 remittance receiver)      │
│                                                                      │
│  OUTWARD REMITTANCES (Money going OUT of India):                    │
│  • Imports payment by Indian companies                              │
│  • LRS (Liberalized Remittance Scheme) - $250,000/year limit       │
│  • Education, travel, medical expenses abroad                       │
│  • Foreign investment by Indians                                    │
│                                                                      │
│  KEY REGULATIONS:                                                   │
│  • FEMA (Foreign Exchange Management Act)                           │
│  • RBI Master Directions on Remittances                             │
│  • Purpose codes for each transaction type                          │
│  • KYC requirements                                                 │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

10.2 SWIFT - The Global Messaging Network

┌─────────────────────────────────────────────────────────────────────┐
│                    SWIFT NETWORK                                     │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  SWIFT = Society for Worldwide Interbank Financial Telecommunication│
│  • Headquartered in Belgium                                         │
│  • 11,000+ financial institutions in 200+ countries                 │
│  • ~40 million messages per day                                     │
│                                                                      │
│  SWIFT CODE (BIC - Bank Identifier Code):                           │
│  ┌─────────────────────────────────────────┐                        │
│  │  H D F C I N B B M U M                  │                        │
│  │  ──── ── ── ───                         │                        │
│  │   │   │  │   │                          │                        │
│  │   │   │  │   └── Branch Code (Optional) │                        │
│  │   │   │  └────── Location Code          │                        │
│  │   │   └───────── Country Code (IN=India)│                        │
│  │   └───────────── Bank Code              │                        │
│  └─────────────────────────────────────────┘                        │
│                                                                      │
│  IMPORTANT: SWIFT does NOT move money.                              │
│  SWIFT only sends MESSAGES between banks.                           │
│  Actual money movement happens through correspondent banking.       │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

10.3 Correspondent Banking

┌─────────────────────────────────────────────────────────────────────┐
│                  CORRESPONDENT BANKING                               │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  Problem: Not all banks have accounts with each other               │
│  Solution: Use intermediary banks (correspondents)                  │
│                                                                      │
│  NOSTRO / VOSTRO ACCOUNTS:                                          │
│  ─────────────────────────                                           │
│  Nostro = "Our account with them" (in foreign currency)             │
│  Vostro = "Their account with us" (in local currency)               │
│                                                                      │
│  Example: HDFC Bank wants to send USD to a US bank                  │
│                                                                      │
│  HDFC Bank                        Chase Bank (US)                   │
│  ──────────                       ───────────────                    │
│  Maintains USD account     ◀───▶  This is HDFC's NOSTRO account    │
│  (Nostro) at Chase                (Chase calls it VOSTRO)           │
│                                                                      │
│  PAYMENT FLOW:                                                      │
│  ─────────────                                                       │
│  1. Indian customer wants to send $1000 to US beneficiary           │
│  2. Customer's bank (HDFC) debits INR equivalent from customer      │
│  3. HDFC sends SWIFT message to its correspondent (Chase)           │
│  4. Chase debits HDFC's nostro account by $1000                     │
│  5. Chase credits beneficiary's bank (or further correspondent)     │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

10.4 SWIFT Message Types

┌─────────────────────────────────────────────────────────────────────┐
│                    SWIFT MESSAGE TYPES (MT)                          │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  CATEGORY 1xx - Customer Payments                                   │
│  MT103 - Single Customer Credit Transfer                            │
│  MT103+ - Straight Through Processing variant                       │
│                                                                      │
│  CATEGORY 2xx - Financial Institution Transfers                     │
│  MT202 - General Financial Institution Transfer                     │
│  MT202COV - Cover Payment (with underlying customer payment info)   │
│                                                                      │
│  CATEGORY 9xx - Cash Management                                     │
│  MT900 - Confirmation of Debit                                      │
│  MT910 - Confirmation of Credit                                     │
│  MT940 - Customer Statement Message                                 │
│  MT950 - Statement Message                                          │
│                                                                      │
│  CATEGORY nxx - Others                                               │
│  MT199 - Free Format Message                                        │
│  MT299 - Free Format Message (Bank to Bank)                         │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

10.5 MT103 Message Format

┌─────────────────────────────────────────────────────────────────────┐
│                    MT103 MESSAGE STRUCTURE                           │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  {1:F01HABORABBAXXX0000000000}                    -- Basic Header   │
│  {2:I103CHABORAXXXXN}                             -- App Header     │
│  {3:{108:MT103}}                                  -- User Header    │
│  {4:                                              -- Text Block     │
│  :20:TXN20240115001                               -- Transaction Ref│
│  :23B:CRED                                        -- Bank Op Code   │
│  :32A:240115USD10000,00                           -- Value Date/Amt │
│  :33B:USD10000,00                                 -- Instructed Amt │
│  :50K:/1234567890                                 -- Ordering Cust  │
│  JOHN DOE                                                           │
│  123 MAIN STREET                                                    │
│  NEW YORK USA                                                       │
│  :52A:CHABORABXXX                                 -- Ordering Inst  │
│  :53A:CITIUS33                                    -- Sender Corresp │
│  :57A:HABORABBXXX                                 -- Acct With Inst │
│  :59:/9876543210                                  -- Beneficiary    │
│  PRIYA PATEL                                                        │
│  456 MG ROAD                                                        │
│  MUMBAI INDIA                                                       │
│  :70:FAMILY SUPPORT                               -- Remit Info     │
│  :71A:OUR                                         -- Charges        │
│  :72:/ACC/HABORABBXXX                             -- S2B Info       │
│  -}                                                                  │
│  {5:{CHK:123456789ABC}}                           -- Trailer        │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

10.6 Purpose Codes for Remittances

sql
-- RBI Purpose Codes for Cross-Border Transactions
CREATE TABLE remittance_purpose_codes (
    purpose_code    VARCHAR(10) PRIMARY KEY,
    category        VARCHAR(50),
    description     VARCHAR(200)
);

INSERT INTO remittance_purpose_codes VALUES
-- Family Maintenance
('P0001', 'PERSONAL', 'Family maintenance'),
('P0002', 'PERSONAL', 'Gift'),
('P0003', 'PERSONAL', 'Donation'),

-- Education
('S0301', 'EDUCATION', 'Tuition fees'),
('S0302', 'EDUCATION', 'Living expenses'),
('S0303', 'EDUCATION', 'Examination fees'),

-- Medical
('S0304', 'MEDICAL', 'Medical treatment abroad'),

-- Travel
('S0305', 'TRAVEL', 'Business travel'),
('S0306', 'TRAVEL', 'Personal travel'),

-- Investment
('S0001', 'INVESTMENT', 'Equity investment'),
('S0002', 'INVESTMENT', 'Debt investment'),
('S0017', 'INVESTMENT', 'Real estate purchase'),

-- Trade
('P0101', 'TRADE', 'Imports - Goods'),
('P0102', 'TRADE', 'Imports - Services'),
('P0103', 'TRADE', 'Exports - Goods'),
('P0104', 'TRADE', 'Exports - Services');

10.7 Remittance Database Schema

sql
-- International Remittance Transaction Table
CREATE TABLE international_remittances (
    txn_id              VARCHAR(35) PRIMARY KEY,
    swift_ref           VARCHAR(16),
    uetr                VARCHAR(36),  -- Unique End-to-End Txn Reference

    -- Direction
    direction           VARCHAR(10) NOT NULL,  -- INWARD, OUTWARD

    -- Amount
    send_amount         DECIMAL(18,2) NOT NULL,
    send_currency       CHAR(3) NOT NULL,
    receive_amount      DECIMAL(18,2),
    receive_currency    CHAR(3),
    exchange_rate       DECIMAL(18,8),

    -- Sender
    sender_name         VARCHAR(140) NOT NULL,
    sender_address      VARCHAR(200),
    sender_country      CHAR(2),
    sender_bank_bic     VARCHAR(11),
    sender_account      VARCHAR(34),

    -- Receiver
    receiver_name       VARCHAR(140) NOT NULL,
    receiver_address    VARCHAR(200),
    receiver_country    CHAR(2),
    receiver_bank_bic   VARCHAR(11),
    receiver_account    VARCHAR(34),
    receiver_ifsc       VARCHAR(11),

    -- Purpose
    purpose_code        VARCHAR(10) NOT NULL,
    purpose_description VARCHAR(200),

    -- Correspondent chain
    sender_correspondent VARCHAR(11),
    receiver_correspondent VARCHAR(11),

    -- Status
    status              VARCHAR(20) NOT NULL DEFAULT 'INITIATED',
    -- INITIATED, SENT, IN_TRANSIT, RECEIVED, CREDITED, REJECTED

    -- Compliance
    aml_status          VARCHAR(20) DEFAULT 'PENDING',
    sanctions_status    VARCHAR(20) DEFAULT 'PENDING',

    -- Timestamps
    initiated_at        TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    sent_at             TIMESTAMP,
    received_at         TIMESTAMP,
    credited_at         TIMESTAMP,

    INDEX idx_swift_ref (swift_ref),
    INDEX idx_uetr (uetr),
    INDEX idx_sender (sender_name, sender_country),
    INDEX idx_receiver (receiver_name, receiver_country)
);

10.8 UPI International

┌─────────────────────────────────────────────────────────────────────┐
│                    UPI INTERNATIONAL                                 │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  UPI is expanding internationally through bilateral agreements:     │
│                                                                      │
│  LINKAGES ESTABLISHED:                                              │
│  • Singapore (PayNow) - Live since Feb 2023                         │
│  • UAE (IPP) - Live                                                 │
│  • Bhutan - Live                                                    │
│  • Nepal - Live                                                     │
│  • France - Live (for Indian travelers)                             │
│  • Sri Lanka - In progress                                          │
│                                                                      │
│  HOW IT WORKS (India-Singapore):                                    │
│                                                                      │
│  Indian User         NPCI           MAS           Singapore User    │
│  (UPI App)           (India)     (Singapore)      (PayNow)          │
│      │                 │             │                 │             │
│      │──Send to SG────▶│────────────▶│────────────────▶│             │
│      │                 │  Message    │   Credit SG    │             │
│      │                 │  Exchange   │   Account      │             │
│      │◀──Confirmation──│◀────────────│◀───────────────│             │
│      │                 │             │                │             │
│                                                                      │
│  Settlement: Through central banks / correspondent banking          │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

Chapter 10 Interview Questions

Basic Level

  1. What is SWIFT? What is a SWIFT code?
  2. What is the difference between nostro and vostro accounts?
  3. What is an MT103 message?
  4. What is LRS (Liberalized Remittance Scheme)?
  5. What are inward vs outward remittances?

Intermediate Level

  1. Explain correspondent banking.
  2. How does a cross-border payment flow work?
  3. What is UETR in SWIFT?
  4. Explain purpose codes for remittances.
  5. How does UPI International work?

Advanced Level

  1. Design a cross-border payment system.
  2. How would you reduce settlement time for international payments?
  3. Design AML/sanctions screening for remittances.
  4. How do you handle currency conversion in real-time?
  5. Design a multi-currency wallet system.

PART 5: System Design and Production Operations

Chapter 11: Designing Payment Systems

11.1 Key Design Principles

┌─────────────────────────────────────────────────────────────────────┐
│               PAYMENT SYSTEM DESIGN PRINCIPLES                       │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  1. IDEMPOTENCY                                                     │
│  ──────────────                                                      │
│  Every operation must be safely retryable                           │
│  Same request executed multiple times = same result                 │
│  Implementation: Use unique transaction IDs, check before process   │
│                                                                      │
│  2. EXACTLY-ONCE PROCESSING                                         │
│  ──────────────────────────                                          │
│  Each transaction must be processed exactly once                    │
│  Not zero times (lost), not twice (duplicate)                       │
│  Implementation: Idempotency keys + transaction logs                │
│                                                                      │
│  3. ATOMICITY                                                       │
│  ───────────                                                         │
│  All-or-nothing: Debit and credit must both succeed or both fail   │
│  Implementation: Database transactions, saga pattern                │
│                                                                      │
│  4. AUDITABILITY                                                    │
│  ─────────────                                                       │
│  Every state change must be logged immutably                        │
│  Who did what, when, and why                                        │
│  Implementation: Append-only audit logs, event sourcing             │
│                                                                      │
│  5. EVENTUAL CONSISTENCY                                            │
│  ───────────────────────                                             │
│  Balance may be temporarily inconsistent across systems             │
│  But must converge to correct state                                 │
│  Implementation: Reconciliation, saga compensation                  │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

11.2 Transaction State Machine

┌─────────────────────────────────────────────────────────────────────┐
│                  PAYMENT STATE MACHINE                               │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│                        ┌───────────┐                                │
│                        │ INITIATED │                                │
│                        └─────┬─────┘                                │
│                              │                                       │
│                              ▼                                       │
│                        ┌───────────┐                                │
│                ┌───────│ VALIDATED │───────┐                        │
│                │       └───────────┘       │                        │
│                │              │            │                        │
│           (Invalid)          │      (Validation Failed)            │
│                │             ▼             │                        │
│                ▼       ┌───────────┐       ▼                        │
│          ┌─────────┐   │  PENDING  │  ┌─────────┐                   │
│          │ REJECTED│   └─────┬─────┘  │ FAILED  │                   │
│          └─────────┘         │        └─────────┘                   │
│                              │                                       │
│                              ▼                                       │
│                        ┌───────────┐                                │
│                ┌───────│PROCESSING │───────┐                        │
│                │       └───────────┘       │                        │
│                │              │            │                        │
│           (Error)            │       (Timeout)                      │
│                │             ▼             │                        │
│                ▼       ┌───────────┐       ▼                        │
│          ┌─────────┐   │ COMPLETED │  ┌─────────┐                   │
│          │ FAILED  │   └───────────┘  │ PENDING │                   │
│          └─────────┘                  │ REVERSAL│                   │
│                                       └─────────┘                   │
│                                                                      │
│  RULES:                                                             │
│  • COMPLETED is terminal (immutable)                                │
│  • FAILED can be retried (new transaction)                          │
│  • PENDING_REVERSAL triggers compensation                           │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

11.3 Handling Double Spend

sql
-- Double Spend Prevention with Optimistic Locking
CREATE TABLE accounts (
    account_id      VARCHAR(20) PRIMARY KEY,
    balance         DECIMAL(18,2) NOT NULL,
    version         BIGINT NOT NULL DEFAULT 0,
    updated_at      TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- Debit with version check
UPDATE accounts
SET balance = balance - :amount,
    version = version + 1,
    updated_at = CURRENT_TIMESTAMP
WHERE account_id = :account_id
  AND balance >= :amount
  AND version = :expected_version;

-- If rows_affected = 0, either:
-- 1. Insufficient balance
-- 2. Concurrent modification (version mismatch)
-- Retry with fresh read

-- Alternative: Pessimistic Locking
SELECT * FROM accounts
WHERE account_id = :account_id
FOR UPDATE;  -- Lock row until transaction commits

UPDATE accounts
SET balance = balance - :amount
WHERE account_id = :account_id;

11.4 Distributed Transaction Patterns

┌─────────────────────────────────────────────────────────────────────┐
│                    SAGA PATTERN                                      │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  Problem: Distributed transaction across multiple services          │
│  Traditional 2PC doesn't scale well                                 │
│                                                                      │
│  SAGA: Sequence of local transactions with compensations            │
│                                                                      │
│  Example: UPI Payment                                               │
│                                                                      │
│  Step 1: Reserve funds (Payer Bank)                                 │
│        Compensation: Release hold                                   │
│                                                                      │
│  Step 2: Credit beneficiary (Payee Bank)                            │
│        Compensation: Reverse credit                                 │
│                                                                      │
│  Step 3: Confirm debit (Payer Bank)                                 │
│        Compensation: N/A (final step)                               │
│                                                                      │
│  If Step 2 fails:                                                   │
│  → Execute Step 1 compensation (release hold)                       │
│  → Mark transaction as FAILED                                       │
│                                                                      │
│  CHOREOGRAPHY vs ORCHESTRATION:                                     │
│  • Choreography: Each service knows next step (event-driven)        │
│  • Orchestration: Central coordinator manages flow                  │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

11.5 Reconciliation System Design

sql
-- Reconciliation Framework

-- 1. Transaction Log (Source of Truth)
CREATE TABLE transaction_log (
    log_id          BIGSERIAL PRIMARY KEY,
    txn_id          VARCHAR(35) NOT NULL,
    event_type      VARCHAR(30) NOT NULL,
    -- DEBIT, CREDIT, REVERSAL, ADJUSTMENT
    account_id      VARCHAR(20) NOT NULL,
    amount          DECIMAL(18,2) NOT NULL,
    balance_before  DECIMAL(18,2) NOT NULL,
    balance_after   DECIMAL(18,2) NOT NULL,
    reference       VARCHAR(50),
    created_at      TIMESTAMP DEFAULT CURRENT_TIMESTAMP,

    INDEX idx_account_date (account_id, created_at),
    INDEX idx_txn (txn_id)
);

-- 2. Daily Position
CREATE TABLE daily_positions (
    position_date   DATE NOT NULL,
    account_id      VARCHAR(20) NOT NULL,
    opening_balance DECIMAL(18,2) NOT NULL,
    total_debits    DECIMAL(18,2) NOT NULL,
    total_credits   DECIMAL(18,2) NOT NULL,
    closing_balance DECIMAL(18,2) NOT NULL,
    transaction_count INTEGER NOT NULL,
    reconciled      BOOLEAN DEFAULT FALSE,
    PRIMARY KEY (position_date, account_id)
);

-- 3. Reconciliation Check
SELECT
    dp.position_date,
    dp.account_id,
    dp.closing_balance as expected_balance,
    a.balance as actual_balance,
    dp.closing_balance - a.balance as difference
FROM daily_positions dp
JOIN accounts a ON dp.account_id = a.account_id
WHERE dp.position_date = CURRENT_DATE - 1
  AND dp.closing_balance != a.balance;

Chapter 11 Interview Questions

Basic Level

  1. What is idempotency? Why is it important?
  2. What is double spend problem?
  3. What is eventual consistency?
  4. What is a transaction state machine?
  5. What is reconciliation?

Intermediate Level

  1. How do you prevent duplicate transactions?
  2. Explain optimistic vs pessimistic locking.
  3. What is the saga pattern?
  4. How do you handle transaction timeouts?
  5. Design a reconciliation system.

Advanced Level

  1. Design a payment system handling 1M TPS.
  2. How do you achieve exactly-once semantics?
  3. Design distributed transaction coordination.
  4. How do you handle split-brain scenarios?
  5. Design a multi-region payment system.

Chapter 12: Production Operations

12.1 Monitoring and Alerting

┌─────────────────────────────────────────────────────────────────────┐
│               PAYMENT SYSTEM MONITORING                              │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  KEY METRICS (The Four Golden Signals):                             │
│                                                                      │
│  1. LATENCY                                                         │
│     • P50, P90, P99 response times                                  │
│     • Alert: P99 > 3 seconds                                        │
│                                                                      │
│  2. TRAFFIC                                                         │
│     • Transactions per second (TPS)                                 │
│     • Alert: TPS < baseline - 20% (possible outage)                 │
│     • Alert: TPS > baseline + 50% (possible attack)                 │
│                                                                      │
│  3. ERRORS                                                          │
│     • Error rate by type                                            │
│     • Alert: Error rate > 1%                                        │
│     • Alert: Any 5xx errors                                         │
│                                                                      │
│  4. SATURATION                                                      │
│     • CPU, Memory, Disk, Network utilization                        │
│     • Database connection pool usage                                │
│     • Message queue depth                                           │
│     • Alert: Any > 80%                                              │
│                                                                      │
│  BUSINESS METRICS:                                                  │
│  • Success rate by payment rail                                     │
│  • Settlement pending amount                                        │
│  • Reconciliation breaks                                            │
│  • Fraud detection rate                                             │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

12.2 Incident Response

┌─────────────────────────────────────────────────────────────────────┐
│               INCIDENT SEVERITY LEVELS                               │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  SEV-1 (Critical):                                                  │
│  • All payments failing                                             │
│  • Data breach / security incident                                  │
│  • Settlement system down                                           │
│  Response: All hands, war room, customer communication              │
│  SLA: Acknowledge in 5 mins, resolve in 1 hour                      │
│                                                                      │
│  SEV-2 (High):                                                      │
│  • Specific payment rail down                                       │
│  • >10% transactions failing                                        │
│  • Latency degradation (P99 > 10s)                                  │
│  Response: On-call + backup, stakeholder notification               │
│  SLA: Acknowledge in 15 mins, resolve in 4 hours                    │
│                                                                      │
│  SEV-3 (Medium):                                                    │
│  • Partial functionality impaired                                   │
│  • <10% transactions affected                                       │
│  • Non-critical service degraded                                    │
│  Response: On-call engineer                                         │
│  SLA: Acknowledge in 1 hour, resolve in 24 hours                    │
│                                                                      │
│  SEV-4 (Low):                                                       │
│  • Minor issues, workaround available                               │
│  • Monitoring alert (not customer-impacting)                        │
│  Response: Business hours                                           │
│  SLA: Resolve in 1 week                                             │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

12.3 Common Production Issues

┌─────────────────────────────────────────────────────────────────────┐
│               COMMON PAYMENT SYSTEM ISSUES                           │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  1. TIMEOUT HANDLING                                                │
│     Problem: Transaction timed out - debited or not?                │
│     Solution: Check transaction status before retry                 │
│               Use idempotency keys                                  │
│                                                                      │
│  2. DUPLICATE TRANSACTIONS                                          │
│     Problem: Same transaction processed twice                       │
│     Solution: Idempotency check on transaction ID                   │
│               Deduplication window (e.g., 24 hours)                 │
│                                                                      │
│  3. SETTLEMENT MISMATCH                                             │
│     Problem: Bank settlement ≠ internal records                     │
│     Solution: Daily reconciliation                                  │
│               Break resolution workflow                             │
│                                                                      │
│  4. STUCK TRANSACTIONS                                              │
│     Problem: Transactions in PENDING state too long                 │
│     Solution: Status check jobs                                     │
│               Automatic timeout and reversal                        │
│                                                                      │
│  5. BALANCE MISMATCH                                                │
│     Problem: Account balance doesn't match transaction sum          │
│     Solution: Balance audit job                                     │
│               Transaction replay capability                         │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

12.4 Disaster Recovery

┌─────────────────────────────────────────────────────────────────────┐
│               DISASTER RECOVERY STRATEGY                             │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  RPO (Recovery Point Objective): Maximum data loss tolerance        │
│  RTO (Recovery Time Objective): Maximum downtime tolerance          │
│                                                                      │
│  Payment Systems Typical Requirements:                              │
│  • RPO: 0 (no data loss)                                            │
│  • RTO: < 15 minutes                                                │
│                                                                      │
│  ARCHITECTURE:                                                      │
│  ─────────────                                                       │
│                                                                      │
│  PRIMARY DC (Mumbai)              SECONDARY DC (Chennai)             │
│  ┌─────────────────┐              ┌─────────────────┐               │
│  │  App Servers    │              │  App Servers    │               │
│  │  (Active)       │              │  (Hot Standby)  │               │
│  └────────┬────────┘              └────────┬────────┘               │
│           │                                │                        │
│  ┌────────▼────────┐              ┌────────▼────────┐               │
│  │  Database       │──Sync Repl──▶│  Database       │               │
│  │  (Primary)      │              │  (Replica)      │               │
│  └─────────────────┘              └─────────────────┘               │
│                                                                      │
│  FAILOVER PROCEDURE:                                                │
│  1. Detect primary failure (health checks)                          │
│  2. Verify data sync status                                         │
│  3. Promote replica to primary                                      │
│  4. Switch DNS / load balancer                                      │
│  5. Verify application connectivity                                 │
│  6. Resume operations                                               │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

Chapter 12 Interview Questions

Basic Level

  1. What are the four golden signals of monitoring?
  2. What is RPO and RTO?
  3. What is an incident severity level?
  4. How do you handle transaction timeouts?
  5. What is reconciliation?

Intermediate Level

  1. How do you monitor a payment system?
  2. Explain your incident response process.
  3. How do you handle stuck transactions?
  4. What is your disaster recovery strategy?
  5. How do you debug production payment issues?

Advanced Level

  1. Design monitoring for 1M TPS payment system.
  2. How do you achieve zero-downtime deployments?
  3. Design a multi-region active-active setup.
  4. How do you handle partial outages?
  5. Design automated incident response.

Appendix A: Quick Reference

Payment Rails Comparison

FeatureUPIIMPSNEFTRTGS
OperatorNPCINPCIRBIRBI
SettlementDeferredDeferredDeferredReal-time
Timing24x724x724x724x7
SpeedInstantInstant30min-2hrInstant
Min Amount₹1₹1₹1₹2,00,000
Max Amount₹1,00,000₹5,00,000No limitNo limit
IdentifierVPAAccount/MMIDAccountAccount

Key Regulatory Bodies

BodyRole
RBICentral bank, monetary policy, bank regulation
NPCIRetail payment systems (UPI, IMPS, NACH)
SEBISecurities market regulation
IRDAIInsurance regulation
PFRDAPension fund regulation

Important Codes

Code TypeExamplePurpose
IFSCHDFC0001234Identify bank branch
SWIFT/BICHABORABBXXXInternational bank identifier
MICR400240001Cheque processing
MCC5411Merchant category

Appendix B: Glossary

TermDefinition
AMLAnti-Money Laundering
BICBank Identifier Code (SWIFT Code)
CBSCore Banking System
CVVCard Verification Value
EMVEuropay, Mastercard, Visa (chip standard)
FDIForeign Direct Investment
FEMAForeign Exchange Management Act
GLGeneral Ledger
HSMHardware Security Module
IFSCIndian Financial System Code
KYCKnow Your Customer
LRSLiberalized Remittance Scheme
MDRMerchant Discount Rate
MIIMajor Industry Identifier
MMIDMobile Money Identifier
NACHNational Automated Clearing House
NPCINational Payments Corporation of India
NRINon-Resident Indian
PANPrimary Account Number (card number)
PCI-DSSPayment Card Industry Data Security Standard
POSPoint of Sale
PSPPayment Service Provider
RBIReserve Bank of India
RRNRetrieval Reference Number
RTGSReal Time Gross Settlement
STPStraight Through Processing
SWIFTSociety for Worldwide Interbank Financial Telecommunication
TPAPThird Party Application Provider
UETRUnique End-to-End Transaction Reference
UMRNUnique Mandate Reference Number
UPIUnified Payments Interface
UTRUnique Transaction Reference
VPAVirtual Payment Address

About This Book

This book was written to provide a comprehensive technical reference for engineers building banking and payment systems in India. It covers the complete landscape from fundamental banking concepts to production operations.
Topics Covered:
  • Banking fundamentals and money movement
  • Core Banking System architecture
  • All major payment rails (UPI, IMPS, NEFT, RTGS, Cards, NACH)
  • International remittances and SWIFT
  • System design patterns for payments
  • Production operations and incident handling
Target Audience:
  • Software engineers building payment systems
  • Technical architects designing financial platforms
  • FinTech professionals
  • Engineering managers in banking/payments
  • Interview candidates preparing for banking domain roles
All Blogs
Tags:system-designbankingnpcIrbiupifintechinterview-prep