Anti-Money Laundering (AML) Policy

1. Purpose and Scope

This policy establishes the anti-money laundering and counter-terrorism financing (AML/CTF) controls for the TRX Resource Platform, which operates:

• A custodial TRON wallet service (Sensei Wallet)
• A TRON Energy and Bandwidth resource marketplace
• A TRX staking pool with reward distribution
• Partner API services for resource delegation
• Telegram-based bot interfaces for wallet and resource operations

This policy applies to all platform services, all employees and contractors involved in platform operations, and all users of the platform regardless of access method (web, Telegram bot, MiniApp, Partner API).

The platform handles TRX and TRC-20 tokens (primarily USDT) and executes on-chain resource delegation transactions. Because the platform facilitates value transfer and custodies user funds through hot wallets and staking pools, it is subject to AML/CTF obligations.

2. Risk-Based Approach

Crypto deposit and withdrawal are never gated by verification level, at any level. Verification level does not set an outflow ceiling. What it sets is how much operator review a withdrawal needs before it is admitted -- a routing decision, not a refusal -- and whether fiat rails (card, IBAN) and account recovery are available.

Every account begins on Level 0 and rises only when identity verification is completed and the provider approves it (section 3). The Level 0 row is the default today; the higher rows describe what verification unlocks.

These figures are USD-equivalent, measured across all assets, over a rolling window rather than a calendar month. They govern who must click approve, never whether the withdrawal happens at all -- a request awaiting a second operator still executes once approved, it is not refused.

Two further ceilings apply to everyone regardless of level, are not lifted by verification, and ARE outright refusals rather than routing decisions: $5,000 equivalent per single withdrawal, and $10,000 equivalent per account per 24 hours (section 4.2). A platform-wide daily outflow ceiling (aggregate, across every account and asset) and a per-account balance cap also apply to every account regardless of level -- see the Security page.

Behavioural risk signals are evaluated on every withdrawal and are listed in section 4.2. Jurisdiction is not an input to risk classification, because the platform performs no geographic check -- see section 7.

Tier Escalation

Not implemented. Every user is on the lowest tier. The field that drives the approval-review table above is only ever raised by a compliance officer approving a verification by hand. There is no automatic escalation when activity crosses a threshold, no notification asking a user to verify, no grace period before enforcement, and no withdrawal-only restriction mode.

Raising a tier requires completing identity verification; until an account does, it stays on the lowest tier. The practical effect is that the platform behaves more conservatively than this policy describes rather than less: every account is held to the lowest-tier review requirement, every withdrawal is reviewed by an operator, and anything above $100 requires two operators to approve. But the withdrawal itself is never refused for being on Level 0. Only the two ceilings named above (per-transaction, per-account-per-day) and the platform-wide ceilings described on the Security page can refuse a withdrawal outright, and none of them read verification level.

3. Know Your Customer (KYC) Requirements

3.1 Data collected at registration

For all users the platform automatically records:

• Telegram user ID
• Wallet addresses associated with the account
• Timestamp of account creation
• Locale and account preferences

The platform does not record an IP address or a device fingerprint against the user record. An earlier version of this policy said it did; that was never implemented. IP addresses do appear in web-server access logs, which are kept for 72 hours and are not linked to the user record.

3.2 Identity verification process

Verification is open. Identity verification runs through E-Gates PassMe (e-gates.io). A user opens the wizard from Settings, is sent to the provider's own hosted page to submit an ID document and a selfie, and Level 1 is granted when the provider returns an approval. The outcome is binary, approved or declined. No identity document passes through this bot, through Telegram, or through our operators; we receive the provider's verdict, a session token and the page address, nothing more.

The consequence for limits is in section 2: an account stays on the lowest tier until it verifies, and the lowest-tier ceilings apply until then. A tier can also be raised by a compliance officer approving a submission by hand.

3.3 Ongoing due diligence

Not implemented. There is no daily batch re-screening of users, no annual re-verification of documents, and no re-verification triggered by a change of name or country. All of these presuppose ongoing programmes we have not built. The only screening that runs is of withdrawal destination addresses, at the moment of withdrawal -- see section 6.

4. Transaction Monitoring

4.1 Automated Monitoring Rules

The platform monitors all transactions processed through the system, including:

• On-chain deposits to platform-managed addresses
• On-chain withdrawals from hot wallets
• Resource delegation orders (energy, bandwidth)
• Staking deposits and unstake requests
• Internal transfers between user accounts
• Partner API order activity

4.2 Alert Thresholds

Every rule below is implemented and runs on every outbound transfer. Several are stricter than the figures this policy used to publish; where that is so, it is noted.

A rule we removed by design, not by accident

An earlier version of this table carried a "Tier outflow ceiling" rule ($200 per 24h / $500 per 30 days, refused outright, at the verification tier every account is currently on). It has been removed, not merely relabelled: crypto deposit and withdrawal are never gated by verification level, at any tier, by design (section 2). The ceilings that still refuse a withdrawal outright are the single-transaction and cumulative-daily-volume rows above, and the platform-wide aggregate ceiling and per-account balance cap described on the Security page -- none of which read verification level.

Rules we do not have

Earlier versions of this policy listed four further rules. None of them is implemented, and they are listed here as planned work rather than deleted quietly:

