Player Account Management (PAM)

Player account management (PAM) is the layer of an iGaming platform that owns user identity and user money: who the user is, what they may do, what they hold and every transaction they have ever made. On the Vuch platform, the PAM layer is formed by the identity and wallet services at the core of the stack — authentication and role management, a unified wallet shared by prediction markets and casino, USDT payment rails, and a complete, atomic transaction history that every other module reads from and writes to.

Nothing regulated happens on the platform without passing through this layer. A prediction market trade, a casino game round, a deposit webhook and an admin balance correction are all, in the end, entries in the same ledger under the same identity.

What the PAM layer covers

One wallet across two products

The defining design decision of the Vuch PAM is that there is exactly one balance per user. The industry norm — a casino balance here, a trading balance there, transfer buttons between them — fragments liquidity and adds friction at exactly the moments an operator wants none. On this platform:

• A user deposits once and the funds are live in both products immediately.
• A prediction market position and a casino session draw on the same balance; winnings from either are instantly available to the other.
• The operator's view of the user is one financial record, not a reconciliation exercise between product silos.

This is enforced structurally: the wallet service is the single financial authority, and both the markets module and the casino module transact against it. The casino side uses seamless wallet callbacks — game providers debit and credit the unified balance per game round in real time through the platform's adapter layer, so there is no separate casino purse and no fund-transfer step in the player journey.

The atomic ledger

Every balance-changing operation is an atomic entry in the platform's financial ledger — the core the entire event-driven architecture is built around. The properties operators get from this:

• Consistency by construction. A trade settlement, a game-round debit and its corresponding win credit either complete fully or not at all. There are no half-applied operations to chase.
• One history, fully queryable. The admin panel's Users section exposes the complete transaction history per user — deposits, withdrawals, trades, game rounds, corrections — as one chronological record.
• Auditability without archaeology. Because reports, balances and risk scoring all derive from the same ledger events, the number finance reconciles and the number the regulator sees are the same number.

Ledger events also feed the platform's event bus, where they become inputs to risk scoring — velocity monitoring, AML signals and the alert pipeline all watch the same stream the wallet writes.

Payments: USDT rails, moderated withdrawals

The finance module attached to the wallet handles money in and out:

• USDT deposits and withdrawals. The current payment layer is USDT-based, which makes the platform a natural fit for crypto-friendly jurisdictions. A fiat payment layer is positioned on the roadmap for operators targeting markets where crypto rails are restricted.
• Payment provider webhooks. Incoming provider callbacks are verified and processed by the payment service, crediting the ledger only on confirmed events.
• Manual withdrawal moderation. Withdrawals pass through a moderation queue with a status model tracking each request from submission through review to approval or refusal, with a full audit trail of decisions in the admin panel. Risk signals from Vuch Shield surface alongside the queue, so reviewers decide with context.

Identity, roles and administration

Authentication and authorization are a dedicated identity service: account lifecycle, sessions, and role-based access control that separates players from operator staff and administrator functions. On the operations side, the admin panel's Users section gives support and compliance teams verification workflows, user search, balance corrections and the full transaction history — with each administrative action recorded as an auditable operation.

Real-time state for the user

The PAM layer is wired to the platform's realtime module: balance updates are pushed to clients over WebSocket the moment the ledger commits, alongside the live trade feed and market resolution notifications. For users, money on this platform behaves like state in a live application, not like a figure that refreshes on page load.

Technical notes

The wallet and identity services are two of the platform's twelve microservices, communicating over the event bus (47 event types) behind a single API gateway. The stack is React 18 + TypeScript, Node.js 22 + Express, Drizzle ORM on PostgreSQL 15, Redis with WebSocket for events and realtime, deployed via Docker Compose — detailed on the tech stack page. REST endpoints for players, wallets and payments are summarized in the public API overview; internal topology is shared during technical evaluation rather than published.

Vuch does not publish blanket certification claims for this layer or any other; a certification roadmap and due-diligence pack are available on request, and compliance configuration — including risk thresholds — is set per jurisdiction during deployment.

Next step

The PAM layer demos best as a sequence: register a user, deposit USDT, trade a market, play a game round, request a withdrawal, and then read the entire story back as one transaction history in the admin panel. Request a demo and bring your finance lead — the ledger is the part of the platform they will interrogate hardest.