KYC levels and wallet limits
1) Why does a wallet need KYC levels and limits
E-wallets (stored-value and bank-linked) manage risk and compliance through tiered identification and dynamic limits. Objectives:- compliance with AML/CFT, sanctions, age norms;
- limitation of losses on fraud/chargebacks/errors;
- secure LTV growth by "unlocking" functions when upgrading KYC.
Principle: the higher the KYC level, the higher the limits (top-up/spend/payout/balance), the wider the geography and available rails (A2A, cards, vouchers), the lower the barriers to repeat operations and accelerated payments.
2) Typical KYC stairs (approximate content of levels)
Level 0 - Guest/Anonymous (Lite/Unverified)
Data: email/phone, base country/IP/device.
Access: limited viewing, sometimes - micropayments/receiving transfers.
Limits: minimum (low per-txn and daily), no payments/withdrawals.
Risk controls: hard velocity/geo, anti-multi-account.
Level 1 - Basic/Simplified Due Diligence
Data: name, date of birth, address/country, phone/mail verification.
Documents: sometimes not required, or auto-checks on databases (liveness/ID-guess).
Access: top-up in small amounts, P2P inside the scheme, limited pay-in.
Limits: low per-txn/24h/7d/30d; payout is limited.
Level 2 - Full KYC/ID & Address
Data: identity document (passport/ID), selfie-liveness, proof of address (bank letter/utility).
Access: all major pay-in, P2P, cash-out to bank/card where allowed.
Limits: medium/high per-txn and periodic; above balance-cap.
Level 3 - Enhanced Due Diligence (EDD)
Add. data: Proof of Funds/Source of Wealth, employment/business status, beneficiaries (for business accounts).
Access: large turnover, accelerated payments, multi-currency accounts, priority processing.
Limits: high or individual; custom thresholds for pay-in/payout/balance/FX.
Level VIP/High-Net-Worth/Corporate
Individual terms, manager, recipient/country whitelists, agreed payment SLAs.
Limits and checks are contractual, with increased monitoring of anomalies.
3) Types of limits (which parameters to design)
Per-transaction (MAX_TXN) - ceiling of one operation.
Daily/7d/30d (ROLLOVER caps) - sliding windows on top-up/expense/outputs/P2P volume.
Balance cap - maximum funds on the wallet.
Channel caps - separate thresholds for cards/A2A/vouchers/crypto-on-ramp (if applicable).
Recipient/Counterparty caps - on new/unverified recipients, limits on the first payment.
Velocity - the number of attempts/failures, the frequency of changing devices/methods.
Geofencing - allowed countries/currencies/rails (allow/deny lists).
Risk tier multipliers - client/session risk label limit ratios.
Merchant/vertical caps - profiles for sensitive MCCs (iGaming/quasi-cache/digital codes).
4) Level upgrade rules (progression)
Triggers: reaching 70-90% of the window limit, trying to pay, entering a sensitive vertical, requesting a balance increase.
Steps: show document checklist, ETA, check status, alternatives (for example, A2A instead of cards).
Automation: auto-pulling data from state/credit bureaus (where legal), re-checking address/age.
Level degradation: with suspicious activity → temporary downgrade of limits, payment hold, EDD.
5) Antifraud/AML and Limits Links
PEP/Sanctions screening: when onboarding and on schedule, when changing data, before large payout.
Adverse media and device/card/IBAN/BIN blacklists.
STR/SAR scenarios: automatic alerts and manual checks for anomalies (structuring, cyclic P2P, mullahs).
Behavioral & device: fingerprint, emulators, proxy/VPN, account bundles.
SCA/Step-Up: if soft-thresholds are exceeded - additional authentication, output delay, PoF/SoW request.
Age-gating and RG (for iGaming): age verification, self-exclusion, responsible play limits.
6) Architecture of the "limit engine" (policy engine)
Design goals: configurability, explainability of decisions, idempotency and audit.
Components:1. Catalog service: KYC levels, countries, currencies, channels, MCC profiles, sanctions/RAP lists (cache with TTL).
2. Policy engine: declarative rules (for example, CEL/JSON/YAML), priorities, rule version, AB tests.
3. Rate-limit/Windowing: counter storage (Redis/Scylla), sliding windows, atomicity.
4. Risk scoring: device/behavior/channel features, model (score), mapping score→multiplikatory limits.
5. Decision API: 'canTopUp/pay/payout?' → response with reasons ('reason _ code', 'next _ required _ action').
6. Explainability: log of rules, what threshold worked, what document is needed.
7. Admin UI: editing thresholds/rules with versioning and two-stage upproval.
8. Audit/Trail: unchanging decision log (hash-chain), storing rule versions.
Non-functional requirements:- Idempotency at the level of orders and limit requests.
- Reliability: quorum/replica, degradation "safe failure" (better failure than skipping the limit).
- Observability: hit-rate metrics by rules, step-up share, average solution time.
7) UX patterns (transparent limits = fewer tickets)
Profile and checkout level label: "Basic/Verified/Pro."
Remaining limit: "Can top up before X today" + window reset date.
Reason for refusal: "Level 1 daily limit exceeded" → "Raise level" button.
On-page KYC: downloading documents without leaving the checkout, step-by-step tips, an example of a photo.
Soft blocking: at the first refusal - alternative methods (A2A/local wallets), partial payment, split.
Payout-safety: warnings on the first withdrawal to a new account, hold before passing EDD.
8) Example of limit matrix (simplified template)
9) Features for iGaming and sensitive verticals
Geo/Licenses: Show purse/payout only in allowed countries/states.
Responsible game: player's own limits (deposits/expenses/time), cooling-off, self-exclusion - synchronize with wallet limits.
Bonus abuse: separate thresholds for new accounts, prohibition of instant withdrawal of bonus funds, step-up for "cache equivalents."
Payout control: enhanced EDD for large winnings, deferral of payments until settlement, verification of the source of funds.
10) Metrics and alerts
Approval rate by levels/channels/geo.
Decline breakdown: limits vs risk vs tech. errors.
Step-Up rate and KYC upgrade conversion (view→start→submit→pass).
Payout hold time, share of escalations in EDD, share VIP.
SAR/STR rate, sanctions/APP.
Complaint/ODR for limit/verification reasons.
Alerts: Spike in rule/country/BIN/device-specific failures.
11) Output checklist
1. Level model and limit matrix in the config service; versioning and rollback.
2. Policy engine with explain logs and solution idempotency.
3. KYC providers: ID verification, liveness, address, sanctions/REP, adverse media.
4. Risk scoring and real-time velocity limits (low latency).
5. UX: transparent limits, on-page KYC, alternatives in case of failure.
6. Payout-gates: holds/step-up for new recipients and large amounts.
7. AML/Compliance: EDD procedures, playbooks STR/SAR, log/evidence retention.
8. Observability: dashboards by limits/CUS/risk, alerts for out-of-sync and degradation of providers.
9. Test package: e2e for all levels (success/failure by limits), escalation in EDD, document change, degradation of KYC services, warming up window counters.
12) Quick answers for support
Why opt-out? - Level X daily limit exceeded. Promotion available: download document Y.
When will the limit be reset? - After N hours (display the exact time of the window).
Why not withdraw? - New recipient/account, need step-up/wait N hours.
How do I upgrade? - Promote button, document list, ETA, real-time review status.
Summary
Build wallet limits as a + policy engine configuration tied to KYC levels and risk scoring. Make the reasons for failures transparent, offer KYC upgrades and alternative rails. For iGaming - additionally implement responsible game limits, strict payout control and sanctions/RAP monitoring. Strong observability (metrics, explain-logs, alerts) turns limits from a "brake" into a controllable lever of growth and safety.