For a licensed exchange, "whoever controls the keys controls the assets." Under Malaysia's RMO DAX framework, Securities Commission (SC) imposes strict requirements for custody of client crypto assets: segregation, hot/cold wallet tiering, multisig or threshold signatures, auditable key governance, strict deposit/withdrawal approvals, insider controls, periodic audits, and reserves. This article explains custody architecture for licensed Malaysian exchanges, from SC requirements, hot/warm/cold wallet layering, MPC and multisig selection, HSM and air-gapped signing, key lifecycle governance, deposit/withdrawal approvals, insider controls, proof of reserves, third-party custody, and insurance, to the SoonTech implementation, helping platforms turn "asset safety" from a slogan into auditable process and engineering capability.

1. SC Requirements for Client Asset Custody

SC's RMO DAX guidelines and on-site inspections require six core things for crypto custody. These six items are not isolated clauses but form a closed loop of "client asset integrity"—from the legal foundation of segregation, through the technical means of key control, to operational process, audit evidence, and financial backstops, with any gap undermining the rest. First, client assets must be segregated from platform proprietary assets—separate accounts, separate custody, no misuse or lending. Second, the vast majority of client assets must be in cold storage, with hot wallets holding only what is needed for day-to-day operations. Third, private keys must use multisignature or threshold signature (MPC) schemes so no single person controls a complete key. Fourth, the platform must maintain full key generation, storage, use, rotation, and destruction procedures with audit records. Fifth, all large withdrawals must require multi-level approval and whitelisted addresses. Sixth, the platform must periodically demonstrate client asset integrity to SC and auditors, typically via proof of reserves, client liability lists, and on-chain address ownership proofs. These are not suggestions but licensing conditions; SC on-site inspections verify policy documents, operation records, and on-chain evidence item by item, and major gaps can lead to penalties or revocation. Beyond SC, NACSA and BNM also review fund flows and address screening from an AML perspective.

2. Hot/Warm/Cold Wallet Tiering

Mature exchanges use a three-tier wallet architecture. Cold wallets are fully offline, with keys never touching the internet, typically protected by HSMs, air-gapped machines, or metal seed shards; cold wallets hold 90–98% or more of long-dated client assets and platform reserves, and signing requires multiple people on-site with large, low-frequency transactions. Warm wallets are semi-online, running on controlled servers with key shards managed by HSMs or MPC nodes, used for daily withdrawal signing and on-chain broadcast, holding days to weeks of operating balances with automated but risk-limited flows. Hot wallets are real-time online, directly connected to deposit/withdrawal systems, holding only the minimum needed for same-day business (typically no more than 0.5–2% of total client assets); they automatically sweep to warm wallets on anomalies or security events. Transfers between tiers must go through an independent approval system; cold-to-warm top-ups, warm-to-hot refills, and hot-to-warm sweeps must all be documented in runbooks. The core logic is physical separation of convenience and security: more online means more convenient but riskier, more offline means safer but more operationally costly.

3. MPC Threshold Signatures vs. Multisig

For signing schemes, traditional multisig and MPC threshold signatures each have their place. Multisig is on-chain: a transaction needs M of N keys to sign, such as 3-of-5 or 5-of-9, with all signatures visible on-chain. It is transparent but less private, and multisig contracts and address formats vary across chains. MPC threshold signing splits the private key off-chain into shards held by different parties; at signing time, the parties run a cryptographic protocol to produce a single valid signature that looks ordinary on-chain. MPC supports arbitrary thresholds, shard rotation, multiple algorithms (ECDSA, Ed25519), and is naturally cross-chain. Modern exchanges typically use MPC as primary with multisig as backup: warm wallets and institutional custody favor MPC for flexibility, rotation, and cross-chain consistency; cold wallets and certain high-security contexts retain multisig or hardware multisig for on-chain verifiability without vendor dependence. Either way, the key principles are that shards never coexist, signing follows approval, and actions are auditable, while avoiding single-vendor lock-in.

4. HSM, Air-Gap, and Offline Signing

Cold storage strength depends on the key generation and signing environment. HSMs are FIPS 140-2/3 or Common Criteria certified devices that generate keys and perform signing inside the chip, with the private key never leaving the device. HSMs can require multiple people and factors to trigger signing and produce tamper-evident audit logs. Air-gapped signing keeps signing machines physically isolated from networks, passing unsigned transactions via QR codes or dedicated media and returning signed transactions for broadcast; this strongly resists remote attacks but is slower, suited for very large cold-wallet transfers. Modern designs combine HSMs and MPC: each MPC node runs on an HSM-equipped server or device, with shards generated and used inside the HSM so a compromised server cannot exfiltrate them; cold wallets further place some shards on air-gapped devices or in geographically distributed vaults. Regardless of the combination, signing environments must be tightly controlled—no unrelated software, no internet or USB access, periodic firmware integrity checks, and multi-person recorded signing sessions.

