Most game economies start as an afterthought — a handful of integers in a database, a store screen bolted onto a gameplay loop that was designed without monetization in mind. Then the game gets traction. Players start spending. A creator marketplace opens. An esports prize pool gets announced. Suddenly those integers are real money, and the systems holding them are not designed for what they're being asked to do.
This piece is for studios that are past the "let's add IAP" stage and thinking seriously about building a game economy that can handle real value. That means wallets, ledgers, payout flows, and the compliance infrastructure that sits underneath all of it.
Hard Currency, Soft Currency, and the Ledger That Connects Them
Before you can think about compliance, you have to have a clear model of what your economy is actually doing. Most GaaS (games-as-a-service) titles run a two-currency system: a hard currency purchased with real money (Gems, Credits, Platinum — whatever you call it) and a soft currency earned through gameplay (Gold, Coins, XP tokens). They're not interchangeable in both directions by design — the one-way valve from hard currency to soft is a deliberate monetization mechanic.
The problem emerges when real-money value needs to move back out. Prize pools, creator earnings from player-generated content marketplaces, esports tournament payouts, and referral bonuses all require the platform to disburse real funds to real people. At that point, you're no longer managing a closed-loop virtual currency system — you're transmitting money, and the regulatory treatment changes significantly.
A clean economy design separates these concerns at the data layer from day one. Your wallet schema should distinguish between:
- Virtual currency balances — hard and soft, denominated in your in-game unit
- Custodial cash balances — real fiat value held on behalf of a player or creator (subject to money-transmission rules)
- Pending holds — funds locked during a transaction or dispute process
Conflating these in a single integer field is how studios end up with ledger reconciliation nightmares when they try to process their first creator payout batch.
The Ledger Architecture: Double-Entry or Bust
A game economy ledger is not a bank ledger, but it borrows the same foundational principle: every transaction should have a debit and a credit, and the system should be able to reconstruct any balance at any point in time from the transaction log alone.
Studios that implement balance as a mutable integer field — just UPDATE wallet SET balance = balance - 100 WHERE user_id = ? — are building technical debt that compounds with scale. When a dispute comes in six months later and someone needs to reconstruct a player's balance history, that field gives you nothing. When your payment processor reports a settlement discrepancy, you have no audit trail.
A minimal double-entry approach looks like this: every wallet operation creates an immutable transaction record with from_wallet_id, to_wallet_id, amount, currency_code, tx_type, and a created_at timestamp. The current balance is derived — SUM(credits) - SUM(debits) — or cached in a separate balance table that's reconciled against the log on a schedule. Either way, the source of truth is the log, not the cached integer.
This matters for compliance too. FinCEN's recordkeeping rules under 31 CFR Part 1022 require money services businesses to maintain transaction records for a minimum of five years. If your ledger can't produce those records, you have an exam problem, not just a technical one.
When Soft Currency Becomes a Regulatory Question
Most virtual currency lawyers will tell you that closed-loop systems — currency that can only be spent within the game and cannot be redeemed for real money — are generally not subject to money-transmission regulation. The FinCEN guidance from 2013 (FIN-2013-G001) drew a line between "convertible virtual currency" and non-convertible systems, and most purely in-game soft currencies fall on the non-regulated side.
We're not saying virtual currency is inherently risky from a regulatory standpoint. The question is whether real value exits the system, and through what mechanism.
The regulatory picture changes when:
- Players can sell virtual items for real money through a studio-operated or third-party marketplace
- Tournament prizes or creator earnings are denominated in hard currency and then cashed out
- A referral or affiliate program pays out real money to players based on in-game activity
- Your "hard currency" can be gifted or transferred between players (peer-to-peer value transfer)
A mid-core PC strategy studio we've spoken with — about 30 people, Stockholm-based, shipping their second title — ran into exactly this when they launched a map-creation marketplace in late 2024. Creators uploading content were earning hard currency, and the studio planned to let creators cash out those earnings quarterly. Three months before launch, their legal team flagged that the cash-out mechanism might constitute money transmission in multiple US states where their player base was concentrated. The marketplace launched without the cash-out feature while they sorted the compliance question, costing them creator acquisition momentum in the process.
The right time to ask these questions is during economy design, not three months before launch.
Wallet Provisioning: Per-Player vs. Per-Game vs. Shared
There are three common wallet provisioning models, each with different engineering and compliance implications.
Per-player, per-game wallets are the simplest model: each player gets one wallet per title. Balances are isolated; there's no cross-game complexity. This works well for studios with a single title or titles with completely separate economies. The downside is that when you eventually want cross-game portability — letting players carry earned currency from Title A to Title B — you have to build a transfer mechanism after the fact, which is considerably harder than designing it in from the start.
Per-player, studio-shared wallets give each player a single wallet across all of your studio's titles. Hard currency purchases in any title add to the same balance; spending in any title draws from it. This makes cross-game promotions straightforward and simplifies financial reporting, but it introduces exchange rate complexity if your titles use different currency units.
Publisher-level hierarchy is the model for multi-studio setups: each studio has its own wallet system, but a publisher-level account sits above them and can move funds between studios, set shared currency rules, and aggregate reporting. This is more infrastructure than most independent studios need, but if you're a publisher managing five or more titles from multiple development teams, it becomes essential for consolidated reporting.
Payout Infrastructure: The Part Studios Underestimate
Getting money out to creators and tournament winners is where most studios hit unexpected friction. The problems are not usually technical — they're compliance-operational. Before you can disburse funds to a player, you need to know: who they are (KYC), whether they're subject to sanctions screening (OFAC), what their tax reporting obligations are (1099-K for US-based earners above IRS thresholds), and through what channel the money should flow.
ACH (Automated Clearing House) is the lowest-cost domestic payout method — typically $0.20–$0.50 per transfer — but it requires the recipient to provide verified bank account details and takes 1–3 business days to settle. PayPal and other digital wallets settle faster and don't require bank account collection, but carry higher transaction fees (typically 2–3% for payouts) and can have account holds on large disbursements. Virtual card issuance works well for one-time prize payouts and doesn't require bank account collection at all, but comes with its own fee structure and issuer limitations.
The real cost of payouts is not the per-transaction fee — it's the KYC and AML overhead. Every creator earning above the IRS 1099-K threshold ($5,000 for 2024 and beyond) needs identity verification and a valid W-9 or W-8BEN. Running that verification in-house, with proper document collection, liveness checks, and ongoing monitoring, is a significant compliance operation. Most studios should not be running their own KYC stack — the combination of regulatory expertise, ongoing monitoring obligations, and the risk of getting it wrong is not worth it for companies focused on making games.
Linq Games operates as a platform layer, not a bank or money transmitter directly. We partner with regulated financial institutions for fund movement, which means your studio's KYC/AML obligations flow through our compliance infrastructure rather than yours. The distinction matters when you're talking to your lawyers about money-transmission licensing exposure.
The Compliance Architecture You'll Need Eventually
If your economy design includes real-money outflows to players — prizes, creator earnings, marketplace proceeds — you're eventually going to need to engage with these compliance building blocks:
FinCEN MSB registration is federally required for money services businesses. Registration itself is free and relatively straightforward, but it carries ongoing suspicious activity reporting (SAR) obligations and BSA program requirements.
State money-transmitter licenses (MTLs) are where the real complexity lives. Most states require separate licenses, each with its own application, surety bond, and examination process. A handful of states — notably Montana, South Carolina, and a few others — have specific exemptions that may apply depending on how your economy is structured. New York's BitLicense framework applies to virtual currency businesses operating in the state. Getting full US coverage typically takes 12–24 months and meaningful legal spend.
PCI-DSS compliance governs how cardholder data is handled. If your IAP purchases touch a payment card — which they do unless you're running entirely through an app store's billing system — you need to understand your PCI scope. More on this in a separate piece.
The point is not to make this sound impossible — studios much smaller than yours have navigated this. The point is that getting the economy architecture right from the start makes the compliance journey considerably shorter. A clean double-entry ledger, clear separation of virtual and fiat balances, and payout flows built on top of compliant infrastructure is the foundation. Everything else is implementation.
Get the ledger right first. Everything downstream — payouts, compliance reporting, cross-game currency, even fraud detection — is easier when the data model is clean.