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, and it does not change operator review either: the review rule below is the same at every level. What it sets is 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). For withdrawals the level changes nothing.

No operator approves a withdrawal the platform can price -- at any amount, at every verification level.This covers all assets and all outbound transfers. A withdrawal the risk engine flags is not held: the flag is recorded and reported to operators (sections 4.2 and 4.3). A withdrawal whose value cannot be priced is refused while the platform-wide outflow ceiling below is on, because that ceiling cannot be checked without a price; with that ceiling off -- and always for a transfer to another account on the platform, which the ceiling does not count -- it waits for two operators.

No per-account ceiling applies to a single withdrawal or to what one account withdraws in a day, at any level. A platform-wide daily outflow ceiling (aggregate, across every account and asset) applies to every account regardless of level, and is an outright refusal. The signing service's own ceilings on any single withdrawal it signs and on its withdrawal total for a rolling day apply as well: they are set per asset for the platform as a whole, read neither the account nor its level, and are outright refusals.

Until 2026-10-12 two further ceilings applied to every account and were outright refusals: $5,000 equivalent per single withdrawal and $10,000 equivalent per account per 24 hours. They were removed that day by the owner's decision; the mechanism is kept and can be switched back on by configuration.

Behavioural risk signals are evaluated on every withdrawal and are listed in section 4.2; they report, they do not hold. 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. For withdrawals that changes nothing, because the review rule is the same at every level: no operator approves a withdrawal the platform can price, at any amount. But the withdrawal itself is never refused for being on Level 0. The only amount ceilings that can refuse a withdrawal outright are the platform-wide ones named above -- the daily outflow ceiling and the signing service's own -- and neither reads 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. Only the last can refuse a transfer. Since 2026-10-12 a flag does not hold the transfer: it is recorded with it and reported to operators, who review the alert afterwards (section 5.1).

Rules 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).

Until 2026-10-12 this table also opened with two outright refusals: a single transaction above $5,000 equivalent, and a cumulative daily volume above $10,000 equivalent for one user. Both were removed that day by the owner's decision (section 2). The only amount ceilings that still refuse a withdrawal outright are platform-wide -- the daily outflow ceiling and the signing service's own (section 2) -- and neither reads 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. A flag does not hold the transfer: it is recorded with it in the hash-chained audit log, and every operator is alerted by message at once (repeat alerts for the same account and the same flags are held back for a day). Only a transfer whose value cannot be priced waits in the approval queue -- a transfer to another account on the platform always, a withdrawal only while the platform-wide outflow ceiling is off, since with it on such a withdrawal is refused (section 2) -- and it is not executed until two operators approve it through the admin panel.

5. Suspicious Activity Reporting

5.1 Internal Escalation

When a compliance alert is triggered:

1. The alert reaches every operator as a message naming the account and the flags, and is recorded in the audit log with the transaction's 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. The flagged withdrawal has already gone ahead -- the review is of the account's activity, not a gate on the transfer. We aim to review high-risk alerts the same working day.
3. The reviewer decides: cleared, or escalated under 5.2. An operator cannot freeze a single account from the admin panel today; for activity that cannot wait, the tool is the platform-wide withdrawal pause.
4. That pause is recorded in the audit log. A decision to clear or escalate an alert has no in-product record yet.

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 and the withdrawal proceeds. At or above $1,000 equivalent it is also flagged: recorded, and operators are alerted. A screening outage therefore blocks no withdrawal.
• 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