5. Key Lifecycle Governance

Keys are not "generate once and done"—they have a full lifecycle. Generation must occur in a secure environment (HSM, air-gapped device, or MPC cluster) with quality randomness, multi-party witness, and records; seeds or shards are stored in tamper-evident envelopes or metal plates across separate locations and people. Use requires request, approval, and execution; large transactions need multi-party approval with business justification; signing happens in controlled environments with audit logs. Rotation periodically (typically annually or biannually) rotates shards or full keys, moving assets from old to new addresses; any key-holder departure, role change, or suspected compromise triggers immediate rotation. Backup and recovery require geographically redundant shard backups and tested recovery procedures so a regional disaster cannot lose assets. Destruction securely wipes or physically destroys unused keys with witnesses and records. Each stage has named owners, runbooks, and audit evidence, and SC on-site inspections sample these records heavily.

6. Deposits, Withdrawals, and Address Whitelisting

Deposit/withdrawal is the front line. On the deposit side, the platform generates unique addresses per user, with keys managed by custody; deposits credit after a defined confirmation count, and source addresses are screened by chain analytics, with high-risk deposits (mixers, darknet, sanctions) delayed or source-reviewed. Withdrawals pass multiple layers: user authentication (password plus SMS/email/TOTP/hardware key), large amounts requiring whitelisted addresses and anti-phishing codes; risk control scoring address risk, behavior, device fingerprint, and 24-hour limits; custody signing with automatic signing for small hot-wallet amounts, semi-automated multisig for medium warm-wallet amounts, and manual multisig for large cold-wallet amounts. No single operations or support engineer can directly initiate signing requests. Address whitelisting is critical: newly added user withdrawal addresses require a 24-hour cooling period and email confirmation; internal cold/warm addresses are themselves whitelisted so a compromised signing node cannot send to arbitrary addresses. Zero-confirmation or unconfirmed crediting must be used cautiously, especially on chains with RBF, to avoid double spends.

7. Insider Fraud and Segregation of Duties

Historically, exchanges have lost client assets more often to insiders or error than to external hackers. Custody requires strict segregation of duties. Key holders, approvers, executors, and auditors must be in separate roles: someone with cold-wallet shards cannot initiate withdrawals, operations cannot approve large transfers, and support/risk cannot touch keys. All internal actions go through ticketing and bastion hosts with no "out-of-band" command-line access; database, server, and HSM permissions use least privilege with just-in-time grant and revocation. Sensitive operations require two or more people with screen recording, independently reviewed afterward. Mandatory leave, job rotation, and background checks reduce the risk of a single long-tenured employee accumulating dangerous authority. Monitoring catches anomalous logins, IPs, bulk user data queries, and whitelist changes. Whistleblower channels and investigation procedures protect reporters. Technology and process should lock together so no single individual can independently move client assets.

8. Proof of Reserves and Client Liability Proof

Whether the platform holds 100% of client assets cannot be self-asserted; it must be verifiable. Proof of Reserves (PoR) has become the industry standard: on a monthly or quarterly snapshot, an independent auditor or open-source tool verifies three things. On-chain reserves—the platform's stated cold/warm/hot addresses hold the stated balances at snapshot time, with control proven by signing a challenge or moving a tiny amount. Client liabilities—all user balances at the same time, typically arranged in a Merkle tree so each user can independently verify their balance is included. Reserves cover liabilities—total assets equal or exceed total client liabilities, with any difference covered by platform capital. PoR must cover every listed asset and exclude proprietary accounts, market-maker loans, and unconfirmed deposits that could inflate reserves. Assets in DeFi, third-party custody, or lending require additional verifiable balance proof and risk disclosure. Beyond periodic PoR, platforms can do real-time or near-real-time on-chain monitoring and Merkle updates so users can verify at any time. SC does not mandate one PoR format but clearly requires it be auditable and verifiable, with underlying addresses, liability lists, and auditor reports available in inspections. In engineering terms, platforms should watch for common pitfalls: snapshot user balances and on-chain block heights must align exactly to avoid double-spend or reorg exploits; the Merkle tree should prevent platforms from understating total liabilities through negative-balance accounts, typically using range proofs or zk-proofs to constrain each leaf; PoR must cover every listed asset including stablecoins, platform tokens, LSTs, and RWAs, not just BTC and ETH; and assets parked in DeFi contracts, flash-loan pools, or market-maker accounts must net out lent collateral so "available" and "pledged" are not conflated.

9. Third-Party and Qualified Custodians

