1.1. The purpose of this Description is to describe the arrangements made by the Company to safeguard the Clients' ownership rights to the Clients' Assets held by the Company, especially in the event of the Company's insolvency, and to prevent the use of the Clients' Assets for the Company's own account.
2.1. The Company, being entrusted with the control of the Assets, is responsible for ensuring that it segregates and safeguards in a proper manner the Assets of every Client from the assets belonging to the Company and from the Assets of other Clients. The Company has tools to identify and limit access to the Assets.
2.2. The Company hereby foresees the arrangements to ensure that: (i) fiat funds belonging to the Clients are not used for the Company's own account; (ii) Crypto-assets and EMT belonging to the Clients are not used for the Company's own account; and (iii) the wallets holding Clients' Crypto-assets and EMT are different from the Company's own wallets.
2.3. This Description aims to protect the Assets, mitigate risks, and ensure compliance with Applicable Law.
3.1. Assets of the Clients are held in separate, dedicated wallets and accounts, fully segregated from the Company's own wallets and accounts, ensuring a clear distinction between the Company's Crypto-assets, EMT and fiat funds, and the Assets that belong to the Clients.
3.2. Access to the Assets is limited to designated personnel within the Company.
3.3. A third-party payment service provider, Finance Incorporated Limited, operating under the brand name Paymix, provides payment services related to the Services offered by the Company. The Clients are informed about the third-party payment service provider in line with this Description (Clause 10).
3.4. The Company does not create wallets containing Crypto-assets of more than one Client (omnibus accounts); thus, the measures for segregation of Clients' Crypto-assets from other Clients' Crypto-assets are not specified.
4.1. The Company generates dedicated wallets in the Company's own infrastructure and/or by using a third-party service provider to keep the Crypto-assets belonging to the Client until these Crypto-assets are exchanged. A unique crypto wallet is created to receive the payment. It is managed by the Company on behalf of the Client, but belongs to the Client and is segregated from the assets of the Company, its other Clients or any third parties.
4.2. Each cryptocurrency account/wallet is created and managed by the Company on behalf of the Client and belongs to the Client. The Crypto-assets are sent directly to this wallet address.
4.3. The approval system for cryptographic keys and safeguarding cryptographic keys (for instance, multi-signature wallets) are as follows:
4.3.1. The Company utilizes OVHCloud's infrastructure in France, along with Intel SGX-based Trusted Execution Environment (TEE) solutions for key management and digital signature generation. Although the Company does not hold cryptocurrency on behalf of Clients, it implements strict security measures to ensure compliance with legal obligations and protect its cryptographic operations. Private keys are securely generated, encrypted, and stored in-house using a secure KMS management system. During private key generation, the key is encrypted using Intel SGX, ensuring sensitive data remains undisclosed and in an isolated environment.
4.3.2. Private keys are never exposed externally and remain sealed within Intel SGX enclaves during cryptographic operations. Multi-layer authentication mechanisms, such as multi-factor authentication (MFA) and VPN access, are enforced to further enhance security. The cryptographic key lifecycle is carefully managed, with periodic key rotation to maintain security integrity. Key deletion policies are in place to prevent unauthorized retention of expired keys. The Company follows industry standards, including NIST SP 800-57 and FIPS 140-2, to ensure best practices in cryptographic key management. The KMS solution supports high availability, with data stored within France.
4.3.3. For selecting cryptographic methods, the relevant industry standards are followed, including NIST SP 800-57 and FIPS 140-2, for secure key management and cryptographic practices. The cryptographic architecture utilizes AES-GCM for both encryption and authentication to provide a comprehensive data protection strategy. AES-GCM ensures confidentiality by encrypting sensitive data using a symmetric key, while its authentication mechanism guarantees data integrity and authenticity, preventing any unauthorized alterations during transmission or storage.
4.3.4. For key management, Intel SGX leverages dynamic key derivation rather than relying on static keys. This approach derives keys based on both the enclave's unique identity (MRENCLAVE) and the platform's identity (MRSIGNER), integrating Intel's secure key management protocol. Furthermore, the seal key is tightly bound to the specific hardware platform using Intel's CPU security features, ensuring that the key cannot be extracted or reused outside of the designated environment. This layered cryptographic approach significantly mitigates the risks of key exposure or tampering, providing a secure execution environment that is both hardware and software-dependent, effectively protecting sensitive data from unauthorized access or modification.
4.3.5. A cryptographic key pair is securely generated within the SGX enclave, leveraging Intel's secure enclave technology to ensure isolation and protection from external threats. The private key is then sealed using AES-GCM encryption, with the seal key derived from SGX-specific mechanisms to enhance security. This sealed private key is stored in an external database, ensuring that it remains encrypted at rest.
4.3.6. When in use, the private key is unsealed within the enclave for signing transactions, ensuring that sensitive operations occur in a protected environment. To maintain security, the key pair undergoes periodic rotation, with new keys generated and old keys registered and securely rotated. Key rotation is determined based on the risk assessment. Additionally, any sealed data and associated key material are securely deleted when no longer needed, following strict data retention and destruction policies to prevent unauthorized access.
4.3.7. Intel SGX establishes a Hardware-based Key Protection by binding cryptographic keys to specific CPU hardware, utilizing platform-specific secrets and unique hardware identifiers like the CPU's MRENCLAVE and MRSIGNER values. This ensures that the cryptographic keys are inherently tied to the hardware platform on which they are generated, preventing their use on any unauthorized or compromised systems. The secure enclave ensures that the keys are never exposed to the outside environment, with operations such as key sealing and unsealing occurring solely within the trusted enclave, reinforcing the integrity of the cryptographic process.
4.3.8. Dynamic Key Derivation in Intel SGX uses the enclave and platform identity to generate sealing keys on demand, ensuring that keys are never stored persistently. This process leverages Intel's secure key derivation mechanisms, where keys are derived using enclave-specific data such as MRENCLAVE (the unique enclave identity) and MRSIGNER (the code signer's identity, platform). By dynamically generating keys at runtime approach mitigates risks associated with key storage and enhances security by ensuring that keys are tightly bound to the specific platform and enclave, further protecting sensitive data from unauthorized access.
4.3.9. Intel SGX provides memory isolation through Enclave Page Cache (EPC), which encrypts the memory allocated to enclaves. This ensures that data, including cryptographic keys, is shielded from unauthorized access, even by privileged processes or the operating system. The encrypted enclave memory is accessible only to the code within the enclave, preventing untrusted code or external processes from reading or modifying sensitive information. This isolation is enforced by hardware-level protections, ensuring that any data stored in EPC remains confidential and secure against potential attacks or leaks.
5.1. EMT shall be deemed to be electronic money, according to MiCAR. The Company has no right to make an offer to the public or seek admission to trading of EMT, as the Company is not authorised as a credit institution or an electronic money institution. However, the Company may provide the Services related to EMT within the services of exchange of EMT to fiat funds and exchange of fiat funds to EMT.
5.2. For the EMT, the safeguarding principles are as follows:
5.2.1. EMT received by the Company and belonging to the Client are transferred to separate wallets opened in the Client's name and provided by the Company or a third-party service provider.
5.2.2. Any third-party service provider must be a crypto-asset service provider licensed in the EU under the MiCAR.
5.2.3. Technical requirements for the third-party service provider to hold EMT:
5.2.3.1. Any third-party service provider responsible for holding Electronic Money Tokens (EMT) on behalf of the Company must meet stringent technical, security, and regulatory compliance requirements to ensure the integrity, segregation, and protection of client assets.
5.2.3.2. The third-party service provider must implement secure infrastructure that guarantees complete segregation of client EMTs from its own operational funds, ensuring that client assets are identifiable, protected, and recoverable in any event, including insolvency.
5.2.3.3. Robust security controls must be in place, including multi-layer encryption, hardware security modules (HSMs) for key management, and end-to-end encryption of EMT transactions. The provider must also enforce multi-factor authentication (MFA), strict role-based access control (RBAC), and continuous monitoring of access logs to detect unauthorized transactions.
5.2.3.4. To mitigate operational risks, the service provider must have a business continuity and disaster recovery (BCDR) plan with redundant infrastructure, real-time transaction monitoring, and automated anomaly detection.
5.2.3.5. Any third-party service provider engaged by the Company must undergo initial and periodic due diligence assessments, including penetration testing, security audits, and regulatory compliance verification. The provider must offer Service Level Agreements (SLAs) ensuring minimal downtime, high availability, and real-time support to maintain seamless operations.
6.1. The Company shall, by the end of the business day following the day on which fiat funds belonging to the Clients were received, place those fiat funds with a credit institution.
6.2. The Company safeguards fiat funds belonging to the Clients through segregation in the appropriately designated account(s) with a credit institution. These accounts are in the name of the Company but are safeguarding accounts and the bank shall acknowledge that it has no interest or right over the funds in the account(s), including the right of set-off for changes or otherwise.
6.3. The Company reviews the credit institution or institutions chosen to hold the Client's fiat funds at least yearly. The factors the Company is considering when selecting the credit institutions to deposit Clients' fiat funds are as follows:
6.3.1. Regulatory compliance - ensuring the credit institution is licensed and regulated by relevant authorities.
6.3.2. Credit ratings and reputation - the Company assesses the financial stability of the chosen credit institution and the reputation and trustworthiness of the credit institution, including compliance with regulations and financial standards.
6.3.3. Financial Health of the credit institution - to ensure capital adequacy, liquidity and solvency.
6.3.4. Operational efficiency and technology.
6.3.5. Risk management practices.
6.3.6. Customer service and relationship.
6.4. There may be situations when the Company is unable to identify the Client entitled to the funds it has received. Despite this, the Company is still able to identify that these unallocated fiat funds have been received from a Client in relation to the Services. This could happen where funds are received, e.g., with an incorrect unique identifier. These funds are still safeguarded.
6.5. Pending allocation of the funds to an individual Client, the Company will record these funds in its books and records as 'unallocated Client funds' and consider whether it would be appropriate to return the money to the person who sent it or to the source from where it was received.
7.1. The amount of fiat funds belonging to the Clients and the amount of funds standing on the safeguarding account(s) is reconciled at the end of each day to ensure that it tallies with the sum of the amount of fiat funds in the books of the Company.
7.2. Use of third parties for electronic money token (EMT) custody:
7.2.1. The Company does not use third-party service providers such as Paymix to hold Client electronic money tokens (EMTs).
7.2.2. USDC or any other electronic money token (EMT) transferred by a Client is not pooled with Company assets and is only used for conversion upon request.
8.1. Since the Company does not provide itself payment services associated with the crypto-asset services (i.e., payment services are provided by a third-party service provider, Finance Incorporated Limited, operating under the brand name Paymix), the Company, in the Client agreements and (or) Terms & Conditions of the Services and on Company's website, provide the information on all of the following: (i) the nature and terms and conditions of payment services related to the crypto-asset services, including references to the Applicable Law and to the rights of clients; and (ii) he details (legal entity name, address, identifier, contact details, supervisory authority) of the payment service provider that provides the payment services.
8.2. The Clients are informed in clear, concise and non-technical language about the key aspects of the Company's systems and policies and procedures to comply with the requirements of safekeeping of Clients' assets as stipulated in this Description. Such information is provided in the Client agreements and (or) Terms & Conditions of the Services and on the Company's website.
9.1. The Description has been reviewed and approved by the CEO.
9.2. The Description may be subject to changes as required under the Applicable Law. If the Description is amended, the latest applicable version of the Description is always available on the Company's Website.
We are using Cookies! For more information please view the Cookie Policy.
© 2025 | All Rights Reserved
LT