Stablecoin KYC for Fintechs: Who Owns the Compliance Perimeter

Stablecoin KYC vendors sell you an SDK. The pitch: "drop our identity component into onboarding and you're compliant." That sale assumes a perimeter the vendor doesn't actually define. The perimeter is your wallet model, your jurisdictions, and your role in the flow. The vendor sits inside it.

In 2026 the rules are legible. MiCA is in full effect across the EU. The EU Transfer of Funds Regulation has applied to every crypto transfer (no threshold) since 30 December 2024. The GENIUS Act ramps US payment-stablecoin rules toward a July 2028 full-compliance cliff. FATF Recommendation 16 (the Travel Rule) is transposed in most major jurisdictions. None of these frameworks single out KYC vendors — they single out roles: the issuer, the wallet provider, the builder. This guide is the perimeter map for the builder embedding USDC, PYUSD, or USD1 into a product.

The three-role model — who owns what

Three roles, three obligation columns. Read your row.

Role	Who runs KYC at the user perimeter	Sanctions screening	Travel Rule data	Direct license bar
Issuer (Circle, Paxos, SG-Forge)	Not the user — the issuer screens its direct counterparties (the wallet providers and bank rails).	Required at mint and redeem.	Originator data on issuer-side transfers.	MiCA EMT / ART, GENIUS Act issuer charter.
Wallet provider (Openfort, Privy, Magic, Fireblocks-tier custodians)	Hook layer — exposes the API surface where the builder's KYC vendor plugs in. Wallet provider does NOT replace the builder's user-onboarding KYC.	Required at signer init + on every transfer (pre-sign hook).	Required to construct and forward originator/beneficiary data for transfers above threshold (EU TFR: every transfer).	MiCA CASP (where custody applies); national equivalents.
Builder / integrator (your app)	You. Onboarding KYC, periodic re-screening, geographic gating, tier upgrades.	Required on user signup and ongoing — counterparty risk lives in your relationship with the user.	Conditional — if you control the data fields, you populate them.	Conditional: financial-promotions registration, local payment-institution license if you actively solicit.

The shorthand: issuer screens the wallet provider; wallet provider screens the user's address; you screen the user. Each row is a different perimeter. Each has its own enforcement tooling.

Who is the user, really — five wallet patterns

KYC obligation hinges on the wallet model. The five patterns below cover most production apps embedding stablecoins; each one shifts the perimeter.

1. Self-custodial embedded wallet, user-side signer

The signer runs in the user's browser. Keys never leave the device. Openfort's standard embedded wallet sits here.

KYC posture: In most jurisdictions, you are NOT the CASP for that user (no custody). You ARE the regulated entity for the user relationship — you market to them, you onboard them, you bear customer-protection obligations. KYC is yours; the wallet provider does not run it.

What the wallet provider gives you: sanctions screening hooks at signer init, a KYC-vendor adapter slot, a policy engine for tier-gated limits.

2. Self-custodial wallet with optional recovery service

Same as (1), plus an optional key recovery service (social recovery, custodial backup, MFA-gated restore). The recovery layer can shift the wallet from purely self-custodial to "self-custodial with custody-adjacent ops."

KYC posture: unchanged for users who don't enrol in recovery. For users who DO enrol, the wallet provider's recovery service may be in scope for additional custody obligations — talk to counsel and ensure the recovery flow itself screens at enrolment.

3. Backend wallet (server-signed)

Your server holds the signer; the user authenticates to your server which signs transactions on their behalf. Custodial.

KYC posture: YOU are running custody. Depending on jurisdiction and volume, you may be a CASP / VASP / MSB. MiCA Art. 75 attaches in the EU; FinCEN MSB registration applies for US flows above the de-minimis threshold; state MTL stacks on top. KYC is non-optional — both onboarding and ongoing.

4. Smart-account wallet with session keys / agentic spend

Smart account (ERC-4337) with delegated session keys that scope an agent (AI or otherwise) to a subset of actions. Backend wallet for the smart account; user-side ownership for the master key.

KYC posture: mostly the same as (3) for the agent's flows. The session key constraints are part of the policy enforcement — sanctions screening, allowed counterparties, per-call limits. The user perimeter is yours either way.

5. Backend wallet for app-owned automation (treasury, payroll, vendor)

The wallet is the app's own balance sheet — not a user wallet. Stablecoin treasury, payroll batches, vendor disbursements, marketplace settlement.

