How AML and KYC work

1) Why do you need AML and KYC

KYC (Know Your Customer) confirms that the customer is a real person with a valid identity and address.

AML (Anti-Money Laundering) prevents money laundering, terrorist financing and sanctions circumvention.

In iGaming, this is a condition of licenses, partner banks and payment providers; default = fines, license revocation, and payment blocks.

2) KYC process: from onboarding to admission to the checkout

KYC Steps

1. Data collection: full name, date of birth, citizenship, address, document (passport/ID), selfie/video-liveness.

2. Document verification: MRZ/chip, anti-tamper, expiry date, selfie matching.

3. Confirmation of address (PoA): invoice for services/bank statement ≤ 3-6 months

4. Sanctions and PEP: screening against sanctions lists, politically exposed individuals and adverse media.

5. Solution: pass/fail/request for additional data; Record the reason and versions of policies.

Verification Request Mini Example

json
POST /compliance/kyc/verify
{
"customerId": "c_1029",  "doc": {"type":"passport","country":"DE","number":"X1234567","expiry":"2030-04-01"},  "identity": {"firstName":"Alex","lastName":"K. ","dob":"1993-02-11"},  "address": {"line1":"Musterstr. 5","city":"Berlin","zip":"10115","country":"DE"},  "liveness": {"provider":"onfido","sessionId":"sess_9a7f"},  "consent": true
}

3) Sanctions, PEP and adverse media

Sanctions: direct coincidence, alias coincidences, secondary coincidences (beneficiaries).

PEP: Current and former positions + family members/loved ones.

Adverse media: Negative references to fraud, corruption, violence.

Solution: true/false/needs review prioritized by source match type and source freshness.

4) KYT for cryptocurrencies (Know Your Transaction)

Address/transaction screening: mixers, darknet clusters, sanctions/exchange wallets.

Source of funds tracing: path of coins to on-ramp/exchange with KYC.

Rules: block of high-risk clusters; clean address requirement; SoF/SoW request by crypt.

KYT Result Example

json
{
"address": "0x9a7f...2b1c",  "riskScore": 83,  "flags": ["mixer_proximity","sanctions_cluster_2hops"],  "recommendation": "deny_and_request_clean_address"
}

5) Scoring and verification levels (risk-based approach)

Initial Risk Score (IRS) on onboarding: country, payment method, age, POP/sanctions, device.

Ongoing Risk Score (ORS) over time: deposit/withdrawal volumes, frequency, abnormal patterns.

Levels:

Low - basic KYC, standard limits.
Medium - additional SoF/PoA, narrowed limits.
High/EDD - extended package of documents, manual review, reduced limits/pause.

6) SoF/SoW and affordability (as part of AML)

SoF (source of funds): salary, business, savings, sale of assets, gift/inheritance, crypt (with a clean path).

SoW (wealth source): a more general income context.

Affordability: matching game intensity to revenue; in case of non-conformity - limits/pause.

7) Transaction Monitoring (TM) and Behavioral Rules

Typical scenarios that the TM engine catches:

Frequent deposits and instant conclusions (pass-through).
Split amounts around thresholds (structuring).
Sharp rise in average tick; high-turnover night sessions.
Payment instrument holder and account mismatch.
Crypt from "dirty" clusters; lots of new addresses with no history.

Event for TM

json
{
"event":"payment. deposit",  "ts":"2025-10-17T12:10:20Z",  "customerId":"c_1029",  "amount":"1000. 00",  "currency":"EUR",  "method":"card",  "country":"DE",  "device":"ios_app",  "traceId":"tr_55f",  "kvc":{"name_on_card_match":true}
}

8) Case management and investigation

Alert → Case → Decision: alert is combined into a case; statements/docking proofs are added; actions and policy versions ('policyVer') are recorded.

Solutions: approve/limit/request info/suspend/offboard.

Escalation: compliance officer/lawyer; Activity log is immutable (WORM).

SAR/STR: suspicious report to regulator according to local law.

9) Data storage, privacy, security

PII isolation: separate storages and access keys, minimizing fields.

Retention: storage N years (by jurisdiction), after - safe removal.

Access: RBAC/ABAC, access log, encryption (KMS/HSM).

Data subject rights: access/correction/restriction of processing, except for the mandatory AML permission.

10) Metrics and SLO AML/KYC

KYC pass-rate / time-to-verify (p50/p95).

Alert precision/recall (TM rule quality).

Case closure time (MTTC), share of cases with EDD.

SAR/STR rate and the proportion of confirmed incidents.

KYT coverage (what% of cryptodeposites were screened).

Affordability interventions (how many limits/pauz).

11) Architectural Compliance Patterns

The compliance layer is a separate module with its own API and storage.

Events: 'kyc. started/passed/failed`, `aml. alert/opened/closed`, `payment. deposit/withdrawal`, `kyd. address_screened`.

Idempotence: all webhooks and solutions are with 'decisionId', repetition of processing does not change the result.

Policy versioning: each calculation stores' policyVer ',' dataVer ',' modelVer '(if there is ML).

12) Examples of solutions (policies → actions)

json
{
"decisionId":"dec_7f3",  "customerId":"c_1029",  "policy":"aml_v3. 6",  "riskScore":72,  "action":"limit_and_request_sof",  "limits":{"deposit_daily":"200. 00","withdrawal_daily":"0. 00"},  "explanation":["rapid_deposits","new_wallet","country_risk_medium"],  "ttl_days":30
}

13) Role of ML/AI and limitations

Use-cases: prioritization of alerts, anomaly of behavioral patterns, ranking of cases.

Guardrails: explainability, non-discrimination, man-in-the-circuit; rules take precedence over models for sanctions/PEP/EDD.

14) Anti-patterns (what breaks compliance)

Same set of checks for all countries/methods (no risk-based approach).

Mixing OLTP money and compliance logs in one database.

Lack of idempotence at cash webhooks - double solutions.

"Black box" ML without explainability and audit.

There are no policy version logs or decision bases.

There is no WORM archive and access control to documents.

KYT ignore for crypt and payer name mismatch.

15) AML&KYC Start/Audit Checklist

Processes

KYC/AML/EDD/Affordability policies with 'policyVer' and EOL are described.
SAR/STR, Escalation and Regulator/Bank Communication Procedures.

Technologies

Separate compliance module: API, storefronts, WORM archive.
Events and idempotent webhooks; end-to-end 'traceId'.

KYC/KYT

KYC (liveness, doc-scan) providers are integrated; PoA flow is clear.
KYT is connected for all crypto operations; stop lists and "clean addresses."

Monitoring

TM rules and ML signals; dashboards SLO/alert quality.
QA cases: selective reassessment, team training.

Privacy

PII isolation, encryption, role access, retention, GDPR/local norms.

16) Player memo (how to complete KYC/AML faster)

Prepare clear photos of documents and fresh Proof of Address.

Use your own cards/wallets; name must match.

With large amounts - keep statements and SoF in advance.

For crypto - translate from a clean address, save Tx-hash and the on-ramp/exchange report.

AML/KYC systems are not a formality, but a working circuit for protecting the operator and players. It is based on identity and address verification, sanctions/PEP screenings, risk-based transaction monitoring, KYT for crypto, case management and documented reporting. Technically, this is a separate module with events, idempotent solutions, WORM archive and strict privacy. This approach reduces regulatory and payment risks, speeds up legal payments and supports a responsible game.