• Structuring detection -- multiple transactions just below a threshold within 24h. Not implemented.
• Multiple accounts, same destination -- three or more accounts withdrawing to one address within 7 days. Not implemented; there is no cross-account correlation.
• Dormant account reactivation -- inactive over 90 days then a large transaction. Not implemented.
• High-risk jurisdiction -- any transaction involving a sanctioned jurisdiction. Not implemented; the platform performs no geographic check of any kind (see section 7).

4.3 Risk Engine Integration

Transaction monitoring rules are enforced by the platform's risk engine, which evaluates every outbound transfer before it is submitted to the signer service. Transactions that trigger a flag are routed to the risk_review status in the approval queue. No flagged transaction is signed or broadcast until a compliance officer or authorized operator reviews and approves it through the admin panel.

5. Suspicious Activity Reporting

5.1 Internal Escalation

When a compliance alert is triggered:

1. The alert appears in the admin panel's compliance queue with full transaction context.
2. The assigned compliance reviewer evaluates the alert. There is no service-level agreement in force: we run no ticketing system and nothing measures review time, so we do not quote one. Flagged withdrawals wait until an operator acts and are never auto-approved by the passage of time. We aim to clear high-risk flags the same working day.
3. The reviewer records a disposition: cleared, escalated, or blocked.
4. All disposition decisions are recorded in the audit log with reviewer identity and reasoning.

5.2 External Reporting

If a transaction or pattern of activity is determined to constitute suspicious activity:

1. A Suspicious Activity Report (SAR) is prepared by the compliance officer.
2. The SAR is filed with the appropriate Financial Intelligence Unit (FIU).
3. The user is NOT notified that a SAR has been filed (tipping-off prohibition).
4. A copy of the SAR filing confirmation is retained in the compliance records.
5. The compliance officer determines whether to restrict, monitor, or terminate the relationship.

5.3 Law Enforcement Requests

The platform cooperates with lawful requests and maintains the ability to:

• Freeze specific user accounts on request
• Provide transaction history for specified addresses or user IDs
• Provide identity verification records for specified users

6. Sanctions Screening

This section describes what runs today. It is narrower than the equivalent section at a bank, and we would rather state the gaps than imply coverage we do not have.

6.1 What is screened

Withdrawal destination addresses, and only those. Before a withdrawal is accepted, the destination address is submitted to a blockchain sanctions-screening provider. Deposit source addresses, resource delegation targets and staking participants are not screened.

6.2 Provider and lists

Screening uses the Chainalysis public sanctions API. It answers one question -- whether an address is sanctioned -- and its coverage derives from designations published by authorities including OFAC, the EU and the UK. We do not maintain our own copy of any list, and we do not screen against the OFAC SDN, OFAC Consolidated, EU Consolidated, UN Security Council or UK HM Treasury lists as separate feeds. Risk categories such as mixer or ransomware are a paid tier we do not subscribe to.

6.3 Name screening

There is none. No name, date of birth or nationality is screened by us against any sanctions or PEP list. Identity verification through E-Gates PassMe verifies a document and collects a name, but the provider returns only an approve-or-decline verdict -- no screening result crosses the API -- so we hold a verified name without running our own name screening against it.

6.4 Screening points

One: withdrawal creation. There is no screening at registration, at document submission, as a daily batch over active users, or at Partner API onboarding.

6.5 Match handling

• Sanctions match: the withdrawal is refused before any funds move, and no operator can approve past it. The account is not automatically frozen and no report is filed automatically; both are manual decisions taken afterwards.
• Provider unreachable: the result is recorded as unknown. At or above $1,000 equivalent the withdrawal goes to manual review; below that it proceeds. A screening outage therefore does not block small withdrawals.
• Fuzzy or name match: not applicable, per 6.3.

6.6 Caching

Screening results are cached for 24 hours per address, so a designation published within the last day may not be reflected immediately.

7. Jurisdictional Restrictions

7.1 The restriction

The platform is not offered to users located in, resident in, or nationals of jurisdictions subject to comprehensive sanctions -- currently North Korea, Iran, Syria, Cuba, and the Crimea, Donetsk and Luhansk regions -- or any jurisdiction added afterwards. This is a term of use that you accept and warrant compliance with. Using the platform from a restricted jurisdiction breaches the terms and is grounds for termination.

7.2 It is not technically enforced

The platform performs no geographic check of any kind. There is no IP geolocation, no country field, no jurisdiction list in code, and no block on registration or on any transaction based on location or nationality. Nor is there a withdrawal-only account mode. We are telling you this rather than letting the sentence above imply a control we do not run.

The one location-adjacent control that does run is sanctions screening of withdrawal destination addresses (section 6). That blocks payments to sanctioned addresses and is not a substitute for jurisdictional enforcement.

8. Record Retention

Records are stored in the platform's PostgreSQL database. Backup tooling exists and encrypts with SSE-KMS on upload, but the backup schedule has not been confirmed running and no full restore test has been documented, so restoring from backup is not a control we can currently evidence. Audit log entries are protected by an hourly-verified SHA-256 hash chain, which detects tampering rather than preventing it; write-once storage is planned and not yet in place to ensure immutability.

9. Employee Training

All employees and contractors with access to user data, transaction records, the admin panel, the compliance review queue, or production infrastructure must complete AML/CTF training within 30 days of starting work, with annual refreshers and ad-hoc training within 14 days of material policy changes.

10. Governance and Review

This policy is reviewed and updated at least annually, or when triggered by regulatory changes, significant incidents, or material changes to the platform's product scope. The compliance officer is responsible for maintaining and enforcing this policy.

11. Definitions