Operator guideENplayerskycdocumentsverification

Players / KYC Status

KYC tab inside the player workspace for browsing user documents, checking third-party verification state, and approving, rejecting, or re-requesting documents.

Reader view

Clean portal guidance

This page keeps the operator explanation, field and action descriptions, and screenshots visible without exposing repo paths, raw sidecars, or editorial-only implementation details.

Narrative content

Page body

What this tab shows

Players / KYC Status is the player-level document and verification workspace. It shows submitted or requested documents, verification tags, provider verification state, the action controls used to approve or reject document items, and the separate used-cards document block for successful deposit cards.

When to use it

Use this tab when you need to:

  • review the player's uploaded verification documents
  • filter KYC documents by tag
  • inspect external verification status from Bynn or SumSub-related flows
  • approve, reject, cancel, or re-request a document
  • review previously used deposit cards and their document status

How to read it

The tab is centred on a paginated document table. Each row represents one user-document record and can include:

  • a document preview
  • tag chips
  • third-party verification state
  • operator/actionee metadata
  • one or more KYC actions based on the current status

Below the document table, the tab renders a second block: User success deposit cards. That block merges successful deposit-card history with stored card-document records so operators can see which cards already have submitted documents and open Update/View for that card.

Known caveats

  • 3rd Party Verification and 3rd Party Verification Date are provider-status summaries. They do not replace manual operator review of the actual document.
  • The real provider-backed path on this tab is Bynn. SumSub values visible on the list are currently controller-injected placeholder fields and should not be treated as confirmed provider evidence.
  • The action buttons depend on the document status. Pending records expose approve/reject actions, while requested or completed records expose a different action set.
  • The row-level Verify by 3rd Party icon is visible for bynn documents, but its list-level click handler is not wired to the backend yet. The working Bynn submission flows currently live in the approval modal and the manual Bynn verification modal.
  • Bynn-style dossier/report links appear only for documents where that provider context exists.
  • User success deposit cards is a separate merged dataset. It is built from successful deposit transactions plus UserCardsDocuments, so card rows can exist in required state even when no card-document record has been submitted yet.
  • The card-document Update/View modal saves back through POST /api/admin/user-cards-documents; it is not part of the main verify-user-document document flow.

Verification status

  • status: verified_backend
  • last verified: 2026-04-18
  • note: document listing, KYC mutation routes, used-card document reads/writes, and Bynn helpers are traced through useUserDocument, useUserCardsDocuments, verify-document-bynn, and the third-party history/dossier helpers.
Grid columns

Columns

field

Document ID

Internal identifier for one user-document record.

Group
document_table
Data Type
integer
field

User ID

Links the document row back to the owning player.

Group
document_table
Data Type
integer
field

Document Name

Document type or provider identifier attached to the uploaded file.

Group
document_table
Data Type
string
field

Preview Document

Direct preview link for the latest uploaded file URL on the row when the document is not represented only by a Bynn dossier/report.

Group
document_table
Data Type
media
field

3rd Party Report

Opens the external Bynn dossier/report when the row belongs to the `bynn` document flow and a dossier ID exists.

Group
document_table
Data Type
link
field

Tags

Review or search tags attached to the document, including KYC-related tags.

Group
document_table
Data Type
string
field

Reason

Document request or rejection reason shown for operator context.

Group
document_table
Data Type
string
field

3rd Party Verification

Combined provider-verification chip. In practice the confirmed signal on this tab is Bynn; SumSub list values are currently placeholder controller fields.

Group
document_table
Data Type
enum
field

3rd Party Verification Date

Latest provider verification timestamp shown on the row. Treat Bynn timestamps as the verified source and SumSub timestamps as placeholder display data on this tab.

Group
document_table
Data Type
datetime
field

Status

Workflow state chip shown at the start of the Action cell. It controls which KYC actions are available on the row.

Group
document_table
Data Type
enum
field

Updated At

Last update time for the document row.

Group
document_table
Data Type
datetime
field

Actionee

Operator or actor linked to the latest document action.

Group
document_table
Data Type
string
field

Action Performed At

Timestamp for the most recent action recorded on the row.

Group
document_table
Data Type
datetime
field

Card Number

Masked successful-deposit card number shown from BIN plus last digits when available.

Group
used_deposit_cards
Data Type
masked-string
field

Card Holder

Card holder name carried from successful deposit history or the stored card-document record.

Group
used_deposit_cards
Data Type
string
field

Expiry Date

Expiry date associated with the deposit card.

Group
used_deposit_cards
Data Type
string
field

Payment Method

Payment method label linked to the successful deposit card.

Group
used_deposit_cards
Data Type
string
field

Status

Card-document state for that successful deposit card. `required` means the card exists in deposit history but no submitted card-document record is linked yet.

Group
used_deposit_cards
Data Type
enum
field

Reason

Reason or note attached to the card-document record.

Group
used_deposit_cards
Data Type
string
field

Processed By

Admin email saved on the latest card-document record for this card.

Group
used_deposit_cards
Data Type
string
field

Last Used

Latest successful-deposit usage time for the card, derived from grouped `TransactionBanking` history.

Group
used_deposit_cards
Data Type
datetime
field

Updated At

Last update time of the stored card-document record when one exists.

Group
used_deposit_cards
Data Type
datetime
Filter dictionary

Filters

field

Search by Tag

Restricts the KYC list to documents tagged with the entered label after the FE refetches and filters the user's document set.

Type
text
Operational notes

Notes

item

For a specific player (`userId > 0`) the document list returns every document status for that player. The pending-only default applies to the generic `userId=0` list, not to this player tab.

item

`get-user-document` currently injects placeholder SumSub values in `UserController.getUserDocument`, so SumSub chips and dates on this tab should be treated as display-only hints rather than verified provider data.

item

The FE ships a generic `verify3rdParty()` request helper, but the current player tab does not call it. The working provider-backed mutation on this surface is `POST /api/admin/verify-document-bynn`.

item

Action availability is driven by each row's current document status.

item

`User success deposit cards` is a second dataset on the same tab. FE merges successful deposit cards from `TransactionBanking` with `UserCardsDocuments` rows so cards can appear in `required` state even when no uploaded card-document record exists yet.

item

`Update/View` for a used card writes through `POST /api/admin/user-cards-documents`, not through the main `verify-user-document` document route.

Related references

Related pages

pagePlayers / Banking

Banking tab inside the player workspace with transaction filters, a paginated banking grid, analytics cards, CSV export, and automatic-withdrawal availability.

pagePlayers / Detail Workspace

Main player workbench at `/player/[playerId]` with tabbed sections, player-level actions, and modal-based operator workflows.

pagePlayers / Fraud Detection

Fraud-detection tab inside the player workspace with fraud risk assessment, related fraud reports, IP analysis, and identity-graph filtering.

pagePlayers / Game Report

Per-player game or provider report inside the player workspace, filtered by date option and grouped either by game or by provider.

pagePlayers / Inbox

Inbox tab inside the player workspace for reviewing sent notifications, filtering by read state or notification type, and resending or deleting messages.

pagePlayers / KPI Summary

Grouped player-level KPI snapshot inside the player workspace, covering player info, deposits, withdrawals, casino totals, bonus cost, and predictive metrics.