What this workstream is

Money flows from the studio to the player's bank account. When a player earns a reward — wins a ranked match, completes a challenge, finishes a tournament — the game server validates the event and calls DBZ's API to initiate a bank payout. The player never interacts with DBZ directly; they see "+$0.25 earned" in-game and can withdraw to their bank whenever they choose.

The studio controls when and why players get paid (business logic). DBZ handles how the money moves (banking rails, KYC screening, tax reporting, compliance). This separation is the core design principle.

What the developer codes

What DBZ handles automatically

The developer triggers these flows with a single API call each, but DBZ does all the heavy lifting through hosted UIs. The developer never builds verification screens or bank linking forms.

Key design decision: Tier 0 allows unlimited earning with no verification — just like Skillz and Mistplay. Players accumulate rewards freely and only hit KYC when they want to cash out. This removes the friction that kills adoption. The developer calls the same endpoint (POST /v1/users/{userId}/verify) regardless of tier — DBZ auto-determines the required verification based on payout volume.

Regulatory anchors

• $3,000 Travel Rule (31 CFR 1010.410) — the key federal threshold. Above this, name + address + ID number are required.
• 1099-MISC at $2,000 (starting 2026, per OBBBA) — triggers W-9/SSN collection for tax reporting on gaming prizes.
• SAR filing at $2,000+ — suspicious activity reports required regardless of KYC tier.
• MSBs are not subject to CIP — unlike banks, money transmitters don't have a Customer Identification Program requirement. KYC thresholds are risk-based, not prescribed.

Retry strategy

For retryable failures, use exponential backoff: 1 min → 5 min → 30 min → 2 hours. Stop after 4 attempts. Always reuse the same Idempotency-Key to prevent duplicate payouts.

Webhook delivery also uses exponential backoff (1 min → 5 min → 30 min → 2 hr → 24 hr). If your endpoint is down, DBZ retains events for 72 hours and replays them via POST /v1/webhooks/replay.

What this workstream is

Money flows from the player's bank account into virtual currency on DBZ's ledger. The player links their bank (via Plaid), purchases virtual currency (e.g., PokeCoins, Halo Credits), and uses it for in-game purchases, tournament buy-ins, or gifting. This is the "on-ramp" — converting real money into the game economy.

This also powers the web store checkout flow: players buy items directly from the studio's web store (bypassing platform fees at 3% vs 30%), paying with their linked bank account or existing virtual currency balance.

Why the wallet holds virtual currency, not USD

This is a deliberate regulatory design choice with major compliance implications:

This is why V-Bucks, Robux, and every major game currency is structured as a one-way purchase — it avoids money transmission on the buy side. DBZ's innovation is adding the cash-out direction (Workstream 1), which requires the MTLs they already have. The buy side is just a normal digital goods transaction.

How the three workstreams form a loop

• Workstream 2 (this one): USD → Virtual Currency (buying credits)
• Workstream 3: Virtual Currency ledger (earning, spending, transferring)
• Workstream 1: Virtual Currency → USD (cashing out to bank)

What this workstream is

Once a player has virtual currency (from Wallet Loading or gameplay rewards), this workstream manages what they do with it: earn more through gameplay, spend on in-game items, transfer to other players, enter tournaments, and cash out to real money.

The key differentiator from V-Bucks or Robux: this currency is convertible. Value flows both ways. When a player cashes out, POST /v1/ledger/convert internally triggers the Payout to Bank flow — the same KYC tiers and compliance apply.

Cash-out triggers the Payout to Bank flow

When a player calls POST /v1/ledger/convert, DBZ internally: (1) debits the VC from the player's ledger, (2) applies the studio's conversion fee, (3) checks the player's KYC tier, (4) initiates a bank payout via Workstream 1. The developer doesn't need to orchestrate this — one API call handles the full conversion-to-payout chain.

If the player hasn't completed KYC yet, the response includes a verificationUrl — same hosted flow as Workstream 1.

Why a conversion fee?

The cash-out fee (set by the studio, typically 10-20%) serves two purposes: (1) it discourages players from immediately converting earned credits to cash, keeping currency circulating in the game economy, and (2) it creates a revenue stream for the studio on conversions. Players know the fee upfront — transparency builds trust.

How tournaments work