US iGaming compliance is not a legal checklist you finish at the end. Instead, it is a set of controls you build into identity, location, and money flows. So, launch readiness depends on engineering and operations, not only policy.
This checklist is for engineering leads, payments ops, and compliance teams. It focuses on what you must decide, build, document, and prove before go-live.
Quick Launch-Ready Summary
You are ready when:
- You can explain your state-by-state scope and enforce it in product flows.
- You can prove KYC, geolocation, AML monitoring, and responsible gambling controls work end to end.
- You can produce audit trails fast, with stable IDs and timestamps.
- You can show internal controls, ownership, and independent checks.
State-By-State Reality: Build a Jurisdiction Matrix First
A jurisdiction matrix is a versioned map of what each state allows and what you must prove. It connects product scope + control requirements + vendor constraints + reporting duties to your feature flags and evidence exports.
US iGaming is not one market. Therefore, start with the matrix. Otherwise, teams ship a “default” flow and patch it late.
What to include in your matrix (per state)
- Product scope: casino, poker, sportsbook, or hybrid (plus web/iOS/Android and skins).
- Age + identity: age threshold, KYC depth, and where you hard-block.
- Geolocation: when you check, when you re-check, and border behavior.
- Vendor constraints: KYC, geo, PSP, games, hosting, labs, and approvals.
- Responsible gambling: limits, cooling-off, self-exclusion, and enforcement rules.
- Reporting + incidents: report cadence, incident triggers, notification timelines.
- Marketing restrictions: minors, excluded players, and promo suppression.
| State | iGaming launch date | Regulator | Operating model | What it means for your build |
|---|---|---|---|---|
| Michigan | iGaming launched Jan 22, 2021 (michigan.gov) | Michigan Gaming Control Board | Tribal + commercial partners | Must support multiple partner patterns and clear separation of duties across operator/vendor/tribe workflows. |
| West Virginia | First online casino operator launched July 15, 2020 (DraftKings IR / draftkings.gcs-web.com) | West Virginia Lottery | Licensees under lottery oversight | Treat it like a regulated market, but smaller. Logging + geo + payments controls still need full audit readiness. |
| Connecticut | Full iCasino launch Oct 19, 2021 (CT.gov) | Connecticut Department of Consumer Protection | Limited operator structure (tribal/lottery framework) | Fewer operators = tighter governance. Expect strict vendor control and strong enforcement optics. |
| Delaware | iGaming live since 2013; major platform relaunch Jan 3, 2024 (Delaware Lottery) | Delaware Lottery | Lottery-run model with state-selected vendor | More “central” control. Your compliance ops must align to lottery reporting and platform constraints. |
| Rhode Island | Online casino launched Mar 5, 2024 | RI Department of Revenue (Lottery + related regulators) | Highly centralized state oversight | Treat geo + age + RG tooling as “must work at launch,” not phased later. |
| Maine | Internet gaming bill became law Jan 11, 2026 (legislature.maine.gov) | Implementation pending rules/licensing | Not live yet | Build your state module now (toggles + geo boundaries + reporting hooks). Go-live timing depends on rulemaking + licensing execution. |
Internal Controls: Define Ownership, Checks, and Proof
Internal controls are the roles, approvals, and system checks that stop unsafe changes and prove compliance during audits.
Compliance breaks when controls stay in documents. Therefore, make controls testable inside the product and ops workflows.
Ownership and escalation
- Compliance: interprets rules and handles regulator responses
- Engineering: builds controls, logging, and evidence exports
- Payments ops: owns PSP setup, monitoring, settlement, disputes
- Support: handles self-exclusion, player comms, escalations
Daily control habits
Lock who can change limits, risk rules, and payout settings.
Require approvals for sensitive changes, not just access.
Run independent reviews for high-risk workflows.
Track training, role changes, and policy updates.
| Control area | What must exist before go-live (engineering + ops) | Proof / evidence exportable on demand | State USP emphasis (where it hits hardest) | ROI impact (business outcomes) |
|---|---|---|---|---|
| Licensing & scope | State scope locked (products, channels, skins, partners). Only allowed states enabled. | Versioned scope matrix + approvals + environment config snapshots. | MI partner patterns, NJ multi-skin, ME feature flags first | Faster state rollout, fewer rework cycles, fewer launch delays |
| Identity (KYC/age) | End-to-end KYC flows incl. fail/retry/manual review; age gating enforced everywhere. | KYC decision logs, reviewer actions, timestamps, evidence retention refs. | CT/RI strict onboarding expectations, NJ fraud pressure | Higher signup→deposit conversion, lower chargebacks, lower manual review cost |
| Geolocation | Geo checks at login + pre cash-in/out + pre wagering + re-check during session. | Geo result logs (method, confidence, reason codes, triggers, user message). | NJ/PA border/commuter reality, RI in-state enforcement optics | Fewer false blocks, higher deposit rate, fewer geo disputes and escalations |
| Wallet & cashier | Ledger is source of truth; idempotent payments; chargeback/reversal handling. | Immutable txn trail + recon report + webhook idempotency evidence. | DE/WV ops efficiency, NJ high volume edge cases | Stops double credits, reduces leakage, faster settlement, fewer disputes |
| AML & fraud monitoring | Unified pipeline across identity + wallet + gameplay; case workflow + reason codes. | Alert→case→disposition with rule versions + analyst IDs + exportable reports. | PA “prove it” audits, NJ alert volume | Lower regulatory risk, fewer manual investigations, better fraud loss control |
| Responsible gambling | Limits + cooling-off + self-exclusion enforced at platform/ledger layer (not only UI). | Limit history + enforcement logs + exclusion lifecycle (request→active→blocked). | CT/RI early trust, NJ/PA scrutiny + scale | Fewer escalations, better retention via trust, lower enforcement risk |
| Logging & audit trail | Stable IDs (player/session/txn/correlation); consistent timestamps; admin action audit. | “Reconstruct a session” export within hours, includes admin + rule versions. | PA/NJ fastest audit expectations | Cuts audit time, reduces lab rework, speeds incident resolution |
| Game/RNG & change control | Approved builds; controlled release + rollback; config/version governance. | Build IDs, release notes, approvals, effective-from timestamps, “live at wager time.” | NJ frequent updates, MI partner-driven releases | Faster certified releases, fewer rollbacks, lower downtime risk |
| Reporting & incident response | State reporting calendar + thresholds; incident triage runbooks. | Sample reports + incident templates + escalation contacts + timelines. | DE cadence-heavy ops, PA/NJ incident scrutiny | Avoid penalties, reduce downtime cost, faster regulator-ready comms |
| Vendor governance | Approved vendors only; SLAs, monitoring, outage playbooks. | Due diligence pack + health checks + change notices + incident tickets. | All, but ME (vendor selection) and DE/RI (centralized ops) | Less vendor downtime, higher conversion, fewer blocked sessions |
GLI-19 Control and Log Framing: Use it as a Build Checklist
Fail-Safe rules you should implement
Many jurisdictions and labs use technical standards as a baseline. GLI-19 often appears in interactive gaming certification work. So, use it as a control-and-logging framing tool, even when your state rules differ.
How to Use GLI-19 without Overthinking it
Use GLI-19 as a build checklist that confirms your controls create audit-ready evidence. It keeps engineering, ops, and compliance aligned on what must be provable during certification.
- Can you reconstruct a player session end to end?
- Can you trace admin and configuration changes to a person and timestamp?
- Can you replay balances and transactions from logs without gaps?
- Are timestamps consistent, and is the time source documented?
GLI-Style Logging you should Support (Practical List)
Use this as a coverage map for the event domains labs review during certification and audit sampling. It ensures your evidence stays complete across services, even when workflows span multiple systems.
- Player account lifecycle: registration, verification state changes, lockouts.
- Session tracking: login, logout, timeouts, forced logoffs, device changes.
- Wallet tracking: deposits, withdrawals, reversals, refunds, adjustments.
- Game/session events: wager accepted, wager settled, win/loss posted.
- Rule and content changes: game rules, paytables, RTP displays, player-facing disclosures.
What “Good Logs” Look Like
Good logs let you reconstruct a full timeline without guessing, even across multiple services. They also preserve the exact context that produced an outcome.
- Use a unique player ID and session ID everywhere.
- Add a transaction ID for every money movement.
- Add a correlation ID across services for each user action.
- Timestamp in a consistent timezone, and document the system time source.
- Store the rule version used at decision time, not only the result.
Geolocation Evidence: Treat it like an Audit Object
Geolocation is not only a “pass/fail” screen. Instead, it is evidence that you enforced state boundaries.
When to run Geolocation Checks
Run geo checks at every point where access, money, or wagering risk changes. This reduces disputes and gives you defensible audit proof.
- On login and session start.
- Before deposits and before withdrawals.
- Before gameplay begins.
- During play at intervals, especially after network changes.
- On device changes or spoof-risk signals.
What to Log for Geolocation Evidence
Geo logs should explain the decision, the signals behind it, and what the player experienced. That way, you can defend enforcement during audits and escalations.
- Geo decision result, confidence score, and method used.
- State outcome and boundary distance (when available).
- Denial reason and the message shown to the user.
- Device and network attributes used for risk scoring.
- Re-check trigger (why you re-ran the check).
Fail-Safe Rules you should Implement
If you cannot confirm location, block regulated actions. Also, tell the user exactly what to do next.
AML Hooks: Wire Monitoring into Identity + Wallet + Gameplay
AML does not work if you only look at deposits. Therefore, collect identity, wallet, and gameplay signals in one pipeline.
Build an AML signal pipeline
Create one unified event stream so risk scoring and cases use complete cross-system context.
- Capture events from identity, wallet, and game services.
- Normalize them into a single schema.
- Score activity with rules and risk models.
Create cases with context and a clear reviewer workflow.
Minimum event coverage
Log the core identity, wallet, and gameplay events that drive detection and escalation decisions.
- Registration, login, and device changes.
- KYC tier changes and manual review outcomes.
- Deposit attempts, failures, successes, reversals.
- Bonus grants, wagering progression, and bonus abuse signals.
- Wagers placed, settlements, and rapid churn patterns.
- Withdrawal requests, cancellations, and approvals
Case workflow that stands up to audits
Make every alert and decision traceable with versioned rules, reviewer identity, and exportable proof.
- Each alert stores a reason code and rule version.
- Each case stores reviewer identity, timestamps, and notes.
- Each outcome stores “why” and links to supporting evidence.
- Each export stores a stable report ID and filters used.
Responsible Gambling Hooks: Enforce at the Platform Layer
Responsible gambling is not only UI. Instead, enforcement must live in the platform and wallet layer.
Controls to ship before launch
Deliver the baseline RG features regulators expect to work end to end on day one.
- Deposit and loss limits with clear time windows.
- Session limits and reality checks.
- Timeouts (cooling-off).
- Self-exclusion with immediate enforcement.
- Support resources that are easy to reach.
Enforcement details that Prevent Loopholes
Apply limits and exclusions at the ledger/platform layer so users can’t bypass UI checks.
- Enforce limits in the ledger, not just the front end.
- Propagate exclusion to all apps, skins, and channels.
- Suppress marketing and promos immediately after exclusion.
- Log every change, including when it becomes active.
Evidence to keep
Store clear timelines and enforcement proof so audits and player escalations are easy to resolve.
- Limit setting history and applied enforcement logs.
- Self-exclusion lifecycle logs (request → activation → enforcement).
- Intervention notes for high-risk behaviors.
Audit Trails: Design for Reconstruction, not Screenshots
Auditors ask one core question: “Can you reconstruct what happened?” So, design your audit trails to answer that.
Audit Rail must cover these Domains
Define the minimum evidence surface so reconstruction never fails because a key system is missing.
- Identity: KYC decisions, overrides, and re-check triggers.
- Location: geo decisions, re-checks, and denial reasons.
- Wallet: every credit/debit, with state transitions.
- Admin: privileged actions, approvals, and role changes.
- Content/rules: changes that affect player outcomes or disclosures
Build an “Audit-Ready” Event Model
Store durable, structured events that export cleanly and remain consistent across versions.
- Use immutable append-only event storage for core events.
- Separate operational logs from audit events.
- Protect audit logs with restricted access and read logging.
- Store schemas and versions, so exports remain consistent.
Change Management that Labs Trust
Prove what changed, who approved it, and what configuration was active at wager time.
- Version configs, risk rules, and payout logic.
- Require approvals for sensitive changes.
- Keep release notes tied to build IDs.
- Preserve “what was active at wager time” logic.
Final 7–14 Day Go-Live Drill
Go-live is a gate. Therefore, test your controls like users will break them.
Stop/Go Checklist
Validate every high-risk control in production-like conditions before you open real money traffic.
- State matrix completed and signed off.
- KYC tiers tested, including failure and retry paths.
- Geo checks tested at boundaries and after network changes.
- AML monitoring running with tuned thresholds and case workflow.
- Cashier tested for reversals, retries, and duplicate webhook calls.
- RG controls are verified across web, iOS, and Android.
- Audit exports generated from production-like data.
After Launch: Weekly Controls that Prevent Drift
Keep thresholds, access, and vendor performance stable so compliance doesn’t degrade over time.
- Review AML alerts and tune thresholds.
- Review payout exceptions and manual adjustments.
- Audit admin actions and access changes.
- Run vendor health checks for KYC and geolocation.
- Refresh public-facing terms and risk notices
For rollout planning beyond one market, review poker licensing costs, jurisdictions, and timelines before you lock budgets and vendor contracts.
Conclusion
US iGaming go-live readiness comes from enforceable controls, not last-minute paperwork. First, lock a state-by-state matrix so only approved states, products, and partners are enabled. Then, prove KYC, geolocation, AML, and responsible gambling controls work end to end, backed by audit-ready logs and fast evidence exports. SDLC Corp helps teams implement these controls, harden payment and geo workflows, and structure audit trails so launches hold up under lab and regulator scrutiny.
FAQs
What does “state-by-state compliance” mean for a US iGaming launch?
It means you cannot ship one rule set and hope it works everywhere. Instead, you must map requirements per state. Then you must enforce them in identity, geolocation, and payments flows.
What logs should we prepare for GLI-19 style testing and certification?
Prepare logs that reconstruct player sessions, wagers, and wallet movements. Also log admin actions, config changes, and rule versions. Finally, keep consistent timestamps and stable IDs across systems.
What geolocation evidence should operators store for audits?
Store decision results, confidence signals, method used, and denial reasons. Also store re-check triggers and the user messaging shown. That way, you can prove enforcement over time, not only once.
How do AML hooks connect to KYC tiers in iGaming?
KYC tiers define what you allow a player to do. Meanwhile, AML monitoring defines what you investigate and escalate. Therefore, trigger tier upgrades and reviews based on deposit, withdrawal, and gameplay risk signals.
Which responsible gambling controls must be enforced at the platform layer?
Deposit limits, loss limits, and self-exclusion must be enforced in the ledger and identity layer. Otherwise, users can bypass UI checks. Also suppress marketing immediately after exclusion.
What makes an audit trail “good” for regulators and labs?
A good audit trail lets you reconstruct outcomes fast. It uses stable IDs, consistent timestamps, immutable events, and versioned rules. Also, it shows who approved sensitive changes and why.
