MOOON Exchange

1. Governance and launch gate

The Board must approve the operating model, risk appetite, product scope, customer eligibility, jurisdictions, accountable officers and escalation routes. A designated Principal Officer and Designated Director must have documented authority, access to records and reporting procedures. No commercial launch decision overrides a failed compliance, custody, security, reconciliation or liquidity control.

FIU-IND registration evidence and relevant identifiers must be independently checked and recorded.
Provider due diligence, contracts, security review, sandbox tests and production acceptance must be complete.
Policies must be reviewed by qualified Indian legal, compliance, tax and cybersecurity professionals.
Material changes require version control, owner approval and staff training.

2. Customer acceptance and KYC/CDD

Planned onboarding requires identity and address verification, age and jurisdiction checks, sanctions and adverse-information screening, customer risk classification, source-of-funds or source-of-wealth review where risk requires it, and beneficial-owner verification for legal persons. Enhanced due diligence and senior approval apply to higher-risk relationships. Anonymous, fictitious, prohibited or inadequately verified accounts are not accepted.

Customer data, screening results, exceptions, approvals and periodic-review dates must be traceable to an accountable reviewer. Accounts may be restricted during verification, investigation, legal hold or risk review.

3. AML/CFT, sanctions and transaction monitoring

The planned control programme includes documented risk assessment, customer and wallet risk scoring, blockchain analytics, sanctions screening, velocity and behavioural monitoring, linked-account detection, alert investigation and escalation. Suspicious activity decisions must be confidential, documented and reported by the authorised officer within applicable timelines. Staff must not tip off a customer about a confidential investigation or filing.

Records must support reconstruction of individual transactions, including customer identity, wallet addresses, asset, amount, network, timestamps, transaction hash, counterparty information, screening evidence and reviewer decisions.

4. Travel Rule controls

Before or concurrently with a covered virtual-asset transfer, the workflow must collect and validate required originator and beneficiary information, identify the counterparty VDA service provider or self-hosted wallet context, screen the parties and retain the transfer record. A transfer must be blocked or held if mandatory information is missing, contradictory, sanctioned or otherwise unacceptable. Post-facto collection is not treated as a normal substitute.

5. Custody and safeguarding model

Production custody requires a separately approved custodian or a formally assessed MPC/HSM wallet architecture. Private keys, signing shares, recovery material and provider API secrets must never be stored in the application database or browser. Roles for initiation, approval and signing must be separated, with least privilege, hardware-backed authentication and an auditable maker-checker workflow.

Hot-wallet exposure limits, cold or warm storage allocation and automated sweep thresholds.
Address allow-listing, withdrawal cooling periods, step-up authentication and velocity limits.
Key ceremony, backup, recovery, business-continuity and disaster-recovery testing.
Daily asset-to-client-liability reconciliation with exception ageing and independent sign-off.
Incident containment, key rotation, customer communication and regulatory notification procedures.

Client assets and company operating funds should be logically and operationally segregated according to the finally approved legal and custody structure. The public interface must not label an internal database balance as verified custody coverage.

6. Deposit confirmation and credit

A submitted transaction hash creates a pending intent only. Credit requires the correct asset, supported network, designated receiving address, amount match, sufficient confirmations, blockchain finality, wallet/transaction risk clearance and completed Travel Rule review where required. The current draft confirmation thresholds are 20 for TRC20, 12 for ERC20 and 15 for BEP20; Operations may raise or suspend thresholds because of reorganisation risk, congestion, provider alerts or network incidents.

Duplicate hashes, unsupported tokens, wrong networks, smart-contract anomalies, sanctioned exposure, replaced transactions and amount mismatches are held for investigation. Credit is idempotent: one approved transfer creates one ledger entry. Manual exceptions require documented maker-checker approval and must not bypass screening.

7. Withdrawal controls