KYC posture: the wallet is internal. The KYC question shifts to counterparties: you onboard your vendors, payroll providers, payout destinations through KYB (know-your-business). Sanctions screening on every outbound transfer is non-negotiable. For the architecture, see Treasury Wallet.

What triggers KYC under each framework

FATF Travel Rule (global baseline)

Recommendation 16 requires originating service providers to transmit sender + beneficiary information on virtual-asset transfers above a jurisdiction-set threshold. Typical thresholds: USD 1,000 (US-aligned), EUR 1,000 (EU pre-TFR), SGD 1,500 (MAS PSN02). Most G20 jurisdictions have adopted some version.

For the builder: if your wallet provider is the originating CASP, it owns the data plumbing. You still own the user-side identity verification — the wallet provider can't transmit data it doesn't have. KYC at onboarding produces the originator dataset the Travel Rule needs.

EU Transfer of Funds Regulation (Reg (EU) 2023/1113)

In force across the EU since 30 December 2024. Applies to every crypto-asset transfer between CASPs — no threshold. Required fields include originator name, address, account identifier (wallet address or distributed-ledger account), and beneficiary equivalents.

For the builder: if you serve EU users, your wallet provider must be TFR-ready. Builder-side, you collect the originator KYC at onboarding. EU TFR is the strictest baseline — if your KYC posture is TFR-ready, you've covered most of the rest of the world.

MiCA — Title V CASP authorization

CASP (Crypto-Asset Service Provider) authorization applies to any service provider offering custody, exchange, transfer, or related services on a professional basis. Non-EU CASP cliff: 2026-07. After that, a non-EU wallet provider cannot serve EU users without (a) full authorization, (b) a narrow reverse-solicitation defense, or (c) member-state-discretionary grandfathering.

For the builder: check your wallet provider's CASP roadmap before 2026-07. If they don't have one, your EU users get cut off. Builders themselves are typically not CASPs unless they self-build custody (pattern 3 or 5 above with EU users).

GENIUS Act — US federal stablecoin issuer framework

Signed July 2025. Issuer-side: 100% reserve backing, quarterly attestation, OFAC sanctions screening on mint/redeem, BSA/AML program, no algorithmic stablecoins. Full-compliance cliff: July 2028.

For the builder: you are almost certainly not an issuer. The cascade hits you indirectly: GENIUS-compliant issuers will tighten distributor terms, and only "qualified stablecoins" (Circle USDC, Paxos PYUSD/USD1, equivalents) move freely on federally-regulated US bank rails. Plan for that selectivity — and for the issuer-side AML requirements bleeding into integrator-side reporting expectations.

FinCEN — Money Services Business + Travel Rule (US)

US-domestic crypto businesses transmitting value above the de-minimis threshold register as MSBs. Originator recordkeeping at $3,000 (31 CFR 1010.410); Currency Transaction Reports at $10,000; OFAC sanctions on every US-touching transaction.

For the builder: if you have US users and operate a backend wallet (pattern 3 or 5), MSB registration is the first step. State MTL stacks on top.

The five-vendor decision tree

KYC vendors solve the document + biometric + screening surface. Pick by jurisdiction, by data depth, and by integration ergonomics — not by SDK-prettiness.

Vendor	Strength	Use it when
Sumsub	Global coverage, fast onboarding, broad doc support.	Default for multi-jurisdiction consumer apps.
Persona	Configurable workflows, US-strong, embedded UX flexibility.	US-heavy traffic, need to design tier-by-tier flows in product.
Dotfile	EU-strong, KYB depth, regulated-entity onboarding.	B2B / KYB use cases, EU regulator alignment.
Onfido (Entrust)	Doc + biometric depth, fraud signal richness.	High-fraud-exposure verticals (gaming, financial-services).
Trulioo	Identity dataset coverage in emerging markets.	LatAm, APAC, MENA expansion where local data thinness matters.

The pattern that survives vendor swaps: wire your wallet provider's KYC hook to a vendor-agnostic interface (onUserKYCStatusChange, setUserKYCTier), and let the policy engine read the tier rather than the vendor. Stack regional vendors as needed; don't bake any one of them into the wallet flow.

The tiered KYC pattern — what gates what

Tiered KYC matches verification depth to risk. The cleanest map for a stablecoin app:

• Tier 1 — light: email + IP / device geolocation. Sufficient for very small balances, view-only, or read-mostly product flows.
• Tier 2 — standard: government-ID document + selfie liveness + global sanctions screen. The default for active spending on most consumer apps.
• Tier 3 — enhanced: proof of funds, source-of-wealth questionnaire, PEP screening, deep-screen sanctions. Required for large cash-outs to bank rail, treasury-grade transfers, or any flow approaching CTR thresholds.

