Fintech founders move fast by necessity. Regulatory windows open and close. Market timing is competitive. The temptation to defer compliance infrastructure — "we'll get SOC 2 after we close the seed round," "we'll do PCI DSS once we have the enterprise customer asking for it" — is understandable and almost always wrong. The compliance surface in financial software is not a separate workstream from the product surface. It is the same surface. Building a payment system without PCI DSS controls is not building a payment system you'll harden later — it is building the wrong system.

This piece covers the specific security and regulatory requirements that shape the architecture of fintech software: which compliance frameworks apply, what they require technically, and the patterns that make compliance a product feature rather than a bolt-on. For the adjacent question of what your MVP needs to validate product-market fit before you build out the full compliance surface, read Building an MVP That Scales first.

The compliance landscape: which frameworks apply and when

The regulatory framework for a fintech product depends on what the product does and where it operates. PCI DSS (Payment Card Industry Data Security Standard) applies to any system that processes, stores, or transmits cardholder data — which in practice means any product that handles credit or debit card payments. PCI DSS Level 1 (more than 6 million transactions per year) requires an annual on-site assessment; lower levels require a Self-Assessment Questionnaire (SAQ), but the technical controls are largely the same.

SOC 2 Type II — a security audit standard from the American Institute of CPAs — is increasingly required by enterprise customers and investors. Unlike PCI DSS, which specifies technical controls, SOC 2 evaluates against five Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. SOC 2 Type II covers a period (typically 6-12 months) rather than a point in time, which means the controls must be consistently applied across the audit window. Starting SOC 2 readiness eighteen months before you expect an enterprise prospect to request the report is not excessive.

Secure architecture patterns for financial software

The two most common security architecture failures in fintech software are: storing sensitive financial data (card numbers, account numbers, routing numbers) in application databases alongside non-sensitive data, and using a single service account with broad database permissions rather than least-privilege access by service. Both are fast to build and expensive to fix.

For payment card data, the correct pattern is to never touch raw card data at all if possible. Using a payment processor's tokenization (Stripe, Adyen, Braintree) moves the PCI DSS scope from SAQ D (the most demanding) to SAQ A or SAQ A-EP, dramatically reducing the compliance surface. The processor handles the raw card data; your system stores only a token. The tradeoff is dependency on the processor's API and pricing, but for most fintech products the trade is obviously correct.

For account and routing numbers, which payment processors do not necessarily abstract, the correct pattern is encryption at the application layer before database storage — not relying solely on database-level encryption. The encryption key should live in a hardware security module (HSM) or a managed key management service (AWS KMS, GCP Cloud KMS), not in the application code or the same database as the encrypted data.

Transaction monitoring and fraud detection

AML and fraud detection are not the same problem, but they share infrastructure. AML transaction monitoring looks for patterns that indicate money laundering or structuring — unusual transaction amounts, unusual counterparty patterns, transactions to high-risk jurisdictions. Fraud detection looks for patterns that indicate the account has been taken over or that the transaction is not being made by the legitimate account holder.

Custom rule engines — velocity checks, threshold alerts, counterparty screening against OFAC lists — are feasible to build for specific product use cases. For products with high transaction volume or complex pattern requirements, integrating a specialized fraud platform (Sardine, Unit21, Sift) gives access to cross-network signals that a single-product rule engine cannot generate. The integration architecture matters: fraud signals should be evaluated before transactions are settled, not after, which requires synchronous scoring in the payment flow rather than asynchronous batch processing.

Every compliance requirement in fintech is also a product feature. The SOC 2 report that closes the enterprise deal, the AML controls that keep your banking partner, the encryption that makes the enterprise security questionnaire possible — compliance is what makes fintech products enterprise-ready.

Why fintech builds require a different kind of engineering partner

Fintech software requires engineers who understand both the technical implementation and the regulatory context — not just "build a payment system" but "build a payment system that satisfies PCI DSS SAQ A-EP, handles AML monitoring under FinCEN guidance, and produces the SOC 2 Type II evidence your auditor will need." Ravve Jay Prevendido and the TTGC team bring this dual context to financial software builds. See custom software for healthcare for a parallel regulated-industry case, and connect at /growth-assessment to discuss your fintech build.