Withdrawal requests reserve available balance but do not themselves sign or broadcast a transaction. Release requires authentication, destination validation, screening, Travel Rule clearance, limits, cooling-period rules, custody instruction reference and maker-checker approval. High-value, new-address, unusual or elevated-risk withdrawals require enhanced review. Rejected requests release the hold with an audit entry.

8. Margin and leverage framework

The current terminal uses isolated simulated margin: the position’s assigned margin is separated from other available funds. Initial margin is position notional divided by leverage. Maintenance margin is mark notional multiplied by the applicable maintenance rate. Fees are reserved or charged separately and may reduce available equity.

Core tier — BTC, ETH: maximum 50x simulated leverage, 100,000 USDT simulated notional, base maintenance rate 0.50%.
Major tier — SOL, BNB, XRP: maximum 25x, 50,000 USDT simulated notional, base maintenance rate 1.00%.
Alt tier — DOGE, ADA, AVAX, LINK, SUI: maximum 10x, 25,000 USDT simulated notional, base maintenance rate 2.00%.

A size add-on of 0.50 percentage points applies above 50% of the tier notional cap and 1.00 percentage point above 80%. These are conservative beta controls, not final commercial limits. The risk committee may reduce leverage, notional, markets or order types without notice during volatility or control incidents.

9. Liquidation and close-out

The simulated isolated liquidation estimate uses entry price, leverage and maintenance rate. For a long position the estimate is entry × [1 − (1/leverage − maintenance rate)]; for a short it is entry × [1 + (1/leverage − maintenance rate)]. Mark price, not the last-trade display alone, should drive production liquidation. Actual execution can differ because of fees, funding, slippage, latency, liquidity gaps and partial fills.

The terminal shows entry, mark, take-profit, stop-loss and liquidation levels on the chart. A buffer of 5% or less is flagged as near liquidation. A production engine must support deterministic state transitions, partial liquidation where appropriate, bankruptcy-price controls, liquidation fees, insurance or loss-allocation rules, replayable events, price-source failover and independent reconciliation.

10. Risk KPIs and operating limits

The admin control centre monitors client ledger liabilities, reserved withdrawals, used margin, gross open notional, open positions, maximum leverage, positions within 5% of liquidation, blocked transfer reviews, missing market marks and provider readiness. Production custody coverage remains “Unavailable” until a verified provider balance can be reconciled.

Asset coverage ratio and unreconciled balance exceptions.
Hot-wallet and single-transaction exposure against approved limits.
Deposit/withdrawal confirmation ageing and manual-override rate.
Liquidation concentration, margin utilisation and stress loss by market.
Failed orders, stale marks, venue divergence, latency and provider outages.
KYC, sanctions, monitoring and Travel Rule alert backlog and ageing.
Security incidents, privileged-access changes and recovery-test results.

11. Market integrity, resilience and conflicts

Planned controls include order and position limits, self-trade and manipulation surveillance, market-data quality checks, venue monitoring, incident kill switches, controlled product changes and documented conflict management. Reference data outages must trigger safe degradation or suspension, not fabricated prices. Employees and connected persons require access controls and conflict declarations appropriate to their role.

12. Records, complaints and incidents

Transaction records should be retained for at least five years and customer-identification records for at least five years after the relationship ends, or longer where law, investigation or legal hold requires. Records must remain retrievable, secure and sufficient to reconstruct activity. Customers must receive a clear complaints channel, reference number, target response time and escalation path. Security, privacy, custody and market incidents require severity classification, containment, evidence preservation, root-cause analysis and tracked remediation.

13. Sources and review

This framework is informed by the FIU-IND VDA guidelines dated 8 January 2026, the FIU-IND registration circular dated 15 September 2025, the Prevention of Money-laundering (Maintenance of Records) Rules and the Prevention of Money Laundering Act materials published by FIU-IND. It is an engineering and operations draft, not a legal opinion or evidence of registration.

Policy questions: noreply@mooon.exchange. Registered office: To the Moon Technology Private Limited, House No. 558, Awas Vikas Colony, Gundaghat, Gorakhpur, Uttar Pradesh, India.