1. Purpose and status
This document sets out a proposed compliance framework for merchant onboarding and payment activity. It is not evidence of regulatory authorisation, an approved internal compliance programme or automated screening already in operation. The future operator must determine which laws apply to its activities and implement the required controls before relying on this policy. References to review, screening and reporting below describe the intended framework.
2. Merchant eligibility and business information
The proposed onboarding process requires merchants to explain who they are, what they sell, where they operate and how they intend to use the service. Approval of an account should not be treated as approval of every future product, jurisdiction or transaction. Merchants should keep their information current and notify the operator of material changes in ownership, management, business activities or transaction patterns.
- Business or individual name, registration details where applicable, business address and operating countries.
- Project website, description of goods or services, expected payment volumes and the purpose of using CryptiumPay.
- Names and roles of authorised representatives, directors and ultimate beneficial owners, with evidence of authority where relevant.
3. Identity and business verification
Depending on the applicable rules and assessed risk, the operator may need to verify individuals, the legal existence of a business, its ownership structure and the authority of its representatives. The final process should specify acceptable documents, verification methods and any external verification provider. Requests should be proportionate to their purpose. Do not send identity documents to an unverified contact or through an unsolicited link, and never disclose wallet seed phrases or private keys.
4. Risk assessment and enhanced review
The proposed assessment considers the nature of the business, its customers and locations, ownership transparency, expected payment activity and relevant risk indicators. Higher risk may require additional evidence, closer review and an approval decision by the responsible person. Politically exposed person status should trigger an appropriate risk assessment rather than a presumption of wrongdoing. The applicable definitions, thresholds and approval responsibilities remain to be established by the operator.
5. Source of funds and transaction context
A review may require evidence explaining the origin of funds and the commercial purpose of payments, such as invoices, contracts, order records or relevant transaction history. Where justified, the source of wealth may also need to be understood. Requests should identify a secure submission channel and the information needed. Providing documents does not by itself guarantee onboarding, release of a transaction or continued access to the service.
6. Sanctions and geographic restrictions
The intended framework prohibits using the service to breach sanctions or conceal a sanctioned person's involvement. The operator must identify the sanctions regimes legally applicable to it and publish supported and restricted locations before live onboarding. This draft does not establish a country blacklist or assert that every international sanctions regime applies in every case. False location details, nominee arrangements and attempts to bypass applicable geographic restrictions would be prohibited.
7. Ongoing monitoring and unusual activity
Proposed monitoring should compare activity with the merchant's stated business and investigate relevant anomalies. Indicators may include unexplained changes in volume, inconsistent business information, transaction splitting to avoid checks, suspicious wallet links or payment patterns without a clear commercial purpose. An indicator is a reason to investigate, not a finding of criminal conduct. The operator must confirm the actual tools, data sources, review process and handling of potential false positives.
8. Requests, restrictions and unresolved reviews
The final terms may permit proportionate restrictions on onboarding, transactions or withdrawals while a legitimate review is pending, subject to applicable law. Where lawful, the merchant should receive information about the steps needed to resolve the review and a way to contact support. The operator should document decisions and review continuing restrictions. This draft does not authorise indefinite retention, forfeiture of funds or an automatic refund when verification is declined; any release or return must be lawful and technically feasible.
9. Reporting and confidentiality
The operator must establish a process to assess suspected financial crime, make any reports required by applicable law and respond to lawful requests from competent authorities. It must also determine when disclosure of an investigation or report is restricted. This page does not claim that a reporting officer has been appointed or that a reporting relationship with a particular authority already exists. Reports and requests must be handled with appropriate confidentiality and access restrictions.
10. Records, privacy and review requests
Verification and transaction-review records should be limited to what is needed, protected against unauthorised access and retained under an approved schedule. The Privacy Policy explains the proposed data-handling framework. Merchants should be able to report inaccurate information or request review of a decision, subject to lawful disclosure limits. Contact support about suspected misuse without including unnecessary personal documents or secret credentials.
11. Details to complete before publication
Required operator decisions: legal entity and jurisdiction; licensing or registration position; permitted customer types and countries; applicable sanctions regimes; KYC/KYB and beneficial ownership requirements; verification providers and secure document channels; risk and monitoring controls; responsible compliance personnel; escalation, reporting and review procedures; and record-retention periods. These are open requirements, not representations of current controls.