Fintech Domain Knowledge

If you're interviewing for Stripe, Plaid, Square, or any neo-bank, domain knowledge gives you a massive edge. Engineering in fintech requires paranoia about accuracy, idempotency, and security.

1. Money Representation & Math

NEVER use floating-point numbers (float32/float64) for money. Floating point math is imprecise (e.g., 0.1 + 0.2 = 0.30000000000000004). If you truncate that over millions of transactions, you lose real money.

• Integer Cents/Paise: The most common approach. Store $10.50 as 1050 (integer). Only format it with a decimal on the frontend.
• Big Decimal Libraries: If you need to calculate complex interest rates with 8 decimal places of precision, use arbitrary-precision decimal libraries (e.g., shopspring/decimal in Go, BigDecimal in Java).
• Banker's Rounding: "Round half to even". Standard rounding (round .5 up) creates a positive bias over large datasets. Banker's rounding rounds 2.5 to 2, and 3.5 to 4.

2. Idempotency (Critical)

Network calls fail. If a client sends a "Charge $100" request and the connection drops before the server replies, the client will retry. Without idempotency, the user gets charged $200.

• Client generates a unique UUID (Idempotency-Key) and includes it in the HTTP header.
• Server checks if it has seen this key in its database.
• If NO: Process the payment, save the result tied to the key, return 200.
• If YES: Do not process the payment. Fetch the saved result for that key and return 200.

3. Double-Entry Accounting (The Ledger)

Money is never "created" or "destroyed", it only moves. Every transaction requires at least two ledger entries: a Debit (Dr) and a Credit (Cr) that must balance to zero.

-- Moving $50 from Alice to Bob
BEGIN;
INSERT INTO ledger (tx_id, account, type, amount) VALUES ('tx1', 'Alice', 'DEBIT', 5000);
INSERT INTO ledger (tx_id, account, type, amount) VALUES ('tx1', 'Bob', 'CREDIT', 5000);
COMMIT;

Immutability: You NEVER UPDATE a ledger row. If a mistake was made, you insert a reversing transaction to undo it. This creates a perfect audit trail.

4. Compliance & Security

• PCI-DSS: Standard for handling credit cards. It is extremely rigorous. Most startups avoid it entirely by using "Tokens" from Stripe/Braintree. The raw PAN (Primary Account Number) never touches their servers.
• KYC / AML: Know Your Customer / Anti-Money Laundering. Regulations requiring you to verify identity (ID scans, SSN/PAN checks) before allowing money movement to prevent funding terrorism or crime.
• PII (Personally Identifiable Information): SSNs, birth dates. Must be encrypted at rest (AES-256). Should be masked in application logs (e.g., ***-**-1234).
• Audit Logs: Every action an admin takes (e.g. refunding a user) must be logged immutably to a separate system.

5. Webhook Security

When a payment gateway (like Stripe) notifies you asynchronously that a payment succeeded, you must secure the webhook endpoint:

1. HMAC Signatures: The provider signs the payload with a shared secret. You must verify the signature to prove the request actually came from them, not a hacker.
2. Replay Attacks: Providers include a timestamp in the header. Reject webhooks older than 5 minutes.
3. Async Processing: Acknowledge the webhook immediately (return 200 OK), then process the business logic in a background queue. If you block, the provider might time out and retry.

6. Common Fintech Systems

• Reconciliation Engine (Recon): Internal ledger says we have $1M. Bank statement says we have $990k. The recon engine runs nightly, matching internal DB records against flat files (CSV/SFTP) provided by the bank to find the missing $10k.
• Fraud / Risk Engine: Evaluates incoming transactions against ML models or rulesets (e.g., Velocity checks: "Has this user made 10 transactions in 1 minute?"). Must execute in <100ms.
• Lending / EMI: Handling amortization schedules, grace periods, late fees, and compounding interest.

7. Payment Processing Flows

Understanding how money actually moves between systems is critical.

Card Payment Flow

1. Customer: Enters card details on checkout page (tokenized by Stripe.js/Razorpay SDK — raw PAN never touches your server).
2. Payment Gateway: (Stripe, Razorpay) receives the token, routes to the card network.
3. Card Network: (Visa, Mastercard) routes the authorization request to the issuing bank.
4. Issuing Bank: Approves or declines based on available balance, fraud checks, 3DS verification.
5. Authorization: An authorization hold is placed on the customer's account. Money hasn't moved yet.
6. Capture: The merchant captures the payment (immediately or later for hotel-style pre-auths). Now settlement begins.
7. Settlement: The acquiring bank transfers funds to the merchant's bank account (T+1 to T+3 days typically).

Key distinction: Authorization ≠ Capture. A pre-auth (like a hotel hold) authorizes $500 but only captures the actual charge of $320 at checkout.

UPI (India-specific — Unified Payments Interface)

UPI is a real-time payment system developed by NPCI. It's essentially a wrapper over IMPS that allows instant bank-to-bank transfers using a Virtual Payment Address (VPA) like user@upi.

8. Subscription & Recurring Billing

• Trial Periods: Time-limited free access. Must handle conversion to paid, cancellation, and trial extension.
• Proration: When a user upgrades mid-cycle (e.g., Basic → Premium), charge only the remaining days difference. This is complex math — most use Stripe/Chargebee for it.
• Dunning: When a recurring charge fails (card expired, insufficient funds), the system retries on a schedule (day 1, day 3, day 5) and notifies the user. After N failures, subscription is paused/cancelled.
• Grace Period: Time after payment failure where the user retains access while dunning retries.
• Invoicing: Legal requirement. Each charge must generate an invoice with tax details (GST in India, VAT in EU).

9. Regulatory Awareness

• RBI Guidelines (India): Data localization (all payment data stored in India), tokenization mandates (no card data storage by merchants), cooling-off periods for investments.
• GDPR (Europe): Right to erasure, consent management, data portability. Fines up to 4% of global revenue.
• SOC 2: An audit standard for service organizations. Type I = controls design at a point in time. Type II = controls effectiveness over 6-12 months. Most B2B fintech companies need this.
• Open Banking: Banks expose APIs (PSD2 in Europe, Account Aggregator in India) allowing third parties to access account data with user consent. Enables apps like 1Finance to aggregate financial data.

10. Fintech Architecture Principles

• Eventual consistency is acceptable for reads, but NEVER for money: The user's dashboard balance can be eventually consistent. The ledger MUST be strongly consistent.
• Exactly-once delivery is a myth in distributed systems: Design for at-least-once delivery + idempotency. Kafka consumers must handle duplicate messages.
• Shadow/Dry-run mode: Before going live, run new financial logic in parallel with old logic. Compare outputs. Only switch once they match for 99.99% of cases.
• Retry with dead-letter queues: Failed payment webhooks go to a DLQ for manual investigation. Never silently drop financial events.
• Immutable audit trail: Append-only tables for all state changes. Never UPDATE or DELETE financial records. Use reversal transactions instead.

Interview Quick Reference