The FinTech Founder's KYC Playbook: From MVP to Series A Compliance

Stage 1: Pre-Launch (0 Users)

What You Actually Need

Before your first user touches your product, you need three things and only three things: a decision about which jurisdictions you will serve (this determines your regulatory obligations), a documented compliance policy (even a two-page document counts — it shows intent), and a vendor relationship or integration plan for identity verification.

You do not need a full AML program. You do not need a compliance officer. You do not need transaction monitoring. Those come later. Right now, you need the foundation.

The Jurisdiction Decision

Your regulatory obligations are determined by where your users are, not where you are incorporated. A Delaware C-Corp serving users in the EU must comply with EU AML directives. A UK fintech serving US users must comply with FinCEN requirements. Map your target markets and identify the regulatory bodies in each.

For most early-stage fintechs, the practical starting point is one primary market. If you are US-focused, your regulatory obligations flow from FinCEN and state-level regulators. If you are EU-focused, AMLD5/AMLD6 and the upcoming AMLR. If you are UK-focused, the FCA and the Money Laundering Regulations 2017.

Do not try to be compliant everywhere on day one. Pick your beachhead market, nail compliance there, and expand jurisdiction by jurisdiction as you scale.

The Compliance Policy

Write a two-page document that covers who your customers are (individuals, businesses, or both), what identity verification you will perform at onboarding, how you will screen customers against sanctions lists, and when you will file suspicious activity reports.

This document is not a legal filing. It is your operating framework. Investors want to see that you have thought through compliance — not that you have hired a 20-person compliance team. The document demonstrates intent, which is what matters at this stage.

Stage 2: MVP Launch (1–1,000 Users)

The Build vs Buy Decision

Pull quote

“Every hour your engineering team spends building verification infrastructure is an hour they're not building your product. At the MVP stage, that trade-off is fatal.”

— Shawn-Marc Melo, CEO deepidv

This is where most founders make their most expensive mistake: they try to build identity verification in-house. The reasoning seems sound — "we're engineers, we can build anything, and we'll save money." The reasoning is wrong.

Building identity verification from scratch requires document template libraries for every country you serve (211+ countries, thousands of document types), biometric matching models trained on diverse populations, liveness detection that passes iBeta Level 2 PAD testing, deepfake detection that catches injection attacks, sanctions screening against OFAC, EU, UN, and country-specific lists, and ongoing model retraining as documents change and attack vectors evolve.

Even a basic implementation — US documents only, no deepfake detection, no sanctions screening — takes 3–6 months of engineering time and produces a system that is less accurate than any commercial provider.

Buy. Every time. At this stage, your engineers should be building the product that differentiates your company, not commodity infrastructure that a vendor does better.

What to Look For in a Vendor

Not all verification vendors are created equal. The differences that matter at the MVP stage are coverage (how many countries and document types does the vendor support — you may not need 211 countries today, but you will need them when you expand), speed (sub-second verification keeps onboarding friction low — anything over 5 seconds and you lose users), accuracy (false rejection rates matter as much as false acceptance rates — a system that rejects real users kills growth), integration complexity (SDK, API, or white-label? How many engineering hours does integration take?), and pricing structure (per-check pricing, monthly minimums, volume discounts — model the cost at 10x your current volume to avoid pricing surprises).

The Minimum Viable Compliance Stack

At the MVP stage with under 1,000 users, your compliance stack needs four components:

Identity verification — Document capture + biometric matching + liveness detection. This is the core check that confirms your user is a real person with a real identity document.

Sanctions screening — Real-time check against OFAC SDN list, EU sanctions, UN sanctions, and any country-specific lists relevant to your jurisdiction.

PEP screening — Politically Exposed Persons screening identifies users who hold (or have held) prominent public positions and may present elevated money laundering risk.

Record keeping — Store verification results, screening outcomes, and decision rationale for a minimum of 5 years (requirement in most jurisdictions).