Some platforms place all or part of client assets with third-party qualified custodians to reduce self-custody burden. Third-party custody is professional, independent, and auditable, often with trust or custody licenses, SOC 2, ISO 27001, and crime insurance; the trade-off is added cost, dependence on external availability, and less product flexibility. Due diligence should cover legal entity and licenses, key architecture (MPC/multisig/HSM), asset segregation, bankruptcy remoteness, insurance coverage, audit reports, SLAs and indemnification, technical integration, and incident history. SC permits third-party custody but the platform remains ultimately responsible for client assets; contracts must clearly define liability, compensation, audit rights, and exit migration. Hybrid arrangements are common: most client assets with a third-party cold custodian, daily operating balances in self-hosted warm/hot wallets; institutional clients may use dedicated or third-party custody fully segregated from platform operations.

10. Insurance, Reserves, and Loss Allocation

Even with strong technology and process, risk is nonzero, so insurance and reserves are the last line of defense. Insurance typically layers crime insurance covering internal/external theft, forgery, and robbery; digital asset custody/specie insurance covering cold-key compromise and physical loss; cyber liability covering hacking, business interruption, and data breach; and D&O covering management decisions. Limits should match cold-wallet holdings, daily volume, and regulatory expectations, with policy terms explicit about coverage (e.g., whether DeFi hacks, insider collusion, and smart-contract losses are included). Platforms should also maintain risk reserves funded from a share of trading fees, liquidation surpluses, and dedicated capital, used when insurance denies or limits coverage; reserve addresses, balances, and usage rules should be public and audited. Legally, customer agreements must allocate losses across platform hacks, user account takeovers, chain anomalies, and custodian failures with clear claims procedures rather than blanket "platform not liable" clauses. SC cares whether platforms have the financial and procedural capacity to cover foreseeable operational risks. During insurance negotiation, platforms should focus on exclusions (whether war, government seizure, insider collusion, and smart-contract bugs are covered), waiting and investigation periods, claims triggers, sub-limits and per-event caps, and reinsurance arrangements. Many policies cover only "stolen keys" but not "insider collusion" or "DeFi contract exploits"—precisely the most frequent loss categories; if coverage mismatches real risk, the insurance is effectively decorative. Risk reserve size should also be reassessed dynamically based on cold-wallet holdings, daily volume, platform leverage, and historical loss rates, with a common guideline of at least 6–12 months of foreseeable operational losses, held in addresses strictly segregated from platform operating wallets.

11. On-Chain Monitoring and Address Risk

Custody is not just safekeeping—it also ensures on-chain flows are not used for money laundering, sanctions evasion, or terrorist financing. Platforms deploy chain analytics (Chainalysis, TRM, Elliptic, or in-house) to score every deposit and withdrawal in real time: checking addresses against OFAC, UN, EU, and Malaysian sanctions lists; identifying flows to and from mixers, darknet markets, scam platforms, ransomware, and sanctioned mixers; and triggering delays, freezes, or manual review for high-risk transactions. Internal wallets are also monitored: cold-to-warm top-ups, warm wallet on-chain movements, and hot-wallet sweeps must match approval tickets, with unauthorized internal transfers triggering immediate alerts. New listings require on-chain risk assessment to confirm whether the chain supports address blacklisting, freezing, and upgrades, avoiding privacy coins or mixer tokens that cannot satisfy compliance. On-chain monitoring integrates with KYC, trading risk, and support tickets in a case-management workflow with data retention and STR filing as required by SC and NACSA.

12. Organization, People, and Culture

Strong technology still requires people to run it. Organizational safeguards include an independent security and custody committee with CISO, CRO, compliance, technology, and independent directors overseeing key policy, large transfers, incidents, and insurance; a 24/7 SOC monitoring chain, systems, and personnel; explicit incident response playbooks for theft, mistaken transfers, key loss, insider fraud, and cloud outages; regular security training and phishing simulations, especially for support, operations, and finance; and liaison channels with local police, SC, BNM, and peer exchange security teams. Culturally, "client asset safety is a non-negotiable bottom line" must be shared from executives to engineers, with resistance to shortcuts around approvals, testing, or just-in-time access for the sake of speed or convenience. Many exchange failures stem not from inadequate technology but from process bypassed by people. SC inspections pay close attention to tone at the top—whether management genuinely treats risk and compliance as priorities.

13. SoonTech Custody and MPC Wallet Solution

