## Building for FinTech: PCI DSS and SOC 2 Compliance Guide

Building financial technology means navigating a maze of compliance requirements. Two acronyms dominate the conversation: **PCI DSS** (for payment card security) and **SOC 2** (for overall security practices).

These frameworks feel overwhelming, but they're not insurmountable. Understanding what's actually required helps you build compliant systems without drowning in paperwork or blowing your budget.

---

### Quick Answer: What You Actually Need

**PCI DSS applies** if you handle, process, or transmit credit card data. Even if you use a payment processor like Stripe, some requirements still apply.

**SOC 2 is often required** by enterprise customers and investors to demonstrate you have proper security controls in place.

The good news: using modern payment processors (Stripe, Braintree, Adyen) significantly reduces your PCI burden. And SOC 2 compliance is achievable with the right approach and tools.

---

### PCI DSS: The Payment Card Industry Data Security Standard

#### What is PCI DSS?

PCI DSS is a set of security standards designed to ensure that all companies that accept, process, store, or transmit credit card information maintain a secure environment. It's enforced by the major card brands (Visa, Mastercard, Amex, Discover).

**Who needs to comply?** Anyone who handles payment card data, even indirectly.

#### The 4 Merchant Levels

| Level | Criteria | Validation Requirements |
| ------- | --------- | ---------------------- |
| **Level 1** | 6M+ transactions/year | Annual on-site audit, quarterly network scan |
| **Level 2** | 1M-6M transactions/year | Annual self-assessment, quarterly network scan |
| **Level 3** | 20K-1M e-commerce transactions/year | Annual self-assessment, quarterly network scan |
| **Level 4** | <20K e-commerce transactions/year | Annual self-assessment, recommended quarterly scan |

**Most startups begin at Level 4** and move up as they scale.

#### The 12 PCI Requirements (Simplified)

PCI DSS has 12 detailed requirements, but they cluster into 6 logical groups:

| Requirement Group | What It Means |
| ----------------- | ------------- |
| **Secure Network** | Firewalls, secure network configurations |
| **Data Protection** | Encryption of cardholder data (at rest and in transit) |
| **Vulnerability Management** | Regular security updates, malware protection |
| **Access Control** | Unique IDs, need-to-know access, physical access controls |
| **Monitoring & Testing** | Logging, monitoring, vulnerability scanning |
| **Information Security** | Policy, training, incident response |

#### The Critical Decision: Touch Card Data or Not?

Your PCI compliance burden depends entirely on whether your systems touch cardholder data.

**Option A: Never Touch Card Data (Recommended)**

Use a hosted payment page where the user enters card details directly on the processor's servers.

| Provider | PCI Burden | Your Responsibility |
| -------- | ---------- | ------------------- |
| **Stripe Checkout** | Lowest | Minimal compliance (SAQ A) |
| **Stripe Elements** | Low-Moderate | SAQ A-VP |
| **Braintree Hosted Fields** | Low-Moderate | SAQ A-VP |
| **Custom implementation** | High | Full PCI audit (SAQ D) |

**Option B: Touch Card Data (Not Recommended for MVPs)**

Your servers see raw card data. This requires significantly more compliance work and higher security standards.

**Recommendation:** Start with hosted payment pages. Only consider touching card data if you have a compelling business reason and the resources for full compliance.

---

### PCI SAQs: Which One Applies?

The Self-Assessment Questionnaire (SAQ) you complete depends on how you handle payments.

| SAQ Type | When It Applies | Complexity |
| -------- | --------------- | ---------- |
| **SAQ A** | Cardholder data never touches your systems (e.g., PayPal) | Lowest |
| **SAQ A-EP** | E-commerce, outsourced payment page but some control | Low |
| **SAQ B** | Face-to-face terminals only | Low |
| **SAQ B-IP** | Face-to-face terminals with internet connectivity | Low-Medium |
| **SAQ C-VT** | Telephone or e-commerce channels with manual processes | Medium |
| **SAQ C** | E-commerce with payment application | Medium-High |
| **SAQ D** | All other merchants, including those who touch card data | Highest |

**For most SaaS companies:** You'll likely use SAQ A or SAQ A-EP if you use Stripe or Braintree properly.

---

### SOC 2: Service Organization Control 2

#### What is SOC 2?

SOC 2 is an auditing framework that demonstrates your service organization has appropriate controls in place to secure customer data. Unlike PCI DSS, SOC 2 isn't legally required. It's often demanded by enterprise customers and investors.

**The five SOC 2 Trust Services Criteria:**

