Introducing /kyc: Pass identity verification when your customer is an agent

Today we're launching /kyc — the primitive that verifies the human or entity principal behind every autonomous business operating on Naïve. Government ID, selfie liveness, AML and sanctions screening — all wrapped around the same Persona infrastructure used by Plaid and Coinbase, and exposed as a runtime object that composes with /llc and /cards.

The problem: every regulated action requires a real principal

State filings, EIN applications, bank account openings, payment card issuance, e-signatures — every meaningful real-world action an agent takes is gated on someone who passed KYC. The state of Wyoming wants to know who's filing the LLC. The IRS wants to know who's responsible for the EIN. Stripe Issuing wants to know whose face matches the ID on the card.

For human-operated SaaS, this is a one-time onboarding flow. For autonomous businesses, it's the foundational primitive — and it's been the hardest one to build correctly.

The status quo is two bad options:

1. Re-implement KYC from scratch on top of a raw provider like Persona, Onfido, or Stripe Identity — and own all the PII handling, vault rotation, and audit logs yourself.
2. Use the KYC built into a single vertical product (Stripe Atlas, Mercury) — and re-verify every time you cross a product boundary.

Until now. /kyc runs the verification once, attaches it to an Employee, and lets every other primitive trust the result.

How /kyc works

The workflow is three steps:

1. Start — naive verification start --members '[...]' with founder details. Naïve returns a hosted Footprint verification URL for the primary member and emails links to secondary members.
2. Verify — each member opens the URL, uploads ID, completes identity verification, and consents. Footprint runs document checks and identity matching; the result writes back to Naïve.
3. Compose — when all members pass (ready_for_formation: true), call /formation to form a Company, or /cards to issue a card as cardholder.

PII — government IDs, biometric vectors, addresses, dates of birth — never lives in plaintext on Naïve servers. It's stored in an encrypted vault and hydrated only at submission time when an external system (state filing, IRS, card issuer) needs it. There is no Naïve API endpoint that returns vault contents to an agent or operator.

What /kyc verifies

Every verification produces a structured result the runtime can act on:

{
  employeeId: "emp_01HXY...",
  status: "passed",        // passed | review | failed
  verifiedAt: "2026-05-01T18:22:14Z",
  documentType: "us_drivers_license",
  documentCountry: "US",
  watchlistHits: [],        // [] when clean
  biometricMatch: 0.987,    // 0.0-1.0
  cipFileUrl: "https://..." // the customer identification program file
}

The cipFileUrl is the audit artifact every state filing system, EIN issuer, and bank wants to see. Naïve generates it from the verification and stores it on the Employee.

Two ways to start a verification: prompt or code

1. Natural language

naive verification start \
  --members '[{
    "first_name": "Alice",
    "last_name": "Smith",
    "email": "alice@example.com",
    "phone_number": "+15551234567",
    "ownership_percentage": 100,
    "role": "primary",
    "is_responsible_party": true
  }]'

The CLI returns the verification ID and the primary member's Footprint-hosted URL. You hand the URL to the verifying party.

2. Code

const res = await fetch("https://api.usenaive.ai/v1/verification", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.NAIVE_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    members: [{
      first_name: "Alice",
      last_name: "Smith",
      email: "alice@example.com",
      phone_number: "+15551234567",
      ownership_percentage: 100,
      role: "primary",
      is_responsible_party: true,
    }],
  }),
});
const { id, primary_link } = await res.json();
// primary_link — send to the user
// id — poll with GET /v1/verification/:id until ready_for_formation: true

The verification URL is single-use and is bound to the member. Re-issuing via naive verification resend <memberId> returns a fresh URL.

Watchlist screening, included

Every verification runs against OFAC, EU, UN, and HMT sanctions lists, plus PEP (politically-exposed persons) databases. Hits surface as structured WatchlistHit objects on the Employee, not as silent failures.

# Check verification status and member details
naive verification status <verification_id>

# Resend a member's verification link if expired
naive verification resend <member_id>

A watchlist hit doesn't auto-reject — it routes to manual review, where a human (you or Naïve compliance) can clear or escalate. This is the FATF-recommended pattern: detect, document, decide.

Revocation and consent

Every verification is consent-based, and consent is revocable. When a user calls revoke_verification_consent, Naïve schedules vault data for deletion in line with GDPR Article 17 and CCPA §1798.105. The Employee object retains the verification status flag for compliance audit trails, but the underlying PII is gone.

What you can build with /kyc

Verify a founder once, form ten companies — A single /kyc-passed Employee can act as principal across multiple /llc formations without re-verification. Useful for fleets of single-purpose companies.

Issue cards in real names with real liability — Compose /kyc with /cards so virtual cards are bound to a verified principal — not a generic "agent" account that will get rejected at higher-risk merchants.

Pass downstream KYC at banks and brokerages — The CIP file from /kyc is the same artifact a bank's compliance team would generate themselves. Hand it to Mercury, Brex, or any partner and skip duplicate verification.

Demonstrate beneficial ownership for FinCEN — Every Company formed via /llc ties to one or more /kyc-verified Employees. The result is a queryable, exportable beneficial ownership graph — exactly what the Corporate Transparency Act requires.

Run AML monitoring on agent-controlled accounts — Re-screen Employees against watchlists on a cadence. Surface hits to an operator before they become regulatory incidents.

Get started

• Read the docs: usenaive.ai/docs/guides/identity-verification
• Quickstart: usenaive.ai/docs/getting-started/quickstart
• Read the FATF guidance on AI identity verification for context on the regulatory landscape
• Join the community on Discord