SoonTech delivers a complete crypto custody and MPC wallet infrastructure for Malaysian licensed exchanges. The wallet layer uses cold/warm/hot tiering with cold wallets supporting HSM, air-gap, and combined multisig/MPC; warm wallets auto-sign via MPC node clusters; hot wallets hold minimum balances with real-time sweeping. The MPC implementation uses industry-standard threshold signature schemes (TSS) across ECDSA, Ed25519, and Schnorr, with shards distributed across regions and cloud providers per client policy, supporting shard rotation and emergency reconstruction while minimizing vendor lock-in. The approval engine supports automatic, semi-automated, and manual flows by amount, asset, and user tier, with address whitelisting, cooling periods, risk scoring, and anti-phishing codes; every action flows through ticketing and bastion hosts with full audit trails. Proof-of-reserves modules provide Merkle liability proofs, on-chain address self-attestation, and audit exports. On-chain compliance integrates major analytics vendors across sanctions, mixers, darknet, and scam labels. The platform also integrates with third-party qualified custodians for hybrid and institutional independent custody. SoonTech's team supports RMO DAX licensing, custody architecture review, audit coordination, and incident drills. In engineering terms, custody is decoupled from matching, clearing, risk, and finance through explicit API boundaries and an event bus: every deposit, withdrawal, top-up, and sweep produces an immutable event log, and the daily reconciliation system matches on-chain transactions, user ledgers, bank accounts, and custody balances to achieve three-way consistency. Operations run multi-AZ with cross-region DR and geographically distributed key shards so neither a data-center nor cloud-provider failure compromises asset safety or withdrawal continuity. For Malaysian localization, the platform supports a Malay interface, MYR fiat rails, local bank integration, and BNM/NACSA reporting templates, reducing localization cost for licensed platforms.

14. Enterprise Implementation Recommendations

For platforms applying for or holding a Malaysian RMO DAX license, build custody in five steps. Start with asset inventory and risk assessment: list all assets, current storage, key holders, internal processes, and external dependencies to identify top risks. Next, restructure into cold/warm/hot tiers, moving 95%+ of assets to cold storage with minimum hot-wallet balances, real-time sweeps, and anomaly monitoring. Third, introduce MPC or multisig with HSMs and key lifecycle governance (generation, use, rotation, backup, destruction), with segregation of duties and dual approvals. Fourth, build proof of reserves, on-chain monitoring, audit logs, and risk reserves so client asset safety is externally demonstrable. Fifth, run regular security drills, penetration tests, DR failovers, insider-fraud exercises, and incident-response drills, feeding results into continuous improvement. Compliance, technology, legal, internal audit, and executives must all be involved—this cannot be left to tech alone. Custody is not a one-time project but an ongoing operational capability.

FAQ

Q1: What cold wallet percentage is compliant?

A: SC does not specify a number but requires that "the majority of client assets be in cold storage." Industry practice is 90–98%+ cold, with hot wallets no more than 1–2%. Set the ratio based on daily withdrawals, holiday peaks, and risk appetite, and document it in internal policy.

Q2: Is MPC or multisig safer?

A: Neither is categorically safer; they differ in cryptographic assumptions, operating models, and failure modes. Multisig is on-chain transparent and simple; MPC is flexible, cross-chain, and more private. Large platforms typically combine them—MPC for warm wallets and institutional custody, multisig for cold or high-security contexts.

Q3: How often should proof of reserves be done?

A: Industry standard is monthly or quarterly by an independent auditor; some platforms offer near-real-time Merkle proofs so users can verify anytime. Frequency depends on regulation, user expectations, and audit cost, but at least annually is a floor.

Q4: If assets are with a third-party custodian, do we still need our own security?

A: Yes. SC makes the platform ultimately responsible. Third-party custody reduces risk but does not transfer responsibility; platforms still need due diligence, contract review, audit oversight, emergency exit, and hybrid custody arrangements.

Q5: What insider risks matter most?

A: A single person holding full keys, a single person initiating and approving large transfers, operations bypassing systems to touch databases or servers, departing employees retaining access, and long-tenured staff never taking leave. Segregation of duties, dual approval, least privilege, mandatory leave, and audit monitoring are the key controls.

Q6: Is insurance mandatory?

A: SC does not mandate insurance for every platform but assesses whether platforms can cover foreseeable losses. For licensed exchanges, crime and custody-specific insurance are industry standard; limits should match cold-wallet size with clear coverage and exclusions.

Conclusion

Crypto custody is a licensed exchange's lifeline: it is not purely a technical problem but a combined system of regulatory compliance, engineering security, people governance, audit transparency, and financial arrangements. Malaysia's SC requirements align with global mainstream regulation—client asset segregation, majority cold storage, multi-party key control, auditability and verifiability, and insurance and reserve backstops. Platforms that build these capabilities early gain advantages in licensing, on-site inspections, institutional onboarding, and long-term user trust. Clients hand over keys, and in doing so hand over trust; platforms must repay that trust with engineering, process, and institutional discipline.

🌐 Build secure and scalable Web3 platforms with SoonTech.

Explore our solutions for White Label Crypto Exchanges, Prediction Markets, MPC Wallets, Matching Engines, Liquidity Integration, and Compliance.