Fintech Compliance Software: KYC, AML, PCI DSS, and SOC 2 for Financial Applications

Compliance is the primary reason fintech software costs more to build and maintain than a standard SaaS product. It's also the primary reason fintech products take longer to launch, and why cutting corners on compliance creates existential risk rather than just technical debt.

This guide covers the four compliance frameworks most relevant to financial software — what each requires, how to implement the technical controls, and what it costs to do it properly.

---

The Compliance Stack for Fintech

┌─────────────────────────────────────────────────────┐
│                    User Interface                   │
├─────────────────────────────────────────────────────┤
│  KYC/KYB Layer     │  AML Screening  │  Fraud       │
│  (Identity verify) │  (Transaction)  │  Detection   │
├─────────────────────────────────────────────────────┤
│              Application Logic                      │
├─────────────────────────────────────────────────────┤
│  PCI DSS Scope     │  Audit Logging  │  Encryption  │
│  (Card Data)       │  (Immutable)    │  at Rest/TLS │
├─────────────────────────────────────────────────────┤
│              SOC 2 Controls (Pervasive)             │
│  Access Control │ Monitoring │ Incident Response    │
└─────────────────────────────────────────────────────┘

Each layer has regulatory requirements, technical controls, and operational processes. The layers interact: your AML screening depends on having solid KYC data; your PCI scope depends on how you handle card data; your SOC 2 audit covers all of it.

---

KYC/KYB: Identity Verification

Know Your Customer (KYC) for individuals, Know Your Business (KYB) for companies — these are the requirements to verify who you're doing business with before allowing financial activity.

KYC data collected:

• Full legal name
• Date of birth
• Government-issued ID (passport, driver's license) — document scan + liveness check
• Address proof
• SSN or equivalent national ID (for US)
• Source of funds (for higher-risk customers)

The implementation choice: Build vs buy for identity verification.

Build the KYC workflow, buy the identity verification engine. Building OCR + liveness detection is a compliance and fraud liability, not a competitive differentiator.

KYC status machine:

// types/kyc.ts
type KycStatus =
  | 'NOT_STARTED'
  | 'PENDING'           // User started, not submitted
  | 'SUBMITTED'         // Documents sent for review
  | 'MANUAL_REVIEW'     // Flagged for human review
  | 'APPROVED'
  | 'REJECTED'
  | 'EXPIRED';          // Re-verification required (typically every 1–2 years)

interface KycRecord {
  id: string;
  userId: string;
  status: KycStatus;
  riskLevel: 'low' | 'medium' | 'high';
  verificationProvider: 'persona' | 'onfido' | 'manual';
  externalVerificationId?: string;
  documents: KycDocument[];
  reviewNotes?: string;
  approvedAt?: Date;
  expiresAt?: Date;
  createdAt: Date;
  updatedAt: Date;
}

// services/kyc.ts
export async function initiateKyc(userId: string): Promise<string> {
  // Create Persona inquiry
  const inquiry = await persona.inquiries.create({
    'inquiry-template-id': process.env.PERSONA_TEMPLATE_ID!,
    meta: { user_id: userId },
  });

  await db.kycRecord.create({
    data: {
      userId,
      status: 'PENDING',
      verificationProvider: 'persona',
      externalVerificationId: inquiry.id,
    },
  });

  return inquiry.attributes['session-token'];  // Pass to frontend SDK
}

// Handle Persona webhook
export async function handlePersonaWebhook(event: PersonaEvent) {
  const inquiry = event.data.attributes;
  const userId = event.data.attributes.meta?.user_id;

  const newStatus: KycStatus = 
    inquiry.status === 'approved' ? 'APPROVED' :
    inquiry.status === 'declined' ? 'REJECTED' :
    inquiry.status === 'needs_review' ? 'MANUAL_REVIEW' :
    'SUBMITTED';

  await db.kycRecord.updateMany({
    where: { externalVerificationId: event.data.id },
    data: {
      status: newStatus,
      riskLevel: mapRiskScore(inquiry['risk-score']),
      approvedAt: newStatus === 'APPROVED' ? new Date() : undefined,
      expiresAt: newStatus === 'APPROVED' 
        ? addYears(new Date(), 2) 
        : undefined,
    },
  });

  if (newStatus === 'APPROVED') {
    await enableFinancialFeatures(userId);
  }
}

---

AML: Transaction Monitoring

Anti-Money Laundering (AML) requirements mandate that you screen customers against sanctions lists, monitor transactions for suspicious patterns, and file Suspicious Activity Reports (SARs) with FinCEN.

Sanctions screening (must happen at onboarding and on every transaction):

// services/sanctions.ts
import { OfacClient } from 'ofac-api-client';  // Or use Chainalysis, Elliptic, ComplyAdvantage

const ofac = new OfacClient({ apiKey: process.env.OFAC_API_KEY! });

interface SanctionsResult {
  clear: boolean;
  matches: SanctionsMatch[];
  screeningId: string;
}

export async function screenEntity(entity: {
  name: string;
  dateOfBirth?: string;
  country?: string;
  taxId?: string;
}): Promise<SanctionsResult> {
  const result = await ofac.search({
    name: entity.name,
    dob: entity.dateOfBirth,
    country: entity.country,
    minScore: 85,  // 85%+ match score triggers review
  });

  // Log every screening — required for compliance audit
  const screening = await db.sanctionsScreening.create({
    data: {
      entityName: entity.name,
      clear: result.matches.length === 0,
      matchCount: result.matches.length,
      rawResult: result,
      screenedAt: new Date(),
    },
  });

  if (result.matches.length > 0) {
    await alertComplianceTeam(screening.id, result.matches);
  }

  return {
    clear: result.matches.length === 0,
    matches: result.matches,
    screeningId: screening.id,
  };
}

// Transaction monitoring rules
export async function assessTransactionRisk(transaction: {
  userId: string;
  amount: number;       // In cents
  type: 'deposit' | 'withdrawal' | 'transfer';
  counterparty?: string;
}): Promise<{ riskScore: number; flags: string[] }> {
  const flags: string[] = [];
  let riskScore = 0;

  // Rule 1: Large cash transactions (CTR threshold: $10,000)
  if (transaction.amount >= 1_000_000) {  // $10,000 in cents
    flags.push('CTR_THRESHOLD');
    riskScore += 40;
  }

  // Rule 2: Structuring detection (multiple transactions just below CTR threshold)
  const recentTotal = await getRecentTransactionTotal(
    transaction.userId,
    24  // hours
  );
  if (recentTotal + transaction.amount >= 950_000 && 
      transaction.amount < 1_000_000) {
    flags.push('POSSIBLE_STRUCTURING');
    riskScore += 60;
  }

  // Rule 3: Velocity — too many transactions too fast
  const txCount = await getTransactionCount(transaction.userId, 1);  // 1 hour
  if (txCount > 10) {
    flags.push('HIGH_VELOCITY');
    riskScore += 30;
  }

  // Rule 4: Round amounts (often indicator of structured payments)
  if (transaction.amount % 100_000 === 0 && transaction.amount >= 500_000) {
    flags.push('ROUND_AMOUNT');
    riskScore += 10;
  }

  return { riskScore, flags };
}

SAR filing requirement: If a transaction is suspicious and exceeds $5,000 (or $2,000 for certain businesses), you must file a SAR with FinCEN within 30 days of detection. This is a regulatory obligation with criminal penalties for willful failure.

---

PCI DSS: Card Data Handling

PCI DSS (Payment Card Industry Data Security Standard) governs how you handle cardholder data. The most important rule: don't store card numbers (PAN). Let your payment processor handle it.

PCI scope reduction with Stripe Elements:

// ❌ NEVER do this — storing raw card data puts you in full PCI scope
const card = {
  number: req.body.cardNumber,  // Never touch this
  expiry: req.body.expiry,
  cvv: req.body.cvv,
};

// ✅ Use tokenization — card data never touches your server
// Frontend: Stripe Elements handles card input
// Your server receives only the PaymentMethod ID

// server/api/payment-methods.ts
export async function POST(request: Request) {
  const { paymentMethodId, userId } = await request.json();

  // Attach the payment method to a Stripe Customer
  const customer = await getOrCreateStripeCustomer(userId);
  
  await stripe.paymentMethods.attach(paymentMethodId, {
    customer: customer.stripeCustomerId,
  });

  // Store only the Stripe token reference — not card data
  await db.paymentMethod.create({
    data: {
      userId,
      stripePaymentMethodId: paymentMethodId,  // Safe to store
      // NEVER store: card number, CVV, full expiry
    },
  });

  return Response.json({ success: true });
}

PCI compliance levels by transaction volume:

Using Stripe/Braintree/Adyen without storing card data puts you in SAQ-A (the simplest questionnaire). Handling card data directly triggers SAQ-D or a full QSA audit.

---

SOC 2: Trust Service Criteria

SOC 2 is an audit framework covering five trust criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Most B2B fintech customers require SOC 2 Type II certification.

SOC 2 technical controls to implement early:

// 1. Immutable audit logging — every sensitive action logged
// services/auditLog.ts
export async function logAuditEvent(event: {
  actorId: string;
  actorType: 'user' | 'admin' | 'system';
  action: string;
  resourceType: string;
  resourceId: string;
  before?: unknown;
  after?: unknown;
  ipAddress?: string;
  userAgent?: string;
}) {
  // Write to append-only table — no UPDATE/DELETE allowed
  await db.$executeRaw`
    INSERT INTO audit_log (
      actor_id, actor_type, action, resource_type, resource_id,
      before_state, after_state, ip_address, user_agent, occurred_at
    ) VALUES (
      ${event.actorId}, ${event.actorType}, ${event.action},
      ${event.resourceType}, ${event.resourceId},
      ${JSON.stringify(event.before)}, ${JSON.stringify(event.after)},
      ${event.ipAddress}, ${event.userAgent}, NOW()
    )
  `;
}

// Postgres: restrict DELETE on audit_log via row-level security
// CREATE POLICY audit_log_no_delete ON audit_log FOR DELETE USING (false);

# 2. Encryption at rest — AWS RDS encryption config (Terraform)
resource "aws_db_instance" "primary" {
  engine                 = "postgres"
  engine_version         = "16.1"
  storage_encrypted      = true        # AES-256 encryption at rest
  kms_key_id            = aws_kms_key.rds.arn
  
  backup_retention_period = 30         # 30-day backups
  deletion_protection    = true        # Prevent accidental deletion
  
  # Enable enhanced monitoring
  monitoring_interval    = 60
  monitoring_role_arn    = aws_iam_role.rds_monitoring.arn
}

SOC 2 controls summary:

---

Compliance Cost Reality

The compounding advantage of getting compliance right early: Companies that implement proper KYC, AML, and audit logging from day one spend 40–60% less on their first SOC 2 audit than those who retrofit controls onto an existing system.

---

Working With Viprasol

We build fintech software with compliance requirements built into the architecture from the start — not retrofitted before an audit. Our experience includes payment platforms, lending software, and investment tools with KYC, AML, PCI, and SOC 2 requirements.

We also help teams navigate the compliance landscape: determining which requirements apply, selecting vendors, and implementing technical controls that satisfy auditors while keeping the product moving.

→ Talk to our fintech team about your compliance requirements.

---

See Also

• Payment Gateway Integration — Stripe integration basics
• Stripe Connect Marketplace — platform payment flows
• API Security Best Practices — securing financial APIs
• SaaS Security Best Practices — application security controls
• Trading Software Development — financial application development