| Criterion | What It Covers |
| ---------- | -------------- |
| **Security** | Protection against unauthorized access |
| **Availability** | System uptime and performance |
| **Processing Integrity** | Complete, accurate, and timely processing |
| **Confidentiality** | Protection of confidential information |
| **Privacy** | Collection, use, and disclosure of personal information |

**Type 1 vs. Type 2:**

| Report Type | What It Covers | Audit Period |
| ----------- | -------------- | ------------ |
| **Type 1** | Controls designed and in place at a point in time | Single date |
| **Type 2** | Controls operating effectively over time | 3-12 months |

**Type 2 is the gold standard** and what most enterprises require.

#### When Do You Need SOC 2?

| Trigger | SOC 2 Required? |
| ------- | --------------- |
| Selling to enterprise B2B customers | Usually yes |
| Handling sensitive customer data | Usually yes |
| Series A+ fundraising | Commonly requested |
| Early-stage B2B SaaS | Sometimes |
| B2C products | Rarely |

**Timeline:** SOC 2 Type 2 typically takes 6-12 months from start to report.

---

### Building Compliant FinTech: Architecture Patterns

#### Payment Architecture (PCI DSS)

**Recommended: Tokenization**

```
Customer → Your Frontend → Stripe/Braintree (Card Data)
                ↓
            Token/Reference ID
                ↓
            Your Backend → Stripe/Braintree API → Charge
```

**Key principles:**

1. **Never store card data**: use tokens from your payment processor
2. **Your servers only ever see tokens**: never raw card numbers
3. **Use 3D Secure** for fraud prevention on high-value transactions
4. **Implement webhook verification**: confirm payment processor webhooks are legitimate

**Example: Stripe Integration Pattern**

```typescript
import Stripe from 'stripe';

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);

// Client-side: Stripe Elements creates a payment method
// and sends it to your backend

async function createPaymentIntent(amount: number, currency: string) {
  // Your server NEVER sees card data
  // Only receives paymentMethodId from client

  const paymentIntent = await stripe.paymentIntents.create({
    amount,
    currency,
    automatic_payment_methods: {
      enabled: true,
    },
  });

  return paymentIntent.client_secret;
}

// Webhook handler: verify signature
async function handleWebhook(signature: string, payload: Buffer) {
  const event = stripe.webhooks.constructEvent(
    payload,
    signature,
    process.env.STRIPE_WEBHOOK_SECRET
  );

  // Handle the event
  switch (event.type) {
    case 'payment_intent.succeeded':
      // Update your database, fulfill order, etc.
      break;
  }
}
```

#### Security Architecture (SOC 2)

**Core security controls:**

| Control | Implementation |
| ------- | -------------- |
| **Access Control** | SSO (SAML/OIDC), RBAC, just-in-time access |
| **Encryption** | TLS 1.3, AES-256 encryption at rest |
| **Logging** | Centralized logging (Datadog, CloudWatch) with tamper-evident storage |
| **Monitoring** | Uptime monitoring, alerting, anomaly detection |
| **Backup** | Encrypted backups, tested restoration |
| **Change Management** | Code review, CI/CD, staged deployments |
| **Incident Response** | Documented procedures, escalation paths |

---

### Compliance-Friendly Technology Choices

#### Payment Processors with PCI Benefits

| Processor | PCI Advantage | Best For |
| ---------- | -------------- | -------- |
| **Stripe** | Excellent documentation, SAQ A eligible, SOC 2 certified | Most SaaS, marketplaces |
| **Braintree** | SAQ A-VP eligible, PayPal ecosystem | E-commerce, PayPal-heavy users |
| **Adyen** | Global coverage, enterprise features | International expansion |
| **Paddle** | Merchant of Record (they handle PCI) | B2B SaaS (simplifies compliance) |

**Note:** "Merchant of Record" models like Paddle or Lemon Squeezy can dramatically simplify compliance because they become the seller, not you.

#### Security & Compliance Tools

| Tool Category | Options | Purpose |
| -------------- | ------- | ------- |
| **SSO/Identity** | Auth0, Okta, WorkOS | Centralized access control |
| **Logging** | Datadog, CloudWatch, New Relic | Audit trail requirements |
| **Security Scanning** | Snyk, Dependabot | Vulnerability management |
| **Compliance Platforms** | Vanta, Drata, Secureframe | Automate SOC 2 preparation |
| **Secrets Management** | 1Password, HashiCorp Vault | Secure credential storage |

---

### Common FinTech Compliance Mistakes

