Staff Console for a Japanese Crypto Exchange
Designed and built a clickable operations console for an FSA-registered crypto-asset exchange in Tokyo: a dashboard of volume, flows and cold storage ratio, one inbox for every four-eyes request, a withdrawals queue that shows why each transfer was held, and hot and cold wallet controls that keep customer assets above the 95% cold storage floor.
Most of our work is under NDA. Per agreement, we can share the work but not the company details - all names and identifying information shown here have been changed.
Dashboard, approvals inbox, withdrawals queue with its transfer panel, wallet overview and cold transfer detail. Each of the 8 demo cold transfers opens its own detail page.
Cold ratio is shown against the 95% legal floor and Asagiri's 98% target for every asset. A cold transfer request shows the projected ratio and is refused if it would fall under 95%.
Withdrawal releases, cold transfers, freezes, suspensions, fee schedules, ledger adjustments, halts and role changes each name the rule that needs a second person, such as 2 approvers for withdrawals over ¥5,000,000.
23 withdrawals across 6 statuses, 14 approval requests, 8 cold transfers, 12 listed assets, 16 wallets, 11 staff users and 2 open incidents with 2 active suspensions.
Asagiri runs an order-book exchange, a sales desk and 2x margin trading for about 420,000 customers, and its operations grew out of scripts, a shared chat channel and spreadsheets. Withdrawals over the auto-approve limit waited in a chat thread, cold wallet top-ups were agreed in messages with no single record of who approved what, reconciliation was a daily spreadsheet one person understood, and suspending withdrawals for a halted chain took over an hour and four people.
Hakari is the one place staff watch the exchange and act on it. Every sensitive action goes to an approvals inbox where the requester can never approve their own request, held withdrawals show their risk checks and hold reasons, and the wallet screens keep the cold storage ratio, own-asset cover and signing quorum in view before any funds move.
A crypto-asset exchange in Japan is registered under the Payment Services Act, supervised by the FSA and bound by the JVCEA's self-regulatory rules. Customer assets, transfers and staff actions all carry rules, and each one has to be provable to inspectors and auditors.
Generally at least 95% of customer crypto-assets by value must sit in cold wallets, and for the part held hot the exchange must hold its own assets of the same type and amount. Customer JPY is held in trust, and segregated management is audited externally. Asagiri's own target is 98%.
The Act on Prevention of Transfer of Criminal Proceeds requires the travel rule for transfers to and from other exchanges, generally with no minimum amount. Unhosted wallets and providers without a travel rule regime need extra checks, and destinations are screened against Japan's sanctions lists and on-chain risk data.
Large withdrawals, cold transfers, freezes, halts, fee changes, suspension switches and role changes all need a second approver, and the requester can never approve their own request. Before Hakari these approvals lived in chat messages with no record of who agreed.
When a chain halts, withdrawals for that asset must stop and customers must be told quickly. FSA inspections and segregation audits took weeks of evidence gathering, because approvals, signatures and reconciliations were spread across tools.
Mapped 14 staff roles from operations analyst and AML officer to cold wallet signer and internal audit, 37 screens, 6 slide-over panels and the data model for customers, transfers, risk checks, travel rule messages, wallets, cold transfers, reconciliation runs, segregation snapshots and approval requests. Wrote down the rules the design follows: the Payment Services Act, JVCEA listing and unfair trading rules, cold storage segregation, the travel rule, the 2x retail leverage cap under the FIEA, sanctions screening and APPI masking of personal data.
Built 5 key screens on a production web3 dashboard kit: the dashboard with KPIs, volume by product, queues and hot and cold balances per asset, the approvals inbox with before and after, evidence and the matrix rule, the withdrawals queue with risk checks and travel rule data, the wallet overview with segregation, hot wallet forecast and suggested sweeps, and cold transfer detail with checks, approvals, signatures and ceremony notes. All actions run on local state.
Integrations with eKYC (such as TRUSTDOCK), sanctions screening (such as LSEG World-Check), on-chain risk (Chainalysis KYT or Elliptic), travel rule messaging (Sygna Bridge or TRUST), Fireblocks with Thales HSMs for cold keys, own blockchain nodes, JPY bank APIs, the customer money trust bank, trade surveillance and Zendesk. Staff single sign-on with a hardware security key, a 30-minute idle timeout, an append-only audit trail, and the remaining screens for customers and KYC, listings, markets, surveillance, incidents and regulatory reports.
Each approval request shows what will change, the requester's reason, the evidence and the rule from the approval matrix that required it. On a request the user raised, the buttons are replaced with "You requested this", and on a cold transfer the requester can neither approve nor sign.
The dashboard and wallet overview show the cold storage ratio against the 95% floor and the 98% target, with assets below target in amber and below the floor in red. A cold transfer request projects the ratio after the move and will not go under 95%.
Held withdrawals carry their reasons as chips, such as high address risk, a new destination under 24 hours or a travel rule name mismatch. Above the approver's ¥5,000,000 limit, approving asks for a second approver, and withdrawals for a suspended asset cannot be released.
A status strip shows each active suspension, such as ETH withdrawals suspended since 09:42, on every screen. Cold transfers move through requested, approved, signed, broadcast and confirmed, with each signer's device and time and the HSM signing ceremony notes on record.

Designed and built a clickable client dashboard for a Singapore staking provider serving funds, family offices and corporate treasuries: positions across six chains, daily rewards split by type with SGD and USD values at receipt, unbonding dates per chain, and an approvals inbox that applies each institution's policy before stake moves.

Designed and built a clickable tokenisation platform for a Vaduz token issuer registered under the TVTG: permissioned tokens for fund units, real estate SPV shares and private credit notes, with every on-chain operation approved under a signing policy, every investor transfer checked before it settles, and the token ledger kept in step with the legal register.
Enterprise Software Engineering - Human + AI
Contact Us
© 2026 - Copyright. All Rights reserved Oceanlab
Location
Global Headquarters
21 Merchant Road, 3rd Floor, Singapore 058267
Main corporate office and leadership operations
North America Office
548 Market Street, PMB 12345, San Francisco, CA 94104
Client operations and business development
India Office
402 Shivalik Shilp II, SG Highway, Ahmedabad 380015
Engineering and delivery center
Enterprise Software Engineering - Human + AI
Contact Us
Locations
Global Headquarters
21 Merchant Road, 3rd Floor, Singapore 058267
Main corporate office and leadership operations
North America Office
548 Market Street, PMB 12345, San Francisco, CA 94104
Client operations and business development
India Office
402 Shivalik Shilp II, SG Highway, Ahmedabad 380015
Engineering and delivery center
© 2026 - Copyright. All Rights reserved Oceanlab