The wallet's policy engine reads the tier and gates the transaction. The user can upgrade tier on demand; the upgrade flow re-runs the KYC vendor.

Where the wallet provider's hooks plug in

A compliance-aware wallet rail exposes five hooks. If your wallet provider doesn't expose all five, you'll bolt them on yourself at higher cost.

1. onSignerInit — sanctions screen the user's primary address. Before a wallet is even constructed, screen the new address against OFAC SDN + EU consolidated + UK OFSI. Reject hits; queue ambiguous matches for manual review.
2. setUserKYCTier(userId, tier, kycVendorRef) — bind KYC status to the wallet. The wallet provider doesn't need to know which vendor ran the verification; it needs to know the tier and the audit reference.
3. onTransferConstruct — Travel Rule originator data plumbing. When a transfer is constructed (before signing), the wallet provider populates the originator fields from the bound KYC. For transfers above threshold, also populates beneficiary fields if available.
4. preSign sanctions hook — counterparty screen on every transfer. Synchronous, fail-closed. Cache + background refresh against the same sanctions lists. Block hits.
5. Audit log per signature. Every signed transaction tied to user ID, KYC tier, sanctions-screen result, Travel Rule data. Exportable for SOC2, regulator letters, and incident response.

Openfort's smart-account wallets expose those hooks directly. The KYC vendor is your choice — Sumsub, Persona, Dotfile, in-house — and the policy engine reads the tier without caring how it was verified.

The 12-item KYC readiness checklist for a stablecoin app

Print this. Tick it before go-live.

1. Tier map defined — Tier 1 / 2 / 3 limits documented and approved by compliance.
2. Primary KYC vendor selected; integration tested in staging.
3. Regional KYC vendor(s) selected for any non-Tier-1 jurisdiction; integration tested.
4. Wallet provider's setUserKYCTier (or equivalent) wired to vendor webhooks.
5. Sanctions list provider chosen (OFAC SDN at minimum; EU consolidated and UK OFSI if EU/UK users).
6. onSignerInit sanctions hook active. Fail-closed verified.
7. preSign sanctions hook active on every outbound transfer. Fail-closed verified.
8. Travel Rule plumbing tested for EU users (TFR — every transfer) and for US/SG/AE users above threshold.
9. Audit-log retention configured (minimum: 5 years for EU AMLD-aligned obligations, 5 years for US BSA).
10. Geographic gating in place — FATF blacklists rejected; sanctioned jurisdictions hard-blocked.
11. Tier-upgrade flow tested — user can re-verify to a higher tier mid-session.
12. Incident-response runbook for sanctions hits, KYC vendor outages, and Travel Rule data-exchange failures.

Common failure modes

1. "The wallet provider runs KYC for me." They don't — they provide the hooks. You bring the vendor and own the user relationship.
2. "Self-custodial means no KYC." It usually means you're not the CASP. It does NOT mean you skip user-onboarding KYC, sanctions screening, or financial-promotions compliance.
3. "I'll add KYC later." EU TFR has been in force since December 2024; MiCA CASP cliff lands in July 2026; GENIUS-cascade tightens through 2028. Retrofitting KYC across an existing user base is 5–10× the cost of shipping it from day one.
4. "My KYC vendor handles sanctions." Most do — for the user's primary identity. They don't run sanctions on every outbound transfer counterparty. That's the wallet provider's pre-sign hook.
5. "Travel Rule is for big transfers only." Not in the EU. TFR applies to every CASP transfer with no threshold since December 2024.

Conclusion

Stablecoin KYC isn't a vendor decision. It's a perimeter decision: who is the issuer, who is the wallet provider, who is the builder, and which obligation crosses your line. Pick a wallet provider that exposes the five hooks above and you can compose your KYC stack from off-the-shelf vendors. Skip those hooks and you'll be re-platforming when the next enforcement letter lands.

For the full regulatory landscape, see Stablecoin Regulation and Licensing. For the payment-rails view of the same obligations, see Stablecoin Payment Rails. For the integrator-side of the GENIUS Act in particular, see The GENIUS Act for App Builders.

Ready to wire KYC + sanctions + Travel Rule hooks into your wallet flow? Start with the Openfort docs or talk to us at pricing.

Related reading

• Stablecoin regulation and licensing
• Stablecoin payment rails
• The GENIUS Act for app builders
• Treasury wallet for stablecoins
• How to build a fintech with stablecoins
• Building stablecoin remittances infrastructure