KYC and AML System Design: Engineering Compliance Into FinTech Onboarding

Introduction

Every FinTech onboarding flow looks simple in the pitch deck: sign up, verify identity, start transacting.

In production, onboarding is a state machine spanning document capture, liveness checks, sanctions list screening, PEP (Politically Exposed Person) checks, risk scoring, manual review queues, and periodic re-verification. Regulators care less about your UI and more about whether you can produce an audit trail proving you knew who your customer was at the time of each transaction.

Engineering KYC/AML well means designing for evidence, not just approval.

Section 1: The Onboarding State Machine

Typical states:

created → documents_submitted → auto_verification → 
  manual_review (if needed) → approved | rejected → 
  periodic_review (ongoing)

Every transition logs:

timestamp,
actor (system, analyst, vendor),
inputs and outputs (redacted where needed),
decision reason codes.

Never hard-delete rejected applications—retain per regulatory retention requirements.

Section 2: Vendor Integration Architecture

Most teams integrate identity vendors (Onfido, Jumio, Persona, etc.). Architecture principles:

Async by default

Vendor verification takes seconds to minutes. Use webhooks + polling fallback—not blocking HTTP in the signup request.

Vendor idempotency

Use stable applicant_id per user. Duplicate webhook events must not create duplicate profiles.

Evidence storage

Store verification artifacts (document metadata, check results, vendor reference IDs) in WORM or append-only storage. Original document images often have strict retention and access rules.

Section 3: AML Screening

Sanctions and PEP screening

Run at:

onboarding,
every high-risk transaction (configurable threshold),
list update events (daily batch re-screen).

Transaction monitoring

Rules-based initially (velocity, geography, amount thresholds), evolving toward ML with human review loops. Alerts create cases—not automatic account freezes without workflow (unless legally mandated).

SAR workflow

When suspicion thresholds are met, compliance officers need tooling to review history, attach notes, and file reports. Engineering provides search, export, and immutable audit—not the legal judgment.

Section 4: Data Architecture

Data type	Storage approach
PII (name, DOB, address)	Encrypted at rest, field-level where possible
Verification results	Structured records + vendor refs
Analyst notes	Append-only case management
Screening hits	Timestamped match records with list version

Separate compliance data plane access from general application DB credentials.

Section 5: Engineering Checklist

Onboarding state machine with full audit trail,
Idempotent vendor webhooks,
Sanctions screening at onboarding + ongoing,
Manual review queue with SLA tracking,
Encryption for PII at rest and in transit,
Role-based access for compliance analysts,
Data retention and deletion policies documented.

Conclusion

KYC/AML system design is workflow engineering with regulatory evidence requirements. Build state machines, not booleans. Store decisions, not just outcomes.