| Mistake | Why It Happens | How to Avoid |
| ------- | -------------- | ------------ |
| **Storing card data** | Teams want to "save cards for future use" | Use processor tokenization, never store PANs |
| **Assuming Stripe makes you PCI compliant** | Misunderstanding of shared responsibility | You still have PCI requirements even with Stripe |
| **Logging sensitive data** | Debug logging captures request bodies | Sanitize logs, never log card data or tokens |
| **No incident response plan** | Teams focus on building, not operations | Document response procedures before you need them |
| **Ignoring change management** | Deploying directly to production | Implement code review, staged environments |
| **Weak access controls** | Shared credentials, no MFA | Use SSO, individual accounts, MFA everywhere |
| **No background checks** | Hiring without verification | Screen employees with system access |
| **Missing SOC 2 documentation** | Doing the right thing, not documenting it | Start documentation early, use compliance platforms |

---

### Minimum Viable Compliance Roadmap

**Phase 1: Foundation (Months 1-3)**

PCI DSS:
- [ ] Choose hosted payment flow (Stripe Checkout or Elements)
- [ ] Complete SAQ A or SAQ A-VP
- [ ] Implement TLS encryption
- [ ] Enable logging for payment flows
- [ ] Review quarterly scan requirements

SOC 2 Preparation:
- [ ] Document security policies (even simple one-pagers)
- [ ] Implement access controls (SSO, MFA)
- [ ] Enable centralized logging
- [ ] Set up background check process for new hires

**Phase 2: Formalize (Months 4-6)**

PCI DSS:
- [ ] Annual SAQ completion
- [ ] Quarterly vulnerability scans
- [ ] Review and update policies

SOC 2 (if pursuing):
- [ ] Select SOC 2 auditor
- [ ] Gap analysis against SOC 2 criteria
- [ ] Remediate identified gaps
- [ ] Begin Type 2 monitoring period

**Phase 3: Certification (Months 6-12+)**

SOC 2 Type 2:
- [ ] Complete monitoring period (typically 6-12 months)
- [ ] Final audit
- [ ] Issue SOC 2 Type 2 report

---

### Compliance Cost Estimates

| Initiative | One-Time Cost | Ongoing Annual Cost |
| ---------- | ------------- | ------------------- |
| **PCI DSS (Level 4, SAQ A)** | $0 - $500 | $200 - $1,000 (scans, SAQ) |
| **PCI DSS (Level 2-3, SAQ A-VP/C)** | $5,000 - $15,000 | $2,000 - $5,000 |
| **PCI DSS (Level 1, full audit)** | $50,000 - $100,000 | $10,000 - $30,000 |
| **SOC 2 Type 2** | $20,000 - $50,000 | $15,000 - $30,000 |
| **Compliance platform (Vanta, etc.)** | Setup: $5,000 | $10,000 - $20,000 |

**Note:** These are rough estimates. Actual costs vary significantly by company size, complexity, and auditor choice.

---

### Real-World Examples

**Example 1: B2B SaaS Marketplace**

Used Stripe Connect for payments, implemented SOC 2 controls while building.

- **PCI:** SAQ A-VP (Stripe Elements, tokenized payments)
- **SOC 2:** Used Vanta for automation, completed Type 2 in 9 months
- **Cost:** ~$35K total for SOC 2, minimal PCI burden
- **Timeline:** Started SOC 2 prep after Series A, certified before enterprise sales

**Example 2: E-commerce Platform**

Handled thousands of transactions monthly.

- **PCI:** SAQ A (hosted checkout via Stripe)
- **SOC 2:** Not initially pursued, added later for enterprise customers
- **Cost:** ~$500/year for PCI compliance
- **Timeline:** PCI compliant from launch, SOC 2 added in Year 2

---

### The Compliance Framework Decision Tree

**Start here:**

1. **Do you handle credit card data?**
   - No → PCI DSS doesn't apply
   - Yes → Continue

2. **Do you use a hosted payment page?**
   - Yes → SAQ A or A-VP (simplified)
   - No → Full PCI audit likely required (expensive)

3. **Are you selling to enterprise customers?**
   - Yes → Plan for SOC 2 Type 2
   - No → May not need SOC 2 initially

4. **Have you raised Series A+?**
   - Yes → SOC 2 commonly requested
   - No → Can likely defer SOC 2

---

## How We Can Help

Building compliant FinTech requires both technical expertise and regulatory knowledge. We've helped financial technology companies navigate PCI DSS and SOC 2 while shipping secure products.

Our [Web Application Development](https://innovativeprospects.com/services/web-application-development) and [AI Features & Automation](https://innovativeprospects.com/services/ai-features-automation) services include security-first architecture, compliance-friendly patterns, and integration with payment processors.

[Book a free consultation](https://innovativeprospects.com/contact) to discuss your FinTech project.

---

Unsure which compliance frameworks apply to your situation? Let's talk through your specific requirements and timeline.