A TON-based gaming infrastructure project ran its whitelist registration on a Thursday. By Friday afternoon, the KYC queue had 2,400 pending applicants. The compliance deadline was midnight. Three selfie-to-ID mismatches had auto-rejected applicants whose Emirates ID photos were blurry on the government portal scan. The project team's operations lead was manually exporting CSVs, cross-referencing approval statuses, and sending rejection emails — one by one.
That scenario is not unusual. It is, in fact, the default state of KYC operations for token sales run without an integrated compliance pipeline. If you are planning a TGE on TON and operating under UAE rules — whether from a DIFC entity or from a mainland company registered in Abu Dhabi or Dubai — the following breakdown covers what the compliance obligations actually look like in practice, and where the friction concentrates.
KYC Tiers and What Each Actually Requires
Tiered KYC is not a Tonstarter invention — it mirrors the risk-based approach that FATF member jurisdictions mandate for virtual asset service providers. The FATF Recommendations, which the UAE has implemented through its AML/CFT framework, require that identity verification be proportionate to transaction risk. In practice, for a token sale, this maps to three operational tiers:
Tier 1: Email and Wallet Address Verification
At the baseline level, a participant provides a verified email address and connects a TON wallet via TON Connect. This establishes a one-to-one mapping between the registered email and a specific on-chain address. It does not verify identity in the legal sense. It confirms that the email account owner also controls the private key for that wallet address. Tier 1 is appropriate for participants whose expected allocation falls below the FATF travel rule threshold — broadly, below USD $1,000 equivalent.
The FATF travel rule, which obligates virtual asset service providers to pass originator and beneficiary information alongside transactions above USD $1,000, is relevant here because UAE-regulated entities are expected to implement it. For allocations below this threshold, Tier 1 is operationally sufficient. Above it, the project — or the platform facilitating the sale — must move to more substantive identity checks.
Tier 2: Government-Issued ID and Selfie Matching
Tier 2 requires a government-issued identity document and a live-capture selfie for biometric matching. For UAE residents, this typically means an Emirates ID — the UAE's national identity card — whose machine-readable zone contains the holder's full legal name, date of birth, and Emirates ID number. For non-residents participating from outside the UAE, a passport is accepted, paired with proof of current residential address.
This is the tier that generates the majority of operational friction. Selfie matching using Emirates ID photographs is impacted by image quality inconsistency — the Emirates ID photograph is captured at issuance (sometimes years prior) and printed at a resolution that does not always cooperate with liveness-detection systems. False-positive rejection rates at this tier run between 3% and 8% depending on the KYC provider and the quality of their Emirates ID-specific model training. Having an appeals path — not just a generic "rejected" notification — is non-negotiable for any UAE-audience sale.
Tier 3: Source of Funds Declarations
Tier 3 applies to allocations above USD $10,000 equivalent and requires a source of funds (SOF) declaration. This is where banks statements, salary certificates, or business ownership documentation enter the picture. UAE-resident applicants typically provide three months of bank statements from a UAE-licensed bank. Non-residents provide equivalent documentation from their home jurisdiction.
SOF verification is time-intensive: a manual review typically takes 2–5 business days per applicant. For a sale with a hard cap and limited high-tier allocations, this timeline creates a sequencing problem — you cannot open Tier 3 applicants two days before the sale date and expect complete compliance.
"The KYC deadline is not the day of the sale — it is at least five business days before it. That gap is where most founders underestimate their compliance burden."
PEP Screening and Sanctions Overlap
KYC does not end at identity verification. For UAE-compliant token sales, every applicant must be screened against politically exposed person (PEP) lists and against consolidated sanctions lists — at a minimum, OFAC (U.S. Office of Foreign Assets Control), EU consolidated sanctions, and UN Security Council consolidated lists.
PEP screening flags individuals who hold or have held prominent public positions: heads of state, senior government officials, military officers above a specified rank, senior executives of state-owned enterprises, and immediate family members of such individuals. A positive PEP match does not automatically disqualify a participant, but it triggers enhanced due diligence (EDD): additional documentation, source of funds review regardless of allocation size, and in some cases a manual compliance review before approval is granted.
Sanctions screening is more absolute — an exact match to an OFAC SDN entry, for instance, requires rejection with no pathway to appeal. The practical challenge is near-match handling: transliteration variations in Arabic names, aliases, and date-of-birth discrepancies all generate alerts that require human review to resolve.
We are not saying that screening for PEPs makes a token sale a financial product — it does not. PEP and sanctions screening is an AML obligation for the platform facilitating the sale, not a claim about the nature of the token being distributed.
The Mechanics of Running KYC for a TGE in Practice
Consider a TON DeFi project planning a TGE with a $500,000 hard cap. The project founder assumes 1,200 applicants will complete KYC. The realistic scenario looks like this:
- 1,800 registrations initiated (over-registration is typical — people register and abandon the flow)
- 1,100 complete Tier 1 (email + wallet bind)
- 780 complete Tier 2 (ID + selfie)
- 55 Tier 2 rejections for selfie mismatch, document expiry, or unsupported document type
- 40 Tier 2 rejections escalated to manual review, of which 28 are eventually cleared
- 190 applicants begin Tier 3 (allocations above $10,000 threshold)
- 160 complete Tier 3 within the SOF window; 30 miss the deadline
- Final approved whitelist: approximately 920 wallets
If the project tried to run this process without a system that automatically links KYC approval status to wallet whitelist entries, the CSV reconciliation alone becomes a multi-person job measured in days. Tonstarter's KYC flow binds approval state directly to the on-chain wallet address at the point of verification — when a wallet passes Tier 2 approval, the whitelist contract state updates without a manual export step.
What Changes When You Operate From DIFC
The Dubai International Financial Centre is a federal financial free zone — it has its own civil and commercial law, its own courts, and its own financial regulator, the Dubai Financial Services Authority (DFSA). For virtual assets, the DFSA has published a virtual assets framework that applies to firms operating within the DIFC perimeter. A DIFC-registered entity running a token sale is subject to DFSA oversight, not to VARA (the Virtual Assets Regulatory Authority, which governs mainland Dubai and the broader UAE).
This distinction matters practically: the DFSA's virtual asset framework has specific disclosure requirements, AML/CFT obligations, and consumer protection rules that differ from VARA's framework. They are not interchangeable. A project incorporated in the DIFC as a DIFC entity — as Tonstarter is — operates under DFSA rules. A project incorporated outside the DIFC, even if physically located in a Dubai building, operates under VARA's regime or under the UAE Central Bank's framework depending on activity type.
For project founders engaging Tonstarter as a platform, the relevant point is this: DFSA registration applies to Tonstarter as an operating entity, not to every project listed on the platform. Each project must conduct its own assessment of whether its token and sale structure fall within or outside the DFSA's regulatory perimeter. This is a question for each project's own legal counsel — not something a launchpad platform can resolve on a project's behalf.
Why Manual CSV Exports Became Extinct on Well-Run Launchpads
The early launchpad era — 2021 through early 2023 — was characterized by KYC and whitelist as two entirely separate operational tracks. The KYC provider (Sumsub, Jumio, or a bespoke integration) would output an approval CSV. The launchpad team would manually import that CSV into their whitelist management system, cross-reference wallet addresses, and push the resulting approved list to the sale contract. Every update required a new export-import cycle. The 5pm Friday deadline rush — where a project team is frantically reconciling the last batch of approvals before a weekend sale — is a product of this architecture.
Integrated KYC-to-whitelist pipelines eliminate this by maintaining a shared approval state. When a wallet completes KYC at the required tier, the approval flag propagates to the sale contract's eligible-address mapping in real time. There is no export step. The compliance record remains — it is stored and auditable — but the operational loop is closed at the infrastructure level rather than the spreadsheet level.
If you are preparing a TON project for a launchpad sale and still relying on a manual reconciliation approach, the question worth asking is not "can we manage this?" but "what does a single CSV error cost us on sale day?" The answer, typically measured in misallocated tokens and participant disputes, is significant.
Tonstarter's compliance framework and KYC flow are documented in detail on the KYC & Compliance page. Project applications open at apply.html — the review process includes an assessment of your KYC readiness before the sale schedule is confirmed.
