Compliance & Security — Non-Negotiable in Fintech
Why Compliance Isn’t Optional
In fintech, security isn’t a “nice to have.” It’s regulated by law. Build an insecure payment system and your company faces:
- Fines (up to millions of dollars)
- Loss of ability to process payments
- Criminal liability
- Customer trust destroyed permanently
As an engineer, you need to know what rules exist and how they affect your code.
PCI-DSS — The Big One
PCI-DSS (Payment Card Industry Data Security Standard) — 12 requirements for anyone who stores, processes, or transmits card data.
In one picture — PCI scope is every system the raw card number touches. The whole game is shrinking that box. Let a gateway take the card and your own backend falls outside scope:
flowchart LR
subgraph IN["In PCI-DSS scope"]
GW["Payment gateway<br/>Razorpay or Stripe"]
NET["Card network<br/>and issuer"]
end
subgraph OUT["Out of scope"]
B["Your backend<br/>sees only a token"]
DB["Your database<br/>stores last 4 plus token"]
end
C["Cardholder<br/>enters card"] -->|raw card number| GW
GW -->|authorize| NET
GW -->|token only| B
B --> DB
Anything inside the In scope box must meet all 12 requirements and get audited. Anything that only ever sees a token is out of scope — which is why “never let card data touch your servers” is the first design rule in fintech.
The 12 Requirements (Simplified)
| # | Requirement | What It Means for Engineers |
|---|---|---|
| 1 | Install and maintain a firewall | Network segmentation. Card data zone isolated. |
| 2 | Don’t use vendor default passwords | Change defaults. Harden servers. |
| 3 | Protect stored cardholder data | Encrypt at rest. Mask PANs (show only last 4). |
| 4 | Encrypt transmission of card data | TLS everywhere. No HTTP for card data. |
| 5 | Use and update antivirus | Keep systems patched. |
| 6 | Develop secure systems | Secure coding practices. Code reviews. OWASP. |
| 7 | Restrict access on need-to-know | Role-based access. Least privilege. |
| 8 | Assign unique ID to each user | No shared accounts. Audit trails. |
| 9 | Restrict physical access | Server room access control. |
| 10 | Track and monitor all access | Logging. Audit trails. Alert on anomalies. |
| 11 | Regularly test security | Penetration testing. Vulnerability scans. |
| 12 | Maintain an information security policy | Documentation. Training. |
PCI-DSS Levels
| Level | Criteria | Audit Requirement |
|---|---|---|
| Level 1 | 6M+ transactions/year | On-site audit by QSA |
| Level 2 | 1M-6M transactions/year | Self-assessment + quarterly scans |
| Level 3 | 20K-1M e-commerce transactions | Self-assessment |
| Level 4 | Under 20K e-commerce | Self-assessment |
What This Means for Your Code
// NEVER do this
logger.info("Card number: " + cardNumber); // PCI violation
logger.info("CVV: " + cvv); // PCI violation — CVV must NEVER be stored
// DO this
logger.info("Card ending in: " + cardNumber.substring(cardNumber.length() - 4));
// Or better: don't handle card numbers at all — use tokenization
Best practice: Use a payment gateway (Razorpay, Stripe) that handles PCI compliance for you. Your backend never sees the full card number.
RBI Guidelines (India-Specific)
| Regulation | What | Impact on Engineers |
|---|---|---|
| Card-on-file tokenization | Merchants can’t store card numbers | Must use network tokens (Visa/MC token service) |
| Two-factor authentication | Online payments need 2FA (OTP/biometric) | Integrate 3D Secure for online card payments |
| Data localization | Payment data must be stored in India | Can’t use AWS us-east-1 for Indian payment data |
| Recurring payment rules | E-mandate required for auto-debit > Rs. 15,000 | Implement e-mandate flow for subscriptions |
| UPI autopay limits | Auto-debit limit Rs. 1 lakh (raised from 15K) | Validate limits in your code |
Security Patterns Every Fintech Engineer Must Know
1. Encryption at Rest and in Transit
At rest: Data in database → AES-256 encryption
In transit: Data between services → TLS 1.2+
Key management: AWS KMS or HashiCorp Vault (never hardcode keys)
2. Audit Trail — Everything Is Logged
Every financial operation must have an immutable audit trail:
@Entity
@Table(name = "audit_logs")
public class AuditLog {
@Id
private Long id;
private String action; // "PAYMENT_CREATED", "REFUND_INITIATED"
private String entityType; // "Payment", "User"
private Long entityId;
private String performedBy; // User ID
private String details; // JSON of what changed
private Instant timestamp;
// No UPDATE or DELETE operations allowed on this table
}
Rule: Audit logs are append-only. Nobody can edit or delete them.
3. Secrets Management
WRONG: application.properties
jwt.secret=mysupersecretkey123
WRONG: Environment variable in Dockerfile
ENV JWT_SECRET=mysupersecretkey123
RIGHT: External secrets manager
- AWS Secrets Manager
- HashiCorp Vault
- Even just environment variables set at deployment time (not in code)
4. Input Validation — Trust Nothing
// ALWAYS validate at the boundary
public ResponseEntity<?> createPayment(@Valid @RequestBody PaymentRequest request) {
// @Valid triggers Bean Validation
// But also validate business rules:
if (request.amount().compareTo(BigDecimal.ZERO) <= 0) {
throw new InvalidAmountException();
}
if (request.amount().scale() > 2) {
throw new InvalidPrecisionException(); // No sub-paise amounts
}
}
5. Rate Limiting on Sensitive Endpoints
| Endpoint | Rate Limit | Why |
|---|---|---|
/auth/login | 5/minute per IP | Brute force prevention |
/payments | 10/second per user | Prevent duplicate charges |
/auth/forgot-password | 3/hour per email | Email bombing prevention |
OWASP Top 10 — Know These
| # | Vulnerability | Fintech Impact | Prevention |
|---|---|---|---|
| 1 | Broken Access Control | User A sees User B’s transactions | Test authorization on every endpoint |
| 2 | Cryptographic Failures | Card data exposed | TLS + AES-256 + proper key management |
| 3 | Injection (SQL/NoSQL) | Attacker dumps your database | Parameterized queries (JPA does this) |
| 4 | Insecure Design | Weak business logic | Threat modeling before building |
| 5 | Security Misconfiguration | Debug mode in production | Security hardening checklist |
Interview Questions
- “What is PCI-DSS and how does it affect your code?”
- “How would you store sensitive financial data?”
- “What’s the difference between encryption at rest and in transit?”
- “Why can’t you store CVV numbers?” (PCI explicitly prohibits it, even encrypted)
- “How do you prevent SQL injection in a Spring Boot application?”
- “What’s an audit trail and why does fintech need it?”
Module done? Add it to today’s tracker