How Money Actually Moves: A Deep Technical Guide to Indian Banking Infrastructure
Introduction
When you tap "Send Money" on your UPI app, what actually happens in the next 2 seconds? Where does the money go? How do banks know? What if something fails?
This blog answers these questions at the infrastructure level. We'll trace money movement from within-bank transfers to cross-border SWIFT payments, examining the accounting entries, settlement mechanisms, and regulatory controls that make India's payment ecosystem work.
I've spent two decades working with core banking systems, RBI integrations, and payment switches. This is the guide I wish existed when I started.
Chapter 1: The Indian Banking & Payment Ecosystem
Before diving into transactions, you need to understand the players and their roles.
The Regulatory Pyramid
┌─────────────────────────┐ │ Reserve Bank of │ │ India (RBI) │ │ - Central Bank │ │ - Settlement Bank │ │ - Regulator │ └───────────┬─────────────┘ │ ┌───────────────────┼───────────────────┐ │ │ │ ▼ ▼ ▼ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │ NPCI │ │ CCIL │ │ Clearing │ │ (Retail) │ │ (Wholesale) │ │ Houses │ │ UPI/IMPS │ │ RTGS/Forex │ │ (Regional) │ └───────┬───────┘ └───────┬───────┘ └───────┬───────┘ │ │ │ └───────────────────┼───────────────────┘ │ ┌───────────┴───────────┐ │ Commercial Banks │ │ (HDFC, ICICI, SBI) │ │ │ │ ┌─────────────────┐ │ │ │ Core Banking │ │ │ │ System (CBS) │ │ │ └─────────────────┘ │ └───────────────────────┘
Reserve Bank of India (RBI)
RBI is not just the regulator—it's the ultimate settlement bank. Every scheduled commercial bank maintains a Current Account with RBI. This is real money that banks own at the central bank.
Key RBI Functions in Payments:
- Banker to Banks: Maintains settlement accounts for all banks
- Settlement Finality: Provides final settlement through its books
- Liquidity Provider: Offers intraday liquidity and LAF (Liquidity Adjustment Facility)
- Oversight: Regulates all payment systems under Payment and Settlement Systems Act, 2007
RBI Settlement Account Structure:
Bank: HDFC Bank RBI Settlement Account: HDFC001RBI ┌─────────────────────────────────────────────────────────┐ │ RBI CURRENT ACCOUNT │ ├─────────────────────────────────────────────────────────┤ │ Opening Balance (9:00 AM) : ₹45,000 Crores │ │ + RTGS Inflows : ₹12,000 Crores │ │ - RTGS Outflows : ₹11,500 Crores │ │ + NEFT Net Position : ₹850 Crores │ │ - UPI Net Settlement : ₹920 Crores │ │ - CRR Requirement (Reserved) : ₹38,000 Crores │ │ ───────────────────────────────────────────────────── │ │ Available for Settlement : ₹7,430 Crores │ └─────────────────────────────────────────────────────────┘
NPCI (National Payments Corporation of India)
NPCI is the switching and clearing infrastructure for retail payments. It doesn't hold money—it routes messages and calculates settlement positions.
NPCI Systems:
| System | Purpose | Settlement |
|---|---|---|
| UPI | Real-time P2P/P2M | Net (T+0) |
| IMPS | 24x7 Interbank | Net (Multiple windows) |
| NACH | Bulk Recurring | Net (T+1) |
| AePS | Aadhaar Banking | Net (T+1) |
| RuPay | Card Network | Net (T+1) |
NPCI's Technical Role:
┌──────────────┐ Message ┌──────────────┐ Message ┌──────────────┐ │ Sender's │ ──────────────► │ NPCI │ ──────────────► │ Receiver's │ │ Bank (PSP) │ │ Switch │ │ Bank (PSP) │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ │ │ │ │ ▼ ▼ ▼ Debits Customer Calculates Net Credits Customer (Ledger Entry) Settlement Position (Ledger Entry) │ ▼ ┌──────────────┐ │ RBI │ │ Settlement │ │ Account │ └──────────────┘
Core Banking System (CBS)
CBS is the heart of every bank. It maintains the single source of truth for all accounts and transactions.
Major CBS Platforms in India:
- Finacle (Infosys) - HDFC, ICICI, Axis
- BaNCS (TCS) - SBI
- Flexcube (Oracle) - Multiple PSU banks
CBS Architecture:
┌─────────────────────────────────────────────────────────────────────┐ │ CORE BANKING SYSTEM │ ├─────────────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ │ │ Account Master │ │ Transaction │ │ General Ledger │ │ │ │ - Customer ID │ │ Engine │ │ - Chart of │ │ │ │ - Account No │ │ - Debit/Credit │ │ Accounts │ │ │ │ - Balance │ │ - Validation │ │ - P&L │ │ │ │ - Status │ │ - Posting │ │ - Balance Sheet│ │ │ └─────────────────┘ └─────────────────┘ └─────────────────┘ │ │ │ │ │ │ │ └────────────────────┼────────────────────┘ │ │ │ │ │ ┌───────────┴───────────┐ │ │ │ Transaction Log │ │ │ │ (Immutable Audit) │ │ │ └───────────────────────┘ │ │ │ │ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ │ │ Limits Engine │ │ Fraud Module │ │ Integration │ │ │ │ - Daily Limit │ │ - Rule Engine │ │ Layer │ │ │ │ - Per Txn │ │ - ML Models │ │ - NPCI Gateway │ │ │ │ - Velocity │ │ - Alerts │ │ - SWIFT │ │ │ └─────────────────┘ └─────────────────┘ └─────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────┘
Settlement Accounts Explained
What is a Settlement Account?
A settlement account is a pooled account that banks use to settle obligations with other institutions. Banks maintain multiple settlement accounts:
- RBI Current Account: For interbank settlement
- NPCI Settlement Account: Virtual position for netting
- Nostro Accounts: Foreign currency accounts abroad
- Vostro Accounts: Other banks' accounts with us
Liquidity Management:
Banks must ensure sufficient funds in RBI account to meet:
- CRR (Cash Reserve Ratio): 4.5% of NDTL
- SLR (Statutory Liquidity Ratio): 18% in government securities
- Settlement obligations
- Payment system requirements
Daily Liquidity Equation: Opening Balance (RBI Account) + Expected Inflows (RTGS, NEFT, UPI net positive) + RBI LAF Borrowing (if needed) - Expected Outflows (RTGS, NEFT, UPI net negative) - CRR Requirement - SLR Requirement ───────────────────────────────────── = Available Free Liquidity If negative → Bank must borrow (LAF/Call Money)
Chapter 2: Within-Bank Transfers (Same Bank)
The simplest form of money transfer. No external party involved.
The Scenario
Customer A (Account: 12345) transfers ₹10,000 to Customer B (Account: 67890). Both accounts are at HDFC Bank.
Technical Flow
Step 1: API Request ┌─────────────────────────────────────────────────────────────┐ │ Mobile App → Bank API Gateway → Transaction Service │ │ │ │ Request: │ │ { │ │ "source_account": "12345", │ │ "destination_account": "67890", │ │ "amount": 10000.00, │ │ "currency": "INR", │ │ "purpose": "Personal", │ │ "request_id": "REQ-2024-001", │ │ "timestamp": "2024-01-15T14:30:00Z" │ │ } │ └─────────────────────────────────────────────────────────────┘ │ ▼ Step 2: Validation Layer ┌─────────────────────────────────────────────────────────────┐ │ Validation Checks: │ │ ✓ Account 12345 exists and is active │ │ ✓ Account 67890 exists and is active │ │ ✓ Account 12345 is not frozen/blocked │ │ ✓ Account 67890 can receive credits │ │ ✓ Amount is positive and within limits │ │ ✓ Daily transaction limit not exceeded │ │ ✓ Velocity check passed (not too many txns) │ │ ✓ Request is not duplicate (idempotency) │ └─────────────────────────────────────────────────────────────┘ │ ▼ Step 3: Balance Check ┌─────────────────────────────────────────────────────────────┐ │ Account 12345 Balances: │ │ ├── Ledger Balance: ₹25,000 │ │ ├── Holds/Liens: ₹3,000 │ │ ├── Pending Debits: ₹500 │ │ └── Available Balance: ₹21,500 │ │ │ │ Required: ₹10,000 │ │ Available: ₹21,500 │ │ Check: PASSED ✓ │ └─────────────────────────────────────────────────────────────┘ │ ▼ Step 4: Fraud Check ┌─────────────────────────────────────────────────────────────┐ │ Fraud Engine Analysis: │ │ - Device fingerprint: Known device ✓ │ │ - IP geolocation: Normal location ✓ │ │ - Transaction pattern: Consistent ✓ │ │ - Beneficiary: Known recipient ✓ │ │ - Amount: Within normal range ✓ │ │ - Velocity: Normal frequency ✓ │ │ │ │ Risk Score: 12/100 (Low Risk) │ │ Decision: APPROVE │ └─────────────────────────────────────────────────────────────┘ │ ▼ Step 5: Transaction Posting (ACID) ┌─────────────────────────────────────────────────────────────┐ │ BEGIN TRANSACTION; │ │ │ │ -- Acquire locks on both accounts │ │ SELECT * FROM accounts WHERE account_no IN ('12345','67890')│ │ FOR UPDATE; │ │ │ │ -- Debit source account │ │ UPDATE accounts │ │ SET balance = balance - 10000, │ │ last_txn_date = NOW() │ │ WHERE account_no = '12345'; │ │ │ │ -- Credit destination account │ │ UPDATE accounts │ │ SET balance = balance + 10000, │ │ last_txn_date = NOW() │ │ WHERE account_no = '67890'; │ │ │ │ -- Insert transaction records │ │ INSERT INTO transactions (...) VALUES (...); │ │ │ │ COMMIT; │ └─────────────────────────────────────────────────────────────┘
Double-Entry Bookkeeping
Every transaction in banking creates at least two entries. The fundamental equation must always balance:
Assets = Liabilities + Equity For customer accounts (which are LIABILITIES to the bank): Debit decreases liability → Customer balance goes down Credit increases liability → Customer balance goes up
Accounting Entries for ₹10,000 Transfer:
Journal Entry #TXN-2024-0001 Date: 2024-01-15 14:30:00 Reference: Internal Transfer ┌────────────────────────────────────────────────────────────────┐ │ Account │ Debit (Dr) │ Credit (Cr) │ Balance │ ├───────────────────────┼─────────────┼─────────────┼───────────┤ │ 12345 (Sender) │ ₹10,000 │ │ ₹15,000 │ │ 67890 (Receiver) │ │ ₹10,000 │ ₹35,000 │ ├───────────────────────┼─────────────┼─────────────┼───────────┤ │ TOTAL │ ₹10,000 │ ₹10,000 │ BALANCED │ └────────────────────────────────────────────────────────────────┘ GL Impact (Bank's Books): ┌────────────────────────────────────────────────────────────────┐ │ GL Account │ Debit │ Credit │ ├────────────────────────────────────┼──────────┼──────────────┤ │ Savings Accounts Liability │ ₹10,000 │ ₹10,000 │ │ (Net Effect: Zero) │ │ │ └────────────────────────────────────────────────────────────────┘
Available Balance vs Ledger Balance
This distinction is critical for understanding why transfers sometimes fail:
┌─────────────────────────────────────────────────────────────────┐ │ BALANCE TYPES │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ LEDGER BALANCE (Book Balance) │ │ └── All posted transactions │ │ └── Reflects actual accounting position │ │ │ │ Example: ₹50,000 │ │ │ │ MINUS: Holds and Liens │ │ ├── Cheque pending clearance: ₹5,000 │ │ ├── EMI auto-debit scheduled: ₹15,000 │ │ ├── Card authorization hold: ₹2,000 │ │ └── Legal lien (court order): ₹3,000 │ │ │ │ Total Holds: ₹25,000 │ │ │ │ AVAILABLE BALANCE │ │ └── ₹50,000 - ₹25,000 = ₹25,000 │ │ └── This is what you can actually spend │ │ │ └─────────────────────────────────────────────────────────────────┘
Why Different Balances?
sql-- How CBS calculates available balance SELECT ledger_balance - COALESCE(pending_debits, 0) - COALESCE(holds_amount, 0) - COALESCE(liens_amount, 0) - COALESCE(minimum_balance_requirement, 0) AS available_balance FROM accounts WHERE account_no = '12345';
ACID Properties in Action
Atomicity:
-- Either both happen or neither BEGIN; UPDATE accounts SET balance = balance - 10000 WHERE id = 'A'; UPDATE accounts SET balance = balance + 10000 WHERE id = 'B'; COMMIT; -- Both succeed -- OR ROLLBACK; -- Both fail
Consistency:
-- Constraints ensure validity ALTER TABLE accounts ADD CONSTRAINT positive_balance CHECK (balance >= minimum_balance); -- Transaction will fail if it violates constraint
Isolation:
-- Row-level locking prevents concurrent modification SELECT * FROM accounts WHERE account_no = '12345' FOR UPDATE; -- Other transactions wait until lock is released
Durability:
-- Write-ahead logging ensures persistence 1. Write to WAL (Write-Ahead Log) 2. Acknowledge transaction 3. Async flush to disk -- If system crashes, replay WAL on recovery
Rollback and Reversal
Scenario: System failure after debit, before credit
Timeline: T1: Debit account 12345 → SUCCESS (committed) T2: System crash T3: Credit account 67890 → NEVER EXECUTED Detection: - Transaction marked as "INCOMPLETE" - Reconciliation job detects mismatch - Automatic reversal initiated Reversal Entry: ┌────────────────────────────────────────────────────────────────┐ │ Account │ Debit (Dr) │ Credit (Cr) │ Narration │ ├───────────────────────┼─────────────┼─────────────┼───────────┤ │ 12345 (Sender) │ │ ₹10,000 │ REVERSAL │ │ Suspense Account │ ₹10,000 │ │ REVERSAL │ └────────────────────────────────────────────────────────────────┘ Suspense account is investigated by operations team.
Why Within-Bank Transfers Are Real-Time:
No external dependencies: ├── No NPCI involvement ├── No RBI settlement ├── No correspondent banks ├── No clearing house ├── No network latency to other institutions └── Pure database operation within CBS Single system → Single transaction → Instant result
Chapter 3: Inter-Bank Domestic Transfers
Now we enter the complex world of moving money between different banks.
The Fundamental Challenge
Problem: Bank A and Bank B have separate databases. Bank A's CBS Bank B's CBS ┌─────────────┐ ┌─────────────┐ │ Account DB │ Cannot directly │ Account DB │ │ Finacle │◄─────────────────────│ BaNCS │ │ (Oracle) │ access │ (DB2) │ └─────────────┘ └─────────────┘ Solution: Intermediary infrastructure + Settlement
3.1 UPI (Unified Payments Interface)
UPI is India's most sophisticated real-time payment system. Let's trace a complete UPI transaction.
The Scenario:
Rahul (HDFC Bank) sends ₹5,000 to Priya (ICICI Bank) using UPI.
Complete UPI Flow:
Phase 1: Transaction Initiation ───────────────────────────────────────────────────────────────── Rahul's Phone PhonePe App (PSP) ┌─────────────┐ ┌─────────────────────┐ │ Enter ₹5000 │ ──────────────► │ Create UPI Request │ │ To: priya@ │ │ { │ │ icici │ │ payer_vpa: │ │ │ │ rahul@ybl │ │ Tap Send │ │ payee_vpa: │ └─────────────┘ │ priya@icici │ │ amount: 5000 │ │ txn_id: TXN123 │ │ } │ └─────────┬───────────┘ │ ▼ ┌─────────────────────┐ │ PhonePe PSP Server │ │ (Payment Service │ │ Provider) │ │ │ │ - Validate request │ │ - Add digital sign │ │ - Forward to NPCI │ └─────────┬───────────┘ │ ▼ Phase 2: NPCI Processing ───────────────────────────────────────────────────────────────── ┌─────────────────────────────┐ │ NPCI UPI SWITCH │ ├─────────────────────────────┤ │ │ │ Step 1: Parse & Validate │ │ - Check VPA format │ │ - Verify PSP signature │ │ - Check for duplicates │ │ │ │ Step 2: VPA Resolution │ │ - rahul@ybl → HDFC Bank │ │ - priya@icici → ICICI Bank │ │ │ │ Step 3: Route Request │ │ - Send to Remitter Bank │ │ (HDFC) for debit │ │ │ └──────────────┬──────────────┘ │ ┌────────────────────────────────┴────────────────────────────────┐ │ │ ▼ │ Phase 3: Debit at Remitter Bank (HDFC) │ ───────────────────────────────────────────────────────────────── │ │ ┌─────────────────────────────────────────────────────────────────┐ │ │ HDFC BANK UPI GATEWAY │ │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ │ │ 1. Receive NPCI Request │ │ │ {txn_id: TXN123, payer: rahul@ybl, amount: 5000} │ │ │ │ │ │ 2. Resolve VPA to Account │ │ │ rahul@ybl → Account: HDFC-12345678 │ │ │ │ │ │ 3. Validation Checks │ │ │ ✓ Account exists and active │ │ │ ✓ Available balance: ₹25,000 (sufficient) │ │ │ ✓ UPI daily limit: ₹85,000 remaining │ │ │ ✓ Transaction limit: ₹1,00,000 (sufficient) │ │ │ ✓ Fraud score: 8/100 (low risk) │ │ │ │ │ │ 4. Debit Account (Provisional) │ │ │ BEGIN TRANSACTION; │ │ │ UPDATE accounts SET balance = balance - 5000 │ │ │ WHERE account_no = 'HDFC-12345678'; │ │ │ INSERT INTO upi_transactions (txn_id, status, ...) │ │ │ VALUES ('TXN123', 'DEBIT_SUCCESS', ...); │ │ │ COMMIT; │ │ │ │ │ │ 5. Create Debit Response │ │ │ { │ │ │ txn_id: TXN123, │ │ │ status: "SUCCESS", │ │ │ debit_ref: "HDFC-DBT-001", │ │ │ rrn: "401512345678" │ │ │ } │ │ │ │ │ └────────────────────────────────────┬────────────────────────────┘ │ │ │ ▼ │ ┌─────────────────────┐ │ │ NPCI SWITCH │◄──────────────────────────────┘ │ Debit Confirmed │ │ Now route to │ │ Beneficiary Bank │ └──────────┬──────────┘ │ ▼ Phase 4: Credit at Beneficiary Bank (ICICI) ───────────────────────────────────────────────────────────────── ┌─────────────────────────────────────────────────────────────────┐ │ ICICI BANK UPI GATEWAY │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ 1. Receive Credit Request from NPCI │ │ {txn_id: TXN123, payee: priya@icici, amount: 5000, │ │ debit_ref: HDFC-DBT-001} │ │ │ │ 2. Resolve VPA to Account │ │ priya@icici → Account: ICICI-98765432 │ │ │ │ 3. Validation │ │ ✓ Account exists │ │ ✓ Account can receive credits │ │ ✓ No credit freeze │ │ ✓ AML check passed │ │ │ │ 4. Credit Account │ │ BEGIN TRANSACTION; │ │ UPDATE accounts SET balance = balance + 5000 │ │ WHERE account_no = 'ICICI-98765432'; │ │ INSERT INTO upi_transactions (...); │ │ COMMIT; │ │ │ │ 5. Send Credit Response │ │ { │ │ txn_id: TXN123, │ │ status: "SUCCESS", │ │ credit_ref: "ICICI-CRT-001" │ │ } │ │ │ └────────────────────────────────────┬────────────────────────────┘ │ ▼ Phase 5: Final Response ───────────────────────────────────────────────────────────────── NPCI → PhonePe PSP → Rahul's Phone { txn_id: "TXN123", status: "SUCCESS", amount: 5000, rrn: "401512345678", timestamp: "2024-01-15T14:30:02Z" } Total Time: ~2 seconds
UPI Settlement Process:
Even though the transaction appears instant, actual money settlement happens later:
UPI Settlement Timeline (T+0) ───────────────────────────────────────────────────────────────── ┌─────────────────────────────────────────────────────────────────┐ │ Hour │ Activity │ ├──────────┼──────────────────────────────────────────────────────┤ │ 00:00 │ Settlement Window Opens │ │ │ │ │ Every │ NPCI calculates net positions │ │ Hour │ ┌─────────────────────────────────────────────────┐ │ │ │ │ Bank │ Total Sent │ Total Recv │ Net Pos │ │ │ │ ├───────────┼────────────┼────────────┼──────────┤ │ │ │ │ HDFC │ ₹500 Cr │ ₹450 Cr │ -₹50 Cr │ │ │ │ │ ICICI │ ₹400 Cr │ ₹420 Cr │ +₹20 Cr │ │ │ │ │ SBI │ ₹600 Cr │ ₹580 Cr │ -₹20 Cr │ │ │ │ │ Axis │ ₹300 Cr │ ₹350 Cr │ +₹50 Cr │ │ │ │ └─────────────────────────────────────────────────┘ │ │ │ │ │ Every │ NPCI sends settlement file to RBI │ │ Hour │ │ │ │ │ │ RBI │ Debits/Credits bank settlement accounts │ │ Action │ ┌─────────────────────────────────────────────────┐ │ │ │ │ HDFC RBI Account: -₹50 Cr (Debited) │ │ │ │ │ ICICI RBI Account: +₹20 Cr (Credited) │ │ │ │ │ SBI RBI Account: -₹20 Cr (Debited) │ │ │ │ │ Axis RBI Account: +₹50 Cr (Credited) │ │ │ │ │ │ │ │ │ │ Net Sum: ₹0 (BALANCED) │ │ │ │ └─────────────────────────────────────────────────┘ │ │ │ │ │ 23:59 │ Final settlement of the day │ └──────────┴──────────────────────────────────────────────────────┘
UPI Failure Scenarios:
Scenario 1: Debit Success, Credit Failure ───────────────────────────────────────────────────────────────── Timeline: T+0ms: NPCI receives request T+50ms: HDFC debits ₹5,000 → SUCCESS T+100ms: NPCI routes to ICICI T+150ms: ICICI credit fails (account frozen) NPCI Action: 1. Mark transaction as "DEEMED" 2. Initiate automatic reversal 3. Send reversal request to HDFC HDFC Reversal: BEGIN TRANSACTION; UPDATE accounts SET balance = balance + 5000 WHERE account_no = 'HDFC-12345678'; INSERT INTO upi_transactions VALUES ('TXN123-REV', 'REVERSAL', ...); COMMIT; Customer sees: "Transaction failed. Amount will be refunded within 24-48 hours." Actual: Usually refunded within minutes. Scenario 2: NPCI Timeout ───────────────────────────────────────────────────────────────── Timeline: T+0ms: Request sent to NPCI T+30sec: No response from NPCI (timeout) Bank Action: 1. Mark as "PENDING" 2. Do NOT debit yet (or reverse if already debited) 3. Wait for NPCI callback or reconciliation NPCI Callback (if transaction succeeded): - NPCI sends status update - Bank completes/reverses accordingly No Callback → Reconciliation: - End of day, bank downloads settlement file - Reconciles all transactions - Auto-reverses unmatched debits
3.2 IMPS (Immediate Payment Service)
IMPS is similar to UPI but uses account number + IFSC instead of VPA.
Key Differences from UPI:
┌───────────────────┬─────────────────────┬─────────────────────┐ │ Feature │ UPI │ IMPS │ ├───────────────────┼─────────────────────┼─────────────────────┤ │ Identifier │ VPA (virtual address)│ Account + IFSC │ │ Limit │ ₹1 Lakh/txn │ ₹5 Lakh/txn │ │ Two-factor auth │ UPI PIN │ MPIN/OTP │ │ 24x7 │ Yes │ Yes │ │ Settlement │ Hourly │ Multiple windows │ │ Primary use │ P2P, P2M │ P2P, Bulk │ └───────────────────┴─────────────────────┴─────────────────────┘
IMPS Message Flow:
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ Sender Bank │────►│ NPCI │────►│Receiver Bank│ │ (HDFC) │ │ Switch │ │ (ICICI) │ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │ │ Message 1 │ │ │ IMPS Request │ │ │ ─────────────► │ │ │ │ Message 2 │ │ │ Forward to │ │ │ Beneficiary │ │ │ ─────────────► │ │ │ │ │ │ Message 3 │ │ │ Credit Status │ │ │ ◄───────────── │ │ Message 4 │ │ │ Final Status │ │ │ ◄───────────── │ │
3.3 NEFT (National Electronic Funds Transfer)
NEFT is a batch-based deferred settlement system.
How NEFT Batching Works:
NEFT Settlement Schedule (Every 30 minutes, 24x7) ───────────────────────────────────────────────────────────────── Window 1: 00:00 - 00:30 ├── Banks collect NEFT transactions ├── At 00:30, batch closes ├── Banks send batch to NPCI ├── NPCI processes and calculates net positions ├── RBI settles by 01:00 └── Credits reflect by 01:30 ┌─────────────────────────────────────────────────────────────────┐ │ Time │ Activity │ ├─────────┼───────────────────────────────────────────────────────┤ │ 10:15 │ Customer initiates NEFT transfer │ │ 10:30 │ Batch window closes, transaction in batch │ │ 10:45 │ NPCI processes batch, calculates netting │ │ 11:00 │ RBI settles net positions │ │ 11:15 │ Beneficiary bank receives credit file │ │ 11:30 │ Customer account credited │ │ │ │ │ Total │ ~1-2 hours (not instant like UPI/IMPS) │ └─────────┴───────────────────────────────────────────────────────┘
NEFT Message Format:
NEFT Transaction Record Structure ───────────────────────────────────────────────────────────────── Field Value Description ─────────────────────────────────────────────────────────────── Transaction Code N01 NEFT Credit Sender IFSC HDFC0001234 Sender branch Sender Account 001234567890 11-digit account Amount 0000050000000 ₹5,00,000 (paise) Receiver IFSC ICIC0005678 Receiver branch Receiver Account 9876543210 Receiver account Sender Name RAHUL SHARMA Receiver Name PRIYA GUPTA Purpose Code PC01 Personal UTR Number HDFC0000012345678 Unique Txn Ref Timestamp 20240115143000 YYYYMMDDHHMMSS
NEFT Deferred Net Settlement:
Net Settlement Calculation ───────────────────────────────────────────────────────────────── Bank A sends: To Bank B: ₹100 Cr To Bank C: ₹50 Cr To Bank D: ₹30 Cr Total Sent: ₹180 Cr Bank A receives: From Bank B: ₹80 Cr From Bank C: ₹60 Cr From Bank D: ₹20 Cr Total Received: ₹160 Cr Bank A Net Position: -₹20 Cr (Net Payer) RBI Action: Debit Bank A's RBI Account: ₹20 Cr This is why it's called "Deferred Net Settlement" - Individual transactions are not settled separately. Only the NET difference is settled.
3.4 RTGS (Real-Time Gross Settlement)
RTGS is for high-value transactions with immediate settlement.
RTGS Characteristics:
┌─────────────────────────────────────────────────────────────────┐ │ RTGS KEY FEATURES │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ Minimum Amount: ₹2,00,000 │ │ Maximum Amount: No limit │ │ Settlement: Real-time, transaction by transaction │ │ Timing: 24x7 (since December 2020) │ │ Settlement Type: GROSS (each transaction settles separately) │ │ │ │ GROSS vs NET: │ │ ───────────── │ │ NET: 100 transactions, 1 settlement (net difference) │ │ GROSS: 100 transactions, 100 settlements │ │ │ └─────────────────────────────────────────────────────────────────┘
RTGS Flow:
RTGS Transaction: ₹10 Crores ───────────────────────────────────────────────────────────────── ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │ Sender │ │ RBI │ │ Receiver │ │ Bank │ │ RTGS │ │ Bank │ │ (HDFC) │ │ System │ │ (ICICI) │ └───────┬───────┘ └───────┬───────┘ └───────┬───────┘ │ │ │ │ 1. RTGS Message │ │ │ ────────────────────► │ │ │ │ │ │ 2. Check HDFC's │ │ RBI Balance │ │ ₹500 Cr available │ │ │ │ │ 3. Settle: │ │ HDFC RBI Acc: -₹10 Cr │ │ ICICI RBI Acc: +₹10 Cr │ │ │ │ │ │ 4. Credit Advice │ │ │ ────────────────────► │ │ │ │ │ │ 5. Credit │ │ Customer │ │ │ │ 6. Confirmation │ │ │ ◄──────────────────── │ │ │ │ │ Total Time: 30 seconds to 2 minutes
RTGS Liquidity Management:
Why Banks Need Liquidity for RTGS ───────────────────────────────────────────────────────────────── Unlike NEFT (net settlement), RTGS settles EACH transaction. Scenario: HDFC RBI Balance: ₹500 Cr 10:00 AM: RTGS Out ₹100 Cr → Balance: ₹400 Cr 10:05 AM: RTGS Out ₹150 Cr → Balance: ₹250 Cr 10:10 AM: RTGS Out ₹200 Cr → Balance: ₹50 Cr 10:15 AM: RTGS Out ₹100 Cr → REJECTED! Insufficient balance Solution: Intraday Liquidity Facility (ILF) - Banks can borrow from RBI for intraday needs - Must repay by end of day - Collateralized by government securities RTGS Queue Management: - If bank lacks funds, transaction queues - RBI optimizes queue to maximize settlements - Banks monitor queue position in real-time
Chapter 4: How Banks "Hold" Money
Understanding why money sometimes appears stuck.
Types of Holds
┌─────────────────────────────────────────────────────────────────┐ │ TYPES OF MONEY HOLDS │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ 1. AUTHORIZATION HOLD (Card Transactions) │ │ ├── Pre-authorization for estimated amount │ │ ├── Common at hotels, gas stations, rentals │ │ ├── Hold reduces available balance │ │ └── Released when actual transaction posts │ │ │ │ 2. CHEQUE CLEARANCE HOLD │ │ ├── Cheque deposited but not yet cleared │ │ ├── Usually 2-3 working days │ │ ├── Funds marked but not available │ │ └── Released when cheque clears or bounces │ │ │ │ 3. PENDING SETTLEMENT │ │ ├── UPI/IMPS debit done, RBI settlement pending │ │ ├── Usually settles within hours │ │ └── Bank has reduced liability but not yet settled │ │ │ │ 4. REGULATORY HOLD │ │ ├── Suspicious transaction investigation │ │ ├── Court order or legal attachment │ │ ├── Tax authority freeze (IT/GST) │ │ └── Can be partial or full account freeze │ │ │ │ 5. MINIMUM BALANCE HOLD │ │ ├── Required minimum balance blocked │ │ └── Cannot be used for transactions │ │ │ │ 6. AUTO-DEBIT RESERVATION │ │ ├── EMI, SIP, or recurring payment scheduled │ │ ├── Amount reserved before due date │ │ └── Released if auto-debit fails │ │ │ └─────────────────────────────────────────────────────────────────┘
Card Authorization vs Settlement
Card Transaction Lifecycle ───────────────────────────────────────────────────────────────── Example: ₹5,000 purchase at Big Bazaar Day 0 (Transaction Day) ──────────────────────────────────────────────────────────────── Customer: Swipes card at POS terminal ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ POS Terminal│────►│ Card Network│────►│ Issuer Bank │ │ │ │ (Visa/MC) │ │ (HDFC) │ └─────────────┘ └─────────────┘ └─────────────┘ Issuer Bank Checks: ├── Card valid and not blocked ├── Available balance/credit limit ├── CVV/PIN verification ├── Fraud score acceptable └── Daily limit not exceeded Response: APPROVED (Authorization Code: 123456) Customer's Account: ┌─────────────────────────────────────────────────────────────────┐ │ Ledger Balance: ₹25,000 │ │ Authorization Hold: ₹5,000 (this transaction) │ │ Available Balance: ₹20,000 │ │ │ │ Note: Money NOT yet deducted from ledger │ └─────────────────────────────────────────────────────────────────┘ Day 1-2 (Settlement Day) ──────────────────────────────────────────────────────────────── Merchant batches transactions at end of day. Acquirer bank (merchant's bank) sends settlement file. Card network calculates net positions. Settlement: ┌─────────────────────────────────────────────────────────────────┐ │ Acquirer Bank receives: ₹4,900 (after fees) │ │ Merchant credited: ₹4,900 │ │ │ │ Issuer Bank pays: ₹4,950 (minus interchange) │ │ Customer ledger debited: ₹5,000 │ │ │ │ Card Network keeps: ₹50 (network fees) │ └─────────────────────────────────────────────────────────────────┘ Customer's Account After Settlement: ┌─────────────────────────────────────────────────────────────────┐ │ Ledger Balance: ₹20,000 (debited ₹5,000) │ │ Authorization Hold: ₹0 (released) │ │ Available Balance: ₹20,000 │ └─────────────────────────────────────────────────────────────────┘
Fraud Detection and Holds
Transaction Fraud Monitoring Flow ───────────────────────────────────────────────────────────────── Every UPI/Card transaction passes through: ┌─────────────────────────────────────────────────────────────────┐ │ FRAUD DETECTION ENGINE │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ RULE-BASED CHECKS (Instant): │ │ ├── Transaction amount > daily limit → BLOCK │ │ ├── Transaction from new device → VERIFY │ │ ├── Transaction from unusual location → FLAG │ │ ├── Multiple transactions in short time → HOLD │ │ └── Beneficiary on blacklist → BLOCK │ │ │ │ ML-BASED SCORING (Real-time): │ │ ├── Pattern matching against fraud cases │ │ ├── Behavioral analysis (typing speed, time of day) │ │ ├── Device fingerprinting │ │ └── Network analysis (beneficiary risk) │ │ │ │ SCORE OUTPUT: │ │ ├── 0-30: Low Risk → APPROVE │ │ ├── 31-70: Medium Risk → APPROVE + MONITOR │ │ ├── 71-90: High Risk → HOLD for manual review │ │ └── 91-100: Critical → BLOCK + Alert │ │ │ └─────────────────────────────────────────────────────────────────┘ High-Risk Transaction Flow: 1. Transaction flagged (score: 85) 2. Amount debited and held (not sent to beneficiary) 3. Transaction enters manual review queue 4. Fraud analyst reviews within 24-48 hours 5. Decision: ├── APPROVE: Release hold, complete transfer └── REJECT: Reverse debit, block transaction
AML (Anti-Money Laundering) Holds
AML Monitoring and STR Filing ───────────────────────────────────────────────────────────────── RBI Mandated Thresholds: ├── Cash transactions > ₹10 Lakh → Mandatory reporting ├── Cross-border > ₹5 Lakh → Enhanced due diligence └── Suspicious patterns → STR (Suspicious Transaction Report) What Triggers AML Holds: ┌─────────────────────────────────────────────────────────────────┐ │ Pattern │ Action │ ├───────────────────────────────────┼─────────────────────────────┤ │ Multiple small deposits to │ Hold + Investigation │ │ avoid ₹10L threshold │ (Structuring) │ │ │ │ │ Large incoming SWIFT from │ Hold pending FEMA check │ │ high-risk country │ │ │ │ │ │ Account with dormant history │ Hold + Document request │ │ suddenly receiving large amounts │ │ │ │ │ │ Mismatch between declared │ Hold + Investigation │ │ income and transaction volume │ │ └───────────────────────────────────┴─────────────────────────────┘ AML Investigation Process: 1. System flags transaction 2. AML team receives alert 3. Customer contacted for documentation 4. Investigation completed (7-30 days) 5. Outcome: ├── CLEARED: Funds released ├── STR FILED: Funds released, report to FIU-IND └── FROZEN: Account frozen, reported to authorities
Chargeback Process
Card Chargeback Flow ───────────────────────────────────────────────────────────────── Scenario: Customer disputes ₹5,000 charge Timeline: Day 0: Customer sees unknown transaction Day 1: Customer raises dispute with issuer bank (HDFC) ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │ Customer │ │ Issuer Bank │ │ Acquirer Bank │ │ │ │ (HDFC) │ │ (ICICI) │ └───────┬───────┘ └───────┬───────┘ └───────┬───────┘ │ │ │ │ Raise Dispute │ │ │ ─────────────────► │ │ │ │ │ │ │ Chargeback Request │ │ │ ─────────────────► │ │ │ │ │ │ │ Notify Merchant │ │ │ + Request Docs │ │ │ │ │ ◄───────────────────│ │ │ Merchant Response │ │ │ (Accept/Dispute) │ │ │ │ Possible Outcomes: 1. Merchant Accepts Chargeback: - Merchant's account debited ₹5,000 - Customer's account credited ₹5,000 2. Merchant Disputes (Representment): - Merchant provides proof (receipt, delivery) - Issuer reviews evidence - Either upholds or reverses chargeback 3. Arbitration: - If no resolution, card network arbitrates - Losing party pays arbitration fee (~$500) Chargeback Time Limits: ├── Customer: 120 days to dispute ├── Merchant: 45 days to respond └── Total resolution: Up to 180 days
Chapter 5: RBI's Role in Domestic Settlement
The central nervous system of Indian banking.
RBI Settlement Infrastructure
RBI Payment Systems Architecture ───────────────────────────────────────────────────────────────── ┌─────────────────────────────────────────────────────────────────┐ │ RBI SYSTEMS │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ RTGS │ │ │ │ - Real-time gross settlement │ │ │ │ - High-value (>₹2L) transactions │ │ │ │ - Settles in RBI books │ │ │ │ - Managed by RBI directly │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ NEFT │ │ │ │ - Deferred net settlement │ │ │ │ - Batch processing every 30 mins │ │ │ │ - Net positions settled in RBI books │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ SFMS (Messaging) │ │ │ │ - Structured Financial Messaging System │ │ │ │ - Secure messaging between banks │ │ │ │ - Cheque clearing messages │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ CTS (Cheque Truncation) │ │ │ │ - Image-based cheque clearing │ │ │ │ - Physical cheque stays at presenting bank │ │ │ │ - Settlement through RBI │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────┘
CRR and SLR: Why Banks Can't Use All Their Money
Regulatory Reserve Requirements ───────────────────────────────────────────────────────────────── Every bank must maintain: CRR (Cash Reserve Ratio): 4.5% of NDTL ├── NDTL: Net Demand and Time Liabilities ├── Must be maintained as cash with RBI ├── NO interest earned └── Purpose: Monetary policy tool, liquidity buffer SLR (Statutory Liquidity Ratio): 18% of NDTL ├── Must be held in government securities ├── Earns interest (government bond yields) └── Purpose: Funds government borrowing, ensures solvency Example Bank Balance Sheet: ┌─────────────────────────────────────────────────────────────────┐ │ Total Deposits (NDTL): ₹10,00,000 Crores │ │ │ │ CRR Requirement (4.5%): ₹45,000 Crores │ │ ├── Must keep with RBI │ │ └── Cannot use for lending or settlement │ │ │ │ SLR Requirement (18%): ₹1,80,000 Crores │ │ ├── Must hold government securities │ │ └── Can pledge for emergency borrowing │ │ │ │ Available for Lending: ₹7,75,000 Crores │ │ (After CRR + SLR + operational buffers) │ └─────────────────────────────────────────────────────────────────┘
Liquidity Adjustment Facility (LAF)
How Banks Manage Short-Term Liquidity ───────────────────────────────────────────────────────────────── Scenario: HDFC Bank needs ₹5,000 Cr for afternoon RTGS settlements but only has ₹4,000 Cr in RBI account. Options: 1. LAF REPO (Borrow from RBI overnight) ┌─────────────────────────────────────────────────────────────┐ │ Bank sells government securities to RBI │ │ Agreement to repurchase next day at higher price │ │ Difference = Interest (Repo Rate: 6.5%) │ │ │ │ Morning: Bank gives ₹5,000 Cr G-Secs to RBI │ │ RBI credits ₹5,000 Cr to bank's account │ │ │ │ Next Day: Bank repays ₹5,000.89 Cr │ │ RBI returns G-Secs │ │ Interest: ₹0.89 Cr (overnight at 6.5%) │ └─────────────────────────────────────────────────────────────┘ 2. MSF (Marginal Standing Facility) ┌─────────────────────────────────────────────────────────────┐ │ Emergency borrowing at higher rate (MSF = Repo + 0.25%) │ │ Can dip into SLR holdings (up to 2%) │ │ Used when normal LAF limit exhausted │ └─────────────────────────────────────────────────────────────┘ 3. CALL MONEY MARKET ┌─────────────────────────────────────────────────────────────┐ │ Borrow from another bank with surplus │ │ Overnight lending between banks │ │ Rate fluctuates based on liquidity │ └─────────────────────────────────────────────────────────────┘
Settlement Risk Management
What Happens If a Bank Can't Settle? ───────────────────────────────────────────────────────────────── Scenario: Bank XYZ has insufficient funds for UPI settlement Timeline: 11:00 AM: UPI settlement window NPCI calculates Bank XYZ owes ₹500 Cr net Bank XYZ RBI account has only ₹300 Cr RBI Actions: ┌─────────────────────────────────────────────────────────────────┐ │ 1. Queue the settlement │ │ - Bank XYZ's outgoing payments wait │ │ - Other banks' incoming from XYZ delayed │ │ │ │ 2. ILF (Intraday Liquidity Facility) │ │ - If bank has eligible collateral │ │ - RBI provides intraday credit │ │ - Must repay by end of day │ │ │ │ 3. If still short by EOD │ │ - RBI forces reverse repo liquidation │ │ - Bank penalized for settlement failure │ │ - Reported to RBI supervision │ │ │ │ 4. Systemic failure scenario │ │ - RBI may invoke emergency liquidity │ │ - In extreme cases, RBI administers the bank │ │ - (Yes Bank, PMC Bank examples) │ └─────────────────────────────────────────────────────────────────┘ Preventive Measures: Banks maintain: ├── Real-time liquidity monitoring dashboards ├── Predictive models for settlement positions ├── Early warning alerts (balance < threshold) ├── Pre-arranged credit lines └── Treasury teams managing positions throughout day
Netting Mechanism Deep Dive
Multilateral Netting Example ───────────────────────────────────────────────────────────────── Without Netting (Gross Settlement): Bank A → Bank B: ₹100 Cr Bank B → Bank A: ₹80 Cr Bank A → Bank C: ₹50 Cr Bank C → Bank A: ₹30 Cr Total Settlement: ₹260 Cr in transfers With Multilateral Netting: ┌──────────────────────────────────────────────────────────────┐ │ │ Bank A │ Bank B │ Bank C │ Net Position │ ├─────────┼─────────┼─────────┼─────────┼─────────────────────┤ │ Bank A │ - │ -₹100 │ -₹50 │ Pays: ₹150 │ │ Pays │ │ │ │ │ ├─────────┼─────────┼─────────┼─────────┼─────────────────────┤ │ Bank A │ - │ +₹80 │ +₹30 │ Receives: ₹110 │ │ Receives│ │ │ │ │ ├─────────┼─────────┼─────────┼─────────┼─────────────────────┤ │ Net │ │ │ │ Bank A: -₹40 │ │ │ │ │ │ Bank B: +₹20 │ │ │ │ │ │ Bank C: +₹20 │ └──────────────────────────────────────────────────────────────┘ Final RBI Settlement: Bank A's RBI Account: Debit ₹40 Cr Bank B's RBI Account: Credit ₹20 Cr Bank C's RBI Account: Credit ₹20 Cr Total Settlement: ₹40 Cr (instead of ₹260 Cr gross) Efficiency: 85% reduction in liquidity requirement
Chapter 6: SWIFT International Transfers
Moving money across borders is fundamentally different.
What is SWIFT?
SWIFT Fundamentals ───────────────────────────────────────────────────────────────── SWIFT = Society for Worldwide Interbank Financial Telecommunication CRITICAL UNDERSTANDING: ┌─────────────────────────────────────────────────────────────────┐ │ │ │ SWIFT IS NOT A PAYMENT SYSTEM │ │ │ │ SWIFT is a MESSAGING NETWORK. │ │ It sends instructions. It does NOT move money. │ │ │ │ Analogy: │ │ ├── SWIFT = Email system │ │ ├── Money Movement = Actual delivery │ │ └── Settlement = Correspondent banking │ │ │ └─────────────────────────────────────────────────────────────────┘ SWIFT Statistics: ├── 11,000+ institutions in 200+ countries ├── 5 billion messages per year ├── Available 24x7x365 └── 99.999% availability
SWIFT Message Types
Common SWIFT Message Types ───────────────────────────────────────────────────────────────── MT103: Single Customer Credit Transfer ├── Used for: P2P cross-border payments ├── Contains: Beneficiary details, amount, purpose └── Example: Indian company paying US supplier MT202: General Financial Institution Transfer ├── Used for: Bank-to-bank cover payments ├── Contains: Settlement instructions └── Usually accompanies MT103 MT199: Free Format Message ├── Used for: Queries, investigations └── Example: "Where is my payment?" MT900: Confirmation of Debit ├── Confirms funds debited from Nostro └── Sent by correspondent bank MT910: Confirmation of Credit ├── Confirms funds credited to Vostro └── Sent by correspondent bank MT940: Customer Statement ├── Account statement └── Reconciliation purposes
Cross-Border Transfer Flow
Let's trace a real international payment:
Scenario: TCS India pays $100,000 to Microsoft USA ───────────────────────────────────────────────────────────────── Parties Involved: ├── Ordering Customer: TCS Ltd, India ├── Ordering Bank: HDFC Bank, India ├── Correspondent Bank: Citibank New York (HDFC's USD Nostro) ├── Beneficiary Bank: JP Morgan Chase, USA └── Beneficiary: Microsoft Corporation, USA Step-by-Step Flow: Day 0, 10:00 AM IST: TCS initiates payment ───────────────────────────────────────────────────────────────── TCS → HDFC Bank: "Transfer $100,000 to Microsoft's account at JP Morgan Chase" HDFC Bank Checks: ├── TCS has INR balance for conversion (₹83 Lakh at 83 rate) ├── FEMA compliance (import payment documentation) ├── Purpose code: P0801 (software services) ├── Sanctions screening (OFAC, UN, EU lists) ├── AML checks passed └── AD (Authorized Dealer) limit available Day 0, 10:30 AM IST: HDFC sends SWIFT MT103 ───────────────────────────────────────────────────────────────── ┌─────────────────────────────────────────────────────────────────┐ │ MT103 Message │ ├─────────────────────────────────────────────────────────────────┤ │ :20: Transaction Reference: HDFC2024011500001 │ │ :23B: Bank Operation Code: CRED │ │ :32A: Value Date/Amount: 240116USD100000,00 │ │ :50K: Ordering Customer: │ │ /HDFC001234567890 │ │ TATA CONSULTANCY SERVICES LTD │ │ TCS HOUSE, MUMBAI 400001 │ │ :52A: Ordering Institution: HDFCINBBXXX (HDFC Bank BIC) │ │ :53A: Sender's Correspondent: CITIUS33XXX (Citi New York) │ │ :57A: Account With Institution: CHASUS33XXX (JP Morgan) │ │ :59: Beneficiary: │ │ /JP Morgan Account Number │ │ MICROSOFT CORPORATION │ │ ONE MICROSOFT WAY, REDMOND WA │ │ :70: Remittance Info: INV/2024/SOFTWARE/001 │ │ :71A: Charges: OUR (sender pays all charges) │ └─────────────────────────────────────────────────────────────────┘ Message Route: HDFC India → SWIFT Network → Citibank NY → JP Morgan → Microsoft Day 0, 11:00 AM IST: Correspondent Banking Action ───────────────────────────────────────────────────────────────── Understanding Nostro/Vostro: ┌─────────────────────────────────────────────────────────────────┐ │ NOSTRO: "Our account with them" (in foreign currency) │ │ VOSTRO: "Their account with us" (mirror of their Nostro) │ │ │ │ HDFC Bank maintains: │ │ ├── USD Nostro at Citibank NY │ │ ├── EUR Nostro at Deutsche Bank Frankfurt │ │ ├── GBP Nostro at Barclays London │ │ └── JPY Nostro at MUFG Tokyo │ │ │ │ From Citibank's perspective: │ │ └── HDFC's Nostro is their "Vostro" (HDFC's money with them) │ └─────────────────────────────────────────────────────────────────┘ Citibank NY receives MT103: 1. Verifies HDFC's signature (BIC authentication) 2. Debits HDFC's Nostro account: -$100,000 3. Sends MT202 cover to JP Morgan 4. Instructs Fedwire (US payment system) transfer Day 0, 11:30 AM IST (2:00 AM EST): Fedwire Settlement ───────────────────────────────────────────────────────────────── ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │ Citibank │ │ Federal │ │ JP Morgan │ │ NY │ │ Reserve │ │ Chase │ └───────┬───────┘ └───────┬───────┘ └───────┬───────┘ │ │ │ │ Fedwire Transfer │ │ │ ────────────────────► │ │ │ │ │ │ Citi Fed Account: -$100,000 │ │ JPM Fed Account: +$100,000 │ │ │ │ │ │ Fedwire Credit │ │ │ ────────────────────► │ │ │ │ │ │ Credit Microsoft │ │ Account Day 0, 6:00 PM IST: Confirmations Flow Back ───────────────────────────────────────────────────────────────── JP Morgan → SWIFT MT910 → HDFC Bank "Funds credited to Microsoft account" HDFC → TCS "Your payment of $100,000 to Microsoft is complete" Full Timeline: ───────────────────────────────────────────────────────────────── 10:00 AM IST: Payment initiated 10:30 AM IST: SWIFT message sent 11:00 AM IST: Correspondent processes (Citi NY) 11:30 AM IST: Fedwire settlement 02:00 PM IST: Microsoft credited 06:00 PM IST: Confirmations received Total Time: ~8 hours (same day if initiated early) Why not instant? Time zones, compliance checks, batch processing
Why International Transfers Take Time
Delay Factors in Cross-Border Payments ───────────────────────────────────────────────────────────────── 1. TIME ZONES └── Fedwire operates only during US banking hours (9 AM - 6 PM ET) └── Payment at 3 PM IST = 5:30 AM ET (Fedwire not yet open) 2. COMPLIANCE CHECKS Each bank in the chain performs: ├── Sanctions screening (OFAC, UN, EU) ├── AML checks ├── FATF compliance └── Country-specific regulations 3. CORRESPONDENT CHAIN More hops = More time ┌─────────────────────────────────────────────────────────────┐ │ Simple: India → US Direct Correspondent │ │ Complex: India → Singapore → UK → US (multiple hops) │ └─────────────────────────────────────────────────────────────┘ 4. CURRENCY CONVERSION └── FX settlement may take T+2 5. BENEFICIARY BANK PROCESSING └── Some banks credit next business day 6. INVESTIGATIONS (if issues) └── Name mismatch, missing info can add days
RBI Oversight on International Transfers
FEMA Compliance Framework ───────────────────────────────────────────────────────────────── Foreign Exchange Management Act (FEMA) governs all forex transactions. Key Controls: 1. AUTHORIZED DEALERS (AD) ├── Only AD banks can handle forex ├── RBI issues AD licenses ├── AD-I: Full forex operations ├── AD-II: Limited scope └── AD banks report daily to RBI 2. PURPOSE CODES Every international transfer needs purpose code: ├── P0101: Import of goods ├── P0801: Software services ├── P1301: Education abroad ├── S0001: Repatriation of foreign investment └── ... 50+ purpose codes 3. LIBERALIZED REMITTANCE SCHEME (LRS) ├── Individuals can remit $250,000 per year ├── For education, travel, investment abroad ├── PAN mandatory ├── Form A2 submission └── TCS (Tax Collected at Source) on excess 4. REPORTING REQUIREMENTS ┌─────────────────────────────────────────────────────────────┐ │ Daily Reporting: │ │ ├── All forex transactions > $10,000 │ │ ├── All suspicious transactions │ │ └── Aggregate positions │ │ │ │ Monthly Reporting: │ │ ├── R-Return (forex positions) │ │ ├── Nostro account balances │ │ └── Forward contract positions │ │ │ │ Annual Reporting: │ │ ├── Foreign Liabilities and Assets (FLA) Return │ │ └── External Commercial Borrowings (ECB) │ └─────────────────────────────────────────────────────────────┘
SWIFT Security and Audit
SWIFT Customer Security Programme (CSP) ───────────────────────────────────────────────────────────────── After Bangladesh Bank heist ($81M stolen via SWIFT), mandatory controls: 1. SECURE YOUR ENVIRONMENT ├── Segregated SWIFT infrastructure ├── Hardened operating systems ├── Restricted internet access └── Physical security controls 2. KNOW AND LIMIT ACCESS ├── Multi-factor authentication ├── Role-based access control ├── Privileged access management └── Regular access reviews 3. DETECT AND RESPOND ├── Transaction monitoring ├── Anomaly detection ├── Incident response procedures └── Daily reconciliation 4. ATTESTATION ├── Annual self-attestation ├── Independent assessment └── Published to counterparties RBI SWIFT Audit Requirements: ├── IS Audit of SWIFT operations annually ├── Pen testing of SWIFT infrastructure ├── Gap analysis against CSP └── Board-level reporting
Chapter 7: Settlement and Reconciliation Deep Dive
The unsung hero of banking operations.
End-of-Day Settlement Process
Bank's End-of-Day Settlement Timeline ───────────────────────────────────────────────────────────────── 23:00 - Day End Cutoff ├── No new customer transactions accepted ├── Batch jobs initiated └── Treasury positions frozen 23:15 - Position Calculation ├── Calculate net UPI position ├── Calculate net NEFT position ├── Calculate IMPS pending ├── Calculate card network positions └── Aggregate all payment channels 23:30 - Settlement File Generation ├── Create settlement files for NPCI ├── Create files for card networks ├── Generate RBI reporting files └── Prepare reconciliation inputs 23:45 - Final Settlement Submission ├── Submit to NPCI for final settlement ├── Confirm RBI account positions └── Trigger auto-settlement mechanisms 00:00 - Day Change ├── Reset daily limits ├── Apply interest accruals ├── Process scheduled debits └── Begin new day processing
Reconciliation Architecture
Multi-Layer Reconciliation ───────────────────────────────────────────────────────────────── ┌─────────────────────────────────────────────────────────────────┐ │ LAYER 1: Transaction Level Reconciliation │ │ ───────────────────────────────────────────────────────────── │ │ Every transaction matched across systems: │ │ ├── CBS Transaction ID │ │ ├── Channel Transaction ID (UPI/IMPS/NEFT) │ │ ├── NPCI Response Code │ │ └── Customer Account Impact │ │ │ │ Mismatch Examples: │ │ ├── CBS shows debit, NPCI shows failure │ │ ├── NPCI shows success, CBS debit not posted │ │ └── Amount mismatch between systems │ └─────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ LAYER 2: Settlement Level Reconciliation │ │ ───────────────────────────────────────────────────────────── │ │ Net positions matched: │ │ ├── Bank calculated position vs NPCI position │ │ ├── Expected RBI debit/credit vs actual │ │ └── Nostro expected balance vs statement │ │ │ │ Mismatch Examples: │ │ ├── NPCI says we owe ₹100Cr, we calculated ₹99Cr │ │ ├── RBI settlement amount differs from expectation │ │ └── Correspondent bank statement doesn't match │ └─────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ LAYER 3: GL Reconciliation │ │ ───────────────────────────────────────────────────────────── │ │ Aggregate accounting entries balanced: │ │ ├── Total customer account debits = GL liability decrease │ │ ├── Total settlement credits = GL asset increase │ │ └── Suspense accounts cleared │ │ │ │ Daily GL Balancing: │ │ ├── Trial balance verification │ │ ├── Inter-branch reconciliation │ │ └── Suspense account analysis │ └─────────────────────────────────────────────────────────────────┘
Exception Handling
Reconciliation Exception Types ───────────────────────────────────────────────────────────────── 1. DEBIT WITHOUT CREDIT (Most Critical) ┌──────────────────────────────────────────────────────────────┐ │ Scenario: Customer debited, beneficiary not credited │ │ ├── Detection: Transaction status mismatch │ │ ├── Impact: Customer funds in limbo │ │ ├── Action: Immediate investigation + reversal │ │ └── SLA: Resolve within 24 hours (RBI mandate) │ └──────────────────────────────────────────────────────────────┘ 2. CREDIT WITHOUT DEBIT (Rare but serious) ┌──────────────────────────────────────────────────────────────┐ │ Scenario: Beneficiary credited, sender not debited │ │ ├── Detection: Settlement position mismatch │ │ ├── Impact: Bank loses money │ │ ├── Action: Investigate, potentially reverse credit │ │ └── Prevention: CBS should never credit without debit │ └──────────────────────────────────────────────────────────────┘ 3. DUPLICATE TRANSACTIONS ┌──────────────────────────────────────────────────────────────┐ │ Scenario: Same transaction processed twice │ │ ├── Detection: Duplicate reference/amount patterns │ │ ├── Impact: Double debit/credit │ │ ├── Action: Reverse duplicate, investigate root cause │ │ └── Prevention: Idempotency checks, unique constraints │ └──────────────────────────────────────────────────────────────┘ 4. AMOUNT MISMATCHES ┌──────────────────────────────────────────────────────────────┐ │ Scenario: ₹1,000 debited, ₹100 credited (missing zero) │ │ ├── Detection: Amount field comparison │ │ ├── Impact: Either party loses ₹900 │ │ ├── Action: Trace original instruction, correct posting │ │ └── Prevention: Amount validation at each hop │ └──────────────────────────────────────────────────────────────┘ 5. TIMING DIFFERENCES ┌──────────────────────────────────────────────────────────────┐ │ Scenario: Transaction on Day 1 (23:59), settled Day 2 │ │ ├── Not really an exception │ │ ├── Just timing difference in reporting │ │ └── Resolved in next day reconciliation │ └──────────────────────────────────────────────────────────────┘
Reconciliation Technology Stack
Modern Reconciliation Infrastructure ───────────────────────────────────────────────────────────────── ┌─────────────────────────────────────────────────────────────────┐ │ RECONCILIATION PLATFORM │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ DATA INGESTION │ │ ├── CBS transaction feeds (real-time CDC) │ │ ├── NPCI response files (batch) │ │ ├── RBI settlement confirmations │ │ ├── Nostro statements (SWIFT MT940) │ │ └── Card network files │ │ │ │ MATCHING ENGINE │ │ ├── Rule-based matching │ │ │ ├── Exact match on reference │ │ │ ├── Amount tolerance matching │ │ │ └── Date range matching │ │ │ │ │ ├── ML-based matching │ │ │ ├── Fuzzy matching for name/reference │ │ │ ├── Pattern recognition for duplicates │ │ │ └── Anomaly detection │ │ │ │ │ └── Manual matching queue │ │ └── Exceptions requiring human judgment │ │ │ │ EXCEPTION MANAGEMENT │ │ ├── Auto-categorization of exceptions │ │ ├── Workflow routing │ │ ├── Aging analysis │ │ └── Resolution tracking │ │ │ │ REPORTING │ │ ├── Daily reconciliation status │ │ ├── Aging reports │ │ ├── Trend analysis │ │ └── Regulatory reports │ │ │ └─────────────────────────────────────────────────────────────────┘ Key Metrics Tracked: ┌───────────────────────────────────────────────────────────────┐ │ Metric │ Target │ Alert │ ├───────────────────────────────────┼───────────┼───────────────┤ │ Auto-match rate │ > 99% │ < 98% │ │ Exceptions resolved same day │ > 95% │ < 90% │ │ Exceptions > 7 days old │ < 0.1% │ > 0.5% │ │ Suspense account balance │ < ₹1Cr │ > ₹5Cr │ │ Settlement position variance │ < 0.01% │ > 0.05% │ └───────────────────────────────────┴───────────┴───────────────┘
Chapter 8: Risk Management and Security
Protecting the payment ecosystem.
Transaction Risk Framework
Risk Assessment at Transaction Level ───────────────────────────────────────────────────────────────── Every transaction evaluated across multiple dimensions: ┌─────────────────────────────────────────────────────────────────┐ │ DIMENSION │ PARAMETERS │ ├─────────────────────┼───────────────────────────────────────────┤ │ Identity Risk │ - Device fingerprint │ │ │ - Behavioral biometrics │ │ │ - Authentication strength │ ├─────────────────────┼───────────────────────────────────────────┤ │ Transaction Risk │ - Amount (unusual for customer?) │ │ │ - Beneficiary (first time? blacklisted?) │ │ │ - Time of day (3 AM transfer?) │ │ │ - Channel (new device? new location?) │ ├─────────────────────┼───────────────────────────────────────────┤ │ Velocity Risk │ - Transactions in last hour │ │ │ - Daily cumulative amount │ │ │ - Beneficiary diversity │ ├─────────────────────┼───────────────────────────────────────────┤ │ Network Risk │ - Beneficiary account age │ │ │ - Beneficiary transaction patterns │ │ │ - Connection to known fraud accounts │ └─────────────────────┴───────────────────────────────────────────┘ Risk Score Calculation: score = w1*identity_score + w2*txn_score + w3*velocity_score + w4*network_score Where weights are tuned based on fraud case analysis.
Fraud Detection Architecture
Real-Time Fraud Detection System ───────────────────────────────────────────────────────────────── ┌─────────────────────────────────────────────────────────────────┐ │ TRANSACTION FLOW │ └────────────────────────────┬────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ FRAUD DETECTION ENGINE │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ STAGE 1: Real-Time Rules (< 50ms) │ │ ├── Hard blocks (blacklisted accounts, sanctioned entities) │ │ ├── Velocity checks (> N transactions in T minutes) │ │ ├── Amount thresholds (> daily limit) │ │ └── Device/IP blacklists │ │ │ │ STAGE 2: ML Scoring (< 100ms) │ │ ├── Feature extraction (100+ features) │ │ ├── Ensemble model prediction │ │ │ ├── Gradient Boosting (transaction patterns) │ │ │ ├── Neural Network (behavioral sequences) │ │ │ └── Isolation Forest (anomaly detection) │ │ └── Probability score output │ │ │ │ STAGE 3: Decision (< 10ms) │ │ ├── Score < 30: APPROVE │ │ ├── Score 30-70: APPROVE + FLAG │ │ ├── Score 70-90: STEP-UP AUTH (OTP, video KYC) │ │ └── Score > 90: DECLINE │ │ │ └─────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ POST-TRANSACTION ANALYSIS │ ├─────────────────────────────────────────────────────────────────┤ │ Near Real-Time (< 5 minutes) │ │ ├── Graph analysis (connections to fraud networks) │ │ ├── Pattern mining (emerging fraud patterns) │ │ └── Velocity aggregation across accounts │ │ │ │ Batch Analysis (Daily) │ │ ├── Account behavior profiling │ │ ├── Fraud ring detection │ │ └── Model retraining with new cases │ └─────────────────────────────────────────────────────────────────┘
Maker-Checker Control
Dual Authorization Flow ───────────────────────────────────────────────────────────────── For high-value or sensitive operations: MAKER (Transaction Creator) │ ├── Creates transaction ├── Enters all details ├── Submits for approval │ └── Transaction Status: PENDING_APPROVAL CHECKER (Authorizer) │ ├── Reviews transaction ├── Verifies details independently ├── Checks: │ ├── Amount accuracy │ ├── Beneficiary legitimacy │ ├── Supporting documentation │ └── Compliance requirements │ ├── Decision: │ ├── APPROVE → Transaction proceeds │ ├── REJECT → Transaction cancelled │ └── RETURN → Sent back to maker for correction │ └── Audit Trail: ├── Maker ID, timestamp ├── Checker ID, timestamp ├── Action taken └── Comments/reason Segregation Rules: ├── Maker ≠ Checker (different persons) ├── Maker cannot approve own transactions ├── Checker cannot create and approve └── Audit trail immutable
Transaction Limits Architecture
Limit Hierarchy ───────────────────────────────────────────────────────────────── ┌─────────────────────────────────────────────────────────────────┐ │ LEVEL 1: Regulatory Limits (RBI Mandated) │ │ ├── UPI: ₹1 Lakh per transaction │ │ ├── IMPS: ₹5 Lakh per transaction │ │ ├── LRS: $250,000 per year per individual │ │ └── Cash withdrawal: ₹2 Lakh/day (PAN required > ₹50K) │ └─────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ LEVEL 2: Bank-Level Limits (Bank Policy) │ │ ├── UPI daily: ₹1 Lakh (can be lower than RBI max) │ │ ├── NEFT/RTGS daily: Based on account type │ │ └── International: Based on customer segment │ └─────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ LEVEL 3: Account-Level Limits (Customer Specific) │ │ ├── Based on KYC level (min KYC vs full KYC) │ │ ├── Based on account vintage │ │ ├── Based on relationship value │ │ └── Based on risk profile │ └─────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ LEVEL 4: Channel/Device Limits (Security Layer) │ │ ├── New device: Lower limits for first 24 hours │ │ ├── New beneficiary: ₹25K first transaction │ │ └── Night hours (11PM-7AM): Reduced limits │ └─────────────────────────────────────────────────────────────────┘ Limit Check Flow: transaction_amount <= MIN( regulatory_limit, bank_limit, account_limit, channel_limit, available_balance )
Chapter 9: Failure Scenarios
What happens when things go wrong.
UPI Failure Scenarios
Scenario 1: Debit Success, Credit Timeout ───────────────────────────────────────────────────────────────── Timeline: T+0ms: Rahul initiates ₹1,000 UPI to Priya T+50ms: HDFC (Rahul's bank) debits ₹1,000 → SUCCESS T+100ms: NPCI forwards to ICICI (Priya's bank) T+30sec: ICICI doesn't respond (timeout) System State: ┌─────────────────────────────────────────────────────────────────┐ │ Rahul's Account: Debited ₹1,000 ✓ │ │ Priya's Account: NOT credited (timeout) │ │ Transaction Status: UNCERTAIN │ └─────────────────────────────────────────────────────────────────┘ Resolution Process: IMMEDIATE (T+30s to T+60s): ├── NPCI marks transaction as "DEEMED" ├── Initiates automatic reversal request to HDFC ├── HDFC receives reversal request HDFC ACTION: ├── Check: Was original debit successful? YES ├── Check: Was credit confirmed? NO (timeout) ├── Action: Reverse the debit │ │ BEGIN TRANSACTION; │ UPDATE accounts SET balance = balance + 1000 │ WHERE account_no = 'Rahul_Account'; │ INSERT INTO transactions ( │ reference, type, amount, status │ ) VALUES ( │ 'TXN123-REV', 'REVERSAL', 1000, 'SUCCESS' │ ); │ COMMIT; CUSTOMER EXPERIENCE: ├── Immediate: "Transaction pending" ├── After 30-60 seconds: "Transaction failed, amount reversed" ├── Worst case: Manual resolution within 24-48 hours RECONCILIATION: ├── End of day: NPCI settlement file excludes this transaction ├── Bank reconciliation: Matches debit with reversal └── Net effect: Zero
Scenario 2: NPCI Switch Failure ───────────────────────────────────────────────────────────────── Timeline: T+0ms: Rahul initiates transaction T+50ms: Request reaches NPCI T+51ms: NPCI switch infrastructure failure Impact: ├── Thousands of transactions affected simultaneously ├── Banks cannot communicate via UPI ├── No debit/credit happens (fail-safe) Bank Response: ┌─────────────────────────────────────────────────────────────────┐ │ 1. Detect NPCI connectivity loss (heartbeat failure) │ │ 2. Circuit breaker activates │ │ 3. New transactions queued (not debited) │ │ 4. Retry mechanism with exponential backoff │ │ 5. Customer informed: "UPI temporarily unavailable" │ └─────────────────────────────────────────────────────────────────┘ Recovery: ├── NPCI restores service ├── Banks receive "all clear" signal ├── Queued transactions processed ├── Failed transactions auto-reversed RBI Reporting: ├── P1 incident report within 2 hours ├── Root cause analysis within 24 hours └── Preventive measures documented
Scenario 3: Bank CBS Downtime ───────────────────────────────────────────────────────────────── HDFC CBS goes down at 3 PM. Affected Operations: ├── Cannot process incoming UPI credits ├── Cannot process outgoing UPI debits ├── Balance inquiries fail ├── All channels affected (mobile, net banking, ATM) Immediate Actions: ┌─────────────────────────────────────────────────────────────────┐ │ 1. DR (Disaster Recovery) activation assessment │ │ - If planned maintenance: Normal, wait │ │ - If unplanned: Initiate DR switchover │ │ │ │ 2. NPCI notification │ │ - Inform NPCI of unavailability │ │ - NPCI routes traffic to DR or queues │ │ │ │ 3. Customer communication │ │ - SMS/notification about outage │ │ - Expected resolution time │ │ │ │ 4. Transaction handling │ │ - Incoming: Queued at NPCI │ │ - Outgoing: Fail at bank gateway │ │ - No debits = No stuck funds │ └─────────────────────────────────────────────────────────────────┘ Post-Recovery: ├── Process queued transactions ├── Reconcile all pending items ├── Identify any stuck transactions └── Customer communication on resolution
Auto-Reversal Mechanism
T+1 Auto-Reconciliation and Reversal ───────────────────────────────────────────────────────────────── Daily Batch Process (runs at 2 AM): ┌─────────────────────────────────────────────────────────────────┐ │ SELECT │ │ txn_id, source_account, amount, status │ │ FROM upi_transactions │ │ WHERE │ │ txn_date = CURRENT_DATE - 1 │ │ AND debit_status = 'SUCCESS' │ │ AND credit_status IN ('PENDING', 'TIMEOUT', 'FAILED') │ │ AND reversal_status IS NULL; │ └─────────────────────────────────────────────────────────────────┘ For each unresolved transaction: ┌─────────────────────────────────────────────────────────────────┐ │ 1. Query NPCI for final status │ │ - If NPCI says SUCCESS: Mark as complete, no action │ │ - If NPCI says FAILED: Initiate reversal │ │ - If NPCI says UNKNOWN: Escalate for manual review │ │ │ │ 2. For reversals: │ │ BEGIN TRANSACTION; │ │ │ │ -- Credit back the customer │ │ UPDATE accounts │ │ SET balance = balance + amount │ │ WHERE account_no = source_account; │ │ │ │ -- Mark transaction as reversed │ │ UPDATE upi_transactions │ │ SET reversal_status = 'COMPLETED', │ │ reversal_time = NOW() │ │ WHERE txn_id = ?; │ │ │ │ -- Send notification to customer │ │ INSERT INTO notifications (...); │ │ │ │ COMMIT; │ │ │ │ 3. Generate exception report for manual review queue │ └─────────────────────────────────────────────────────────────────┘
Refund Flow Architecture
Customer-Initiated Refund vs Auto-Reversal ───────────────────────────────────────────────────────────────── AUTO-REVERSAL (System-initiated): ├── Trigger: Technical failure detected ├── Timeline: Minutes to 24 hours ├── Customer action: None required └── Flow: Bank detects failure → Auto-reverse → Notify customer CUSTOMER REFUND REQUEST (Dispute): ├── Trigger: Customer claims non-delivery of goods/service ├── Timeline: 7-45 days ├── Flow: ┌─────────────────────────────────────────────────────────────────┐ │ Day 1: Customer raises complaint │ │ ├── Via mobile app: "Dispute Transaction" │ │ ├── Via call center │ │ └── Via branch │ │ │ │ Day 1-3: Bank logs complaint │ │ ├── Generate complaint reference │ │ ├── Provisional credit (for cards, after 7 days) │ │ └── Initiate investigation │ │ │ │ Day 3-15: Investigation │ │ ├── Request merchant response │ │ ├── Collect transaction evidence │ │ └── Review delivery proof │ │ │ │ Day 15-45: Resolution │ │ ├── If merchant at fault: Refund customer │ │ ├── If customer at fault: Close complaint │ │ └── If disputed: Escalate to card network │ └─────────────────────────────────────────────────────────────────┘
Chapter 10: Real-World Architecture View
Putting it all together.
Complete UPI Transaction Architecture
End-to-End UPI Architecture ───────────────────────────────────────────────────────────────── ┌─────────────────────────────────────────────────────────────────────────┐ │ CUSTOMER LAYER │ ├─────────────────────────────────────────────────────────────────────────┤ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ PhonePe App │ │ GPay App │ │ Paytm App │ │ Bank's App │ │ │ │ (PSP: YBL) │ │ (PSP: AXIS) │ │ (PSP: PPB) │ │ (Direct) │ │ │ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │ │ │ │ │ │ │ │ └────────────────┴────────────────┴────────────────┘ │ │ │ │ └────────────────────────────────────┼────────────────────────────────────┘ │ HTTPS/TLS ▼ ┌─────────────────────────────────────────────────────────────────────────┐ │ PSP LAYER │ ├─────────────────────────────────────────────────────────────────────────┤ │ ┌─────────────────────────────────────────────────────────────────┐ │ │ │ PSP Backend (Yes Bank/Axis/Paytm) │ │ │ │ ├── API Gateway (rate limiting, auth) │ │ │ │ ├── UPI Service (transaction processing) │ │ │ │ ├── VPA Resolution Service │ │ │ │ └── Fraud Engine Integration │ │ │ └─────────────────────────────────────────────────────────────────┘ │ │ │ │ └────────────────────────────────────┼────────────────────────────────────┘ │ UPI Protocol (ISO 20022) ▼ ┌─────────────────────────────────────────────────────────────────────────┐ │ NPCI LAYER │ ├─────────────────────────────────────────────────────────────────────────┤ │ ┌─────────────────────────────────────────────────────────────────┐ │ │ │ NPCI UPI SWITCH │ │ │ │ │ │ │ │ ┌────────────────┐ ┌────────────────┐ ┌────────────────┐ │ │ │ │ │ Transaction │ │ VPA Directory │ │ Settlement │ │ │ │ │ │ Router │ │ Service │ │ Engine │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ Routes to │ │ Maps VPA to │ │ Calculates net │ │ │ │ │ │ correct bank │ │ bank + account │ │ positions │ │ │ │ │ └────────────────┘ └────────────────┘ └────────────────┘ │ │ │ │ │ │ │ │ ┌────────────────┐ ┌────────────────┐ ┌────────────────┐ │ │ │ │ │ Dispute │ │ Reconciliation │ │ Reporting │ │ │ │ │ │ Management │ │ Service │ │ Engine │ │ │ │ │ └────────────────┘ └────────────────┘ └────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────┘ │ │ │ │ └────────────────────────────────────┼────────────────────────────────────┘ │ Bank Integration Protocol ┌────────────────┴────────────────┐ ▼ ▼ ┌─────────────────────────────────┐ ┌─────────────────────────────────┐ │ REMITTER BANK │ │ BENEFICIARY BANK │ │ (HDFC) │ │ (ICICI) │ ├─────────────────────────────────┤ ├─────────────────────────────────┤ │ ┌───────────────────────────┐ │ │ ┌───────────────────────────┐ │ │ │ UPI Gateway │ │ │ │ UPI Gateway │ │ │ │ ├── Request validation │ │ │ │ ├── Request validation │ │ │ │ ├── VPA resolution │ │ │ │ ├── Account lookup │ │ │ │ └── Response handling │ │ │ │ └── Response handling │ │ │ └───────────────────────────┘ │ │ └───────────────────────────┘ │ │ │ │ │ │ │ │ ▼ │ │ ▼ │ │ ┌───────────────────────────┐ │ │ ┌───────────────────────────┐ │ │ │ Fraud Engine │ │ │ │ AML Engine │ │ │ │ ├── Rule evaluation │ │ │ │ ├── Sanctions check │ │ │ │ ├── ML scoring │ │ │ │ ├── Pattern analysis │ │ │ │ └── Decision │ │ │ │ └── STR flagging │ │ │ └───────────────────────────┘ │ │ └───────────────────────────┘ │ │ │ │ │ │ │ │ ▼ │ │ ▼ │ │ ┌───────────────────────────┐ │ │ ┌───────────────────────────┐ │ │ │ CORE BANKING (CBS) │ │ │ │ CORE BANKING (CBS) │ │ │ │ ├── Balance check │ │ │ │ ├── Account validation │ │ │ │ ├── Debit account │ │ │ │ ├── Credit account │ │ │ │ ├── Limits management │ │ │ │ ├── Limits update │ │ │ │ └── Transaction log │ │ │ │ └── Transaction log │ │ │ └───────────────────────────┘ │ │ └───────────────────────────┘ │ └─────────────────────────────────┘ └─────────────────────────────────┘ │ │ └────────────────┬─────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────────────┐ │ RBI SETTLEMENT │ ├─────────────────────────────────────────────────────────────────────────┤ │ ┌─────────────────────────────────────────────────────────────────┐ │ │ │ NPCI Settlement File → RBI │ │ │ │ │ │ │ │ Bank │ Net Position │ RBI Account Action │ │ │ │ ────────────────────────────────────────────────────────────── │ │ │ │ HDFC │ -₹100 Cr │ Debit ₹100 Cr │ │ │ │ ICICI │ +₹80 Cr │ Credit ₹80 Cr │ │ │ │ SBI │ +₹20 Cr │ Credit ₹20 Cr │ │ │ │ ────────────────────────────────────────────────────────────── │ │ │ │ Net │ ₹0 │ Balanced ✓ │ │ │ └─────────────────────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────────────┘
Settlement Timing Example
Day in the Life: UPI Settlement ───────────────────────────────────────────────────────────────── 00:00 - 01:00 (Window 1) ├── Transactions processed: 2.5 Crore ├── Total value: ₹15,000 Crores ├── Settlement at 01:00: │ HDFC: -₹1,200 Cr | ICICI: +₹800 Cr | SBI: +₹400 Cr 01:00 - 02:00 (Window 2) ├── Transactions: 1.8 Crore (lower, late night) ├── Value: ₹8,000 Crores ├── Settlement at 02:00 ... (continues hourly) 09:00 - 10:00 (Peak Morning) ├── Transactions: 8 Crore (office hours begin) ├── Value: ₹45,000 Crores ├── Settlement at 10:00 18:00 - 19:00 (Peak Evening) ├── Transactions: 12 Crore (highest) ├── Value: ₹65,000 Crores ├── Settlement at 19:00 23:00 - 00:00 (Day End) ├── Final settlement window ├── All positions netted ├── RBI accounts reflect final positions └── Reconciliation begins
Example Ledger Entries
Complete Ledger Trail for ₹1,000 UPI Transaction ───────────────────────────────────────────────────────────────── HDFC BANK (Remitter Side): ┌────────────────────────────────────────────────────────────────────────┐ │ Entry 1: Customer Account Debit │ │ ─────────────────────────────────────────────────────────────────────│ │ Account: Rahul Savings (12345678) │ │ Dr: ₹1,000 │ │ Narration: UPI/TXN123456/Priya@icici │ │ Balance After: ₹24,000 │ │ │ │ Entry 2: NPCI Settlement Account Credit │ │ ─────────────────────────────────────────────────────────────────────│ │ Account: NPCI Settlement Pool (Internal GL) │ │ Cr: ₹1,000 │ │ Reference: TXN123456 │ │ │ │ At Settlement Time: │ │ Entry 3: NPCI Settlement Account Debit │ │ ─────────────────────────────────────────────────────────────────────│ │ Account: NPCI Settlement Pool │ │ Dr: ₹1,000 (part of net settlement) │ │ │ │ Entry 4: RBI Account Credit (If HDFC is net receiver) │ │ OR RBI Account Debit (If HDFC is net payer) │ │ ─────────────────────────────────────────────────────────────────────│ │ Account: RBI Settlement Account │ │ Net movement based on aggregate position │ └────────────────────────────────────────────────────────────────────────┘ ICICI BANK (Beneficiary Side): ┌────────────────────────────────────────────────────────────────────────┐ │ Entry 1: NPCI Settlement Account Debit │ │ ─────────────────────────────────────────────────────────────────────│ │ Account: NPCI Settlement Pool (Internal GL) │ │ Dr: ₹1,000 │ │ Reference: TXN123456 │ │ │ │ Entry 2: Customer Account Credit │ │ ─────────────────────────────────────────────────────────────────────│ │ Account: Priya Savings (98765432) │ │ Cr: ₹1,000 │ │ Narration: UPI/TXN123456/From Rahul │ │ Balance After: ₹16,000 │ │ │ │ At Settlement Time: │ │ Entry 3: NPCI Settlement Account Credit │ │ ─────────────────────────────────────────────────────────────────────│ │ Account: NPCI Settlement Pool │ │ Cr: ₹1,000 (part of net settlement) │ │ │ │ Entry 4: RBI Account movement based on net position │ └────────────────────────────────────────────────────────────────────────┘ RBI BOOKS (Settlement): ┌────────────────────────────────────────────────────────────────────────┐ │ Net Settlement Entry (Hourly): │ │ ─────────────────────────────────────────────────────────────────────│ │ HDFC RBI Current Account: Dr ₹500 Cr (net payer this hour) │ │ ICICI RBI Current Account: Cr ₹300 Cr │ │ SBI RBI Current Account: Cr ₹200 Cr │ │ ─────────────────────────────────────────────────────────────────────│ │ Total: ₹0 (Balanced) │ └────────────────────────────────────────────────────────────────────────┘
Summary: Key Takeaways
How Money Actually Moves
Within-Bank: Database update (instant, no external party) Customer A → CBS → Customer B UPI/IMPS: Message routing + Net settlement Customer → Bank A → NPCI → Bank B → Customer Settlement: RBI (hourly/daily) NEFT: Batch processing + Deferred net settlement Transactions batched → NPCI → Net calculation → RBI Settlement: Every 30 minutes RTGS: Real-time gross settlement Each transaction settles immediately at RBI For high-value (>₹2L) SWIFT: Message network + Correspondent banking No direct settlement - uses Nostro/Vostro Settlement: Correspondent bank networks
Why Money Gets "Held"
1. Authorization Hold: Card pre-auth before actual settlement 2. Cheque Clearance: Waiting for presenting bank confirmation 3. Settlement Pending: Transaction done, RBI settlement awaited 4. Fraud Investigation: Transaction flagged for review 5. Regulatory Hold: AML/compliance investigation 6. Legal Attachment: Court order or tax authority freeze
The Regulatory Framework
RBI: Central bank, ultimate settlement, regulatory oversight NPCI: Retail payments infrastructure (UPI, IMPS, NEFT) CCIL: Wholesale/forex settlement FEMA: Cross-border transaction regulations PSS Act: Payment systems regulation
The Risk Controls
Layer 1: Transaction limits (per txn, daily, channel) Layer 2: Fraud detection (rules + ML) Layer 3: AML monitoring (patterns + thresholds) Layer 4: Sanctions screening (OFAC, UN, domestic) Layer 5: Maker-checker for high-value Layer 6: Reconciliation and exception handling
For Fintech Developers: Implementation Checklist
If you're building payment systems:
□ Implement idempotency (prevent duplicate transactions) □ Use database transactions with proper isolation □ Implement circuit breakers for external services □ Log everything (immutable audit trail) □ Handle timeouts gracefully (don't leave funds in limbo) □ Implement reconciliation from day one □ Build fraud rules engine early □ Design for reversals and refunds □ Monitor settlement positions real-time □ Test failure scenarios extensively □ Comply with RBI data localization requirements □ Implement proper encryption (at rest and in transit)
Conclusion
The Indian payment ecosystem is a marvel of distributed systems engineering. Behind every "Payment Successful" message lies a complex choreography of systems, regulations, and reconciliation processes working in harmony.
Understanding these internals isn't just academic—it's essential for anyone building financial systems. Whether you're designing a new fintech product, debugging a failed transaction, or preparing for a system design interview, knowing how money actually moves gives you the foundation to build reliable, compliant, and scalable payment infrastructure.
The next time you tap "Send," you'll know exactly what happens in those 2 seconds.
This guide reflects the Indian banking system as of 2024. Regulations and systems evolve—always refer to RBI and NPCI official documentation for current specifications.