KYC & Redemption-Trust
Engine
Coinz · V1 · Verify users progressively, not upfront for everyone
Most redemptions wait on a human
- Manual ops review is the default, so payouts are slow and the workload scales straight with volume.
- The signals to safely clear good users already exist (
GBG,SEON, closed-loop) but are not combined into one rule. - So trusted repeat players hit friction, and ops hand-reviews redemptions a rules engine could clear on its own.
Verify progressively, escalate only when risk demands it
Identity and fraud checks run in the background at signup, no friction for the player.
Trusted users with a verified method redeem without document KYC, the slow step is skipped.
Shufti verification fires only on real risk or an unverified method, not for everyone.
A delta on a live system, not a rebuild
Roughly 70% of the machinery already runs in production. V1 is the unifying layer on top.
- GBG-pass redemption bypass
- Closed-loop redemption routing
- SEON continuous fraud scoring
- Shufti document KYC
- AptPay auto-payout on approval
- One explicit decision engine over the signals
- Per-method verified state + auto-emailed request
- good_behavior as a gating input
Seven signals the engine reads
sms_verified is intentionally dropped as a branch, phone ownership is already proven at registration, so it is true for every active account.
Background checks set a trust tier
seon = approved
seon = suspicious
OR duplicate account
A separate always-on duplicate-account check (DOB + name + state or canonical email) blocks synchronously at signup. gbg != pass (fail / partial / error) is not-trusted but does not restrict, only a player-level SEON DECLINE + the duplicate check do.
Every redemption runs one router
KYC-free redemption when all hold
→ Auto-approve, AptPay payout fires, no document KYC. Eligible from the second redemption onward.
Trusted but one signal short
method not verified → auto-email to verify it; this redemption is manual, future ones can auto
seon = suspicious / DECLINE at redemption → Shufti ID verification + manual review (account not restricted)
good_behavior = false → Shufti ID verification + manual review
amount ≥ ceiling → Shufti ID verification + manual review
gbg != pass (fail / partial / error) → not trusted for auto; Shufti ID verification at redemption
Precedence: restricted accounts are stopped upstream; among the rest, manual-verify > auto-approve. Triggered requirements stack.
Trust is dynamic: good_behavior can flip to false between redemptions (its own monitoring, separate from SEON), dropping a previously-trusted player back to manual on the next attempt.
Restricted accounts are locked out, not reviewed
Triggered when any of these hold:
→ Full lockout, no login / play / deposit / withdrawal. The only way back is a CS / Fraud backoffice override, no self-service, no automated re-KYC in V1.
Today the block is silent, no Slack or email alert (CustomerIO sync + a metrics counter only). gbg=fail alone does not restrict, and a redemption-time DECLINE verifies (Shufti + manual), it does not lock out. Whether V1 adds a reinstatement path and a restrict alert are open questions.
Per-method verification, by auto-email
Closed-loop purchase method is verified automatically.
Backend rule only, no front-end UI in V1.
Shufti is not used here, it verifies identity, not cards.
Verified state persists, nothing already on file is re-requested: once a method is verified or a player has passed Shufti, the engine does not ask again.
Three guardrails on the logic
below ceiling → auto
at or above → Shufti ID + manual review
Always manual (CORE-7), regardless of trust. Auto-approval starts at the 2nd.
No purchase method, so no auto-verified method. Standard unverified-method path.
Threshold values are operator-configurable in BackOffice, the PRD locks the capability, not the numbers.
What good looks like
Twelve calls before build
| Decision | Proposed default | Owner |
|---|---|---|
| good_behavior scoring rules | Non-gating (default true) until scoring ships; separate from SEON | Data |
| Legal triggers that force KYC (tax, sanctions) | None encoded in V1, hook only | Compliance |
| Auto-approve ceiling (SC) | Start at current live caps | Compliance / Payments / Ops |
| Is closed_loop an automated flag today? | Assume engine computes it (new) | Engineering |
| Should gbg=fail alone restrict? | No, keep informational (only SEON DECLINE + duplicate restrict today) | Risk / Compliance |
| Reinstatement path for restricted accounts, or hard lockout? | Keep lockout + CS / Fraud override in V1 | Compliance / Ops |
| Post-signup multi-account signal to the engine? | Signup block exists, no new post-signup trigger in V1 | Risk / Engineering |
| "Payment mismatch" vs closed_loop=false? | Treat as inverse of closed-loop | Payments / Engineering |
| Alert CS / Fraud on auto-restrict? | Add a Slack / email alert | Engineering / Ops |
Three more from stakeholder review
| Decision | Proposed default | Owner |
|---|---|---|
| Apple Pay deposits + method_verified, the masked DPAN never PAN-matches the redemption card | Treat as non-PAN-matchable; clear via GBG-pass / identity (reconcile with the live CORE-107 bypass) | Payments / Engineering |
| Cumulative redemption ceiling (completed + pending), not per-request only | Add a rolling cumulative check alongside the per-request ceiling | Compliance / Payments / Ops |
| Daily auto-approve caps (max count + max total auto-payable per day) | Cap in BackOffice, inside the existing $800/day + 5/day platform rules | Payments / Ops |
Three things from this room
01 Review the engine logic, tell us where a path is wrong.
02 Take an open decision, twelve need owners.
03 Approve R6 so we can move to ticketing.