You do not need transaction monitoring at this volume. You do not need enhanced due diligence automation. You do not need a case management system. Add those when your user base and transaction volume justify them.

Stage 3: Growth (1,000–50,000 Users)

When Transaction Monitoring Becomes Mandatory

As your user base grows, transaction monitoring transitions from optional to mandatory. The threshold varies by jurisdiction, but as a practical matter, once you are processing more than a few hundred transactions daily, you need automated monitoring.

Transaction monitoring evaluates every transaction against risk rules and behavioral baselines: is this transaction unusually large for this user? Is this pattern consistent with structuring (breaking large amounts into smaller transactions to avoid reporting thresholds)? Is this user transacting with counterparties in high-risk jurisdictions?

At this stage, your monitoring can be rule-based — a set of defined thresholds and patterns that trigger alerts. Machine learning-based monitoring comes later when you have enough data to train models on your specific user population.

Enhanced Due Diligence Automation

Not every user presents the same risk. Enhanced Due Diligence (EDD) applies additional scrutiny to higher-risk users: PEPs, users from higher-risk jurisdictions, users with unusual transaction patterns, and users whose source of funds cannot be easily explained.

At the growth stage, you need a system that automatically flags users for EDD based on risk criteria, routes EDD cases to your compliance team for review, documents the EDD decision and rationale, and schedules periodic re-review of EDD cases.

Pull quote

“The compliance infrastructure you build at 10,000 users is the infrastructure investors evaluate at Series A. Build it right the first time.”

The Compliance Hire

Somewhere between 5,000 and 20,000 users, you need your first dedicated compliance person. This does not need to be a Chief Compliance Officer with 20 years of experience. It needs to be someone who understands your regulatory obligations, can review alerts and make SAR filing decisions, can represent your compliance program to regulators, and can translate regulatory requirements into product specifications for your engineering team.

If you cannot hire a full-time compliance person, engage a compliance consultant on a retained basis. What you cannot do is leave compliance decisions to engineers who are not trained to make them.

Stage 4: Series A Readiness (50,000+ Users)

What Investors Actually Evaluate

By the time you are raising a Series A, your compliance program needs to withstand investor due diligence. Investors (and their legal teams) evaluate six areas.

Licensing. Are you properly licensed or registered in every jurisdiction where you operate? Do you have pending applications where required?

KYC completeness. What percentage of your user base has completed full identity verification? The answer needs to be 100% for your active user base. A gap — "we verified 85% of users" — is a red flag.

AML program. Do you have documented policies, transaction monitoring, sanctions screening, SAR filing procedures, and record keeping? Can you demonstrate that the program is followed in practice, not just on paper?

Verification vendor. Who provides your identity verification? What is the contractual relationship? What happens if the vendor raises prices or changes terms? Investors prefer vendors with no third-party dependencies — because those dependencies create cascading vendor risk.

Compliance team. Who is responsible for compliance? What is their background? Is the function adequately resourced for your current scale and projected growth?

Regulatory history. Have you received any regulatory inquiries, enforcement actions, or fines? Have you filed SARs? (Having filed SARs is actually a positive signal — it shows your monitoring is working.)

The Cost Model Investors Want to See

Investors will ask about your cost-per-verification and how it scales. The answer they want to hear is that your verification costs decrease as a percentage of revenue as you grow — not that they increase proportionally.

This is where vendor architecture matters. Verification providers built on stacked third-party APIs pass through the cost of every downstream API — document classification from one provider, biometric matching from another, sanctions screening from a third. Each takes a margin. Your cost is the sum of all margins plus the vendor's margin on top.

Providers that own their technology stack — document intelligence, biometric matching, deepfake detection, risk scoring, sanctions screening all built in-house — can offer structurally lower pricing because there are no third-party markups.

At Series A scale, the difference between a $5 per-check stacked provider and a $1–2 per-check in-house-stack provider compounds into hundreds of thousands of dollars annually.

The FinTech KYC Checklist