Introduction:
Fintech has stopped being a category and become an expectation. Consumers assume instant payments. Regulators assume real-time monitoring. Banks assume API-based data sharing. The McKinsey 2026 research on the next era of fintech places worldwide fintech revenue at approximately $650 billion in 2025, projected to reach $2 trillion by 2030. That growth trajectory is built on engineering infrastructure that must be simultaneously fast, compliant, and resilient.
Product engineering for fintech is not general software engineering with compliance added at the end. It is a discipline in which compliance architecture, payment infrastructure design, and security engineering are first-class concerns from the first sprint. Fintechs that treat compliance as a documentation exercise discover, usually during their first audit or bank sponsor review, that the remediation cost dwarfs the cost of getting it right at the start.
"PCI-DSS is the floor. Every fintech build in 2026 layers regional overlays on top: NYDFS in the US, PSD2 and DORA in the EU. Treating compliance as a questionnaire is how fintech engineering teams fail their first audit."
Why Fintech Product Engineering Is a Specialised Discipline
Domain-specific failure modes demand domain-specific engineering expertise:
• A race condition in a ledger update produces a financial discrepancy requiring regulatory disclosure
• Missed Strong Customer Authentication logic results in PSD2 non-compliance — the product cannot legally operate in the EU
• An incorrectly scoped PCI-DSS cardholder data environment results in a failed audit and potential card brand sanctions
• An AML model that cannot explain its flagging decisions creates regulatory exposure under explainability requirements
• A payment API without rate limiting enables card testing attacks that expose the platform to chargeback liability
The Compliance Stack Every Fintech Must Navigate
Framework | What It Governs | Engineering Obligations | Consequence of Non-Compliance |
PCI-DSS v4.0 | Payment card data security | Network segmentation, tokenization, encryption, audit logging; continuous validation | Fines $5,000–$100,000/month; loss of card processing |
KYC/AML (BSA) | Customer identity verification; financial crime prevention | Real-time screening; explainable model outputs; SAR filing automation | Regulatory sanctions; criminal exposure for officers |
SOC 2 Type II | Security, availability, confidentiality controls | Continuous monitoring; auditable controls; vendor management programme | Required for enterprise B2B sales |
PSD2/SCA (EU) | Payment services and open banking | Strong Customer Authentication; FAPI APIs; consent management | Cannot legally process EU payments |
DORA (EU, 2025) | Digital operational resilience | ICT risk management; incident reporting; resilience testing | Applies to all ICT providers to EU financial entities |
CFPB Section 1033 (US) | Consumer financial data access rights | Open banking API; consumer data portability | Federal law since 2024; financial penalties |
GDPR | Personal data of EU residents | Data minimisation, consent, right to erasure, DPIAs | Up to 4% of global annual revenue |
PCI-DSS Architecture: Scope Reduction First
The most important PCI-DSS engineering decision is how to minimise the Cardholder Data Environment (CDE) scope. Every system that stores, processes, or transmits cardholder data is in scope. Scope reduction strategies:
• Tokenization: replace PANs with non-sensitive tokens at the earliest possible point in the payment flow — downstream systems are removed from PCI scope
• Network segmentation: isolate the CDE using firewall rules and separate network segments — systems outside the CDE are not in scope
• No PAN storage: design so cardholder data is never stored in application databases — use a PCI-compliant payment processor
• Hosted payment page: handle card entry through a PCI-certified iframe or redirect — keeping card data outside your application scope entirely
• Policy-as-code: implement PCI controls as infrastructure-as-code templates validated in CI/CD — compliance by construction, not post-deployment audit
Real-Time Payments and High-Availability Architecture
Requirement | Engineering Implementation | Consequence If Absent |
Sub-second payment processing | Event-driven architecture; message queues (Kafka); async pipelines | Payments queue; user experience degrades |
99.99% availability | Multi-region deployment; active-active failover; circuit breakers | Downtime costs users; regulatory SLA violations |
Horizontal scaling | Stateless service design; containerization; Kubernetes | Cannot scale to peak load; costs non-linear |
Idempotency | Idempotency keys on all operations; deduplication logic | Duplicate transactions; financial discrepancies |
Audit trail | Immutable event log; tamper-evident storage | Cannot satisfy regulatory reporting requirements |
Fraud detection | ML inference in <50ms; model serving; feature store | Fraud signals arrive after approval; loss exposure grows |
KYC/AML Integration
KYC and AML are legal requirements for any fintech handling money movement or account opening. In 2026, regulators expect real-time screening with explainable outputs:
• Identity verification: integrate with providers (Jumio, Onfido, Stripe Identity) for document verification, liveness detection, and sanctions screening at account opening
• Ongoing transaction monitoring: continuous screening of transaction patterns against risk models at sub-second latency
• Explainable model outputs: AML flagging decisions must produce human-readable explanations — black-box models create regulatory exposure
• SAR filing automation: generate Suspicious Activity Reports automatically from flagged transaction data
• Data retention: KYC documentation retained for minimum 5 years with full audit trail
Open Banking and API-First Design
Open banking — regulatory frameworks requiring financial institutions to share customer data via APIs — is a legal requirement in the EU (PSD2) and US (CFPB Section 1033). FAPI (Financial-grade API) defines the security requirements: OAuth 2.0 and OpenID Connect with PKCE, mutual TLS, and request object signing.
