Introduction
In FinTech, compliance is not a "nice-to-have" — it is mandatory. A payment platform must comply with a series of security, privacy, and reporting regulations. Violations can result in millions of dollars in fines, loss of licenses, and loss of customer trust.
1. PCI-DSS — Payment Card Industry Data Security Standard
1.1 Overview of PCI-DSS
PCI-DSS is a mandatory security standard for any organization that processes, stores, or transmits payment card data.
PCI-DSS v4.0 (2024+) — 12 Requirements:
├── Build & Maintain Secure Network
│ ├── 1. Firewall configuration
│ └── 2. No vendor-supplied defaults
├── Protect Cardholder Data
│ ├── 3. Protect stored data
│ └── 4. Encrypt transmission
├── Vulnerability Management
│ ├── 5. Anti-malware
│ └── 6. Secure development
├── Access Control
│ ├── 7. Restrict access (need-to-know)
│ ├── 8. Unique IDs for access
│ └── 9. Physical access control
├── Monitoring & Testing
│ ├── 10. Track & monitor access
│ └── 11. Regular security testing
└── Security Policy
└── 12. Information security policy
1.2 PCI-DSS Compliance Levels
| Level | Criteria | Request |
|---|---|---|
| Level 1 | >6M transactions/year | Annual on-site audit (QSA) |
| Level 2 | 1M-6M transactions/year | Annual SAQ, Quarterly scan |
| Level 3 | 20K-1M transactions/year | Annual SAQ, Quarterly scan |
| Level 4 | <20K transactions/year | Annual SAQ |
1.3 Design of PCI-DSS Compliant system
┌─────────────────────────────────────────────────────┐
│ PCI-DSS SCOPE │
│ ┌─────────────────────────────────────────────┐ │
│ │ Cardholder Data Environment (CDE) │ │
│ │ │ │
│ │ ┌──────────┐ ┌──────────┐ ┌─────────┐ │ │
│ │ │ Payment │ │ HSM │ │Tokenizer│ │ │
│ │ │ Service │ │ │ │ │ │ │
│ │ └──────────┘ └──────────┘ └─────────┘ │ │
│ │ │ │
│ │ Network Segmentation (VLAN/Firewall) │ │
│ └─────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────┐ │
│ │ Connected Systems (Reduced Scope) │ │
│ │ ┌──────────┐ ┌──────────┐ │ │
│ │ │ API GW │ │ Logging │ │ │
│ │ └──────────┘ └──────────┘ │ │
│ └─────────────────────────────────────────────┘ │
│ │
│ Out of Scope: Wallet Service, Reporting, etc. │
│ (if properly segmented) │
└─────────────────────────────────────────────────────┘
Strategy: Minimize PCI scope with tokenization — replace card data with tokens immediately, other services only process tokens.
1.4 Tokenization Flow
Customer ─── PAN: 4111...1111 ───► Tokenizer ─── Token: tok_abc123 ──►
│
┌────▼────┐
│ HSM │ (Hardware Security Module)
│ Encrypt │
│ & Store │
└─────────┘
Everywhere else in the system: only tok_abc123 is used
PAN never leaves the CDE (Cardholder Data Environment)
2. PSD2 and Open Banking
2.1 PSD2 — Payment Services Directive 2
PSD2 is an EU directive requiring banks to open APIs to third-parties:
PSD2 Key Requirements:
├── Strong Customer Authentication (SCA)
│ ├── Knowledge (password, PIN)
│ ├── Possession (phone, token)
│ └── Inherence (biometrics)
│ → At least 2 of 3 factors required
│
├── Open Banking APIs
│ ├── Account Information Service (AIS)
│ ├── Payment Initiation Service (PIS)
│ └── Card-Based Payment Instrument (CBPII)
│
└── Consumer Protection
├── Reduced liability for unauthorized transactions
├── No surcharges for card payments
└── Faster complaint resolution
2.2 3D Secure 2 (3DS2) — SCA Implementation
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ Customer │ │ Merchant │ │ Card │ │ Issuer │
│ │ │ (PSP) │ │ Network │ │ Bank │
└────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘
│ │ │ │
│ Checkout │ │ │
├─────────────►│ │ │
│ │ 3DS Auth │ │
│ ├─────────────►│ │
│ │ │ Auth Req │
│ │ ├─────────────►│
│ │ │ │
│ │ │ Risk-based │
│ │ │ Decision │
│ │ │◄─────────────┤
│ │ │ │
│ Challenge (if needed) │ │
│◄────────────────────────────┤ │
│ OTP/Biometric │ │
├────────────────────────────►│ │
│ │ │ │
│ │ Auth Result │ │
│ │◄─────────────┤ │
│ Result │ │ │
│◄─────────────┤ │ │
3. Regulations of the State Bank of Vietnam
3.1 Legal framework
Hệ thống quy định FinTech tại Việt Nam:
├── Luật Ngân hàng Nhà nước (2010)
├── Luật Các tổ chức tín dụng (2024, sửa đổi)
├── Luật Giao dịch điện tử (2023)
├── Nghị định 101/2012 về thanh toán không dùng tiền mặt
│ └── Nghị định 35/2023 (sửa đổi)
├── Thông tư 39/2014 về trung gian thanh toán
├── Thông tư 23/2022 về dịch vụ ví điện tử
└── Sandbox FinTech (Nghị định 13/2023)
3.2 Requirements for eWallets
| Request | Content |
|---|---|
| License | Must be licensed by the State Bank of Vietnam as a payment intermediary |
| Charter capital | Minimum 50 billion VND |
| KYC | Identity verification via CCCD/eKYC |
| Limit | Unverified wallet: 10 million. Verified: 100 million |
| Link | Must be linked to a bank account |
| Report | Periodic reporting to the State Bank |
| Archive | Store transactions for a minimum of 10 years |
| Safe | Comply with SBV information security standards |
3.3 eKYC Requirements
eKYC Flow (theo quy định NHNN):
├── 1. Thu thập thông tin
│ ├── CCCD (Căn cước công dân gắn chip)
│ ├── NFC đọc chip CCCD
│ └── Video call / Liveness detection
├── 2. Xác minh
│ ├── OCR trích xuất thông tin CCCD
│ ├── Face matching (ảnh CCCD vs selfie)
│ ├── Liveness check (chống giả mạo)
│ └── Cross-check với CSDL quốc gia
├── 3. Phân loại rủi ro
│ ├── Low risk: Giao dịch < 10 triệu
│ ├── Medium risk: 10-100 triệu
│ └── High risk: > 100 million (need further verification)
└── 4. Storage & Reporting
├── Storing KYC records >= 5 years
└── Report to SBV according to regulations
4. Compliance Architecture
4.1 Compliance-by-Design Principles
┌──────────────────────────── ─────────────────────────────┐
│ COMPLIANCE-BY-DESIGN │
├──────────────────────────── ─────────────────────────────┤
│ │
│ 1. Data Minimization │
│ → Only collect necessary data │
│ │
│ 2. Encryption Everywhere │
│ → At rest (AES-256), In transit (TLS 1.3) │
│ │
│ 3. Audit Trail │
│ → Immutable logs for all changes │
│ │
│ 4. Access Control │
│ → RBAC + need-to-know principle │
│ │
│ 5. Data Retention │
│ → Policy-driven retention & deletion │
│ │
│ 6. Consent Management │
│ → Explicit consent, easy withdrawal │
│ │
└──────────────────────────── ─────────────────────────────┘
4.2 Audit Trail Design
-- Immutable audit log table
CREATE TABLE audit_log (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
timestamp TIMESTAMPTZ NOT NULL DEFAULT NOW(),
actor_id UUID NOT NULL,
actor_type VARCHAR(50) NOT NULL, -- 'user', 'system', 'admin'
action VARCHAR(100) NOT NULL,
resource_type VARCHAR(100) NOT NULL,
resource_id UUID NOT NULL,
old_value JSONB,
new_value JSONB,
ip_address INET,
user_agent TEXT,
correlation_id UUID NOT NULL,
-- No UPDATE or DELETE allowed
CHECK (action IN ('CREATE', 'UPDATE', 'DELETE', 'READ', 'EXPORT'))
);
-- Append-only: revoke UPDATE and DELETE
REVOKE UPDATE, DELETE ON audit_log FROM app_user;
5. Compliance Monitoring & Reporting
5.1 Automated Compliance Checks
compliance_checks:
pci_dss:
- name: "Encryption at rest"
check: "All databases use AES-256 encryption"
frequency: daily
- name: "Access logging"
check: "All CDE access is logged"
frequency: real-time
- name: "Vulnerability scan"
check: "ASV scan completed"
frequency: Quarterly
nhnn:
- name: "Transaction limits"
check: "Wallet limits enforced"
frequency: real-time
- name: "KYC verification"
check: "All users verified before limit increase"
frequency: on-event
- name: "Regulatory reporting"
check: "Monthly reports submitted"
frequency: monthly
Summary
Compliance in FinTech is an indispensable foundation. Key takeaways:
- PCI-DSS: Minimize scope by tokenization, network segmentation
- PSD2/SCA: 3D Secure 2 for Strong Customer Authentication
- SBV of Vietnam: eKYC, wallet limit, periodic reports
- Design principles: Data minimization, encryption, audit trails
Next article: We will start building Payment Gateway Architecture — end-to-end payment flow from checkout to settlement.