Compliance Architecture
Data boundaries, KYC flows, and regulatory framework
Data Boundary Architecture
Developer's Domain
Zero PII, zero PCI scope
- Tokenized userId (
usr_xxx) - Tokenized bankAccountId
- Masked last4 digits
- Status webhooks
- KYC tier (1/2/3)
- Balance amounts
Developer NEVER receives:
- Real names
- SSN / government IDs
- Bank account numbers
- Address data
- Identity documents
DBZ's Domain
Fully licensed, compliant
- Full legal name
- SSN / TIN
- Government ID documents
- Bank account + routing numbers
- Address verification
- Sanctions screening (OFAC)
- Transaction monitoring
- SAR filing
- 1099-NEC tax reporting (>$2K)
- ACH origination
- Plaid integration
- PCI-compliant vault
KYC Verification Sequence
Sweepstakes Distinction (AB 831)
California AB 831 (effective Jan 1, 2026) bans sweepstakes casinos that use dual-currency models. Connecticut, New Jersey, Nevada, and Montana have passed similar laws.
| Factor | Sweepstakes Casinos (banned) | DBZ Virtual Currency (legal) |
|---|---|---|
| How players earn | Purchase gold coins, receive sweeps coins as "bonus" | Earn through gameplay skill/performance |
| Outcome determination | Chance-based (slots, roulette) | Skill-based (game performance, tournament ranking) |
| Virtual currency source | Purchased or received as promotional bonus | Earned through measurable gameplay actions |
| Cash-out mechanism | Sweeps coins to cash (disguised gambling) | Earned coins to USD via licensed money transmitter |
| Regulatory classification | Illegal gambling (AB 831) | Licensed money transmission (FinCEN MSB + state MTLs) |
API-level protection: The ledger API enforces that virtual currency can only be credited via POST /v1/ledger/credit (called by the developer's server, not purchased by the player). There is no endpoint for players to directly buy virtual currency with cash and then convert it back — that would be a sweepstakes model.
For PII edge cases, payout compliance flow, and developer communication strategy, see Research.
Player Journeys
The same platform from the player's perspective
Journey 1: Casual Player Earns a Reward
- 1. Player wins a match — In-game notification: "You earned 500 Gold Coins!" No signup, no KYC — Tier 0, coins credited instantly via ledger API.
- 2. Player accumulates 2,000 Gold Coins — In-game prompt: "Cash out your coins? Convert to $20.00." Player taps "Cash Out."
- 3. First cash-out triggers KYC — Game opens DBZ's hosted verification page (Tier 1: name, DOB, country). Takes under 2 minutes. No SSN, no ID upload for amounts under $200/month. Player redirected back to game.
- 4. Player links bank account — DBZ's hosted Plaid flow opens. Player selects their bank, logs in. Game never sees bank details. Player sees "Chase ****6789 linked."
- 5. Player receives payout — Conversion: 2,000 Gold Coins to $20.00 to DBZ wallet to ACH to bank. Arrives in 1-2 business days (instant via Lightning if player uses DBZ wallet).
Journey 2: Competitive Player Enters a Tournament
- 1. Player sees "Friday Night Showdown" — $5 entry, $225 first prize. Player taps "Enter Tournament."
- 2. Entry fee flow — If wallet has $5+: instant debit, entry confirmed. If wallet is empty: "Load your wallet" via Plaid bank link or DBZ checkout (card). Entry fee held in escrow.
- 3. Geo + age check (invisible to player) — DBZ checks GPS + IP (player is in Texas — skill gaming legal). KYC confirms player is 22. If player were in Arkansas: "Cash tournaments aren't available in your area. Try a Gold Coin tournament instead!"
- 4. Player competes and wins — Game submits results via API. Player sees: "1st Place! $225 prize credited to your wallet."
- 5. Player cashes out winnings — $225 credited to DBZ wallet (from escrow). Player taps "Withdraw to bank" — ACH payout initiated. Arrives in 1-2 business days.
Journey 3: Player Buys Items via Web Store
- 1. Player sees in-game banner — "20% off Gold Coin packs — buy direct!" Link opens game's web store (not app store).
- 2. Checkout — DBZ's hosted checkout page loads with Apple Pay / card options. Player pays $7.99 for 1,000 Gold Coins (vs. $9.99 through App Store IAP). Studio saves on app store fees, passes some savings to player.
- 3. Coins credited — Webhook fires, game credits 1,000 Gold Coins instantly. Player returns to game with coins ready to spend.
Why the Player Perspective Matters for API Design
| Player Need | API Design Implication |
|---|---|
| Instant feedback ("I won!") | Ledger credit is synchronous, returns balanceAfter immediately |
| Minimal friction to earn | Tier 0 KYC (email only) for earning — no barriers to engagement |
| Friction only at cash-out | KYC triggered by conversion/payout, not by earning |
| Trust that money is safe | Escrow model for tournaments — entry fees protected from studio manipulation |
| Know when money arrives | Webhook-driven push notifications with estimatedArrival on payout object |
| Fallback when restricted | Virtual currency tournaments available globally, cash only where legal |
| Transparent fees | Payout object includes fee field so players see exactly what they receive |
Roadmap
6-month phased rollout, each phase building on the infrastructure of the last
Ship:
- Users & Identity API (registration, OAuth2 login)
- Wallet balance + transaction APIs
- Wallet load from linked bank account (virtual currency purchase)
- DBZ Checkout Widget (hosted payment for web stores)
- Webhook infrastructure
- Developer portal: docs, API keys, sandbox
Why first: Leverages DBZ's existing payment infrastructure (Lightning charges, project wallets) most directly. Revenue flows in from day one — players buying virtual currency and web store items. No third-party integrations needed (no Plaid, no ACH). Fastest path to value for studios.
Parallel work: Begin Plaid partnership and ACH integration conversations (long lead time for Phase 3).
Ship:
- Currency configuration API
- Ledger APIs (credit, debit, transfer, balance)
- Tournament APIs (create, enter, results, settle)
- Escrow system for tournament buy-ins
- Geo-fencing for cash tournament eligibility
- Anti-fraud rules (velocity checks, pattern detection)
Why second: Builds directly on Phase 1 — players already have wallets with virtual currency, now they can earn it through gameplay and spend it in tournaments. Creates the demand for Phase 3: players accumulate currency they want to cash out. Tournaments are the killer demo because they exercise every API in one use case.
Ship:
- Bank Account Linking API (Plaid-powered hosted flow)
- Conversion API (virtual currency to fiat)
- Payout API (create, retrieve, list, cancel, retry)
- Full KYC tier system (Tier 0-4 with progressive verification)
- Hosted KYC widget (all tiers)
- Tax reporting infrastructure (1099-MISC at $2K threshold)
Why last: Most complex workstream — requires Plaid integration for bank linking, ACH rails for settlement, full KYC/AML pipeline, and tax reporting. Shipping last gives time to finalize third-party partnerships (started in Month 1) while Phases 1-2 generate revenue and prove product-market fit. By this point, players have currency they want to cash out, creating natural pull for the feature.
Phase Gates
| Gate | Phase 1 to 2 | Phase 2 to 3 |
|---|---|---|
| Technical | Webhook infra handles 10K+ events/day; checkout completion rate >60% | Ledger + escrow can process 100K+ txns/day |
| Compliance | Virtual currency purchase flow reviewed by compliance counsel | KYC pass rate >70%; Plaid integration tested; skill-gaming legal review complete for target states |
| Business | 3+ studios live with wallet loading + checkout | Tournament pilot with 1+ studio; Plaid + ACH partnerships finalized |
| DX | Time-to-first-checkout under 2hrs in sandbox | Time-to-first-payout under 2hrs in sandbox |
For execution risks and fallback plans, see Research. For success metrics, see Research.